Automatic Retry & Rerouting

Payment processing doesn't always succeed on the first attempt. Temporary issues like network timeouts or system unavailability can cause initial failures, while scheme limitations or regulatory restrictions may prevent processing on the preferred rail.

The nature of instant payment schemes allows us to offer automatic retries for temporary issues and rerouting to alternative rails when the preferred rail is unavailable. These capabilities rely on real-time processing and immediate feedback, which are not possible with traditional batch-based systems.

We currently offer the following features for SEPA Instant payments only.

Automatic Retry and Rerouting Process

If payment processing on SEPA Instant is not possible, the payment will automatically be retried or rerouted:

Automatic retries handle temporary issues that may prevent immediate payment processing, such as network timeouts or temporary system unavailability. When these transient problems occur, the system will automatically retry the payment on the same rail at regular intervals before considering alternative approaches.

Automatic rerouting occurs when a payment cannot be processed through the preferred rail due to more fundamental limitations, such as scheme-specific restrictions, regulatory requirements, or transaction amount limits. In these cases, the routing logic automatically attempts to process the payment through alternative payment rails according to your configured priorities, either through the default logic or through your specified scheme selection override or prioritized clearing networks list.

Both mechanisms work together to maximize payment success rates while providing you with visibility into how your payments are being processed and why certain routing decisions were made.

The following diagram illustrates how automatic retries and rerouting work together:

The logic that dictates when retries and rerouting occur is based on the type of error received.

Soft Rejections

These are temporary issues that may be resolved through retries:

• Agent timeout
• Offline creditor bank
• Temporary system unavailability

Payments receiving soft rejections will remain in "Pending Processing" status during the retry period.

Hard Rejections

These are divided into two categories:

1. Reroutable Rejections

• Trigger automatic rerouting to alternative rails
• Include regulatory restrictions, scheme limitations, and transaction type restrictions
• See error codes table in Rerouting section above

The following error codes trigger automatic rerouting to an alternative rail:

2. Terminal Rejections
   These result in the payment being rejected back to the client without rerouting attempts:

• Invalid or closed account number
• Blocked account
• Other fundamental beneficiary account issues

Note: For payments that cannot be processed through any available rail, you will receive a clear rejection reason to help you take appropriate action.

Tracking Rerouting and Retry events

Rerouting Events

There are two ways to track rerouting events:

• The routingStatus property in the payment response: If the payment is rerouted, the routingStatus property will be updated to show the new rail and the reason for the rerouting. This is available in the following endpoints: GET Singles Payments, GET Payment status and GET Payment by transaction reference
• Via notifications: the PaymentRouting notification is triggered when the payment is rerouted, and the payload includes the routingStatus property. For more details, see examples.

Retry Events

When a payment enters a retry loop, the payment status will remain as Pending Processing until the retry period ends. If the payment retry fails, the payment will be rejected.