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.
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.
- 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.
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.
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
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.
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
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.
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_namecarries the acquirer the model chose. - Silent mode: logged only, never used for processing.
clearing_institute_namestill 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 code | Description |
|---|---|
| 000.500.100 | Silent mode: AI recommendation logged, not used for processing. |
| 000.500.200 | Enabled: AI and static/weighted routing chose the same acquirer. |
| 000.500.300 | Enabled: 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
- 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.