Auto Rescue for SEPA payments

Besides Auto Rescue for card transactions, we support rescuing SEPA transactions. Because SEPA transactions always have eventCode AUTHORISED in the response, these require a different rescue logic compared to card transactions.

We apply our rescue logic on two chargeback reasons for SEPA.

• AM04: Insufficient funds
• MS03: No reason specified. This code is used in some countries/regions instead of AM04.

Also note that for SEPA payments, we have a maximum of two rescue attempts within the rescue window. The reasons for that are:

• The period between the initial transaction and the first decline message is longer than for card transactions. This means we have fewer days left to rescue the transaction.
• Because chargebacks are typically fined by the issuing bank, it is important to keep the number of rescue attempts low.

On this page, you will learn how to:

1. Enable Auto Rescue for SEPA transactions.
2. Receive updates on the Auto Rescue process.

We also explain how you can:

• Send a payment link when the Auto Rescue process ends unsuccessfully.
• Cancel the Auto Rescue process for a payment.
• Test how your integration handles Auto Rescue updates.
• Reconcile retry attempts in Adyen generated reports.

How it works

Step 1: Enable Auto Rescue

You can enable Auto Rescue for SEPA payments at:

• Account level
• Transaction level.

Enable at account level

To enable Auto Rescue for all qualifying SEPA payments, contact our Support Team or your Adyen Account Manager to configure this for you.

Enable at transaction level

To enable Auto Rescue for SEPA payments on transaction level, contact our Support Team or your Adyen Account Manager to configure this for you.

When configured, to enable Auto Rescue for a SEPA transaction in your payment request:

• Add the autoRescue flag.
• Submit a unique merchantOrderReference. This reference represents a specific billing cycle or subscription and will appear in any Auto Rescue updates or reports. You can connect any Auto Rescue retry attempt to the original /payments request using this reference.

For example:

• Make a /payments request, and specify:

  • shopperInteraction: ContAuth
  • autoRescue: true
  • maxDaysToRescue: The rescue window, in days. You can specify between 1 and 42 days. We recommend using a rescue window of one calendar month (30 days).
  • reference: Your unique reference for this payment request.
  • merchantOrderReference: Your unique order reference. For example, a concatenation of a unique shopper reference and the transaction date.
  • paymentMethod.type: sepadirectdebit
  • paymentMethod.sepa.ownerName: The name on the SEPA bank account. For testing, use a concatenation of chargeback and reasonCode. See the example below.
  • paymentMethod.sepa.ibanNumber: The IBAN of the bank account. Make sure to not encrypt this value.

  The following example shows how to enable Auto Rescue for a SEPA shopper-not-present transaction submitted to the /payments endpoint. In case of a chargeback, Auto Rescue will automatically retry this payment for a maximum of 30 days.

  You will receive a response containing:

  • resultCode: Authorised

  In case the transaction is charged back, you will receive a webhook event containing:

  • eventCode: CHARGEBACK

  The Auto Rescue process will attempt to rescue this transaction.

Step 2: Receive Auto Rescue updates

To update you on the Auto Rescue process, we send you a webhook event. We send an event when:

• A rescue attempt was made, and it was:
  • Successful
  • Unsuccessful
• The rescue process ended either because the payment was rescued, or the process was unsuccessful.

You will receive the webhook 16 days after the rescue attempt.

Retry attempt successful

If a retry attempt was successful, this means we didn't receive another chargeback within the specified rescue window and the Auto Rescue process ended, you will receive a webhook event with:

• eventCode: AUTORESCUE
• eventDate: The date of the retry attempt.
• success: true
• reason: retryWindowHasElapsed

Here's an example of the Auto Rescue process end webhook event.

If we received another chargeback but the second retry was successful, the process ends and you will receive a webhook event with:

• eventCode: AUTORESCUE
• eventDate: The date of the retry attempt.
• success: true
• reason: maxRetryAttemptsReached

Here's an example of the Auto Rescue process end webhook event.

You can view how much revenue has been recovered with Auto Rescue in your Customer Area, under Reports. Search for the RevenueAccelerate report.

Retry attempt unsuccessful

If a retry attempt was unsuccessful, this means we received chargebacks after each of the two retry attempts. You will receive a webhook event with:

• eventCode: AUTORESCUE
• eventDate: The date of the retry attempt.
• success: false
• reason: maxRetryAttemptsReached

Here's an example of the Auto Rescue process end webhook event.

Send a payment link

In case the Auto Rescue process ended unsuccessfully, you can optionally use Pay by Link to send the shopper a payment link so they can still proceed with the payment, for example, using other payment method.

To activate Pay by Link for Auto Rescue, contact our Support Team.

After we activate the feature, you will receive additional data fields in the Auto Rescue process end webhook:

• paymentLink.url — The URL where the shopper can complete the payment. Valid for 5 days.
• paymentLink.expiresAt — The date when the payment link expires, in ISO 8601 format. For example, 2019-11-23T12:25:28Z or 2020-05-27T20:25:28+08:00.

When the shopper has paid with Pay by Link, you receive an AUTHORISATION webhook event with:

• shopperReference: The payment details used by the shopper.
• recurringDetailReference: The token you can use for the next subscription renewal. For more information, refer to Tokenization.

Cancel Auto Rescue

While a payment is in the Auto Rescue process, your shopper may provide you with a new payment method, or cancel their subscription. In these scenarios, you should cancel the Auto Rescue process for the charged back payment.

To cancel the Auto Rescue process:

1. Make a /cancel request, specifying: 

   • originalReference: The rescueReference that you received in the payment response.
   • cancellationType: autoRescue

   The following example shows how to cancel the Auto Rescue process for a payment with a rescueReference of 865497581465325B.

2. You receive a /cancel response containing:

   • response: [cancel-received]
   • pspReference: The PSP reference associated with this /cancel request. This is different from the PSP reference associated with the original payment request.

   After we have processed your cancel request, you receive a webhook event with:

   • eventCode: CANCEL_AUTORESCUE
   • success: Indicates whether your request to cancel the rescue process was successful.
   • merchantOrderReference: Unique order reference that you provided in the payment request.

Test Auto Rescue and go live

Before flagging live payments for Auto Rescue, we recommend that you test how your integration handles scenarios involving Auto Rescue updates.

To simulate scenarios involving Auto Rescue updates:

1. Make a test /payments request that is flagged for Auto Rescue. In the request, additionally provide:

   • autoRescueSepaScenario: Set this to the scenario you want to test:
     • AutoRescueSuccessfulFirst: The payment is authorized but we received a chargeback. The first retry attempt is successful because we received no chargeback after this attempt within 30 days.
     • AutoRescueSuccessfulSecond: The payment is authorized but we received a chargeback. The first retry attempt is authorized but we received a second chargeback. The second retry attempt is successful because we received no chargeback after this attempt within 30 days.
     • AutoRescueFailed: The payment and all retry attempts are authorized, but we received chargebacks after each attempt.
   • ownerName: Set this to the type of chargeback that you want to simulate. Use a concatenation of chargeback and the reason code. For example, chargeback:MS03 or chargeback:AM04.

   The example below shows how to test a scenario, with the /payments endpoint, where the second retry attempt is successful:

2. You receive Auto Rescue updates corresponding to the scenario you are testing. If this scenario involves multiple retry attempts, these Auto Rescue updates will occur several minutes apart.

Auto Rescue reports

Each Auto Rescue retry attempt is a separate transaction, and thus generates a unique pspReference. If you want to see all payments initiated by Auto Rescue, we can add the Payment Requester Type column to your Received payment details report. Contact our Support Team or your Adyen Account Manager to configure this for you.

To connect an Auto Rescue retry attempt to a payment request, use the value in the Merchant Order Reference column. This corresponds to merchantOrderReference you provided in the payment request. We can add Merchant Order Reference to the following reports:

• Received payment details report
• Settlement Detail Report
• Payments Accounting Report

Contact our Support Team or your Adyen Account Manager to configure this for you.

Example

The following example represents two payment requests with merchantOrderReference A1 and A2.

• A1: The payment was rescued on the first retry attempt.
• A2: The payment was rescued on the second retry attempt.

See also