Every decline
has a

recovery path.

Every failed payment has a reason. Your merchants decide what happens next.

A payment declines. Your merchants define what the platform does next. Each merchant on your platform gets a configurable recovery layer: retry logic, return-code-based fallback strategies, and SCA exemption rules. When a transaction declines, the platform doesn't give up, it follows the logic the merchant set. You define what they can configure. They operate it themselves.

Book a demo

Turn declines into

recovered payments.

Not all declines are equal. A soft decline from an unavailable acquirer deserves a retry on a different provider. A hard decline for card velocity does not. Your merchants can map each return code to a specific behavior, retry or not, same provider or another, with a specific authentication action. The result: every decline follows a logic, and the transactions that can be recovered are recovered automatically.

Retry on the right target

When retry is enabled for a return code, your merchants choose where it goes: back to the same provider, or rerouted to another. Retrying on the same provider makes sense for transient failures, a temporary outage, a timeout. Rerouting to another provider makes sense when the issue is structural, a card scheme restriction, a BIN incompatibility.
Both options are available per return code.

Every return code. One behavior.

The return code mapping table gives your merchants a clear, editable view of how each failure type is handled. Some codes are pre-configured and locked (scheme rules that cannot be overridden). Others can be customized. The status column, Default, Custom, Not editable, makes it immediately clear which rows a merchant can act on, and which ones are set by the platform.

Control authentication.

Protect conversion.

3DS authentication protects against fraud. It also adds friction. The right configuration reduces that friction on the transactions that don't need it, without compromising compliance. Each merchant on your platform can define SCA rules: when to request a challenge, when to attempt an exemption, and what the default behavior is when no rule matches. The engine evaluates rules in order and applies the first one that matches, the same logic as routing, applied to authentication.

Rules that match transaction context

SCA rules fire based on transaction attributes: amount, country, payment method, channel. A merchant processing low-value recurring transactions in the EU can apply a low-value exemption by default. A merchant processing high-value e-commerce can request a challenge on every transaction above a threshold. Both configurations live in the same interface, per merchant, without any development work.

A default for every unmatched transaction

When no SCA rule matches, a default behavior applies. Your merchants set it explicitly: challenge requested, challenge mandatory, or a specific exemption reason. Nothing falls through without a defined authentication posture.

Every merchant's recovery posture. One view.

Fallback and SCA configurations are per merchant, but you don't manage them one by one. As an operator, you have a centralized table of every merchant's configuration under your scope: fallback settings, return code customizations, SCA activation status, recovery rate. Spot the merchants running on defaults. Identify the ones with low recovery rates. Intervene when it matters, without connecting as each merchant individually.

Every decline has a