🧭 Payment routing and optimization

Why multi-acquiring

In multi-acquiring, a merchant signs with several acquirers and splits its traffic among them. A single acquirer is a single point of failure. Four scenarios show why: a technical outage, approval rates drifting on one corridor, a price increase the merchant cannot refuse, and a unilateral decision to de-risk a whole sector. Even top-tier providers have suffered outages lasting several hours. Above a certain volume (about €10 million to €20 million a year online), multi-acquiring is no longer a nice-to-have. It becomes both insurance against downtime and a performance lever.

Smart routing: sending each transaction to the right place

Smart routing dynamically picks, for each transaction, the acquirer, the credential, and the exemption request that maximize an objective function, usually the probability of approval net of costs. The standard decision criteria, in order of impact, are as follows.

• BIN / issuing country: route to the acquirer that processes this corridor domestically;
• Card brand (CB, Visa, Mastercard, Amex): acquirers differ in their licenses and their performance by scheme. On co-badged cards, choosing Cartes Bancaires (CB), France's domestic scheme, or Visa/Mastercard is itself a routing decision (the merchant sets the default brand, and the customer can change it);
• Currency: avoid FX conversion entirely by settling in the presentment currency;
• Debit vs. credit, card tier: different performance and different costs;
• Auth rate history by (acquirer × BIN × amount band), recalculated continuously;
• Marginal cost: interchange + scheme fees + acquirer margin on each route;
• Real-time health: latency and technical error rate on each route (circuit breaker).

routing_rules:
  - name: french-cards-cb
    match: { bin_country: FR, brand: [CB, VISA, MC] }
    route: acquirer_fr             # domestic acquiring, CB brand if co-badged
    fallback: acquirer_paneuro

  - name: uk-cards
    match: { bin_country: GB, currency: GBP }
    route: acquirer_uk             # UK entity -> domestic post-Brexit
    fallback: acquirer_paneuro

  - name: large-credit-orders
    match: { amount_gte: 50000, card_type: credit }   # cents
    route: best_auth_rate          # model-based: auth rate observed by BIN
    exemption: none                # always 3DS above 500 EUR (TRA not allowed)

  - name: small-domestic-orders
    match: { bin_country: FR, amount_lt: 3000 }
    route: acquirer_fr
    exemption: tra                 # acquirer TRA, soft-decline loop enabled

  - name: default
    route: acquirer_paneuro
    exemption: none

health_checks:
  error_rate_5m_max: 0.05          # above 5% technical errors over 5 min,
  action: failover                 # the route is pulled from the pool (circuit breaker)

Cascading and failover

Failover automatically switches traffic to a backup route when the primary route stops responding. If the primary route is down (timeouts, 5xx errors, response code 91), the transaction moves to the secondary route with no manual intervention. Cascading (or cross-acquirer retry) covers a different case. After an issuer decline on route A, the transaction is resubmitted through route B. This works because the same issuer may respond differently depending on the acquirer submitting the transaction: the MID's reputation, domestic versus international channels, and the data in the message all play a part.

• Cascade only technical declines (91, timeouts) and, sparingly, generic declines (05), never hard declines (41, 43, 54, 57, MAC 03): scheme resubmission rules apply across acquirers, not per acquirer;
• Count attempts globally (card × merchant), across all acquirers, to stay within Visa and Mastercard retry limits;
• Limit the depth: one cascade (2 attempts) captures most of the gain; beyond that, cost and latency outweigh the benefit;
• Measure the net gain: cascade recovery rate − extra authorization fees − higher risk of double charging.

Payment orchestrators

A payment orchestrator is an abstraction layer that sits on top of PSPs and acquirers. The merchant integrates once. Behind that integration, the orchestrator provides connections to multiple providers, a provider-agnostic token vault, the routing and cascading engine, multi-provider 3DS, and unified reconciliation. The market includes independent specialists (Primer, Gr4vy, ProcessOut/Checkout.com, Payrails, CellPoint Digital, and others). Large PSPs also sell “orchestration” products, where the provider making routing decisions is also one of the places the traffic can go.

• Agnostic vault: credentials (encrypted PANs, network tokens) sit in a layer independent of the PSPs, which is what makes switching possible;
• Normalization: response codes, webhooks, and settlement formats standardized across providers;
• Routing console: rules can be changed without a deployment, with built-in A/B testing;
• Multi-PSP reconciliation: settlement files aggregated, with automatic matching from transaction to bank payout.

Monitoring, A/B testing, and KPIs

Payment performance monitoring means continuously tracking authorization, authentication, dispute, and cost metrics, measured on homogeneous segments rather than in aggregate. Issuer and route performance drifts all the time, with scoring updates, incidents, and seasonal fraud patterns. Managing it relies on segmented monitoring and controlled experiments. A single, overall approval rate blends populations too different to reveal what caused a change.

-- Auth rate, last 7 days vs previous 7, by issuer (highest volume)
WITH stats AS (
  SELECT
    issuer_name,
    bin_country,
    COUNT(*) FILTER (WHERE created_at >= now() - interval '7 days')          AS tx_7d,
    AVG(CASE WHEN approved THEN 1.0 ELSE 0 END)
        FILTER (WHERE created_at >= now() - interval '7 days')               AS ar_7d,
    AVG(CASE WHEN approved THEN 1.0 ELSE 0 END)
        FILTER (WHERE created_at >= now() - interval '14 days'
                  AND created_at <  now() - interval '7 days')               AS ar_prev
  FROM authorizations
  WHERE created_at >= now() - interval '14 days'
    AND is_retry = false                     -- NET auth rate: first attempts only
  GROUP BY issuer_name, bin_country
)
SELECT issuer_name, bin_country, tx_7d,
       round(ar_7d  * 100, 1) AS auth_rate_7d,
       round(ar_prev * 100, 1) AS auth_rate_prev,
       round((ar_7d - ar_prev) * 100, 1) AS delta_pts
FROM stats
WHERE tx_7d > 500                            -- minimum sample size
  AND (ar_7d - ar_prev) < -0.02              -- alert: drop > 2 pts
ORDER BY tx_7d DESC;
-- A drop at ONE issuer only = a problem at that issuer or with it
-- (new scoring model, ACS incident). A drop everywhere = a route problem.

• Randomize per transaction (not per day) to cancel out day-of-week effects;
• Segment the analysis by BIN country × brand × amount band, because an overall uplift can hide a regression in one segment;
• Sample size: detecting a 1-point gain on an auth rate of about 88% takes several tens of thousands of transactions per arm;
• Measure net margin (including fraud and costs), not just auth rate;
• Every new route goes through a canary release at 5–10% of traffic before full rollout.

The hidden costs of acceptance

Total cost of acceptance (TCA) covers every charge a merchant pays to accept card payments. The negotiated fee rate is only part of it. The other, less visible items include currency conversion, fees on declined transactions, behavioral scheme fees, and dispute handling costs. At high volume, these items often cost more than the acquirer margin itself.

Reconciliation is what surfaces these costs. It means matching each transaction to its net bank payout, line by line, using the acquirer's settlement files. That exposes the actual charges: the FX rate applied, itemized scheme fees, reserve holdbacks, and chargeback debits. Reconciliation done only in aggregate reveals cost drift 6 months late.