Automatic Rebilling

This is a CSiDonate PLUS edition feature.

The information in this article only applies when using the BluePay payment service.

Overview

An overview of the automatic BluePay Rebilling workflow.

CSiDonate has the ability to automatically write gifts into iMIS when supported recurring plans are created via CSiDonate.

This process works via the BluePay Rebill POST account setting, which allows CSiDonate to receive notifications whenever a recurring payment is processed automatically in BluePay.

Requirements

The following requirements must be met for the automatic rebilling system to work:

• In the BluePay Account settings, the Rebill POST URL setting must be set to the correct CSiDonate endpoint. This is typically https://<SCHEDULER_URL>/Extensions/BluePayRebillImporter.aspx

• The iMIS app server (specifically, the ASI Scheduler website) must be able to receive and respond to HTTP requests from BluePay's data centers.

• The Rebill ID in BluePay must have a corresponding valid record in the Demo_Recurring_Gift table.

Process

Refer to the diagram above for a high level workflow overview. The following steps are a detailed list of what occurs during a notification:

• The recurring gift record is retrieved from the Demo_Recurring_Gift table using the Rebill ID, by querying for it in the RG_UNIQUE_ID column.

  • If the record was not found, an Audit Log record is written. Stop. 

• The Account ID, User ID, and Secret Key are checked with the associated Financial Account (in the RG_FIN_ACCT_ID column) against the incoming parameters from BluePay.

  • If the Financial Account is not set up correctly, or has mismatching information different than the BluePay request, an Audit Log record is written. Stop. 

• A request is made against the BluePay Transaction Lookup API to retrieve additional details for the transaction that occurred for this recurring payment.

  • If the request fails, an Audit Log record is written. Stop. 

• (2.9.1+) If the RG_PLEDGE_TRANS_NUM field in the Demo_Recurring_Gift table is populated:

  • If the associated transaction number has at least one open pledge installment with a balance greater than 0

    • Then the payment is applied as a pledge installment to the next available open pledge invoice with a non-zero, non-negative balance.

      

      Note: CSiDonate will write the amount that was charged via BluePay, even if this does not match the pledge installment amount. CSiDonate will over-pay and under-pay pledges.

      For over-payments made via BluePay, a credit can be applied to another pledge installment or another order in iMIS.

      For under-payments made via BluePay, CSiDonate will apply a subsequent payment to the same pledge installment until there is no remaining balance.

      It is important to ensure that the pledge installment amount matches the Rebilling Amount in BluePay to avoid under- or over-payments.

    • BluePay is notified of the successful transaction (to prevent future retries). Stop. 

  • If no open transaction was found, or CSiDonate was otherwise unable to write the next pledge installment, a standard gift will be written (see next line).

• A gift is written into iMIS using a combination of information from the transaction details from BluePay (Amount, payment information, status), and the Demo_Recurring_Gift record (Fund, DIstribution, Appeal, Campaign).

  • If the gift fails to write into iMIS, an Audit Log record is written. Stop. 

• BluePay is notified of the successful transaction (to prevent future retries). 

Retry Workflow

The Retry Workflow feature was added in CSiDonate 2.9.1.

If a recurring payment fails, an email will be sent to the administrative contact email listed in the System Settings. You can see a sample of what the e-mail looks like to the right.

This e-mail contains a special, one-time use link that will allow you to re-attempt the gift import. It is important that, if multiple staff members receive this e-mail, only one person clicks the link. While we have taken measures to ensure the link cannot be clicked twice, there is still a risk of inserting a duplicate gift, so please coordinate with your team.

When you receive this e-mail, it may be due to one of the following problems:

•  A SQL deadlock or timeout occurred

•  The CSiDonate API was not able to communicate with the SQL Server or iMIS

•  A gift processing error occurred in iMIS

We are unable to send this notification email during the following conditions:

•  Your firewall or network infrastructure has blocked BluePay's initial payment notification / webhook call (via HTTPS).

•  Your servers are down, not responding, or BluePay's notification request times out.

Retrying the Gift Notification

By clicking the Retry Import button, we will attempt to write the missed gift into iMIS. You may see one of three messages in your browser:

•  Success – This indicates that the gift was written into iMIS successfully.

•  Error – This indicates that the gift failed to write to iMIS a second time. You will see a Correlation ID on screen – send this code to CSI Support and we will assist you with troubleshooting.

•  Failed – This typically indicates that the retry link was already clicked, and cannot be clicked again.

For any of these messages, you can close the browser window when complete, there is no further action to take.

Note: You cannot retry a failed retry, that is, if you click Retry Import and the gift fails to write during that process, we do not send out a subsequent email, and you cannot click the "Retry Import" button a second time.