Bank processing
Bank processing — many acquirer banks behind one API.
topropay's orchestration layer puts every connected acquirer bank behind one API. On each payment, the routing engine reads the issuer BIN and picks the acquirer bank most likely to approve it. Soft declines retry on the next bank. Every settlement lands in one ledger.
- Many
- connected acquirer banks
- REST
- unified bank-processing API
- <200ms
- routing decision
- 1 ledger
- across every acquirer bank
The three roles
Issuer bank, acquirer bank, scheme — how they fit together
Bank processing has three roles. The merchant's gateway never talks to the issuer directly. It sends each payment to the acquirer bank, and the acquirer uses the scheme rails to reach the issuer. topropay sits on the merchant's side of that picture.
- Issuer bank
The issuer bank is the bank that gave the card to the shopper. It approves or declines each payment against the cardholder's account, applies any 3DS or SCA challenge, and settles the funds to the acquiring bank on the scheme's clearing cycle.
- Acquirer bank
The acquirer bank is the licensed bank that processes the payment for the merchant under one or more scheme licences (Visa, Mastercard, Amex, and so on). It takes the request from the merchant's gateway and sends it through the scheme to the issuer. It then settles the funds to the merchant — or to an aggregator that pays its sub-merchants.
- Scheme
The card scheme (Visa, Mastercard, Amex, Discover, JCB) is the rails between the issuer and the acquirer. It sets the message format, the clearing cycle, the interchange and the dispute calendar. It also runs programmes like VDMP, VAMP, VFMP and ECP, which the acquirer bank tracks per merchant.
Key benefits
Why orchestrated bank processing wins on every axis
Four outcomes we see again and again once an orchestration layer sits in front of the traffic, in place of a single direct relationship.
- 01
Many acquirer banks behind one bank-processing API
Bank processing on topropay is one REST API in front of a panel of connected acquirer banks. The merchant integrates once. From there, the routing engine sends each payment to the right acquirer bank. The platform absorbs the complexity of the many bank relationships.
- 02
Per-transaction routing on every authorisation
Each payment runs through the routing engine in under 200ms. We score the routes on the merchant's own results and pick the one most likely to approve at the lowest cost. If a bank soft-declines, the next bank in line takes over in the same request. The buyer sees one clean result.
- 03
Issuer-bank-aware routing
The routing engine reads the issuer bank's BIN profile — country, scheme tier, product type. It then picks the acquirer bank most likely to win that exact pair. Cross-border pairs get the route that has cleared them best in the past, not a one-size-fits-all default.
- 04
One reconciliation feed across every acquirer bank
Settlements, fees, refunds and chargebacks from every acquirer bank flow into one ledger, keyed off vault tokens. Finance closes the month from a single export instead of merging a CSV per bank. Every row is tagged with the acquirer bank ID, the issuer BIN and the routing policy.
How it works
From bank-panel mapping to live processing in five stages
Five stages take you from picking the right acquirer banks to live traffic in production. Most merchants go live in weeks. The rest is tuning.
- 01
Map the acquirer bank panel to your traffic
A short discovery finds the acquirer banks that best fit the merchant's traffic. We look at geography, scheme split, BIN bands, MCC, average ticket and chargeback profile.
- 02
Onboard once, sub-merchant on the platform's acquirer relationships
Underwriting and KYC run through topropay's sub-merchant model. The merchant integrates once. The platform handles the per-bank paperwork that would otherwise repeat for each relationship.
- 03
Route each authorisation across the panel
Every payment goes through the routing engine. It scores each route on BIN, scheme, currency, country pair and risk, then picks the one most likely to approve at the lowest cost. On a soft decline, it moves to the next route in the same request.
- 04
Capture, refund and dispute through the same API
Captures, refunds and dispute responses all run against vault tokens through the same API. It does not matter which acquirer bank handled the original payment.
- 05
Reconcile across acquirer banks from one feed
Each acquirer bank settles on its own schedule and file format. topropay merges them all into one ledger, keyed off vault tokens. Daily exports drop straight into your ERP or warehouse.
Main use cases
Where a multi-acquirer-bank setup earns its keep
Six kinds of merchant share the same orchestration layer but stress the bank panel in different ways: DTC, SaaS, marketplaces, PSPs, travel and licensed high-risk verticals.
- DTC
Cross-border DTC and online retail
Merchants in the EU, US and APAC that sell worldwide need an acquirer bank in each region to keep interchange and disputes local. A US-issued card should run through a US acquirer; an EU-issued card, through an EU one. topropay routes each card for you.
- SaaS
Subscriptions and SaaS
Renewal recovery depends on the acquirer bank. A card that fails on one bank may clear on another for reasons that have nothing to do with the card. Cascading across the panel turns a per-provider retry script into a simple routing policy.
- Plat
Marketplaces and platforms
Marketplaces often have sellers in countries that no single acquirer bank covers well. Multi-acquirer routing helps most here. Each seller's payments go to a sensible regional bank, with one reconciliation for the whole platform.
- PSP
PSPs and ISVs reselling capacity
Resellers ride the platform's acquirer-bank portfolio. Their merchants inherit the routing, the BIN-level reporting and the unified reconciliation. The PSP keeps the relationship and sets the pricing.
- Travel
Travel and ticketing
Disputes on high-value bookings can turn on which acquirer bank handled the original payment. Being able to route to the bank best suited to that BIN and dispute window protects the margin.
- Risk
Licensed high-risk verticals
Some verticals find direct acquirer-bank underwriting hard to get. A curated multi-bank panel helps: chargeback-aware routing tuned to each MCC and chargeback band.
Platform features
Capabilities behind the bank processor relationships
What the platform ships for working with a panel of acquirer banks: the API, the routing engine, the dispute queue and the operator portal.
-
Unified bank-processing API
One REST contract across every connected acquirer bank; SDKs for web, mobile and server.
-
BIN-level routing
Per-BIN, per-scheme, per-currency routing weights — scored against the merchant's own outcomes.
-
Cascade & retry
Soft declines cascade to the next ranked acquirer bank inside the same authorisation; nothing leaks back to the buyer.
-
Acquirer-ID reporting
Every authorisation tags the acquirer bank ID and BIN used; analytics roll up per bank, per scheme, per region.
-
PCI DSS Level 1 vault
Card data captures into the platform's vault before it touches any acquirer bank; vault tokens drive refunds, retries and recurring.
-
3DS2 / SCA orchestration
Selective challenges per transaction across the acquirer-bank panel — PSD2-compliant in Europe without breaking conversion.
-
Network tokens & updaters
Network tokens by default; scheme updaters keep saved cards alive across issuer-bank re-issuance events.
-
Dispute & chargeback queue
Unified queue across acquirer banks; evidence-pack templates per vertical; automated representment for select scheme types.
-
Scheme programme tracking
Visa VDMP / VAMP / VFMP and Mastercard ECP / EFMP thresholds tracked per acquirer-bank relationship — surfaced in the dashboard.
-
Settlement currency policy
Settlement currency per acquirer bank is a configuration choice; merchants don't carry FX they didn't ask for.
-
Operator portal
One dashboard for authorisations, refunds, disputes and chargebacks across every connected acquirer bank.
-
Sandbox parity
Per-environment sandbox that mirrors production — routing, cascade, 3DS, settlement and chargeback scenarios across the bank panel.
Trust & compliance
Compliance posture across the acquirer-bank panel
Every acquirer-bank relationship sits inside the platform's audited environment. Sub-merchants inherit that posture, so they don't carry a separate certification per bank.
- PCI DSS Level 1
- Annual on-site assessment and quarterly ASV scans; sub-merchants inherit the posture across the connected acquirer-bank panel.
- Scheme programme tracking
- Visa VDMP / VAMP / VFMP and Mastercard ECP / EFMP thresholds tracked per acquirer bank with dashboard alerts.
- SCA & PSD2
- Selective 3DS2 on the authorisation path keeps approval high in Europe without skipping the compliance bar.
- Sanctions & AML alignment
- Sanctions screening on onboarding; AML monitoring tuned per merchant vertical and per acquirer-bank appetite.
- 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 map the panel
One API in front of every acquirer bank that fits your traffic.
A 45-minute review walks through the acquirer-bank panel for your regions and BIN mix. We cover the routing policies that suit your traffic, plus a sandbox to test against — all before any commitment.
Frequently asked
Buyer questions about bank processing on topropay
Questions buyers ask before they commit — on the issuer / acquirer / scheme triangle, routing across acquirer banks, pricing and sandbox parity.
- 01
What does topropay mean by bank processing?
Bank processing on topropay is the back-end side of card payments. It covers routing payments across connected acquirer banks, the scheme messaging, the clearing and the settlement. The merchant builds against one API. The platform handles the bank relationships, the scheme messaging, and the settlement and reporting for each bank.
- 02
What is an acquirer bank, in plain terms?
The acquirer bank — also called the acquiring bank — is the licensed bank that processes card payments for the merchant under one or more scheme licences. It takes the request from the merchant's gateway and sends it through the scheme to the issuer. It then settles the funds to the merchant, or to an aggregator that pays its sub-merchants.
- 03
What's the difference between acquirer bank and issuer bank?
The acquirer bank holds the relationship with the merchant. The issuer bank holds the relationship with the cardholder. On each payment, the merchant's gateway sends the request to the acquirer bank, which passes it through the scheme to the issuer bank for approval. The funds settle back along the same path, on the scheme's clearing cycle.
- 04
How does the acquirer bank and issuer bank pair affect approval rates?
Outside fraud signals, the acquirer-and-issuer pair affects approval rates more than any other single factor. A US-issued card usually clears better through a US acquirer than through an EU one. A UK debit card usually clears better through a UK acquirer than a US one. topropay's routing engine reads the issuer BIN and picks the acquirer bank most likely to win that pair.
- 05
Does the order matter when we say issuer and acquirer bank?
By convention we say 'issuer and acquirer bank' when we describe the flow. The issuer authorises against the cardholder's account first. The acquirer bank then handles the messaging and the merchant-side settlement. Either order is fine in industry usage. The flow is the same.
- 06
What about issuer bank and acquirer bank for international cardholders?
The pairing matters most for international cardholders. Take a French-issued card paying a Spanish merchant. It clears differently depending on whether the merchant's acquirer is licensed in the EU or outside it. An EU acquirer gets intra-region rates and a better approval profile; a non-EU one gets cross-region rates and a different decline curve. topropay routes each pair to the route most likely to win it.
- 07
How does an issuer and acquirer bank routing decision happen in practice?
The routing decision happens in milliseconds. The engine reads the issuer BIN. It looks up the merchant's policy and past results for that BIN range across the panel. It scores each candidate route and picks the highest one. The decision lands inside the same payment request, with no extra round-trip.
- 08
Is topropay itself an acquirer bank?
topropay is not a direct acquirer bank in every market. It is an aggregator that connects to several licensed acquirer banks and routes traffic across them. The merchant joins as a sub-merchant on the platform's bank relationships. It inherits the underlying licences instead of holding direct acquirer contracts of its own.
- 09
What does bank processor mean in this context?
'Bank processor' and 'processing bank' are loose synonyms for acquirer bank — the bank that processes the card payment for the merchant. Usage varies. Some teams use 'bank processor' for the technology side and 'acquirer bank' for the licensing side. In most cases they mean the same bank.
- 10
How does processing bank selection happen on the routing engine?
The routing engine picks the processing bank per payment. It scores the panel on approval likelihood, cost and dispute risk for the exact BIN, scheme, currency and country pair, then picks the top route. It repeats this on every payment.
- 11
Can a merchant keep an existing acquirer-bank relationship and add topropay on top?
Yes. Most merchants with a direct acquirer-bank relationship add topropay alongside it. The platform sits in front and routes extra traffic across the rest of the portfolio, while the existing relationship stays in place. You gain options without having to exit a contract.
- 12
How does bank processing handle cross-border interchange?
Cross-border interchange is the higher fee acquirers pay when the cardholder's country differs from the merchant's. The routing engine weighs it on every payment. When the merchant has a bank in the cardholder's region, routing there keeps the payment intra-region and the interchange domestic.
- 13
What scheme programmes does the platform track per acquirer bank?
The platform tracks Visa VDMP (chargeback monitoring), VAMP (acquirer monitoring) and VFMP (fraud monitoring), plus Mastercard ECP and EFMP, for each acquirer-bank relationship. Dashboard alerts fire when a merchant's chargeback or fraud ratio nears a threshold. That gives the merchant time to act before the acquirer's own monitoring kicks in.
- 14
How is bank processing priced on the platform?
Bank processing on topropay is priced per payment, on top of the underlying acquirer-bank economics. Interchange and scheme fees pass through where the acquirer supports it. The platform fee is a separate line on the invoice. There is no retainer and no monthly minimum.
- 15
How is the multi-acquirer-bank model different from just adding more gateways?
Multi-acquirer routing is about the back end: you choose which acquirer bank actually processes the payment. Adding more gateways changes what the merchant builds against, but it need not change the bank-processing outcome. topropay does both at once: one gateway to integrate on the front, and smart routing across many acquirer banks on the back.
Related
Related on the topropay platform
- Entity Acquirer overview Deep-dive on the acquirer entity — scheme relationships, BINs, acquirer-IDs.
- Service Acquiring service Acquiring as a service — the operational shape behind a multi-bank panel.
- TPPP Third party payment processor The sibling page — same multi-provider model from the TPPP framing, including PSP and sub-merchant detail.
- Bank Acquiring bank overview The licensed-institution framing of the multi-bank panel — what an acquiring bank is and how routing rides multiple licences.
- Routing Smart routing & cascading The per-transaction scoring engine that picks an acquirer bank per authorisation.
- Pair Acquirer & issuer pair The four-party model — how the issuer BIN drives the acquirer choice on every authorisation.