Skip to content

Smart Dunning and Payment Failures in Arc XP Subscriptions

Reducing churn is a critical priority for publishers because retaining existing subscribers is often more cost-effective than acquiring new ones. In the competitive landscape of digital media of digital media, having subscribers who choose not to renew their subscriptions can result in revenue loss. Given that the costs associated with attracting new subscribers—through marketing campaigns, promotions, or discounts—can be high, focusing on retention ensures better long-term profitability.

Payment processing can occasionally fail due to various reasons, for example:

  • Technical issues, such as an unresponsive gateway.
  • Financial challenges, such as insufficient funds in a customer’s account.

In response, Arc XP Subscriptions employs a series of strategies to minimize involuntary churn. This process, known as dunning, involves repeated attempts to secure payment (Source: M-W.Com). Additionally, integration with Vindicia Retail offers another way to recover payments.

Payment Failures Types

Failed payment attempts can be classified into two types: hard and soft declines.

Soft decline

A soft decline happens when a payment attempt fails due to temporary issues that might be resolved by retrying the transaction. These are generally not permanent and can often be fixed without direct intervention from the customer. Common reasons for soft declines include:

  • Insufficient funds: The customer’s account doesn’t have enough balance at the time of the transaction.
  • Gateway errors: Issues with the payment gateway or network that prevent the transaction from going through.
  • Card limits reached: The transaction exceeds the card’s set spending limit.
  • Card issuer timeout: The bank took too long to respond, leading to an automatic decline.

In many cases, soft declines can be addressed by implementing dunning strategies (i.e., automatic retries or reminders) to recover payments.

We recommend that a payment optimization Dunning configuration be set up to handle these issues so users do not have their subscriptions immediately terminated.

Hard decline

A hard decline indicates a more permanent issue that cannot be resolved by simply retrying the transaction. Hard declines require the customer to take action to update or correct their payment details. Common reasons for hard declines include:

  • Lost or stolen card: The card has been reported as lost or stolen, so the issuer blocks any transactions.
  • Closed account: The customer or the bank closed the account or credit card.
  • Invalid card number or expiration date: The card details are incorrect or have expired.
  • Card permanently blocked: The issuing bank has blocked the card due to fraud suspicion or security concerns.

Because the system cannot recover hard declines through retries, you must contact the customer to provide new or updated payment information.

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.

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.