Decline Management is currently in Beta and was introduced as part of Payments2Us 11.6. It should be configured and thoroughly tested in a Sandbox before being enabled in Production.
1. Create a test Recurring Payment
Create a Recurring Payment using the same Merchant Facility that has your Default Soft Codes and Smart Retry Strategies configured. Please go through this article on How to Setup Decline Management for Regular Giving.
For instructions, see How to set up recurring payments for credit cards. Payments2Us requires the Recurring Payment to be Active, have an amount, and have a valid Billing Token before it can normally be processed.
2. Make the Recurring Payment ready for testing
Before running the Recurring Payment Processor, update the test Recurring Payment so it is due for processing:
- Status: Active
- Next Payment Date: today
- Last Processed Date: a date before today
- confirm the Recurring Payment has an amount and the other required processing details.
Important: Do not set Last Processed Date and Next Payment Date to the same day when preparing the test. Set the Last Processed Date to an earlier date and the Next Payment Date to today.
Then run the Recurring Payment Processor from the Merchant Facility.
So for a simple test:
Last Processed Date: Yesterday
Next Payment Date: Today
Status: Active3. Create a test decline
You need the next payment attempt to return a decline code that you have configured in Default Soft Codes.
For example, when testing with Windcave, you can deliberately change the Billing Token on the test Recurring Payment. Windcave returns response code JD for an invalid DPSBillingId, and Payments2Us documents JD as an invalid Billing Token.
For example:
Default Soft Codes: 51,61,JD
Test payment response: JDBecause JD is included in Default Soft Codes, the failed transaction is treated as a Soft Decline and Smart Retry processing begins.
Only deliberately modify the Billing Token on a test Recurring Payment in a Sandbox.
4. Check the result
After the processor runs, check the new Payment Txn and the related Recurring Payment.
You should see the failed Payment Txn with the gateway response, such as JD. Smart Retry then looks at the active strategies for the same Merchant Facility and selects the appropriate strategy.
If a strategy has JD in its Retry Response Codes, that strategy should be selected. The strategy settings are then used to calculate what happens next, including:
Retry Delay Days / Cadence Pattern
↓
Allowed Retry Days
↓
Next Payment DateOn the Recurring Payment, confirm that:
Smart Retry Strategy → selected strategy
Next Payment Date → calculated retry date
Remaining Cadence → updated, if using a custom cadence
Retry Attempts → increasedFor example, if the selected strategy uses:
Retry Delay Days: 2
Allowed Retry Days: Any Daythen the Next Payment Date should be scheduled two days after the failed attempt.
If it uses:
Cadence Pattern: 1,7,14
Allowed Retry Days: Any Daythe first failure should schedule the next retry after one day and Remaining Cadence should become:
7,14