Acquirer
topropay sits in front of many licensed acquirers — across Europe, the UK, APAC and LATAM. For each payment, routing picks the right acquirer. And one ledger reconciles the money across every acquirer ID and BIN range you use.
The short version
A merchant acquirer is a licensed institution. It processes card payments for merchants under one or more scheme licences. It holds the link to Visa, Mastercard and the other networks. It takes the payment, captures the funds, and pays them to the merchant — or to an aggregator, which then pays its sub-merchants.
For a merchant in one market and one vertical, a single acquirer usually works. For everyone else, one acquirer is where the trouble starts. You get one underwriting appetite, one rate card, one chargeback ratio, one uptime story. topropay sits in front of several. So the question stops being "which acquirer" and becomes "what's the right routing policy".
The rest of the page fills in the picture. How the platform routes across many acquirers. What acquirer BIN and acquirer ID mean in the data model. And how the connected acquirers line up with Visa, Mastercard and the other networks.
Key benefits
Put the orchestration layer in front of the acquirer panel — instead of one direct acquirer — and four outcomes show up again and again.
topropay's portfolio holds licensed acquirers across Europe, the UK, APAC and LATAM. To your integration, the whole set is one unified API. To the routing engine, each acquirer is a lane — scored on every payment against your own traffic.
BIN, scheme, currency, country and risk signals pick which acquirer runs each payment — in under 200ms. The routing weight that wins is the one your real traffic backs, not the one a sales call argued for.
If the chosen acquirer returns a soft decline, the payment cascades to the next-ranked acquirer — inside the same request. The buyer sees one clean result, not a retry loop across acquirers.
Settlements, fees, refunds and chargebacks from every acquirer flow into one ledger, keyed off vault tokens. Finance closes the month from a single export — no matter how many acquirer-ID rows sit upstream.
How it works
Six stages. The engineering work is front-loaded, and ops gets simpler after that. Most merchants go live within weeks. The rest is tuning, not re-platforming.
Map your traffic — geography mix, scheme split, BIN bands, average ticket — against the connected acquirer panel.
Underwriting and KYC run through the sub-merchant model. You integrate once, and the platform handles the per-acquirer paperwork.
Pick routing policies per segment, set risk thresholds, switch on the methods relevant per market — all from the dashboard.
Live traffic flows through the routing engine. Soft declines cascade to the next-best acquirer, inside the same request.
Daily settlement and dispute exports per acquirer roll into one normalised ledger keyed off vault tokens.
Weekly reviews show where a different acquirer, or a different policy, would lift net revenue.
The data model
The acquirer BIN is one of the richest identifiers in card payments. The platform reads every part the routing engine can use. It then shows them in dashboard analytics, keyed off acquirer ID.
Main use cases
Six kinds of merchant use the same orchestration layer. Each one stresses the acquirer panel in its own way — same product, different routing policy.
European DTC brands sell into the US, UK and APAC. They need an acquirer in each region to keep interchange and dispute outcomes local. The platform routes EU card BINs to EU acquirers, US BINs to US acquirers, and so on — one integration, routing that fits each region.
Renewal recovery depends on the acquirer. A card that declined on one acquirer may clear on another, for reasons that have nothing to do with the card. Cascading across acquirers turns a per-provider retry script into a simple setting.
A marketplace's sellers often span countries that no single acquirer covers well. Multi-acquirer routing keeps each seller's payments and payouts on a sensible regional acquirer. Reconciliation still happens once, on the platform side.
On a high-ticket booking, a dispute can hinge on which acquirer handled the original payment. So keep the option to route to the acquirer best suited to that BIN and dispute window. It protects your margin.
Resellers ride the platform's acquirer portfolio. Their merchants inherit multi-acquirer routing, BIN-level reporting and unified reconciliation. The PSP keeps the relationship and the pricing.
Some verticals find direct acquirer underwriting hard to get. A curated multi-acquirer panel helps: chargeback-aware routing across acquirers, tuned to each MCC and chargeback band.
Scheme relationships
Routing weights, dispute calendars and scheme programmes differ by network. The platform runs both as parallel lanes on the same orchestration surface.
Platform features
What the platform ships for working with many acquirers — on top of the general orchestration features every merchant gets.
One REST contract across every connected acquirer; SDKs for web, mobile and server.
Per-BIN, per-scheme, per-currency routing weights — scoring against your own outcomes.
Every authorisation tags the acquirer ID and BIN used; analytics roll up per acquirer, per scheme, per region.
Soft declines fail over to the next ranked acquirer inside the same authorisation; nothing leaks back to the buyer.
Card data captures into our vault before it touches any acquirer; vault tokens drive refunds, retries and recurring.
Network tokens by default; scheme updaters keep saved cards alive across acquirer re-issuance events.
Selective authentication per transaction, applied where the acquirer and region call for it.
Settlements, fees, refunds and chargebacks normalised across every acquirer into one ledger.
One queue across acquirers, evidence-pack templates per scheme, automated representment for select case types.
One dashboard for authorisations, refunds, disputes and chargebacks across every acquirer in the connected set.
Trust & compliance
Every acquirer relationship sits inside the platform's audited environment. Sub-merchants inherit that posture, so they don't carry separate certifications.
Annual on-site assessment and quarterly ASV scans, inherited by sub-merchants on the platform's acquirer relationships.
Visa VDMP / VAMP / VFMP and Mastercard ECP / EFMP thresholds tracked per acquirer relationship; the dashboard surfaces position vs limit.
Selective 3DS2 challenges on the authorisation path keep approval high in Europe without breaking compliance bars.
Sanctions screening on onboarding; AML monitoring tuned per acquirer's appetite and per merchant vertical.
Licensed gaming, regulated financial services and other compliance-bound merchants supported only where current operating licences exist. Grey and black-market verticals are out of scope.
Ready to map acquirers
A 45-minute acquirer review covers three things. Which connected acquirers fit your BIN, scheme and geography mix. The routing policies that suit your traffic. And the sub-merchant onboarding path. No long questionnaire needed up front.
Frequently asked
What buyers ask before they commit — definitions, key differences, Visa vs Mastercard, BIN data, and how the acquirer panel shows up in the platform's data model.
An acquirer is a licensed bank, or a non-bank financial institution, that processes card payments for merchants under one or more scheme licences. It holds the link to Visa, Mastercard and the other networks. It takes the payment, captures the funds, and pays them to the merchant — or to an aggregator, which then pays its sub-merchants.
Marketing copy tends to blur the two. Strictly, the acquirer holds the scheme licence and the merchant contract. A payment processor may be the same firm, or a separate tech provider that runs the message flow for the acquirer. topropay sits a layer above both. It routes payments across several acquirers — and the processors behind them — through one API.
Merchant acquirer is just the longer form of 'acquirer'. It makes the split from the card issuer clear. The merchant acquirer supplies acquiring services to a merchant. The issuer is the bank that gave out the card. topropay connects to many merchant acquirers across regions.
For cross-border merchants, acquirer services run through a regional acquirer panel. EU card BINs route to EU acquirers. US card BINs route to US acquirers. And so on. Settlement currency is a policy choice, so merchants don't carry FX they didn't ask for.
topropay is not a direct card acquirer in every market. It is an aggregator. It integrates with several licensed card acquirers and routes traffic across them. The merchant joins as a sub-merchant on the platform's acquirer relationships. It inherits the underlying licences, rather than holding direct acquirer contracts.
A credit card acquirer (sometimes written creditcard acquirer in older industry texts) is the acquirer that handles credit-card payments. That sets it apart from debit, prepaid or alternative-method rails. The platform's connected acquirer set covers credit, debit and prepaid card BINs across the supported regions.
CF acquirer usually means a 'cardholder-funded acquirer'. Depending on context, it can also mean the 'card-funded' setup of an acquirer relationship. The label shows up on some scheme reports. It marks cardholder-funded flows apart from sponsor-funded ones. topropay handles both shapes on the relevant acquirers. The routing engine treats them as separate lanes when the acquirer needs that.
Acquirer ID is the unique identifier a card scheme — Visa, Mastercard, and so on — assigns to an acquirer. It shows up on scheme reports, chargeback case files, dispute responses and BIN-level reconciliation. In topropay's analytics, every payment is tagged with the acquirer ID it landed on. So you can roll up performance per acquirer over time.
Yes. Acquirer Visa connectivity — that is, acquirers licensed and active on the Visa network — is part of the connected acquirer panel across regions. You can also set Visa-only routing policies from the dashboard. For example, all Visa BINs can run on the Visa-licensed acquirers.
A visa acquirer for a given country is simply a Visa-licensed acquirer that operates there. topropay's connected acquirer panel includes Visa acquirers across Europe, the UK, the US (via partners), APAC and LATAM. Merchants can set the active Visa acquirer set per market from the dashboard.
The merchant dashboard shows acquirer BIN data. That means which BIN ranges each acquirer covers, plus per-BIN approval, cost and dispute analytics. The data is live, not a quarterly export. So if a BIN range's approval rate drifts on one acquirer, you can re-route it to another with a single policy change.
Yes. The routing engine treats a mastercard acquirer just like a Visa acquirer. It's another lane, with its own scheme rules, interchange surface and dispute calendar. Mastercard BINs route to Mastercard-licensed acquirers, and you set the policy from the dashboard.
An acquirer payment gateway is the gateway an acquirer exposes for authorisation, capture and refund. Sometimes a third party exposes it for the acquirer. topropay sits in front of many acquirer payment gateways and turns them into one unified API. Your integration talks to topropay. topropay talks to the right acquirer's gateway on each payment.
This page is about the acquirer — the entity, its scheme relationships, BINs and IDs. The sibling acquiring page is about the service — how acquiring works within the wider payment platform. Most merchants need both views, and the platform delivers them as one product.
Payment acquirer is a broader word for acquirer. It covers card and non-card rails — account-to-account, wallets, BNPL — where the provider does an acquirer-like job. topropay's payment-acquirer set includes card acquirers and their non-card equivalents on bank rails, BNPL and crypto, via partner gateways.
Related