Payment acquirer explained — what BazPay does as a direct acquirer.
The acquirer is the licensed entity that holds scheme membership, authorises card transactions and settles them into the merchant's bank account. BazPay is a direct regional acquirer for merchants: one contract, one named MID, one interchange++ statement per scheme cycle.
This page explains the acquirer role, the identifiers it uses (acquirer BIN, ICA, MID, acquirer name) and how BazPay compares to third-party acquirer arrangements sitting on aggregated licences.
Why the acquirer relationship matters
The acquirer is the entity your MID lives on, the entity that settles your funds and the entity that appears on scheme reporting. Four properties separate a direct regional acquirer from a reseller sitting on someone else's licence.
-
Direct acquirer, not a reseller
BazPay holds acquiring membership with the card schemes on its own regional licence. The merchant contract, the MID and the settlement all sit with the same entity — no intermediary payment acquirer in between.
-
Named MID for clean attribution
Every merchant receives its own MID at each scheme. Chargeback ratios, decline data and settlement reporting attribute to your legal entity, not to a pool shared with other merchants on an aggregator's licence.
-
Interchange++ reporting on every charge
Scheme fees, interchange and the acquirer margin appear as separate lines on every settled transaction. Finance teams reconcile against the source, not against a blended rate on a monthly summary.
-
Acquirer + gateway on one platform
The gateway that authorises the transaction and the acquirer that settles it are the same platform. Signed webhooks, real-time analytics and the API contract all sit under one signature scheme and one dashboard.
The four acquirer roles you will encounter
The literature uses several terms — merchant acquirer, card acquirer, payment acquirer, third-party acquirer — often to describe the same entity from different angles. Below is how each term maps to what BazPay actually does.
-
Merchant acquirer
Merchant acquirer
The acquirer holds the contract with the merchant. It authorises charges, collects the funds from the card scheme and settles them into the merchant's bank account. BazPay plays this role directly for its regional book.
- Merchant contract
- MID
- Settlement
-
Card acquirer
Card acquirer
The specific role of processing card scheme transactions and holding membership with Visa, Mastercard, Cartes Bancaires and eftpos. BazPay's regional licence covers this role — a creditcard acquirer for merchants across the EU, UK, Australia, Canada and New Zealand.
- Visa
- Mastercard
- Cartes Bancaires
-
Payment acquirer
Payment acquirer
The broader term covering any acquiring role across card, wallet and alternative payment methods. On BazPay, the payment acquirer role reaches cards, wallets and local payment methods through one contract.
- Cards
- Wallets
- Local APMs
-
Third-party acquirer
Third-party acquirer
A third-party acquirer refers to a licensed entity that acquires transactions on behalf of merchants who are not the acquirer themselves. BazPay is the third-party acquirer of record on its regional book — direct, not resold.
- Direct entity
- Regulated
- regional licence
The boarding side of the same relationship on merchant acquiring. The direct-vs-reseller comparison on payment processors.
The identifiers an acquirer uses in payments
An acquirer relationship comes with a small set of identifiers that appear in scheme messages, settlement reports and dispute tools. Knowing what each one means helps merchants read their statements and troubleshoot integrations.
| Identifier | What it is and where it appears |
|---|---|
| MID (Merchant ID) | Named per merchant at each card scheme; identifies your entity to Visa, Mastercard and CB. |
| Acquirer BIN | The Bank Identification Number range issued by a scheme to the acquiring bank; used inside authorisation and settlement messages to identify the acquirer. |
| Acquirer ICA | Mastercard's Interbank Card Association number — the Mastercard-specific identifier for the acquiring institution. |
| Acquirer name | The human-readable acquirer name that appears in scheme messages and, in some cases, in dispute-management tools. |
| MCC | Merchant Category Code assigned to your business at boarding; used by issuers for scoring and by finance for interchange interpretation. |
Every charge object on the BazPay API carries these identifiers where the scheme returns them — see the API reference for the exact field names.
How the acquirer processes one card charge
Six stages describe the acquirer's role from the moment card data enters the payment environment to the settled dollar in the merchant's settlement account. Each stage is instrumented and each stage change fires a signed webhook.
-
Shopper submits
Card details enter the acquirer's PCI environment through hosted fields, a hosted page, a plugin or the API.
-
Score
The acquirer scores the order inline — device, velocity, geography — before the authorisation is sent to the scheme.
-
Authorise
The acquirer forwards the request to the scheme, which routes it to the issuer. The 3-D Secure 2 result is bound to the authorisation.
-
Issuer decides
The issuer approves or declines. Approval returns an authorisation code and a scheme response; decline returns a reason code.
-
Capture and clear
On approval, the acquirer captures the transaction and submits it through scheme clearing. The interchange bucket is finalised at this stage.
-
Settle to merchant
The acquirer credits the merchant's local settlement account per scheme cycle. Interchange, scheme fees and acquirer margin appear on the settlement line.
Direct regional acquirer vs reseller PSP
Not every acquirer holds direct scheme membership. Some resell an upstream acquirer's licence through an aggregator arrangement. The comparison below shows where each model earns its keep for a merchant reviewing acquirer options.
| Dimension | BazPay (direct regional acquirer) | Reseller PSP |
|---|---|---|
| Contract | Direct BazPay as acquirer | Reseller PSP on aggregated MID |
| MID structure | Named per merchant | Shared MID pool |
| Chargeback attribution | Attributed to your MID | Diluted across the pool |
| Settlement | Per-scheme cycle to your local settlement account | Aggregated payout, common delay |
| Reporting | Interchange++ line detail | Blended-rate summary |
| Underwriting decision | Direct with BazPay's onboarding team | Passed through the reseller |
| Scheme membership | Direct on the regional acquiring licence | Held by an upstream partner |
Fees and settlement on the pricing page. The ongoing service envelope around the acquirer on payment gateway services. The wider regional processing view on Single Euro Payments Area processing.
Features BazPay ships as your acquirer
Every capability below is on the standard acquiring relationship. There is no premium tier for interchange++ reporting, cascade retries or signed webhooks — the primitives are the platform.
-
Direct scheme membership
BazPay holds membership directly with Visa, Mastercard, Cartes Bancaires and eftpos as a regional acquirer. No reseller in the settlement chain.
-
Named MID per merchant
Your own merchant identifier at each scheme. Chargeback attribution, decline data and settlement reporting all key to your entity.
-
Interchange++ statements
Every settled charge breaks out interchange, scheme fees and gateway margin. Finance teams reconcile at line-level.
-
Cascade retries
Reason-code-aware retry on soft declines against a second connection or with a network-token refresh — recoverable losses recovered.
-
3-D Secure 2.2 + exemptions
Authentication on every card charge with automatic exemption logic — TRA, low-value, trusted-beneficiary, MIT — bound to the authorisation.
-
Signed webhooks
HMAC-signed, replay-protected events for every state change across authorisation, capture, refund, dispute and settlement.
-
Real-time decline data
Scheme response and normalised reason codes visible within seconds — no waiting for an end-of-day report to see why a charge failed.
-
SEPA / SEPA Instant payouts
Merchant settlement lands in your local settlement account per scheme cycle. Instant payouts on approved corridors where both banks participate.
Read the acquirer fields on every charge
The charge object surfaces the acquirer identifiers the scheme returns — the MID it posted against, the acquirer BIN, the ICA where relevant and the human-readable acquirer name. Your finance and support teams reconcile against these fields without opening a second portal.
{
"id": "ch_5F9k",
"amount": 4990,
"currency": "EUR",
"status": "succeeded",
"network": "visa",
"acquirer": {
"name": "BazPay regional",
"mid": "MID-000..1234",
"bin": "4XXXXX",
"ica": null
},
"authorisation_code": "AB12CD",
"metadata": { "order_id": "ORD-10842" }
}Full schema in the API reference; handler samples in the developer docs. Approval and decline detail in real time on real-time analytics.
Who boards on BazPay as their acquirer
The four merchant profiles below sit inside BazPay's regional underwriting policy. Each gets the same acquirer relationship, the same named MID and the same interchange++ reporting.
-
Multi-country e-commerce
DTC brands running regional storefronts on Shopware, Magento 2, WooCommerce or PrestaShop. One named MID across every market.
-
Subscription software
SaaS billing with card-on-file renewals, dunning-aware retries and MIT exemptions on rebills — attributed to your acquirer contract.
-
Professional services
B2B invoicing with named-payer trust lists, enforced 3-D Secure 2 over a threshold and interchange++ reporting for the finance team.
-
Digital publishers
Membership renewals and paywall unlocks reconciled per SKU on one MID with clean chargeback attribution.
Out of scope for BazPay as acquirer: adult, gambling, CBD, nutraceutical, forex, CFD, crypto-exchange, debt-collection and MLM. BazPay is not a merchant of record and not a marketplace of third-party PSPs.
Security and compliance for the acquirer environment
The acquirer environment runs inside a PCI DSS Level 1 assessment renewed each year. Hosted fields, gateway-side vaulting and network tokens keep merchants at SAQ A. Open-finance regulation 3-D Secure runs on every card charge with 3-D Secure 2.2 and automatic exemption logic. Regional data residency and GDPR are default.
- PCI DSS Level 1
- Annual assessment on the acquiring and gateway environment
- Merchant SAQ A
- Hosted fields and gateway vault keep card data out of your stack
- Authentication
- 3-D Secure 2.2 with automatic exemption logic on every card charge
- GDPR
- In-region data residency; DPA on request
- Scheme registrations
- Visa VIRP and Mastercard SPoC/PCI-CP where required
Common questions about acquirers
What is an acquirer, and what does it do in payments?
An acquirer is the licensed entity that holds membership with the card schemes and authorises, clears and settles transactions on behalf of the merchant. In payments, the acquirer sits between the merchant and the scheme — it takes the authorisation request, forwards it to the scheme, receives the issuer's response and eventually credits the merchant's bank account. BazPay is a direct regional acquirer with a defined acceptance list.
What is the difference between a merchant acquirer and a payment acquirer?
The terms are often used interchangeably. A merchant acquirer emphasises the merchant-facing relationship — the contract, the MID and the settlement into the merchant's bank account. A payment acquirer emphasises the broader acquiring role across card, wallet and alternative payment methods. BazPay plays both roles as one entity for its regional book.
What is an acquirer BIN, and where does it appear?
An acquirer BIN is a Bank Identification Number range assigned by a card scheme to the acquiring bank. It identifies the acquirer inside authorisation and settlement messages. Merchants generally do not need to memorise their acquirer BIN — it is populated automatically by the scheme messages your gateway sends. BazPay includes the acquirer identifiers on every charge object your API integration receives.
What is an acquirer ICA?
The Interbank Card Association (ICA) number is Mastercard's identifier for the acquiring institution — the equivalent of the acquirer BIN in Mastercard message flows. It appears in scheme reporting and in some dispute-management tools. Your BazPay dashboard surfaces the acquirer ICA where a scheme process requires it.
How can I check the acquirer name and acquirer ID for my transactions?
The acquirer name and acquirer identifiers propagate through the BazPay charge object and settlement records. You can find them in the dashboard under transaction detail and via the API on the settlement webhook payload. Scheme reporting and dispute portals may also display the acquirer name in a standardised form.
I saw "acquirer not found" in an error message — what does that mean?
"Acquirer not found" is a diagnostic message that typically means the requested payment method or MCC combination is not enabled on your merchant profile with the acquirer, or the routing lookup failed to identify a valid acquiring path for the transaction. On BazPay, this is usually a configuration issue: check that the method is enabled in the dashboard, that your MID is provisioned for the relevant scheme and that the transaction fits within your boarded acceptance mix. Support can inspect the routing log if the check does not surface the cause.
How does a third-party acquirer differ from a direct acquirer?
"Third-party acquirer" in this context means an acquirer that is a separate legal entity from the merchant — a distinct licensed institution that acquires transactions on the merchant's behalf. Every acquirer that isn't the merchant themselves is technically a third party. What matters more is whether that acquirer holds direct scheme membership (BazPay does) or resells another acquirer's licence through an aggregator arrangement (BazPay does not). Direct scheme membership is what keeps reporting and chargeback attribution clean.
Can I keep my saved cards if I move my acquirer to BazPay?
Yes. Vault imports, network-token portability and debit-order mandate migration are supported under scheme-approved processes, subject to the receiving bank's consent letters. Old and new webhook streams typically run in parallel until traffic is proven on the new acquirer, so subscription renewals continue without asking shoppers to re-enter their card details.
Board on a direct regional acquirer, not a reseller pool
Share your business model and volumes and a named onboarding manager will confirm boarding fit inside one working day. See also merchant acquiring, gateway services and about NEWERA PAYMENT TECHNOLOGIES LTD.