Payment network

Payment network orchestration — one API across card, bank, mobile and crypto rails.

topropay puts every payment network behind a single unified API. Visa, Mastercard, Amex, JCB, RuPay on card; SEPA, ACH, PIX, UPI (via partners), BLIK, iDEAL on bank rails; Apple Pay, Google Pay on mobile; USDC, USDT and majors on crypto via partner gateways. One routing engine, one ledger, eight network categories.

topropay router VISA MC AMEX SEPA PIX UPI* ACH USDC
One routing brain. Eight network categories on the rim.
8+
network categories under one API
60+
connected acquirers and PSPs
300+
methods globally
1
ledger across networks

Key benefits

Why orchestrating across networks wins on every axis

Four outcomes that show up consistently once card, bank, mobile and crypto networks share one orchestration layer rather than per-network plumbing.

  1. 01

    Every payment network behind one API

    Visa, Mastercard, Amex, JCB, RuPay, plus bank rails (SEPA, ACH, PIX, BLIK, iDEAL, PayID, OSKO), mobile rails (Apple Pay, Google Pay) and crypto rails (USDC, USDT, BTC, ETH via partner gateways). One integration in front of the lot; new networks ship as configuration, not engineering.

  2. 02

    Routing per network, per scheme, per BIN

    Authorisations route on the scheme network they belong to (Visa BINs to Visa-licensed acquirers, Mastercard BINs to MC-licensed acquirers, RuPay BINs to RuPay-licensed acquirers) and per BIN inside each network. The routing engine scores every authorisation in under 200ms against your own outcomes.

  3. 03

    Payment network tokenisation by default

    Scheme network tokens (Visa Token Service, Mastercard MDES) replace PANs at authorisation time and persist across card re-issuance. Vault tokens identify customers across networks for refunds, retries and recurring. Sensitive data never lands in merchant origin.

  4. 04

    One reconciliation feed across every network

    Settlements, fees, refunds and chargebacks from every network normalise into one ledger keyed off vault tokens. Per-network analytics surface inside the operator portal; the daily export tags every row with the network, scheme, acquirer and routing policy that ran it.

How it works

From network selection to a single ledger row

Five concrete stages between switching a network on and a normalised ledger row in tomorrow's finance export. Engineering integrates once; ops tunes the policies.

  1. 01

    Switch networks on

    Network coverage per merchant contract is dashboard-level — Visa, MC, Amex, SEPA, ACH, PIX, UPI (via partners), crypto via partner gateways. Adding a network later is a configuration step, not an integration project.

  2. 02

    Route per network

    Per-network routing policies — approval-, cost- or composite-weighted — sit next to method availability per market. The routing engine reads BIN, scheme, currency, country pair and risk on every authorisation.

  3. 03

    Authorise across the connected portfolio

    Every authorisation runs through the routing engine and lands on a connected acquirer licensed on the relevant network. Soft declines cascade to the next ranked acquirer inside the same request, where one is available on that network.

  4. 04

    Tokenise and reuse

    Card data captures into the PCI DSS Level 1 vault; scheme network tokens issue alongside. Refunds, retries and recurring all run on vault tokens — the merchant never deals with PAN data across networks.

  5. 05

    Reconcile from one ledger

    Settlements per network roll into one ledger; method, scheme, network and acquirer tags on every row let finance roll up by any axis. Daily exports drop into ERP or warehouse.

Main use cases

Where international payment network coverage earns its keep

Six merchant shapes that share the same orchestration layer but stress different slices of the network mesh — from consumer ecommerce to b2b invoicing and crypto.

  • B2C

    Consumer ecommerce across card networks

    Visa and Mastercard dominate consumer ecommerce in most markets — the merchant runs routing-weighted policies across multiple Visa- and MC-licensed acquirers in parallel and surfaces local rails (iDEAL in NL, PIX in BR) as a method tile alongside.

  • B2B

    B2B payment network for invoicing and supplier flows

    B2B payment network use cases combine corporate / commercial card rails with bank-rail invoicing (ACH, SEPA, PIX) and (where treasury wants it) stablecoins via partner crypto gateways. The platform handles all three under one API — invoices and corporate-card receipts share the same reconciliation feed.

  • Marketplace

    Marketplaces with multi-network payouts

    Per-seller payouts in BRL via PIX, in EUR via SEPA, in USD via ACH and (where applicable) in stablecoin via partner crypto rails — all through the same orchestration layer. Split-payment routing preserves per-seller economics across networks.

  • Mobile

    Mobile payment network coverage

    Apple Pay, Google Pay, Samsung Pay, Click to Pay and Alipay+ as a mobile payment network layer on top of the underlying card networks. The hosted pay sheet surfaces them per device class; the back-end shape is identical to card.

  • Cross-border

    International payment network for cross-border merchants

    International payment network coverage across Europe, the UK, APAC and LATAM with regional acquirer panels per network. EU card BINs route to EU acquirers, US BINs to US acquirers, AU BINs to AU acquirers — same integration, region-correct routing per scheme.

  • Crypto

    Cryptocurrency payment network rails

    Cryptocurrency payment network rails surfaced through licensed partner crypto gateways — stablecoins on L2s, majors on mainnet, optional conversion-on-receipt. Same authorisation API as card; same reconciliation feed for finance.

Network coverage

A sample of the connected networks

What the platform routes across out of the box. Per-merchant availability depends on contracted regions and vertical; the dashboard surfaces the live network set.

  • VISA Visa scheme
  • MC Mastercard
  • AMEX American Express
  • SEPA EU bank rail
  • PIX BR instant rail
  • UPI* IN bank rail
  • ACH US bank rail
  • USDC stablecoin (partner)

* India UPI / NetBanking is delivered through licensed partner gateways rather than a direct RBI Payment Aggregator licence held by topropay.

Platform features

Capabilities behind network payment solutions on the platform

What the platform ships across the network mesh — from the API surface up to the operator portal and reconciliation feed.

  • Unified network payment gateway API

    JSON-over-HTTPS REST surface across card, bank-rail, mobile and crypto networks; SDKs for web, mobile and server.

  • Multi-acquirer routing per network

    Per-network routing across multiple acquirers licensed on each network; weights tuned against your own approval, cost and dispute outcomes.

  • Cascade & retry

    Soft declines cascade to the next ranked acquirer inside the same authorisation; failure-mode-aware retry policies for recurring traffic.

  • Payment network tokenisation

    Scheme network tokens (Visa TR, Mastercard MDES) plus PCI DSS Level 1 vault tokens; PAN never leaves the platform.

  • Card payment network coverage

    Visa, Mastercard, Amex, JCB, Discover, RuPay across the connected acquirer panel.

  • Bank-rail network coverage

    SEPA, Bacs, ACH, PIX, BLIK, iDEAL, OXXO, PayID, OSKO, Interac — surfaced through one API per region.

  • Mobile payment network

    Apple Pay, Google Pay, Samsung Pay, Click to Pay and Alipay+ surfaced through the hosted pay sheet and embedded SDK.

  • Crypto payment network

    USDC, USDT, BTC, ETH and others via licensed partner crypto gateways; same API as fiat.

  • 3DS2 / SCA orchestration

    Selective authentication per transaction across card networks; PSD2-compliant in Europe without breaking conversion elsewhere.

  • Unified reconciliation

    Settlements, fees, refunds and chargebacks across every network normalised into one ledger.

  • Operator portal

    One dashboard for authorisations, refunds, disputes and chargebacks across every connected network.

  • Sandbox parity

    Sandbox that mirrors production for every network — card 3DS challenges, PIX bank confirmation, ACH R-codes, crypto chain confirmations.

Trust & compliance

Compliance posture across the network mesh

Every authorisation runs through a single audited environment. Merchants inherit the platform's posture rather than carrying separate certifications per network.

PCI DSS Level 1
Annual on-site assessment plus quarterly ASV scans; sub-merchants inherit the posture across card networks.
Scheme programme tracking
Visa VDMP / VAMP / VFMP and Mastercard ECP / EFMP thresholds tracked per acquirer relationship on every connected card network.
Bank-rail mandate handling
NACHA authorisations (ACH), SEPA mandate IDs (SEPA), BCB end-to-end IDs (PIX) captured and retained per scheme rules.
Crypto network compliance
Crypto rails delivered through licensed partner gateways with VASP / MiCA-relevant authorisations; address screening and Travel Rule support where applicable.
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 where current operating licences exist. Grey and black-market verticals are out of scope regardless of network.

Ready to orchestrate

Route across every payment network from one API.

A 30-minute network review covers the rails relevant to your traffic, the routing policies that fit your scheme mix, and a sandbox to test against before any commercial commitment.

Frequently asked

Buyer questions about payment network orchestration

Questions buyers ask before committing — covering card, bank, mobile and crypto networks, network tokenisation, B2B routing and per-merchant configuration.

  1. 01

    What does topropay mean by payment network in this context?

    Payment network here means the underlying rail an authorisation moves on — Visa, Mastercard, Amex, JCB, RuPay on the card side; SEPA, ACH, PIX, UPI, BLIK, iDEAL on the bank-rail side; Apple Pay, Google Pay, Samsung Pay on the mobile side; USDC, USDT, BTC, ETH (via partner gateways) on the crypto side. topropay sits across all of them with one API.

  2. 02

    How does the network payment gateway behave inside the unified API?

    The network payment gateway behaviour — authorise, capture, refund, dispute — runs through the same REST surface as every other rail. The merchant calls /v1/payments with a method field; the platform identifies the relevant network (Visa, MC, PIX, etc.) from the BIN, scheme or rail metadata and routes accordingly.

  3. 03

    What card payment network coverage does the platform support?

    Card payment network coverage spans Visa, Mastercard, Amex, JCB, Discover and RuPay across the connected acquirer panel. Per-merchant availability depends on the merchant's contracted regions and acquirer relationships — the dashboard shows the live state per scheme.

  4. 04

    How does a b2b payment network setup differ from B2C?

    A b2b payment network setup leans on corporate / commercial card rails (with Level 2 / Level 3 data where the merchant qualifies for interchange-optimised rates), plus bank-rail invoicing (ACH, SEPA, PIX) for higher-ticket counterparty payments. topropay handles all three under one API; B2B routing policies typically weight cost more heavily than B2C consumer policies.

  5. 05

    Are crypto payment network rails first-class or bolted on?

    Crypto payment network rails are first-class — surfaced through the same unified API as card and bank rails, via licensed partner crypto gateways. The routing engine, vault, webhooks and reconciliation feed all treat crypto authorisations the same way as card ones. The difference shows up in chain-confirmation timing and the optional conversion-on-receipt policy.

  6. 06

    What does cryptocurrency payment network coverage look like in practice?

    Cryptocurrency payment network coverage includes stablecoins (USDC, USDT, DAI, PYUSD) on multiple chains (Ethereum, Solana, Tron, Base, Arbitrum), majors (BTC via Lightning where supported, ETH on mainnet), and a configurable conversion-on-receipt policy per asset per merchant. Available rails per merchant depend on jurisdiction and vertical.

  7. 07

    What about international payment network coverage across regions?

    International payment network coverage spans Europe, the UK, APAC and LATAM through the connected acquirer panel. EU card BINs route to EU acquirers, US BINs to US acquirers, AU BINs to AU acquirers, with regional bank rails (SEPA in EU, ACH in US, PIX in BR, etc.) surfaced as separate methods. Settlement currency is a policy choice.

  8. 08

    What is payment network tokenisation and why does it matter?

    Payment network tokenisation replaces the PAN with a scheme-issued network token (Visa Token Service / VTS, Mastercard Digital Enablement Service / MDES) at authorisation time. The merchant runs subsequent charges against the token; the token persists across card re-issuance (so recurring keeps flowing), and sensitive PAN data is removed from the merchant's systems entirely. topropay enables network tokens by default for every supported scheme.

  9. 09

    Are network payment solutions on the platform sized for small merchants?

    Yes — network payment solutions on the platform carry no platform retainer, no monthly minimum and no per-environment fee. A small merchant gets the same routing engine, vault and reconciliation feed as an enterprise; pricing is per-authorisation on top of underlying acquirer / rail economics.

  10. 10

    How does the platform handle network payment systems that differ by region?

    Network payment systems differ by region in three axes: which schemes operate (Visa / MC everywhere, plus RuPay in India, Verve in Nigeria, etc.), which bank rails exist (SEPA in EU, ACH in US, PIX in BR), and which mobile rails dominate (Apple Pay / Google Pay broadly, Alipay+ in APAC). The platform abstracts the differences behind one API — the merchant configures per-market policy from the dashboard.

  11. 11

    What does mobile payment network coverage actually mean?

    Mobile payment network coverage on the platform includes Apple Pay, Google Pay, Samsung Pay, Click to Pay and Alipay+ — surfaced through the hosted pay sheet (web) and the embedded SDK (mobile apps). Behind the scenes these flows ride on the underlying card networks (Visa / MC) but the buyer experience is a tokenised tap rather than a card-form entry.

  12. 12

    Can a merchant disable specific networks they don't want to accept?

    Yes — network availability is a per-merchant dashboard configuration. A merchant who doesn't want to accept Amex, or who doesn't want crypto authorisations on their checkout, simply turns those networks off. The routing engine respects the policy on every authorisation.

  13. 13

    How does the dispute and chargeback flow work across networks?

    The unified dispute and chargeback queue surfaces cases across every connected network in one place. Scheme-specific evidence-pack templates (Visa, Mastercard chargeback codes; ACH return codes; SEPA disputes) accelerate response. Bank-rail networks like PIX don't carry a scheme chargeback cycle — those flows route into merchant-initiated refund handling instead.

  14. 14

    Is the sandbox close enough to production for each network?

    Yes. The sandbox supports deterministic helpers per network — card 3DS challenge / frictionless / decline outcomes, PIX bank-confirmation timing, ACH R-code rejections, SEPA mandate scenarios, crypto chain-confirmation simulation. Merchants build the full integration against the sandbox before commercial commitment.

  15. 15

    How does the orchestration layer compare to integrating directly with each payment network?

    Integrating directly with each payment network means a separate API per scheme, per bank rail and per crypto provider — each with its own webhook handler, error model and reconciliation file. topropay's orchestration sits one layer above and collapses the lot behind a single API contract — the merchant integrates once and accumulates network coverage as configuration.