The functionality described in this article is available starting with the RaiseNow Fundraising Kit for Salesforce V.1.21. Contact RaiseNow Support if you wish to upgrade to the current version.
RaiseNow provides several mechanisms to support you in using Process Builder within Salesforce to control how dunning processes are executed. Below we will outline two simple processes in order to deal with reversals and failed payments.
Reversal may occur when the RaiseNow payment gateway receives information about a chargeback, for example for a credit card payment, or a reversal for a direct debit donation initiated by the donor through their bank. Most customers choose to resolve these situations before deciding to close the recurring donation or triggering a recharge.
This is the process we are going to build. The basic idea is as follows:
- On detecting a reversal we will check the status of the concerned installment w.r.t. previous reversals. We also trigger a manual escalation process.
- We wait for a defined interval before attempting to execute another charge. The charge will only be executed if the original conditions are still met.
- If the conditions are not met, we close the recurring donation in Salesforce. This change will propagate back to RaiseNow.
We start by defining a new process in Process Builder that will start when a platform event is received.
As a trigger we select the "RaiseNow Reversal Succeeded" event. This event will be propagated to Salesforce when the RaiseNow payment gateway receives corresponding information for a payment.
As we have to define a condition, we will select the below expression as this will always evaluate to true and we want the process to always run when this event is received.
We continue by defining a criteria for attempting a recuperation process through our first action group. In this example we have decided that, if a person has already executed a reversal for the same installment (Opportunity), we will not try to charge the same Opportunity again. So we create a custom field on the Opportunity to count registered reversals.
We want to only execute this first action group if that value is less than 1. In the field definition on the object we have to set a default value to 0 in order for the below operation to work. Your custom field could looks something like this.
We can identify the correct Opportunity by following the object relation from Transaction->Opportunity in the process builder. This allows us to select a custom field for a "Reversal Counter" on the Opportunity.
In addition we define a rule to only execute this action if the related Opportunity is not marked as "Closed Lost". We need this condition to ensure the time based action will not trigger if, for example, the telemarketer has confirmed that the donor does indeed no longer want to support the organization.
As an immediate action we choose to post to chatter adding useful information received in the event. Of course you could choose any other action provided by the Process Builder for your custom escalation flow.
We also ensure to increase the increment on our reversal counter by one.
We wait for 15 days and then execute a charge on the Opportunity. The Apex method is provided by the managed package and will automatically identify the payment method associated with the Recurring Donation and trigger a charge corresponding to the Opportunity amount.
If the charge can be executed successfully a payment will be registered with the Opportunity it's StageName will be updated to "Closed Won". We have successfully recovered this recurring donation.
If the Opportunity is already lost or we already have logged reversals from a previous iteration of this process we will close the Recurring Donation.
There are numerous reasons why a payment may fail. A lot of them are temporary. The process for recouping failed payments described here will do the following:
- On detecting a failed payment we will check certain conditions before executing a retry. At a certain point we will want to close the Recurring Donation instead of endlessly charging it.
- We wait for a defined interval before executing a retry. We will repeat the retry several times.
- If we have reached the number of maximum retries we will escalate for manual resolution.
- After a defined period we will close the recurring donation.
Again we start be defining a new process in Process Builder that will start when a platform event is received. But this time the triggering Platform Event will be "RaiseNow Payment Failed".
We define a custom field on the Opportunity in Salesforce to count the number of failed charge attempts we have registered for this Opportunity. Do not forget to assign 0 as the default value.
In order to decide if we should execute the the action group 1, we check the number of failed charges on the Opportunity:
If the condition is met we post a quick notice to chatter and raise the increment on the failed charge counter.
We wait for a defined number of days and re execute the charge.
If we have reached the defined number of retries we close the Recurring Donation instead as we did before.
The above process should give you the tools to define a dunning process for your organization. Please consider the following points as well.
We recommend that you take the defined period and frequency of the Recurring Donation into account when building your own dunning process. Most likely retry intervals for yearly recurring donation should have longer retry configurations than monthly donations.
Regarding Lapse and Pause functionalities on the Recurring Donation are currently not supported.
At various points in the guide we referred to manual resolution processes. We highly recommend that you leverage marketing automation tools such as Marketing Cloud in order to send automated and personalized content to your donors as well as escalate to manual resolution mechanism if the automated processes do not lead to the desired results. The RaiseNow support team can direct you to partners with a proven track record in defining and implementing these sorts of processes.