Payment acceptance infrastructure with international card reach.
BazPay's payment acceptance layer covers cards, wallets, local payment methods and SEPA Instant on one direct regional acquiring contract. The acquiring is local; the card scheme networks are global — foreign-issued cards authorise on the same MID and settle into the same EUR balance as domestic transactions.
Built for merchants across the EU, UK, Australia, Canada and New Zealand: e-commerce sellers, subscription software firms and professional-services businesses. One integration, one signed webhook stream, one interchange++ statement across every method you accept.
Why breadth of acceptance runs better on one platform
Stitching a card processor to a SEPA Instant vendor to a per-country APM aggregator makes reporting hard and adds a webhook contract per vendor. Four properties keep the acceptance infrastructure uniform on BazPay.
-
Breadth of methods, one integration
Cards, device wallets, local payment methods and instant rails share the same REST endpoint and the same signed webhook envelope. Adding a new method is a dashboard toggle, not a re-integration.
-
International card reach on a regional acquiring licence
Card networks are international. A card issued outside the region authorises against BazPay's own regional acquiring contract and settles into the same balance as a domestic charge — international payment acceptance without stitching regional PSPs.
-
Named MID for clean attribution
Every merchant boards on its own MID with the schemes. Chargeback ratios, decline data and settlement reporting are attributed to your entity — no dilution across an aggregator's pool.
-
One reporting surface across every rail
Approval, decline, refund, dispute and payout events flow through the same signed webhook stream and interchange++ statement. Finance teams close the book against one schema, not five.
What the acceptance layer covers
Four method families reach every regional market on one contract. Turn any family on from the dashboard as your business enters a new country or channel.
-
Cards
Card acceptance with global scheme reach
Visa, Mastercard, Cartes Bancaires and eftpos authorise on our own regional acquiring licence. Cards issued outside the region route through the same contract — the acquiring is local but the scheme networks are global.
- Visa
- Mastercard
- Cartes Bancaires
- eftpos
-
Wallets
Tokenised device wallets
Apple Pay and Google Pay ride the same card rails with a wallet-supplied network token. No PAN in the request, and one-click checkout is native on supported devices without a separate SDK.
- Apple Pay
- Google Pay
-
Local APMs
Local alternative payment methods
Local payment methods complete the regional acceptance mix — a German shopper reaches for SEPA Instant, a British shopper for Bancontact, an Australian for BLIK. All behind the same charge object as cards.
- iDEAL
- Bancontact
- BLIK
- Pay by bank
- PayTo
- Interac
-
Bank rails
SEPA and SEPA Instant
For higher-ticket B2B invoicing and subscription mandates, instant credit transfer and Direct Debit sit alongside cards on the same platform. SEPA Instant delivers merchant payouts on approved corridors.
- SCT
- BACS Direct Debit
- SEPA Instant
Payment-method depth on card and APM processing. The German method up close on iDEAL payments. SEPA Instant-level detail on Single Euro Payments Area processing.
How a payment moves through the acceptance layer
Six stages describe the path from method selection to settled dollar. Each stage is visible in the dashboard and each stage change fires a signed webhook.
-
Show methods
Your checkout renders the acceptance mix — hosted page, hosted fields or plugin. Only methods you have enabled appear to the shopper.
-
Shopper picks
Card, wallet, SEPA Instant, Bancontact — the payment_method field on the charge request selects the rail. Response shape does not change.
-
Authenticate
3-D Secure 2.2 runs only when the risk earns it for cards; bank-authenticated methods run inside the shopper's own bank flow.
-
Authorise
The processor posts to the acquirer, wallet network or APM connector as required. International-issued cards route through the same regional contract.
-
Confirm
One signed charge.succeeded webhook fires whichever rail carried the payment. Your fulfilment handler reacts once.
-
Reconcile
Settlements land in your local settlement account with interchange++ line detail. Refunds, chargebacks and disputes fire signed events keyed to the same charge ID.
One acquiring contract vs a regional PSP per market
Adding a new country used to mean signing a new PSP. Direct regional acquiring plus native regional APM coverage replaces most of that vendor sprawl. The comparison below shows where each model earns its keep.
| Dimension | BazPay (one contract) | Regional PSP per market |
|---|---|---|
| Contract | One direct regional acquiring contract | Regional PSP per market |
| MID | Named to your legal entity | Shared across the aggregator's pool |
| Method addition | Dashboard toggle, no new integration | New vendor SDK per method |
| International cards | Route through the same regional acquiring contract | Separate cross-border processor |
| Reporting | Interchange++ line detail across every rail | Blended-rate summary per vendor |
| Settlement | EUR to your nominated IBAN, per scheme cycle | Aggregated payouts, common delay |
| Fraud engine | Inline rule engine across every method | Bolt-on per method |
Boarding on merchant acquiring. Buyer's shortlist on payment network gateway. Getting-started path on accept online payments. Where the acquirer role fits vs the issuer on issuing and acquiring. Security floor on secure payment services.
Features that expand acceptance without expanding integration work
Every capability below is on the standard integration. Turning on a new payment method uses features you already have — no premium tier gates hosted fields, network tokens or the webhook contract.
-
Hosted checkout page
Prebuilt hosted checkout shows the full acceptance mix without any front-end code on your side — the fastest way to expand acceptance in a new market.
-
Hosted fields
Card, expiry and CVC inputs served from our PCI environment inside your checkout so raw PAN never touches your stack.
-
Storefront plugins
Maintained plugins for WooCommerce, Magento 2, PrestaShop and Shopware expose every enabled method through the storefront's own checkout.
-
REST API + signed webhooks
One versioned endpoint accepts a payment on any rail; every state change emits an HMAC-signed, replay-protected event.
-
Network tokens
Visa and Mastercard network tokens keep card-on-file charges alive after reissue — acceptance stays warm across renewals.
-
3-D Secure 2.2 + exemptions
Authentication on every card charge with automatic exemption logic; bank-authenticated APMs run their own 3-D Secure natively.
-
Real-time analytics
Approval, decline, cancel and fraud verdicts per method visible within seconds — see what a method rollout did before the next scheme cycle.
-
Interchange++ reporting
Interchange, scheme fees and gateway margin split per settled charge across cards and APMs, keyed by method.
One REST call accepts a payment on any enabled method
The payment_method field selects the rail; the response object shape is
stable across cards, wallets, local APMs and SEPA Instant. Idempotency headers keep retries safe
end to end.
POST /v1/charges
Idempotency-Key: 8f1c-2b3a-9e4d
{
"amount": 4990,
"currency": "EUR",
"payment_method": "card",
"capture": "auto",
"three_d_secure": "required_if_needed",
"metadata": { "order_id": "ORD-10842" }
}
Change payment_method to ideal, apple_pay or
sepa_debit and the request routes to the corresponding rail. The response
shape does not change. Full schema in the API reference.
Where broad payment acceptance earns its place
The four merchant profiles below already run cross-method, cross-country acceptance on BazPay. Each uses the same charge object and the same signed webhook.
-
Multi-country e-commerce
DTC brands running one storefront across our markets. Card and wallet acceptance in every country, plus per-market APMs turned on from the dashboard.
-
International SaaS with regional customers
Software vendors with buyers in and outside the region. International-issued cards authorise on the same contract; Regional customers see local APM options at checkout.
-
Professional services and B2B invoicing
Higher-ticket invoices delivered as hosted payment pages with card + SEPA Instant + open banking — the buyer chooses the method that suits their finance policy.
-
Digital publishers with global readership
Membership and paywall businesses accepting subscriptions from regional and cross-border shoppers, with card-on-file renewals kept warm by network tokens.
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 not a marketplace of third-party PSPs.
Security and compliance across every accepted method
Card handling runs inside a PCI DSS Level 1 environment assessed each year. Hosted fields and gateway-side vaulting keep your annual return at merchant SAQ A. Authentication runs on every card charge with 3-D Secure 2.2 and automatic exemption logic; bank-authenticated APMs run native strong customer authentication inside the shopper's own bank.
- 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
Questions merchants ask about broadening payment acceptance
What does "payment acceptance" mean on BazPay?
Payment acceptance is the merchant-side capability to take money from shoppers on any supported method — cards, wallets, local payment methods or SEPA Instant — and settle it into your bank account. On BazPay the acceptance layer is a single REST API and a signed webhook stream: one integration reaches every rail we support.
How is international payment acceptance handled on a regional acquiring licence?
Card scheme networks (Visa, Mastercard, Cartes Bancaires, eftpos) operate internationally. A card issued outside the region authorises against BazPay's own regional acquiring contract and settles into the same EUR balance as a domestic charge. BazPay does not hold local acquiring licences outside the region — international reach here means "international-issued cards accepted on the regional contract", not "local acquiring in every region".
Is this true global payment acceptance, or regional-focused?
The direct acquiring relationship is in-region; the card scheme reach is global by construction. That combination is a common fit for merchants across the EU, UK, Australia, Canada and New Zealand whose customer base is largely EU, UK and Commonwealth but includes international card traffic. Merchants whose primary market is outside the region with local-acquiring requirements will typically need a partner that holds local licences in those regions — BazPay is not that partner.
How does BazPay compare with running separate PSPs per market for payment acceptance infrastructure?
One direct regional acquirer with a named MID and interchange++ reporting replaces the vendor sprawl of running one PSP for cards, another for local methods, another for SEPA Instant and yet another for wallets. The trade-off is scope — you get the breadth for regional business, not for every vertical.
How do I add a new payment method to my acceptance mix?
Turn the method on from the dashboard once it is provisioned for your merchant profile. The API contract does not change — set the payment_method field on the charge request and the platform routes to the appropriate rail. The signed webhook, refund flow and reporting all extend without additional integration work.
Which currencies can I accept and settle in?
Card authorisation runs in EUR and more than twenty presentment currencies. Settlement lands in EUR into a regional settlement account by default. Named settlement currencies are available for approved corridors; discuss corridor availability with sales during boarding.
Which merchant profiles fit this acceptance model?
Merchants across the EU, UK, Australia, Canada and New Zealand: e-commerce sellers, subscription software firms, professional-services businesses and digital publishers. BazPay does not board adult, gambling, CBD, nutraceutical, forex, CFD, crypto-exchange, debt-collection or MLM merchants, and does not act as a merchant of record or a marketplace of third-party PSPs.
What does the compliance floor look like for payment acceptance?
PCI DSS Level 1 on the acquiring and gateway environment (annual assessment), merchant SAQ A on your side (hosted fields and gateway vault keep card data out of your stack), authentication via 3-D Secure 2.2 with automatic exemption logic, GDPR under In-region data residency and adherence to the SEPA and BACS rulebooks on bank-rail flows.
Scope your acceptance mix on one direct regional acquirer
Share your target markets, monthly volume and current acceptance stack. A named engineer will confirm boarding fit and map the method rollout inside one working day. See also pricing, payouts and the deeper merchant acquiring reference.