A single acquirer approves some card types and issuing countries better than others. A French card processed by a French acquirer is domestic for interchange and for the issuer's risk model; sent through a US acquirer, the same card becomes cross-border, costs more and is declined more often. Smart routing exploits those gaps transaction by transaction, and at method level too, sending a Dutch shopper to iDEAL or a Brazilian one to Pix where a card would convert worse.

It is the component between checkout and providers that evaluates each payment against configured conditions and names a destination. Instead of hard-coding "send everything to Acquirer A", the merchant writes rules that a non-developer can change in a dashboard, applied in milliseconds before authorization.

A rule pairs conditions with an action. Conditions read the BIN and issuing country, card brand, currency, amount, payment method and fraud score; actions name a provider, a split or a fallback list. A sample set:

1. Brazilian card in BRL: local Brazilian acquirer.
2. Amount above €1,000: Acquirer A with 3DS requested.
3. American Express: the Amex direct connection.
4. Everything else: 80% Acquirer A, 20% Acquirer B.

The engine stops at the first match, so order is itself logic: a €1,500 Brazilian BRL payment hits rule 1, not rule 2.

Static rules only encode what the merchant already knows. Smart routing logs every authorization by provider, BIN, issuer country, amount band, response code and latency, keeps rolling approval rates per segment, and scores each eligible provider on expected approval, fee and health. If the first attempt returns a soft decline or a timeout, the payment is cascaded to the next provider; hard declines such as a reported stolen card are not retried, because schemes penalise repeat attempts. The rules stay as guardrails, for example never sending a currency to a provider that cannot settle it.

A subscription merchant processing €10 million a month at 86% approval adds a second acquirer and routes German and Dutch cards locally. Approval rises to 89%, roughly €300,000 a month in sales that would otherwise have failed.

Rule changes alter money flow in production, so they are tested like code: first in a sandbox with test cards covering each branch, then in shadow mode logging what a new rule would have done on live traffic, then as a controlled A/B routing split. The audit log of who changed which rule is what acquirers and auditors ask for after an incident, and what a buyer of a payment business checks alongside token portability, since card tokens stored with one provider may not move with the volume.

See also: Workflow builder.