Reduce failed payments with Success+#

What is Success+ and what does it do?#

Success+ is a payment intelligence and automation product that uses machine learning to manage and reduce payment failures. When a payment fails, Success+ retries it on the date it's most likely to succeed, recovering on average 71% of failed payments.

What payments does Success+ retry?#

Success+ will only retry payments that fail due to NSF (Non-sufficient funds). You can see a breakdown of reason codes below:

*MS03 only applies to the following countries: Austria, Belgium, Germany, Luxembourg and Slovakia

Good to Know#

Please ensure you are listening and making actionable changes to the late_failure_settled event, as this payment may also be eligible to be retried through Success+. A late failure is not a final state, depending on the reason code as shown above.

For example, if a payment encounters a late failure due to non-sufficient funds, it is eligible to be retried through Success+.

How to use Success+#

Enabling Success+#

Success+ is enabled via the GoCardless dashboard.

1. Log into the GoCardless dashboard and navigate to the Success+ page. Or follow the link here.
2. Click Turn on Success+
3. Choose the scheme/schemes you want to enable Success+ for
4. Choose the configuration that suits your business. We offer a default preset with the highest chance of recovery.
5. Click Enable retries for… to enable Success+

Using Success+ through API#

As mentioned above, the initial configuration for Success+ is done via the GoCardless dashboard, even if your business uses GoCardless via API.

API merchants do have the additional ability to decide whether Success+ should be applied on each payment they submit, via a boolean flag. This is useful if your business wants to create its own rules about when Success+ should apply to different customers or payment types.

The Success+ flag#

The flag retry_if_possible is used to control whether Success+ is enabled on a payment. The following payment types support this boolean flag:

• Individual payments
• Instalment schedules
• Subscriptions

For API users enabling Success+, the flag is mandatory and by default, the flag will be set to false. If you are enabling Success+ as a partner, the flag will automatically be set to true unless specified otherwise.

Using Success+ with individual payments#

Creating payments

When creating a payment, set retry_if_possible to true. This will enable intelligent retries if the payment is eligible.

Updating payments

If a payment has been created with retry_if_possible set to true, then it can be updated to false. This will prevent the payment from being automatically retried in the event of a failure.

POST https://api.gocardless.com/payments HTTP/1.1
Content-Type: application/json
{
  "payments": {
    "amount": 100,
    "currency": "GBP",
    "retry_if_possible": true,
    ...
  }
}
 
PUT https://api.gocardless.com/payments/PM123 HTTP/1.1
Content-Type: application/json
{
  "payments": {
    "retry_if_possible": false
  }
}

Using Success+ with Instalment Schedules#

When creating an instalment schedule set retry_if_possible to true to ensure that all instalment payments created are automatically retried upon failure.

POST https://api.gocardless.com/instalment_schedules HTTP/1.1
Content-Type: application/json
{
  "instalment_schedules": {
    "name": "Bike Invoice 271",
    "total_amount": "2500",
    "currency": "GBP",
    "retry_if_possible": true,
    ...
}

Using Success+ with Subscriptions#

When creating a subscription set retry_if_possible to true to ensure that all payments created for the subscription are retried automatically upon failure.

POST https://api.gocardless.com/subscriptions HTTP/1.1
Content-Type: application/json
{
  "subscriptions": {
    "amount": "2500",
    "currency": "GBP",
    "interval_unit": "monthly",
    "retry_if_possible": true,
    ...
}

Handling Failures#

On payment failure the failed event will always be sent. If the payment will be automatically retried the field will_attempt_retry will be true.

When a payment is automatically retried it will trigger a resubmission_requested event just like any other type of retry.

GET https://api.gocardless.com/events/EV123 HTTP/1.1
 
HTTP/1.1 200 (OK)
Content-Type: application/json
{
  "events": {
    "id": "EV123",
    "created_at": "2014-04-08T17:01:06.000Z",
    "resource_type": "payments",
    "action": "failed",
    "details": {
      "origin": "bank",
      "cause": "insufficient_funds",
      "description": "The customer's account had insufficient funds to make this payment.",
      "scheme": "sepa_core",
      "reason_code": "AM04",
      "will_attempt_retry": true
    },
    "metadata": {},
    "links": {
      "payment": "PM123"
    }
  }
}

What to do if a payment is going to be retried#

• After any payment_failed event with will_attempt_retry set to true, we will send a payment:resubmission_requested event.
• You can treat this exactly the same as a manual user-triggered retry - the payment will be re-attempted on the new charge_date and will go through the normal payment flow.

How to know which payments will be retried#

• You can use the will_attempt_retry flag on the payment:failed event to identify payments which will be intelligently retried.
• If the flag is set to true, then the payment will be intelligently retried.
• If set to false, the payment will not be retried and then you can retry the payment manually.

How to stop a payment being retried#

• To stop a payment from being retried, call the update payment endpoint with retry_if_possible set to false
• While the initial payment will still continue, it will not be automatically retried.
• The payment status must be in "pending_submission" for it to be updated successfully

When a payment will be retried#

The retry_if_possible field does not guarantee the payment will be retried on failure. A payment will be retried if the following conditions are met:

• Intelligent retries for the scheme has been enabled on the settings page.
• The payment has field retry_if_possible set to true.
• The payment has failed due to insufficient funds.
• The number of payment failures is lesser than the number of retries configured in the intelligent retries settings page.
• The subsequent retry can be confirmed within the retry window configured in the intelligent retries settings page.

What's next?#