Bank-rail orchestration · multi-bank
topropay routes every authorisation across a panel of licensed acquiring banks, cascades soft declines inside the same auth, captures stored credentials in a PCI L1 vault, and gives finance one reconciliation feed across every connected bank.
Who holds what
topropay doesn't hold the banking licence. Five categories that sit with the connected acquiring bank by design.
What sits with topropay: the unified API, the PCI L1 vault, the routing engine, the unified dispute queue and the reconciliation feed across the panel.
Key benefits
Four properties that show up the moment volume stops sitting behind a single acquiring bank and starts routing across a panel.
The merchant integrates against topropay's unified API once. The connected panel of licensed acquiring banks sits behind it; adding or rotating a bank relationship is a routing-policy change, not an integration project.
Per-BIN, per-currency, per-country scoring picks the right acquiring-bank lane for each authorisation. Soft declines cascade to the next ranked bank inside the same auth without surfacing to the buyer.
ACH, SEPA Direct Debit, Bacs, Open Banking, PIX, PayID and OSKO surface through the same API as card. Bank-rail-specific mandate handling (NACHA, SEPA mandates) is carried per scheme rules.
Settlements, interchange, scheme fees, bank-side fees, refunds, returns and chargebacks from every connected bank normalise into one ledger. Finance reads one feed, not one per acquirer.
How bank payment processing flows
What happens between the buyer's card entry and the row in the merchant's general ledger when bank-side routing runs through topropay.
topropay's connected acquiring-bank relationships are enabled per merchant; each bank holds the relevant scheme licence (Visa, Mastercard, Amex, regional) and rail authorisations.
The routing engine scores every acquiring-bank lane on BIN, scheme, currency, country pair and risk — including bank-side dispute-programme posture (VDMP / VAMP / VFMP, ECP / EFMP).
Each authorisation runs through the top-ranked acquiring bank; if it returns a soft decline, the next ranked bank receives the retry inside the same authorisation.
Clearing follows the connected bank's scheme calendar. Settlement files flow into topropay's ingestion pipeline tagged with the originating bank, BIN and scheme.
Daily exports normalise every connected bank's settlement file into one ledger. Per-row tags surface the originating bank, scheme programme position and currency for finance.
Main use cases
Six regional and structural shapes where multiple connected acquiring banks beat sitting behind a single one.
Card and SEPA Direct Debit volumes route across multiple connected EU acquiring banks; per-country interchange optimisation runs inside the routing engine.
UK card-scheme acceptance plus Bacs Direct Debit and Open Banking via licensed UK acquiring-bank relationships, surfaced through one API.
Visa, Mastercard, Amex, Discover plus NACHA-compliant ACH routed across multiple US acquiring banks; soft declines cascade between US lanes.
Australian PayID / OSKO (NPP) plus card-scheme acceptance via licensed AU partner acquiring banks. Singapore and NZ connectivity sit behind the same API.
Brazilian PIX and Boleto rails via partner-licensed institutions surface alongside card-scheme acceptance in one merchant record.
Resellers inherit the connected acquiring-bank panel and configure independent routing per downstream merchant; the PSP keeps the relationship, the platform handles the message exchange.
Platform features
Twelve capabilities the platform ships once and reuses across every connected acquiring bank.
One REST contract for card-acquiring-bank, ACH, SEPA, Open Banking, PIX, PayID and Bacs connectivity.
BIN-table-aware scoring picks the right acquiring bank per issuer / scheme / country pair.
Soft declines cascade to the next ranked acquiring bank inside the same authorisation without leaking to the buyer.
Card data captures into the PCI L1 vault before any bank sees it; vault tokens drive refunds, recurring and retries.
Scheme network tokens by default for card; updaters keep tokens alive across re-issuance.
NACHA authorisations for US ACH; SEPA mandate IDs for SEPA Direct Debit; Bacs mandates per scheme rules.
Selective EMV 3DS2 per PSD2 exemption logic; frictionless flows pass through; step-up where issuer or amount require it.
Card chargebacks, ACH returns and SEPA SDD recalls share one queue; evidence-pack templates per vertical.
Visa VDMP / VAMP / VFMP and Mastercard ECP / EFMP positions surfaced per connected acquiring bank.
Refunds require justification; every refund event logged with actor identity, reason code and timestamp for audit.
Lifecycle transitions fire signed, replay-safe webhooks; accounting-system connectors push receipts to the merchant's ERP.
Settlements, fees, refunds and chargebacks from every connected bank normalise into one ledger; per-row bank, BIN, scheme and currency tags.
Industry relevance
topropay's bank-panel posture targets licensed merchants operating across EU, UK, APAC, LATAM and the US. India connectivity is delivered through licensed partner gateways (RBI Payment Aggregator-authorised); topropay doesn't hold a direct RBI licence. Licensed gaming operators are supported where current operating licences exist — casino bank payment methods route through licensed gaming-tolerant acquiring banks where the scheme programme posture is healthy.
Trust & compliance
One audited environment plus per-bank scheme programme positions surfaced in the dashboard. Sub-merchants inherit the relevant posture without carrying separate certifications themselves.
Ready to put bank-rail volume on a panel
A 30-minute bank-panel review covers the connected acquiring banks relevant to your geographies, routing weights tuned to your BIN mix, mandate handling for ACH / SEPA / Bacs, and a sandbox to test against before any commercial commitment.
Frequently asked
Definitions, bank-side responsibilities, ACH / SEPA / Bacs mechanics, India connectivity, licensed-gaming posture and the practicalities of running on a panel.
On topropay, bank payment system describes the unified API and orchestration layer that sits in front of multiple licensed acquiring banks. The merchant integrates once; the platform routes each authorisation across the connected bank panel, captures stored credentials in the PCI L1 vault, and exposes one reconciliation feed across every bank settlement.
No. topropay is the orchestration layer — it doesn't hold a banking licence and doesn't act as an acquiring bank. The acquiring relationships and the per-region scheme licences sit with licensed acquiring banks in each target geography. topropay routes between them, holds the vault, and normalises reconciliation.
The bank payment gateway role on topropay is filled by the unified gateway sitting in front of the connected acquiring-bank panel. The gateway tokenises card data into the vault, builds the authorisation request, picks the right acquiring bank via the routing engine, and surfaces the response back to the merchant — all through one API contract.
Bank payment processing on topropay runs: tokenise card data into the vault → routing engine scores the connected acquiring-bank lanes for the authorisation → top-ranked bank receives the auth → soft declines cascade to the next bank → capture follows scheme rules → settlement file ingested → reconciliation row added to the unified ledger with the originating bank tagged.
Yes — that's the model. The acquiring bank holds the licence, the scheme membership and the merchant agreement on the bank side; topropay's gateway runs in front of it, handling vault, routing, dispute aggregation and reconciliation. For the merchant, the result is one API in front of many acquiring-bank gateways.
A commercial bank payment gateway is the same shape from the bank's perspective — a commercial bank's acquiring arm connected into topropay's panel for routing. The merchant doesn't pick one commercial bank gateway; the merchant gets routing across the connected commercial-bank panel, plus non-commercial-bank acquirers where relevant.
bank payment gateway india connectivity is delivered through licensed partner gateways operating with RBI Payment Aggregator authorisations. topropay doesn't hold a direct RBI Payment Aggregator licence; the merchant doesn't need their own RBI relationship — Indian card and UPI volume rides the partner connectivity behind the unified API.
ACH and SEPA Direct Debit sit on the same authorisation engine as card. NACHA mandate handling and SEPA mandate IDs are captured at first authorisation; recurring debits use the same vault token model as card-on-file. Returns (ACH R-codes) and SEPA recalls share the unified dispute queue with card chargebacks.
Casino bank payment methods are supported only for licensed gaming operators with the relevant operating licences in their target markets (UKGC, MGA, ANJ, KSA / KGC, etc.). The connected acquiring-bank panel includes gaming-tolerant licensed banks where the scheme programme posture is healthy. Unlicensed gambling operations are out of scope regardless of the connecting bank.
The bank payment api is a REST API with JSON-over-HTTPS, signed webhooks for lifecycle events, and SDKs for web, mobile and server. The same endpoints carry card, ACH, SEPA, Open Banking and regional rail authorisations — scheme detection runs against the BIN or rail identifier.
Integrating one acquiring bank directly means owning the bank-specific integration, the per-rail message format, the BIN-table-aware routing logic and the bank-side reconciliation normalisation. topropay's panel approach delivers the same outcome (per-authorisation bank selection across many connections) without per-bank integration projects on the merchant side.
If a connected acquiring bank suspends a vertical, its score drops in the routing engine and authorisations route to the next ranked bank automatically. Dashboard alerts surface the suspension; if no alternative bank covers the vertical, the platform flags it to the operator rather than silently failing authorisations.
Yes. Per-merchant routing policies in the dashboard let the merchant pin specific BIN ranges, currencies or country pairs to specific acquiring banks. Manual pins coexist with the scoring engine; the policy editor surfaces the resulting routing behaviour for review.
Bank-side fees, interchange, scheme fees, and per-rail processing fees normalise into the unified reconciliation feed, tagged per row with the originating bank, fee category and currency. Finance reads net-of-fee receipts and can decompose by fee type on demand.
Most merchants move from a single bank gateway to topropay in 2–6 weeks, including KYB, sandbox testing and a phased traffic cutover. Many run topropay alongside the existing bank during the cutover so approval, cost and dispute outcomes can be measured per acquiring bank before absorbing the rest of the volume.
Related