Direct Debit options in NXT

Faith Murray

Question: how much flexibility does NXT provide in batching recurring gifts?

• Can you set a filter to only autoprocess credit cards and not process direct debits, for example?
• Can a recurring gift in NXT still be batched and processed in database view?
• Does Portal support direct debit transactions if a donor wants to switch payment info?

Soliciting feedback as I try to keep up to date with how NXT develops, so I can determine when/if we can switch over to NXT recurring gifts. We process direct debits directly through our bank right now, with no processing fees. If we ever switch over to NXT recurring gifts, I would like to be able to continue processing direct debits in database view manual batching. It would be easy enough to only convert credit card gifts to NXT and leave the direct debits in DB, but my concern is for donors who switch from credit card to direct debit at a later date.

What I would like to see is that donors can switch to direct debit in Portal, but I can tell NXT not to process direct debits, and then we pull the direct debits in database batching. Is this doable presently?

Dan Snyder

@Faith Murray Good questions. The only one that I know for sure is point 2. You cannot move an NXT batch to database view and process it there. The NXT batch only appears in database view once it has been committed in NXT.

I am not sure of the other settings around direct debit, but would suspect there is not a way to do that.

One thing to look out for that has impacted some of our processes is the gift date added. No matter when you commit the batch, the gift date added value will match the gift date. So if you have a process that looks for gifts entered yesterday or last week, it can easily miss gifts that were made in NXT, but not processed on the same date. I have added an idea to have this changed.

Alex Wong

@Dan Snyder
One thing to look out for that has impacted some of our processes is the gift date added. No matter when you commit the batch, the gift date added value will match the gift date. So if you have a process that looks for gifts entered yesterday or last week, it can easily miss gifts that were made in NXT, but not processed on the same date. I have added an idea to have this changed.

Oh man that one sucks, particular when you need to do Dailiy Gift Digest/Report. These gifts will always get missed. So for a workaround, i have done a webhook on gift creation, and if it is from NXT web batch, I will “recreate” the gift record and delete the gift record created by the “approval” of the web gift batch.

Emmet O'Conlon

@Faith Murray
We have some issues with the NXT donation forms too. We have separate forms for PayPal and Venmo since the donor cover does not work with them right now.

I do not know if it's feasible, but you could maintain a separate OLX form for direct debit donations to maintain control over them. Otherwise, the web view donation forms take complete control, AFAIK.

Emmet O'Conlon

@Dan Snyder Added my vote. Thanks for LMK!

Faith Murray

Sounds like it's an all-or-nothing feature then? I appreciate all the input! @Dan Snyder I also added my vote as well!

Austen Brown

@Faith Murray - The only way to control which RGs are apart of automatic processing is if you're the one promoting them from Database View to Web View. If you were to move forward with collecting RGs through an NXT donation form, I recommend only offering credit card as a payment option - in your case.

Shelley Bell

@Alex Wong
Can you give a little more detail on your work-around process? Thanks!

Alex Wong

@Shelley Bell
The workaround is to create the gift as it is “created” by NXT web batch commit and delete the gift created by the web batch commit. Confusing? here's the details

• Use SKY API to register a webhook on gift added
  • there's documentation on doing this
  • with this webhook, the flow is called everytime a gift is created, with the gift system id
• Use the gift system id to call the Get Gift to get info on the gift
• Condition to check if the gift was created by web batch
  • if no, do nothing
  • if yes
    • get all custom fields of this gift
    • create a new gift using api providing the same info as the gift created by the web batch
      • this is also when I would apply my org's gift entry processing SOP (reference needs to be in a certain character formatting), campaign coding, custom fields, etc
    • recreate all custom fields on the new gift
    • delete the old gift

old gift automatically gone (that has the “bad” gift date added info) and the new gift is created with the correct gift date added info (today, day of batch commit).

Alex Wong

@Alex Wong:

@Shelley Bell
The workaround is to create the gift as it is “created” by NXT web batch commit and delete the gift created by the web batch commit. Confusing? here's the details

• Use SKY API to register a webhook on gift added
  • there's documentation on doing this
  • with this webhook, the flow is called everytime a gift is created, with the gift system id
• Use the gift system id to call the Get Gift to get info on the gift
• Condition to check if the gift was created by web batch
  • if no, do nothing
  • if yes
    • get all custom fields of this gift
    • create a new gift using api providing the same info as the gift created by the web batch
      • this is also when I would apply my org's gift entry processing SOP (reference needs to be in a certain character formatting), campaign coding, custom fields, etc
    • recreate all custom fields on the new gift
    • delete the old gift

old gift automatically gone (that has the “bad” gift date added info) and the new gift is created with the correct gift date added info (today, day of batch commit).

Sorry, forgot this is not the Developer/SKY API forum. Unfortunately, my workaround is using custom coding, so may not be for everyone