Intelligent payment routing that scores every authorisation.
BazPay's intelligent payment routing picks the acquiring connection most likely to approve per BIN, method and currency. Soft-decline cascading lifts approvals inside the same shopper action, and the whole decision is visible on the charge object.
Built for merchants across the EU, UK, Australia, Canada and New Zealand who care about the approval rate that reaches settlement, not the one printed on a monthly summary. No separate orchestration vendor, no black box between your request and the network.
What payment routing changes for a merchant
Static configurations peak on day one and drift from there. A live routing engine holds approvals steady across BIN churn, issuer behaviour changes and scheme rule updates. Four things stay true for merchants using intelligent routing at BazPay.
-
Approvals lifted where merchants notice — the retry
Soft declines that would have failed once now cascade to a second connection with a better recent record for that BIN. The lift shows up on the same authorisation, not on the next scheme cycle.
-
One decision, visible per charge
The routing verdict, the rule set applied and the exemption claimed are stamped on the charge object. There is no black box between your request and the connection that authorised it.
-
Open-finance regulation-aware routing by default
The router reads the exemption engine before it picks a connection. Frictionless requests take the fastest path; step-up requests go where the 3-D Secure round-trip is fastest.
-
No new vendor to integrate
Intelligent routing runs on the same REST API and signed webhook stream you already use. There is no separate orchestration service to sign a second contract for or route your traffic through.
The signals the router reads on every charge
Four signal families feed the routing decision. None of them decides alone — the router blends them and grades every candidate connection against live approval history for that shopper profile.
-
BIN
BIN and issuer signals
The card's BIN identifies the issuing bank and the region. The router matches recent approval history for that issuer against each of our acquiring connections and picks the one with the strongest live signal.
- BIN region
- Issuer history
- Card type
-
Method
Payment method
Cards, device wallets and local payment methods take different paths. The router chooses the correct one from the payment_method flag on the request — no branching in your integration code.
- Card
- Wallet
- APM
- SEPA Instant
-
Currency
Currency and market
Presentment currency and shopper geography feed the routing decision. Same-currency, same-country pairings route to the connection with the best domestic approval profile.
- EUR
- EUR
- AUD
- 20+ more
-
Risk
Fraud verdict and 3-D Secure
The router reads the fraud engine's verdict and any SCA exemption before it picks a path. A trusted-beneficiary MIT and a frictionless one-off take different routes.
- Fraud verdict
- SCA exemption
- MIT flag
Payment-method depth on card and APM processing. The acquiring contract feeding the router on merchant acquiring.
The life of one routed authorisation
Six stages describe how the router evaluates, cascades and stamps a decision on every charge. Each stage is visible in the dashboard and each stage change fires a signed webhook.
-
Read
The router reads BIN, payment method, currency, risk verdict and any SCA exemption flag from the incoming charge request.
-
Score
Each candidate connection is scored on recent approval history for that BIN, current health and cost profile — the intelligent routing decision.
-
Authenticate
If the exemption engine cleared frictionless, the router picks the fastest path. Otherwise it targets the connection with the shortest 3-D Secure round-trip.
-
Post
The authorisation posts to the chosen connection with the authentication result bound to the transaction for issuer scoring.
-
Cascade
On a soft-decline reason code, the router re-attempts against a second candidate with a better recent profile — before the shopper sees an error.
-
Trace
The routing verdict, connection ID, cascade steps and exemption applied are stamped on the charge object and the signed webhook.
Native intelligent routing vs a bolted-on orchestrator
Both approaches work; they trade different things. A separate orchestration vendor gives you cross-processor reach. A native router gives you cleaner attribution and one fewer contract to renew. The comparison below shows the concrete axes.
| Dimension | BazPay native routing | Third-party orchestrator |
|---|---|---|
| Approval lift trigger | Inline soft-decline cascade | Post-hoc analytics only |
| Routing signals | BIN, method, currency, risk, MIT | Round-robin or none |
| Authentication integration | Router reads exemption engine | Authentication decided separately |
| Visibility | Per-charge routing trace | Vendor black box |
| Integration surface | Same REST endpoint, same webhook | Extra orchestration vendor |
| Reporting | Interchange++ per attempted connection | Blended per merchant |
Umbrella flow on payment orchestration. The software layer that hosts the router on network payment gateway. Buyer's comparison on payment processors.
Features that make the router earn its keep
Every capability below is available on the standard integration. Routing runs server-side by default; the primitives you need to observe, tune and audit it ship with the same account.
-
BIN-aware routing
Live approval history per BIN range drives the pick — not last quarter's average across everyone else's traffic.
-
Soft-decline cascading
Reason codes that mean "try again elsewhere" trigger a second attempt on a different connection within the same shopper action.
-
Open-finance regulation-aware routing
The router consumes the exemption engine's verdict — TRA, low-value, trusted-beneficiary, MIT — before it picks a path.
-
Method-aware routing
Cards, wallets and local APMs each have their own optimal connection graph; the router uses the payment_method flag transparently.
-
Currency-aware routing
Presentment currency and shopper geography inform the routing decision so domestic pairings land on domestic connections where possible.
-
Per-charge routing trace
Every charge object carries a routing_trace field with the connection selected, alternates evaluated and any cascade attempts logged.
-
Dashboard controls
Enforce or exclude specific routing rules from the dashboard — no engineering release needed for a routing policy change.
-
Signed webhook events
routing.decided and routing.cascaded events fire on the same signed-webhook stream as approvals, refunds and settlements.
The routing decision on the response object
The router runs server-side, so your create-charge call is unchanged. The response object gains a routing_trace field: which connection was selected, what alternates were considered and any cascade attempts that resolved before the shopper saw an error.
{
"id": "ch_02H9F...",
"status": "succeeded",
"amount": 12900,
"currency": "EUR",
"network": "visa",
"routing_trace": {
"policy": "bin_history_v3",
"selected": "conn_eu_a1",
"alternates": ["conn_eu_a2", "conn_eu_b1"],
"cascade": [
{ "connection": "conn_eu_a2", "reason_code": "05", "action": "retry" }
]
}
}The complete schema and every routing-related field lives in the API reference. Handler samples for the webhook events in the developer docs.
Where intelligent routing pays for itself
Every merchant type BazPay boards benefits from routing, but four profiles see the lift most quickly. Each uses the same API surface and the same signed-webhook stream.
-
Multi-country e-commerce
Storefronts serving several regional markets get domestic-shaped routing per shopper without stitching regional PSPs together.
-
Subscription software
Renewal traffic benefits most from BIN-aware routing — the same card that authorised last month gets the connection with the strongest recent record for its issuer.
-
Digital publishers
Low-ticket, high-volume books lift measurably when soft declines cascade to a second connection inside the same shopper action.
-
Professional services
Higher-ticket B2B invoices where a hard decline is a lost sale — routing plus step-up-when-necessary keeps the good ones through.
Out of scope for BazPay: adult, gambling, CBD, nutraceutical, forex, CFD, crypto-exchange, debt-collection and MLM. BazPay is not a marketplace of third-party PSPs.
Security, PSD2 and change control on the router
The router runs inside the PCI DSS Level 1 environment assessed each year — no card data leaves scope during routing. Authentication runs on every card route with automatic exemption logic where the rules allow, and routing-policy changes are audit-logged and reversible.
- PCI DSS Level 1
- Routing runs inside our PCI-audited environment; no card data leaves the scope
- Authentication
- 3-D Secure 2.2 with automatic exemption logic on every card route
- GDPR
- In-region data residency; DPA on request
- Scheme compliance
- Visa VIRP and Mastercard SPoC/PCI-CP registrations where required
- Change management
- Routing-policy edits are audit-logged; every version is reversible
Questions merchants ask about routing
What is intelligent payment routing, and how does it lift approvals?
Intelligent payment routing is the decision engine that picks which acquiring connection an authorisation posts to. It reads the card BIN, payment method, currency, SCA exemption and recent approval history per connection, then chooses the path most likely to approve. On soft declines, it cascades to a second connection inside the same shopper action — the lift shows up on the same authorisation attempt, not on a report next month.
How is dynamic payment routing different from a static rules table?
A static rules table sends traffic on a pattern like "Canadian cards go here, New Zealand cards go there" and never learns from what happens next. Dynamic payment routing evaluates recent approval history per BIN and per connection continuously, so the pick reflects live network conditions and issuer behaviour — not last quarter's averages baked into a config file.
Does BazPay's routing infrastructure route across third-party processors?
No. BazPay is a direct regional acquirer, not a marketplace of third-party PSPs. Intelligent routing here operates across BazPay's own acquiring connections and 3-D Secure pathways. That keeps the reporting clean — every alternate carries interchange++ line detail from the same platform — and removes the vendor-management overhead of a multi-processor orchestrator.
How does the router interact with authentication and 3-D Secure 2?
The router reads the exemption engine's verdict before it picks a connection. If the request qualifies for a frictionless flow (risk analysis, low value, trusted beneficiary or MIT), the fastest path is chosen. If a challenge is required, the router picks the connection with the shortest 3-D Secure 2.2 round-trip for that issuer's ACS. The authentication result is bound to the transaction for issuer scoring either way.
Do international payment routing decisions cover foreign-issued cards?
Yes. Cards issued outside the region authorise on BazPay's regional acquiring licence like any other card, and the router applies the same live-history logic to pick the best-performing connection for that BIN. The acquiring stays EU, UK and Commonwealth; the card networks are global, so international intelligent payment routing is a natural extension of the same engine.
Can I see which connection a charge routed to?
Yes. Every charge object carries a routing_trace field showing the connection selected, the alternates evaluated and any cascade attempts. routing.decided and routing.cascaded events fire on the same signed-webhook stream as approvals, so your reporting stack can reconstruct the full decision path per charge without polling a separate audit endpoint.
Do I need to change my integration to use payment routing infrastructure?
No. Intelligent payment routing is a native part of the BazPay REST API. Your create-charge call is unchanged — the router runs on the server side. Reading the routing_trace field is optional but useful; ignoring it means your integration behaves exactly as it did before the router was in play.
How do I turn a routing rule off or force a specific path for testing?
Routing policies are administered from the dashboard with audit logging and versioning. You can pin a specific connection for a subset of traffic, exclude a candidate from cascading, or roll back a policy edit at any time. For sandbox tests, override headers on the create-charge request let you force a specific route.
Route your traffic on live approval data
Share your monthly card volumes and existing gateway. An integration engineer will map the routing lift you can expect and the migration path within one working day. Related surface: payments solutions, open banking and payouts.