Payment aggregator vs direct acquirer — where BazPay sits.
A payment aggregator admits many merchants under a single master merchant account and settles them from a pool. BazPay is not that. BazPay is a direct regional acquirer that opens a named MID per merchant on its own acquiring licence. This page explains the two models, and when each one fits.
Built for EU, UK and Commonwealth e-commerce sellers, subscription software firms, retail chains and professional-services businesses. Direct settlement to your settlement account, interchange++ line detail, no reseller layer between you and the network.
Four things a direct acquirer gives you that an aggregator does not
An aggregator is fast to sign and easy to leave. A direct acquirer is slower to sign and — after underwriting — clean to operate. Four differences show up on the invoice, the settlement report and the chargeback packet.
-
No shared-MID risk
Aggregators share one merchant identifier across many sellers. That means one seller's chargebacks and one seller's compliance issues can ripple back to yours. BazPay's named MID puts every merchant on its own scheme record.
-
Direct settlement, not aggregated payout
Funds settle per scheme cycle from our regional acquiring balance into your named settlement account. There is no aggregator holding funds in a pooled account before releasing them to you on a schedule you did not choose.
-
Interchange++, not blended aggregation rate
Aggregators typically publish one blended rate per card class. BazPay publishes interchange, scheme fees and the acquirer margin separately on every settled transaction, so finance teams see the actual cost each month.
-
Underwriting your entity, not the pool
A named onboarding manager reviews your legal entity, ownership and business model against regional criteria. You are underwritten as yourself — not admitted to a pool and hoping the pool's average holds.
The aggregator model, explained honestly
Aggregator, direct acquirer, mobile-specific and third-party — four labels for structurally different relationships with the card networks. Below is the field guide, with BazPay's position on each.
-
Aggregator
Payment aggregator model
A single regulated entity — often called a payment gateway aggregator — holds one master merchant account and admits many sub-merchants under it. Boarding is fast and light. In return, the shared MID means shared exposure: reserve holds, delayed settlement and blended reporting are all common.
- Shared MID
- Fast boarding
- Pooled reserves
-
Direct acquirer
Direct-acquirer model
One acquirer holds direct scheme membership and issues each merchant its own MID with the card networks. BazPay operates this model for its regional book. Underwriting takes longer, but the merchant sits on its own scheme record with clean attribution.
- Named MID
- Direct scheme record
- Interchange++
-
Mobile
Mobile payment aggregator
Some aggregator platforms are optimised for in-app acceptance, wrapping Apple Pay and Google Pay behind a single sub-merchant credential. BazPay reaches the mobile rail through native SDKs on its own acquiring licence — the mobile experience is similar, the MID structure is not.
- iOS SDK
- Android SDK
- Apple Pay + Google Pay
-
Third-party
Third-party payment aggregator
A third-party aggregator sits between the merchant and a downstream acquirer. Reporting flows through the third party and settlement is aggregated. BazPay is not a third-party payment aggregator — the acquirer and the platform are the same entity.
- Reseller layer
- Aggregated reporting
- Not the BazPay model
The buyer's comparison of processor types lives on payment processors. The unified software layer over card, wallet and APM networks is on network payment gateway.
Aggregator vs direct acquirer — the shortlist
Seven axes separate a payment aggregator setup from a direct acquiring contract. The table below is the shortlist to apply during procurement. BazPay's answer sits in the first column; a typical aggregator sits in the second.
| Dimension | BazPay direct acquirer | Typical payment aggregator |
|---|---|---|
| Merchant identifier | Named MID per merchant | Shared master MID over sub-merchants |
| Boarding speed | Days (underwriting is direct) | Hours (self-serve under the pool) |
| Settlement | Per-scheme cycle to your local settlement account | Aggregated payout on the aggregator's schedule |
| Reporting | Interchange++ line detail | Blended aggregator rate summary |
| Reserve holds | Named, contractual, per merchant | Pooled, can shift with book-wide risk |
| Chargeback attribution | Attributed to your entity | Diluted or aggregated across pool |
| Regulatory posture | regional acquiring licence, PSD2 native | Depends on the aggregator's jurisdiction |
Fees and settlement details on the pricing page. Bundled feature set for a specific vertical on payments solutions.
From aggregator sub-merchant to named-MID acquirer
Six stages describe the switch from an aggregator to a direct acquirer. Each stage is visible in the dashboard and each stage change fires a signed webhook.
-
Discovery
Business model, volumes and existing stack reviewed with a named integration manager before boarding starts.
-
Underwrite
KYC and merchant review. Documents, ownership and business model reviewed against regional acquiring policy for your vertical.
-
Provision
A named MID is opened with the schemes for your legal entity. Sandbox and live credentials are issued for the API.
-
Integrate
One REST endpoint, one webhook signing secret and hosted fields for the checkout. Maintained plugins cover the common regional commerce stacks.
-
Authorise
Every charge posts against your MID with the correct MCC and 3-D Secure result bound to the transaction.
-
Settle
Funds reconcile per scheme cycle into your named local settlement account with interchange++ line detail on every row.
Features that come with the direct-acquirer model
Everything below ships on the standard integration and is available to every merchant BazPay boards. None of it depends on being large enough to negotiate — it is the baseline.
-
Named MID per merchant
Your own scheme identifier — the primitive an aggregator model does not give you. Chargeback ratios, decline data and settlement all belong to your entity.
-
REST API + signed webhooks
One endpoint creates a charge; HMAC-signed, replay-protected events confirm every state change across every rail.
-
Hosted fields
Card, expiry and CVC inputs served from our PCI environment inside your checkout, keeping your annual return at merchant SAQ A.
-
Gateway-side vault
Store credentials once and re-use them across renewals, upgrades and one-clicks. Portable if you ever change stack.
-
3-D Secure 2.2
Authentication with automatic exemption logic. Liability shift where the scheme permits it, less friction where it does not.
-
Idempotent requests
Retry-safe create requests keyed to your idempotency header. A network blip never becomes a double charge.
-
Interchange++ reporting
Every settled transaction breaks out interchange, scheme fees and acquirer margin for line-level finance reconciliation.
-
Direct regional settlement
SEPA and SEPA Instant to your named settlement account; no aggregator holding tank between your revenue and your bank.
The charge object posts against your MID — not a pool
One REST call creates a charge. The response returns a canonical charge object with the MID it posted against — your MID — and the interchange bucket, scheme fees and any exemption applied. Every downstream event carries the same charge ID.
POST /v1/charges
Idempotency-Key: 8f1c-2b3a-9e4d
{
"amount": 4990,
"currency": "EUR",
"payment_method": "card",
"capture": "auto",
"three_d_secure": "required_if_needed",
"descriptor": "ACME EU LTD",
"metadata": { "order_id": "ORD-10842" }
}The full schema — including the MID and MCC on the response — lives in the API reference. Handler samples are in the developer docs.
Merchants for whom the direct-acquirer model earns its keep
Four regional merchant profiles typically pay off the switch from an aggregator to a direct acquirer inside a scheme cycle or two — through lower blended cost, cleaner chargeback attribution and named settlement.
-
E-commerce sellers
DTC brands and multi-country storefronts running Shopware, Magento 2, WooCommerce or PrestaShop. Local card acceptance without stitching regional aggregators.
-
Subscription software
SaaS teams billing monthly and annual plans with saved-card renewals, MIT exemptions and dunning-aware retries — all under one named MID.
-
Professional services
Agencies, consultancies and B2B service firms invoicing higher tickets with named-payer trust lists and enforced 3-D Secure 2.
-
Digital publishers
Membership renewals, single-issue purchases and paywall unlocks reconciled per SKU with clean chargeback attribution to your entity.
Out of scope for BazPay: adult, gambling, CBD, nutraceutical, forex, CFD, crypto-exchange, debt-collection and MLM. BazPay is not a merchant of record and does not operate as a payment aggregator or a marketplace of third-party PSPs.
Security, compliance and regulatory posture
BazPay operates under regional acquiring rules and PSD2. It is not licensed as a payment aggregator by any cross-border regulator, and it does not hold an RBI payment aggregator licence in India — the regulatory perimeters are separate. The signals below apply to the platform globally.
- 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
- SEPA / SEPA Instant
- Direct participation for merchant payouts in supported corridors
- Scheme registrations
- Visa VIRP and Mastercard SPoC/PCI-CP where required
Payment aggregator questions merchants ask
What is a payment aggregator, and is BazPay one?
A payment aggregator is a regulated entity that holds one master merchant account with the card schemes and admits many sub-merchants under it. Sub-merchants share a MID, blended reporting and aggregated settlement. BazPay is not a payment aggregator. BazPay is a direct regional acquirer that opens a named MID per merchant on its own acquiring licence — the opposite architectural choice.
How is a payment aggregator different from a payment gateway?
A payment gateway is the software layer that moves authorisation messages between a merchant, the networks and issuers. An aggregator is a commercial and regulatory model that decides *who owns the merchant relationship with the schemes*. A single provider can be both — BazPay is a gateway and a direct acquirer, but not an aggregator. See the distinction laid out on the payment gateway and payment aggregator comparison table above.
Do you have a payment aggregator licence — RBI or otherwise?
No. The RBI payment aggregator licence is an Indian regulatory instrument. BazPay is operated from the EU, UK, Australian, Canadian and New Zealand markets by NEWERA PAYMENT TECHNOLOGIES LTD and is not licensed by the Reserve Bank of India. BazPay serves merchants across the EU, UK, Australia, Canada and New Zealand under the applicable regional acquiring and PSD2 framework — a different regulatory perimeter with different obligations.
Can BazPay board merchants who are looking for a mobile payment aggregator?
Yes, if the merchant is a regional business selling through a native iOS or Android app. BazPay ships mobile SDKs that render Apple Pay, Google Pay and card entry in-app and route to the same charge object as the web integration. The MID is still named per merchant — the mobile experience is aggregator-like from the shopper's side, but the settlement structure is direct.
When does the aggregator model fit better than a direct acquirer?
Aggregators fit when you need to accept card payments in hours, do not need scheme-level identity, and are comfortable with pooled reserves and blended reporting. Micro-sellers, one-off event ticketing and platform sub-merchants often start on an aggregator. Merchants who bill enough volume to reconcile line by line, or who need chargeback ratios attributed cleanly, usually outgrow the aggregator model.
Which payment aggregator companies does BazPay compete with?
BazPay does not compete with aggregators on their strongest dimension — instant self-serve boarding — because BazPay is a direct regional acquirer with its own underwriting. Where BazPay does substitute an aggregator: merchants across the EU, UK, Australia, Canada and New Zealand that have outgrown the pool, need interchange++ reporting or want a named MID for chargeback and reserve reasons.
Is BazPay a third-party payment aggregator?
No. A third-party payment aggregator sits between a merchant and a downstream acquirer. BazPay is the acquirer for its regional book — the platform and the scheme membership belong to the same entity. There is no third party in between reporting or between settlement.
Can I switch from a payment aggregator to BazPay without losing my saved cards?
Yes, when the aggregator supports a scheme-approved credential migration. Card credentials, network tokens and debit-order mandates can be imported under a migration plan agreed with the receiving bank, subject to consent letters. Old and new webhook streams typically run in parallel until traffic is proven on the new stack.
Outgrown the aggregator model?
Share your business model, existing aggregator and monthly volume. A named integration manager will confirm boarding fit and map the migration inside one working day. See also card and APM processing, all products and about NEWERA PAYMENT TECHNOLOGIES LTD.