What happens after a failed payment attempt?
Each merchant account carries its own fallback policy: an active state, a maximum number of attempts including the first one, a maximum number of retries after the initial failure, and a decision on whether attempts made during provider downtime count toward those limits. When the policy is active, the platform retries according to that configuration and the return code mapping defined alongside it.
In detail
Each merchant account carries its own fallback policy, so what happens after a decline follows rules the merchant set rather than a generic default.
The policy settings
- An active state, to switch the policy on or off.
- A maximum number of attempts, including the first one.
- A maximum number of retries after the initial failure.
- A decision on whether attempts made during provider downtime count toward those limits.
When the policy is active, the platform retries according to that configuration and the return code mapping defined alongside it.
The return code mapping
Not all declines are equal. A soft decline from an unavailable acquirer deserves a retry, possibly on another provider. A hard decline, such as one linked to card velocity, does not. The mapping table sets, for each return code, whether a retry happens, whether it targets the same provider or another one, and how the attempt behaves, including SCA preferences and exemptions. Some codes follow scheme rules and cannot be overridden.
Your role as operator
You define what your merchants can configure, and they operate it themselves. Every decline then follows a logic, and the transactions that can be recovered are recovered automatically, while those that should not be retried are left alone.