AI Dynamic Routing

Last updated:October 15, 2026

Use this playground to see AI Dynamic Routing pick an acquirer in real time, without needing a live merchant configuration.

How it works

Turn AI Dynamic Routing on for a channel you already run. No new channel, no new merchant accounts, no integration change, just one setting.

Your setup today, plus one switch
Multiple acquirers
Already running today
Weighted default
Static split picks first
AI checkpoint
Your one setting to enable
You switch this on
Best-fit acquirer
Wins only when better

The rest of this playground runs on a richer test setup: guaranteed minimum shares for three named acquirers, plus a fourth channel dedicated entirely to dynamic scoring. See Channel setup below, it's what the two use cases run against.

To consider
  • Acquirer names here are anonymized (Acquirer A, B, C); the mechanism is real.
  • Every example submits at the merchant entity level, using the DB payment type for simplicity.
  • Dispatching, 3DS, and Fraud Management run unchanged, whichever acquirer processes the transaction.
  • A decline is still recoverable, immediately through Smart Retry or on a schedule through MAC Scheduler.
  • AI Dynamic Routing decides the first attempt only; recovery is a separate step it doesn't change.
  • See the AI Dynamic Routing guide for the full recovery story.

Channel setup

For testing purposes, this playground uses a more comprehensive setup than the simplest case above: one merchant entity, three acquirer channels each with a guaranteed minimum share of traffic, and a fourth channel where every eligible acquirer is scored per transaction and the best one wins.

Merchant entityOne entity, four channels
Channel A
Acquirer A
Guaranteed
10%
Channel B
Acquirer B
Guaranteed
10%
Channel C
Acquirer C
Guaranteed
10%
Channel D
Dynamic
Every acquirer, scored live per transaction
Acquirer A
Acquirer B
Acquirer C
70%
10%
10%
10%
70% Dynamic

30% guaranteed. Each acquirer keeps a fixed minimum share, regardless of transaction context.
70% dynamic. The model scores every acquirer for each transaction and picks the best fit, live.

Acquirer A, guaranteed
Acquirer B, guaranteed
Acquirer C, guaranteed
Dynamic channel

Use cases

Same three acquirers behind the dynamic channel, two different transactions submitted to the merchant entity above. Transaction context, not a fixed split, decides which one wins.

CIT recurring payment

Card on file, repeat charge
The customer initiates a cardholder-initiated, recurring charge against a card already on file. Weighted dispatch alone would send this to its usual default acquirer. The dynamic channel re-scores all three acquirer merchant accounts for this exact context, and overrides the default only if a better fit exists.

How it works

The merchant submits the recurring charge

Sent to the merchant entity, tagged as a cardholder-initiated recurring payment. Weighted dispatch picks its usual default acquirer.

The dynamic channel scores all three acquirers

The default is kept or overridden based on each acquirer's live score for this transaction.

Transactions created
DBSubmitted
→
AOAcquirer decision recorded
→
✓Same DB, approved

1. The merchant submits the recurring charge

Initiate a server-to-server POST request at the merchant entity, with standing instruction fields set for a cardholder-initiated recurring payment.

Sample request:

2. The dynamic channel scores all three acquirers

The decision is recorded on a second transaction, the AO leg. Query it below to see whether the default was kept or overridden.

Sample request:

One time payment

Card not stored
The customer pays once, with no card stored and no standing instruction. Weighted dispatch already has a default acquirer for this context. The dynamic channel re-scores all three acquirers for this same context before confirming or overriding that default.

How it works

The merchant submits the one-time payment

Sent to the same merchant entity, with no standing instruction fields. Weighted dispatch picks its usual default acquirer.

The dynamic channel scores all three acquirers

The default is kept or overridden based on each acquirer's live score for this transaction.

Transactions created
DBSubmitted
→
AOAcquirer decision recorded
→
✓Same DB, approved

1. The merchant submits the one-time payment

Initiate a server-to-server POST request at the same merchant entity, with no standing instruction fields, simulating a first-time shopper.

Sample request:

2. The dynamic channel scores all three acquirers

Same AO leg mechanism as CIT recurring above. Query it below to see the outcome for this transaction.

Sample request:

The AO leg

Every model invocation, in either use case above, creates a second transaction record, the AO leg (AI Optimization), purely for reporting.

  • Acquirer overridden: the result code reports the change, and clearing_institute_name carries the acquirer the model chose.
  • Silent mode: logged only, never used for processing. clearing_institute_name still shows the acquirer the model would have picked.
  • Webhook: the AO leg can be enabled for webhook delivery, so the decision reaches the merchant's own systems as it happens, instead of polling.
Result codeDescription
000.500.100Silent mode: AI recommendation logged, not used for processing.
000.500.200Enabled: AI and static/weighted routing chose the same acquirer.
000.500.300Enabled: acquirer changed by the AI recommendation.

No AO leg is created when the mode is Disabled, or when fewer than two eligible acquirers remain after static dispatch. These are new codes and may not yet appear in the live result codes reference; this table is a static preview pending rollout.

Configuration

To consider
  • Requires more than one eligible acquirer. Running on a single acquirer today? See AI Acquirer Advisory first.
  • The 10-10-10-70 split shown here is a worked example, not a required ratio. Guaranteed shares are set to match each acquirer's commercial commitment.
  • Which acquirers can take part in dynamic routing needs confirming against what the model currently supports, before enabling it for any of them.

Please log in to view configuration details.

See also