Can retry behavior differ by decline reason?

Short answer

Yes. Each return code represents a specific failure scenario, and the mapping table sets three things per code: whether a retry happens, whether that retry targets the same provider or another one, and how the attempt behaves. The behavior can inherit the previous transaction, carry a challenge preference, or apply an SCA exemption reason such as low value, corporate, trusted beneficiary, risk analysis or delegated authentication. Each row shows whether it holds a default or a custom value.

In detail

Yes. Each return code represents a specific failure scenario, and the mapping table sets the behavior for each one.

Three settings per code

Whether a retry happens at all.
Whether that retry targets the same provider or another one.
How the attempt behaves.

Retrying on the same provider suits transient failures, such as a temporary outage or a timeout. Rerouting to another provider suits structural issues, such as a scheme restriction or a BIN incompatibility.

Attempt behavior

The retry can inherit the previous transaction's settings, carry a challenge preference, or apply an SCA exemption reason such as low value, corporate, trusted beneficiary, risk analysis or delegated authentication. That lets a merchant recover a payment declined for authentication reasons without forcing the same friction again when an exemption legitimately applies.

Clear ownership of each row

Each row shows whether it holds a default value, a custom value or a value that is not editable. Some codes are locked because scheme rules cannot be overridden. The status column makes it immediately clear which rows a merchant can act on.

For you as an operator, this keeps recovery logic precise and auditable. Your merchants adapt it to their traffic, within the limits the platform and the schemes impose.

Read the full article →