Smart routing

Smart routing — per-transaction scoring across every connected provider.

topropay's smart routing engine scores every card authorisation across the connected provider panel in under 200ms. The route most likely to clear at the lowest landed cost wins, the cascade absorbs soft declines, and one reconciliation feed makes the lot operational.

Book a routing review Read the API docs
routing score · BIN 4012 35•
routed to Acquirer A · approval-weighted policy
<200ms
routing decision per authorisation
BIN-level
scoring against your own outcomes
Cascade
on soft decline inside one request
1 ledger
across every connected provider

Key benefits

Why smart payment routing wins where a static gateway loses

Four outcomes that show up consistently once smart routing sits in front of the connected provider panel instead of a static single-provider gateway.

  1. 01

    Smart routing on every payment authorisation

    Every authorisation runs through the routing engine in under 200ms. The route most likely to clear at the lowest landed cost wins, scored against the merchant's own traffic — not against a static spec sheet. Routing happens inside the authorisation request; the merchant doesn't manage it transaction by transaction.

  2. 02

    Cascade absorbs soft declines inside the same request

    When the chosen provider returns a soft decline, the cascade rotates to the next ranked route inside the same authorisation. The shopper sees one clean result — approved or declined — not a per-provider retry loop. International traffic disproportionately benefits because cross-border declines are noisier than domestic ones.

  3. 03

    Pick the optimisation goal per segment

    Approval-weighted, cost-weighted, or composite — pick the policy per region, per BIN range, per scheme. Routing weights are dashboard-configurable and tuned against your real outcomes. A merchant that wins on conversion can compress cost; a merchant that wins on cost can lift approval.

  4. 04

    Every route tagged, every outcome reported

    Each authorisation tags the connected provider, BIN range and routing policy that ran it. The dashboard rolls outcomes up per route, per scheme, per region — so the next policy change is a data exercise rather than a guess. Routing is operational, not opaque.

How it works

From request to routed approval in five stages

Five concrete stages between a single POST and a written ledger row. The whole flow takes one round-trip from the merchant's perspective; the engine does the rest internally.

  1. 01

    Score the request

    BIN, scheme, currency, country pair, risk signals and merchant policy all feed into the score. The engine computes a ranked list of connected providers in under 200ms per authorisation.

  2. 02

    Run on the top-ranked provider

    The authorisation routes to the highest-scoring connected provider. The platform handles the per-provider message exchange; the merchant doesn't see the wiring.

  3. 03

    Cascade on soft decline

    If the top provider returns a soft decline (issuer transient, network, velocity, similar), the cascade rotates to the next ranked route — inside the same authorisation request, no second round-trip to the merchant.

  4. 04

    Capture the outcome

    Approve, decline or final hard-fail surfaces back to the merchant in one webhook event. The platform writes the provider ID, route score and decision latency to the ledger row.

  5. 05

    Tune from the dashboard

    Weekly reviews surface segments where a different provider or a different policy would improve net revenue. Adjustments are dashboard changes, not engineering releases.

Main use cases

Where routing for payment processing earns its keep

Six merchant shapes that share the same smart-routing engine but stress it differently — cross-border, SaaS, marketplaces, travel, cost-sensitive merchants and licensed high-risk verticals.

  • Cross-border

    Cross-border merchants selling globally

    Cross-border traffic benefits most from smart payment routing: the issuer-acquirer pair matters more than any other single factor for approval rate. Routing each authorisation to the regional acquirer most likely to win that pair compresses cross-border decline noise into measurable uplift.

  • SaaS

    Subscriptions and SaaS renewal recovery

    Renewal recovery is provider-sensitive: a card that declined on one acquirer may clear on another for reasons orthogonal to the card itself. Cascading across the connected portfolio converts a per-provider retry script into a routing-policy decision.

  • Plat

    Marketplaces and platforms

    Per-seller authorisations route to a sensible regional provider with one platform-side reconciliation. Per-tenant routing policies let a marketplace serve sellers across regions without per-seller integration work.

  • Travel

    Travel, ticketing and high-ticket

    High-ticket bookings benefit most from chargeback-aware routing — the route most likely to clear and the route best-equipped for the relevant dispute window are not always the same. Composite scoring weighs both.

  • Cost

    Cost-sensitive merchants on debit / low-margin tickets

    Cost-weighted routing on low-margin tickets compresses landed cost per authorisation. Same authorisation engine, different policy — the merchant moves the optimisation dial without a re-integration.

  • Risk

    Licensed high-risk verticals

    Verticals where direct provider underwriting is selective benefit most from chargeback-aware routing — the engine reads dispute risk per BIN and per route and tunes weights accordingly. Licensed operators only.

Platform features

Capabilities behind the smart routing payment gateway behaviour

What the platform actually ships for smart routing — beyond the general orchestration features shared with the rest of the platform.

  • Smart routing engine

    Per-transaction scoring on BIN, scheme, currency, country pair, risk signals and merchant policy.

  • Cascade & retry

    Soft declines cascade to the next ranked provider inside the same authorisation; nothing leaks back to the buyer.

  • Policy library

    Approval-weighted, cost-weighted, composite or custom per-segment policies — dashboard-configurable.

  • BIN-level analytics

    Per-BIN, per-scheme, per-currency outcomes feed back into the scoring model — your own traffic, not vendor benchmarks.

  • Provider-ID tagging

    Every authorisation tags the connected provider used; the ledger row carries provider, BIN, route score and latency.

  • Chargeback-aware scoring

    Dispute-risk weight per BIN and per route — the engine reads it on every authorisation, not just at policy-change time.

  • Network tokens & updaters

    Network tokens by default; scheme updaters keep saved cards alive across re-issuance events.

  • 3DS2 / SCA orchestration

    Selective challenges per transaction — PSD2-compliant in Europe without breaking conversion elsewhere.

  • Unified webhook events

    Signed, normalised webhooks fire on every state change; the event model is identical regardless of which provider ran the route.

  • Per-segment overrides

    Override the global policy for specific BIN ranges, schemes, geographies or amount bands — without forking the integration.

  • Sandbox parity

    Sandbox supports the full routing model — soft-decline cascade scenarios, multi-segment policies, scoring outcomes — for realistic testing.

  • Operator portal

    Per-route, per-segment, per-policy analytics — visible to ops and finance, not just engineering.

Trust & compliance

Compliance posture across every routed authorisation

Every authorisation runs through a single audited environment — regardless of which provider the engine routed it to. Merchants inherit posture rather than carrying separate certifications per provider.

PCI DSS Level 1
Annual on-site assessment and quarterly ASV scans; sub-merchants inherit the posture regardless of which provider the engine routed to.
SCA & PSD2
Selective 3DS2 on the authorisation path keeps approval high in Europe without skipping the compliance bar.
Scheme programme tracking
Visa VDMP / VAMP and Mastercard ECP / EFMP thresholds tracked per connected provider; dashboard alerts surface position vs limit.
Signed event delivery
Replay-safe webhooks with HMAC signatures; SIEM-friendly out of the box.
Data residency
Regional data-residency options for merchants under regulators that require it; EU-resident traffic stays in-region by default.
Licensed verticals only
Licensed gaming, regulated financial services and other compliance-bound verticals supported only where current operating licences exist. Grey and black-market verticals are out of scope regardless of integration shape.

Ready to tune the engine

Smart routing across every connected provider. One API.

A 30-minute routing review covers the policies that fit your traffic shape, the connected provider panel for your geographies, and a sandbox to test against before any commercial commitment.

Book a routing review Read the API docs

Frequently asked

Buyer questions about smart routing on topropay

Questions buyers ask before committing — how routing scores, what it tunes, how it interacts with cascade and recurring, and a clarification on competitor-vertical references.

  1. 01

    What is smart routing on a payment platform?

    Smart routing on topropay is the per-transaction scoring that picks which connected provider runs each authorisation — based on BIN, scheme, currency, country pair, risk signals and merchant policy. The decision happens in under 200ms inside the authorisation request; the cascade absorbs soft declines without a second round-trip to the merchant.

  2. 02

    How does routing payment differ from a static single-acquirer setup?

    Routing payment dynamically across many connected acquirers, each authorisation, beats a static single-acquirer setup on three axes: approval rate (the issuer-acquirer pair matters), landed cost (interchange and scheme fees vary per route), and resilience (an outage at one provider doesn't take the whole checkout with it). A static setup ships only the single provider's appetite.

  3. 03

    What does the smart payment routing engine actually score?

    Smart payment routing scores route fitness as a composite of BIN range, scheme, currency, country pair, risk signals, dispute history, provider uptime, and a merchant-policy weight (approval / cost / composite). The score is computed against the merchant's own outcomes, not vendor benchmarks — so a route that wins for one merchant might lose for another with a different BIN mix.

  4. 04

    Are smart payment systems the same as smart routing?

    Smart payment systems is a broader umbrella that often includes smart routing plus the surrounding tooling — operator portal, analytics, dispute queue, reconciliation. Smart routing specifically is the per-transaction scoring engine. topropay covers both: smart routing as the core engine, plus the smart-payment-systems surface around it.

  5. 05

    What does a smart payment solution include beyond routing?

    A smart payment solution on topropay includes smart routing, cascade, vault tokenisation, network tokens and scheme updaters, selective 3DS / SCA, dispute-queue tooling, multi-currency capture and unified reconciliation. Smart routing is the most-cited capability, but the value compounds when paired with the rest of the stack.

  6. 06

    How does a smart routing payment gateway integrate with the merchant's stack?

    A smart routing payment gateway integration on topropay is one REST endpoint with a method field plus webhook handler. The merchant doesn't pick the provider per authorisation — the platform's smart routing engine does. The merchant configures the policy (approval / cost / composite) and surfaces the outcome via the same webhook event model regardless of which provider ran the route.

  7. 07

    Is payment smart routing different from payment routing in general?

    Payment smart routing emphasises the scoring intelligence — per-BIN, per-scheme, per-route analytics tuned against the merchant's own outcomes. Generic payment routing might be a static rule set ('all Visa to acquirer A'); smart routing is the dynamic, score-based version. topropay does the dynamic kind.

  8. 08

    Can payment gateway routing rules be authored per BIN or per amount band?

    Yes. Payment gateway routing on topropay supports per-segment overrides — by BIN range, by scheme, by geography, by amount band, by MCC. The global policy still runs as the default; segment overrides take precedence where defined. All changes are dashboard-configurable; no engineering release.

  9. 09

    How does cascading work alongside smart routing on retries?

    On soft decline, the cascade rotates inside the same authorisation request to the next ranked route — the engine has already scored the candidates. On the next renewal attempt for a recurring transaction, the engine recomputes scores with updated signals (account-updater event, BIN refresh, time-of-day, recent outcomes) and may pick a different route from the previous attempt.

  10. 10

    Does the platform support 'BNA Smart Payment Systems Ltd' / gambling-vertical providers?

    BNA Smart Payment Systems Ltd is a separate gambling-vertical PSP — not affiliated with topropay. Licensed online-gambling operators integrate with topropay's smart-routing engine like any other licensed merchant; routing weighs the connected gambling-vertical-friendly providers in the panel against the operator's BIN and chargeback profile. Unlicensed gambling and grey-market betting are out of scope regardless of any provider's claims.

  11. 11

    Is smart routing compatible with sub-merchant onboarding?

    Yes. Sub-merchants on topropay's acquirer relationships inherit the smart-routing engine by default — each sub-merchant gets its own policy and its own per-route analytics. The platform's routing engine doesn't know or care whether the merchant is direct or sub; it scores routes the same way.

  12. 12

    How is the routing for payment processing tuned over time?

    Routing for payment processing on topropay is tuned by feeding production outcomes back into the scoring model. Weekly reviews surface segments where a different route would have improved approval / cost / dispute. Adjustments to policy weights, per-segment overrides and new provider routes happen from the dashboard.

  13. 13

    Can a merchant pin certain BINs to a specific provider regardless of scoring?

    Yes — per-segment overrides let a merchant pin specific BIN ranges (or specific schemes / countries / amount bands) to a chosen provider for compliance, contractual or risk reasons. The smart routing engine respects the pin and skips scoring for those segments.

  14. 14

    What's the difference between smart routing and load-balancing across providers?

    Load-balancing distributes traffic evenly (or by share) across providers regardless of expected outcome. Smart routing distributes traffic based on per-transaction expected outcome — approval, cost, dispute risk. Load-balancing optimises for capacity; smart routing optimises for net revenue. topropay's engine is the latter.

  15. 15

    Does smart routing affect chargeback rates?

    Yes — composite scoring weighs dispute-risk per route alongside approval and cost. A high-dispute BIN routed through a provider with a chargeback-friendly representment workflow can net higher than the same BIN routed through a provider that doesn't. Routing isn't just about the front-end authorisation; it touches the back-end dispute lifecycle too.

Related

Related on the topropay platform