Skip to content
Arc XP
Product Documentation

Smart Dunning and Payment Failures in Arc XP Subscriptions

Preventing churn is a top priority for publishers and we have added new features to help capture more payments after a renewal failure. Payments sometimes fail to process, due to a host of issues including technical (e.g., the gateway is unresponsive) and monetary (e.g., the customer’s account had insufficient funds). When this happens, Arc XP Subscriptions works through a series of techniques in an effort to prevent involuntary churn. “Dunning” refers to the process of making persistent demands for payment (Source: M-W.Com). The integration with Vindicia Retail can also be used to help collect payments.

Payment Failures Types

Failed payment attempts fall into two categories: hard and soft. Soft declines are issues that are possibly temporary, such as gateway error, network issues or insufficient funds. We recommend that a payment optimization “Dunning” configuration be set up to handle these issues so users do not have their subscriptions immediately terminated.

Smart Dunning

We have configurable Dunning logic to optimize your efforts to reduce churn and recover potential lost revenue from terminations. Soft declined payments, or temporary authorization failures, can still be captured by retry attempts but hard declines require a customer to update their payment method since the account is closed or the card is invalid. Now using the Smart Dunning features, hard and soft declines can be configured separately, and you can create targeted payment retries and communication. Additionally, payment retries can be made based on timing in the month and the number of days after an initial failure.

To help track users who’s subscription renewal has failed and are currently going through the Dunning rules we have added a new Subscription status of Dunning. This has replaced the old status of Suspended.

Setup for Smart Dunning & Decline Code Management

  1. Managing Decline Code

    Decline codes are specific to each bank and can at times be ambiguous. In order to not incorrectly categorize a code, and allow clients flexibility, we have created a management screen for code configuration. Decline codes default to Soft type there is a management screen for each payment gateway to change the label on a code to a hard decline.

  2. Soft Decline Termination Grace Period

    Once decline codes have been categorized, payment optimization rules should be set. Select Edit in the overflow menu next to the payment provider you want to configure.

    This will bring you to the Create Payment Optimization screen where there are two options for subscription termination settings.

  3. Soft Decline Rules

    The additional payment retry attempts can be added using the Add retry rule button. There are options to add rules based on the number of days after the initial payment failure or based on the time of the month. There is no limit on the number of rules or days for retry attempts but we recommend no more than 5 attempts and not going past 45 days. This is due to credit card contracts that stipulate the number of payment attempts for one order.

    The Contact Customer option setting will send an additional WebSocket event when enabled. This helps you to communicate with customers when a payment has failed after a period of time but not for every payment retry attempt.

  4. Hard Decline Termination Grace Period & Contact

    Hard declines, will never be successful until a customer updates their payment method. To provide time for customers to get communications and update their payment method a grace period can be set. Contacting customers about the need to update their payment method is made easier using the contact settings for hard declines. This will send the Dunning_Reminder WebSocket event with the decline type indicated in the body of the event.

Payment Method Updates

A customer can update their payment method after a subscription has entered the Dunning process. When this happens a renewal will be attempted within 5-10 minutes. If the payment is successful then the subscription moves to an Active status. If it is not successful then the Dunning process will continue.

Customer Communication WebSocket Event

You should use the Dunning_Reminder WebSocket event to tailor communications to customers when a payment has been declined. This event will only be sent when Contact Customer is enabled. Details on the WebSocket events can be found here.