Recurring handling through Sky API for Raiser's Edge NXT: Current API Support Question

Hello,

We currently are scoping out an integration that would allow importing a recurring donation from a separate system into Raiser's Edge NXT; aka, an "is_manual = 1", "payments.payment_method = Other" gift record.

We have a couple of different types of recurring records in our external system:

- "Close-ended recurring" - A recurring donation with an end date. Aka, you give on a
certain day, with a set frequency (e.g. weekly), until X date.
- "Open-ended recurring" - A recurring donation with no end date. Aka, you give on a certain day, with a set frequency (e.g. weekly), until the end of time.

We saw that within the Gift definition that there are several "gift" types that relate to recurring:
- Pledge
- PledgePayment
- PledgeWriteOff
- RecurringGift
- RecurringGiftPayment

Out of curiosity, what is the current support for manual recurring entries entered in through the API? I see the documentation for type explicitly states "at this time, you can only add gifts with the Donation, Other, GiftInKind, RecurringGift, and RecurringGiftPayment type".

For a similar integration with eTapestry, we use "Recurring Gifts" + "Recurring Gift Schedules" for open-ended recurring, and "Pledge" + "PledgePayments" for close-ended recurring; however, if we were to try something similar with Raiser's Edge NXT it appears right now the API does not support pledge record creation. (at least according to the documentation)

I'm also not quite sure if that's even the proper way to represent recurring in Raiser's Edge NXT, since it is a different service from eTapestry; or if there's a better way to represent both close-ended and open-ended recurring in RE NXT.

Thank you!

Comments

  • Anthony Gallo
    Anthony Gallo Blackbaud Employee
    Tenth Anniversary Kudos 5 First Reply Name Dropper

    @Qgiv Product
    I am having a hard time finding the question in the first part of this post, all of what you have there sounds correct. I think the answer to most of this is that if you enter a recurring gift as a legacy/is_manual gift, then any of the payment applications will be fine. If the gift is an NXT RG, the Blackbaud is the system of record and there is no way to allow for external payment applications, BB will charge those automatically.

    For pledges, these gifts can have any payment application as well for the installments.

    The open ended and close ended parts of this post seem to be irrelevant from our standpoint since we either need to charge the gift or we don't. If we don't, then you will use the API for that payment application or they can do so from within the system manually.

  • @Anthony Gallo ok, got it, thank you for the clarification! I think this helps us forward right now. We're going to investigate having recurring with an end date and recurring without an end date be created within Raiser's Edge NXT as Recurring Gifts + Recurring Gift Schedules, and just ignore pledges for the moment.

    We do have a concept of invoices within our system, and those may be better-equipped to use the Pledge + PledgePayment gift types, but since the current non-preview endpoint only supports recurring record types we'll likely just focus on the recurring object types for now.

  • Anthony Gallo
    Anthony Gallo Blackbaud Employee
    Tenth Anniversary Kudos 5 First Reply Name Dropper

    This post touched on pledges so I wanted to come back to throw and update. We can now accept non full pledge payments and payment to multiple pledges via the API.

  • @Anthony Gallo This is great news (I'm late to the party)! Can you tell me, is this only for Gift V2 or is this also available on V1? If only V2, is there a planned date for parity with V1 (missing a bunch of fields, including Gift Sub Type, Lookup ID…..). Will V2 replace V1? Seems odd to ask, but they are quite different.

  • Anthony Gallo
    Anthony Gallo Blackbaud Employee
    Tenth Anniversary Kudos 5 First Reply Name Dropper

    @William da Silva It is currently with just gift v2. We have plans to move everything over to the newer endpoint without any breaking changes but that is not something we have firm commitments on as far as dates go quite yet.

  • @Anthony Gallo
    I have some questions,

    if I create a Recurring Gift via API as an is_manual gift, how should I configure these fields in the payments section?:

    'account_token'
    'bbps_configuration_id'

    and, when I create his respective Recurring Gift Payment, do I need to set it to is_manual too? and how sould I need to setup these payments section fields?


    'checkout_transaction_id'
    'bbps_transaction_id',

    I was thinking I only need to add payment_method field to ‘payments’ section, but I don't know if this is the correct approach.
    Or if you can please tell me which fields (and its values) to include in the Recurring Gift, and Recurring Gift Payment ‘payments’ section, I will appreciate it a lot
    thank you.

  • Anthony Gallo
    Anthony Gallo Blackbaud Employee
    Tenth Anniversary Kudos 5 First Reply Name Dropper

    @Giovanni Trejo Abasolo

    Account Token, BBPS Configuration ID, and both transaction IDs are not required for is_manual = true.
    Account token and configuration ID are required for Automated Recurring Gifts. If the payment is processed through checkout or BBPS, then the transaction IDs and configuration ID can be included in the payment to allow refund processing through web view. If the payment is not processed through Blackbaud then the transaction IDs should be left null.


    is_manual is only valid for Recurring Gifts (non automated) and Pledge, not for payments.
    We now have capture for manual RGs without account tokens in the Convert dialog, the gift will be automatable assuming it has a valid schedule.


  • @Anthony Gallo thanks a lot for your answer,
    so, in this case, in the Recurring Gift payment, do I set these fields this way? (I'm not processing the payments, I only send the data to RE NXT for reporting purposes).
    is_manual = false,

    account_token = null,

    bbps_configuration_id = null,

    checkout_transaction_id = null,

    bbps_transaction_id = null

    Since the Gift documentation in the bbps_transaction_id field mentions this:
    “The bbps transaction ID. Must parse to a valid, non-empty GUID. Only applies to payment methods of CreditCard and DirectDebit. When adding a recurring gift payment, either a bbps_transaction_id or checkout_transaction_id must be provided for each payments object.”

    I don't know how to set up these fields, thank you.


  • @Anthony Gallo
    I'm having an issue with the Recurring Gift, I set is_manual =true, account_token = null, and bbps_configuration_id = null, but in the batch in the Gift Management, this error appears:

    https://res.cloudinary.com/dxfcit5dh/image/upload/v1689272522/Screenshot_2023-07-13_at_12.16.46_p.m._lvmoxz.png

    https://res.cloudinary.com/dxfcit5dh/image/upload/v1689272685/Screenshot_2023-07-13_at_12.24.33_p.m._zrbxf3.png

    I attach the data that I'm sending to create the Recurring Gift, thank you.

  • Anthony Gallo
    Anthony Gallo Blackbaud Employee
    Tenth Anniversary Kudos 5 First Reply Name Dropper

    @Giovanni Trejo Abasolo
    Gifts marked as “is_manual” do not go thru batch. They are database view only gifts, non automated recurring. This flag will create a gift directly.

  • @Anthony Gallo
    thanks a lot for your explanation,
    I was able to send the Recurring Gift, now, I send the Recurring Gift Payment in a batch, this is a correct approach to handle this? the created batch has no problems with the Recurring Gift Payment data, but the batch still needs to be approved.

    also, for the One Time/Donation flow, I send the Donation in a batch for approval, is a correct aproach? or the One Time/Donation transaction, do not go thru batch?
    Recurring Gifts, Recurring Gift Payments, and One Time/Donation data is sending to RE NXT only for reporting purpouse,

    thanks.

  • Anthony Gallo
    Anthony Gallo Blackbaud Employee
    Tenth Anniversary Kudos 5 First Reply Name Dropper

    @Giovanni Trejo Abasolo
    There really is not going to be any automated workflows for these manual recurring gifts. The organization will have a process in place to handle those and batch/web view will not be able to be involved. We will be eventually moving off the non recurring gifts down the road and focusing on the web view automated kind.

    Payments can be applied to these gifts but they again will not come thru batch.

Categories