Payment processing for EU low-risk merchants, on one gateway.
Processing payment through BazPay covers the whole path: collection, fraud decision, PSD2 authentication, authorisation on the right rail, capture, notification and settlement into your EU IBAN. Cards, EU local methods, open banking and payouts share one contract and one REST API.
Built for e-commerce sellers, subscription software firms and professional-services businesses. One statement to reconcile, one dashboard for operations, one webhook contract for engineering.
Why merchants consolidate payment processing on BazPay
Splitting the stack between a gateway, an acquirer, a fraud vendor and a reporting tool costs time on every reconciliation and on every code change. Consolidation removes the seams that make that expensive.
-
One contract for every rail
Cards, wallets, EU local methods, open banking and payouts share one merchant agreement. No sub-processor chain and no separate reconciliation per rail.
-
One REST API and one dashboard
The charge object never changes shape between rails. Product, finance and support teams read the same record. Engineering wires the integration once.
-
Line-level reporting from day one
Interchange, scheme fees and gateway margin post to each transaction. Payouts reconcile against the source charges with no spreadsheet gymnastics.
-
EU acquiring, global card reach
Settlement lands in an EU IBAN. Cards issued outside the EU authorise on the same contract, so a growing checkout does not need a new PSP.
How processing the payment works, step by step
Eight stages sit between the checkout button and the settled euro. Each stage is visible in the dashboard and emits a signed webhook — you never have to guess what state an order is in.
-
Collect
Hosted fields or the checkout page render the payment form inside our PCI environment. Card data never touches your servers.
-
Enrich
The gateway attaches BIN metadata, IP geo, device fingerprint and any customer history you have shared for the payer.
-
Score
Your fraud rules run inline. A single decision resolves before the authorisation call to the acquirer or the APM.
-
Authenticate
3-D Secure 2.2 fires only when the risk earns it. PSD2 exemptions are claimed automatically where the rules permit.
-
Authorise
The request posts to the chosen rail — card acquirer, APM provider or open-banking bank. The response returns with a canonical status.
-
Capture
Charges capture immediately or on a delayed trigger. Partial captures and partial refunds both post cleanly against the original.
-
Notify
A signed webhook confirms every state change. Idempotency keys make retries safe when your listener is offline.
-
Settle
Funds reconcile per rail cycle into your EU IBAN. Each line ties back to its own transaction ID and interchange breakdown.
Rails supported for processing payment online
Four rail families run through the same API. Turn any of them on from the dashboard. Each block below links to the dedicated product page for the deeper detail.
-
Card rails
Card and APM processing
Direct EU acquiring on Visa, Mastercard, Maestro and Cartes Bancaires, with device wallets and the EU local-method library on the same contract.
- Visa
- Mastercard
- Apple Pay
- Google Pay
- iDEAL
- BLIK
-
Bank rails
Open banking
PSD2-authorised account-to-account payments across supported EU banks. Bank-side authentication, no card number in the flow.
- PSD2 AISP/PISP
- SEPA Instant
-
Payouts
Outbound payments
SEPA, SEPA Instant and push-to-card payouts in approved corridors. Named beneficiary detail and signed webhooks on every state change.
- SEPA
- SEPA Instant
- Push-to-card
-
Recurring
Subscriptions and mandates
Stored credentials, network-token refresh and merchant-initiated exemptions for card renewals. SEPA Direct Debit mandates for bank-rail plans.
- MIT
- Card-on-file
- SDD
Features engineered into the processing platform
The primitives below are available on the standard integration. No enterprise-tier gate on the API surface, no premium add-on for signed webhooks or interchange reporting.
-
Hosted fields
Card, expiry and CVC inputs served from our PCI environment inside your checkout. The PAN never crosses your infrastructure.
-
Gateway-side vaulting
Store the credential once, charge it repeatedly across renewals, upgrades and one-clicks. Portable at any time.
-
Idempotent API
Retry any create request with the same key. The gateway never double-charges on a network blip, so your worker code stays simple.
-
Signed webhooks
Every event carries an HMAC signature, a timestamp and a replay-safe ID. Verify with a shared secret from the dashboard.
-
Real-time decline data
Reason codes surface in the dashboard within seconds and via the events stream, so dunning fires against fresh data.
-
Interchange++ reporting
Scheme fees, interchange and gateway margin split on every line, ready for reconciliation with your finance stack.
-
Retry orchestration
Soft declines can be re-tried on a second connection or scheduled for a later run. Rules live beside your fraud rules.
-
Sandbox parity
The sandbox exposes the same rails, the same response shape and the same webhook contract as production.
A REST API that treats rails as an argument
One endpoint creates a payment. The payment_method field selects the rail —
card, wallet, EU APM or open banking. Idempotency keys make retries safe. The response
shape is stable, so integration code does not branch per rail.
POST /v1/payments
Idempotency-Key: 8f1c-2b3a-9e4d
{
"amount": 4990,
"currency": "EUR",
"payment_method": "card",
"capture": "auto",
"three_d_secure": "required_if_needed",
"customer": "cus_5F9k",
"metadata": { "order_id": "ORD-10842" }
}
Change "payment_method": "card" to "ideal",
"bancontact" or "open_banking" and the same call posts to the
corresponding rail. See the complete schema in the API reference.
Industries that consolidate on BazPay
The default configuration reflects these four merchant profiles. Underwriting stays low-risk on purpose, so approvals hold steady across the book.
-
E-commerce sellers
DTC brands and multi-country storefronts on Shopware, Magento 2, WooCommerce or PrestaShop. One connection covers cards and EU local methods.
-
Subscription software
SaaS teams billing monthly and annual plans. Card-on-file, network-token refresh and dunning-aware retry logic on renewals.
-
Professional services
Agencies, consultancies and B2B service firms invoicing retainers. Named-payer allow lists and 3-D Secure 2 above a chosen ceiling.
-
Digital publishers
Media businesses selling memberships, single-issue purchases and paywall unlocks. Frictionless renewals and account-takeover heuristics.
Out of scope for BazPay: adult, gambling, CBD, nutraceutical, forex, CFD, crypto-exchange, debt-collection and MLM.
Consolidated processing vs multi-vendor stack
A conventional stack splits the work across four vendors. Each vendor has its own SDK, its own event schema and its own statement. The seams cost engineering and finance time on every reconciliation.
| Dimension | BazPay (consolidated) | Multi-vendor stack |
|---|---|---|
| Vendor count | One (BazPay) | Gateway + acquirer + fraud + reporting |
| Reconciliation | One statement, per-line detail | Multiple exports, blended rates |
| 3-D Secure link | Bound to the same charge object | Separate 3DS vendor to correlate |
| Dispute evidence | SCA + signals attached automatically | Manual packet assembly |
| API surface | One SDK, one webhook contract | Multiple SDKs and event schemas |
| Change management | Dashboard rules, effective next order | Deploy per vendor or file a ticket |
Pricing detail on the pricing page. Plugin coverage on the WooCommerce, Magento 2, PrestaShop and Shopware integrations page.
Security and compliance signals
Card data is captured in hosted fields inside our PCI DSS Level 1 environment, so most merchant integrations qualify for SAQ A. PSD2 SCA and exemption logic run on every card charge. Bank rails use PSD2-authorised access, and payouts settle over SEPA and SEPA Instant where the beneficiary bank participates.
Data stays in the EU. GDPR data processing agreements are available on request. Access to the dashboard is protected with role-based permissions and enforceable second-factor login for every user.
Fraud rules and dispute defence sit in anti-fraud controls. Ready-to-embed checkout surfaces live in hosted checkout products.
Questions merchants ask first
What does processing payment through BazPay actually cover?
The gateway takes the collection, runs the fraud decision, applies PSD2 SCA where required, posts the authorisation to the correct rail (card acquirer, APM provider or open banking), captures the funds, emits a signed webhook, and reconciles into settlement. One integration covers the entire path.
Do I need separate accounts for card and non-card rails?
No. Card acquiring, EU APMs, open banking and payouts run under one BazPay merchant agreement. You enable rails from the dashboard and the API accepts the new payment method without a code change beyond a request flag.
How long does processing the payment take end to end?
Authorisation is sub-second on card rails and typically completes within the shopper's checkout wait. Capture posts on the same request or on a later trigger, up to seven days for cards. Settlement follows the rail's own cycle — daily on card schemes, near-instant on SEPA Instant.
What is the difference between processing payment online and in-person acceptance?
BazPay processes payments online through its gateway API and hosted checkout. In-person acceptance is out of scope; the platform is designed for e-commerce, subscription software and professional-services businesses that collect through a website, an app or an invoicing link.
How is reporting structured?
Every transaction posts with an interchange++ split — scheme fees, interchange and gateway margin on separate lines. Payouts reconcile line by line against source charges. Data is available in the dashboard, via signed webhooks and through the reporting endpoints in the API.
What is required to start processing a payment on BazPay?
Company documentation, beneficial ownership records, a description of the merchant model and the URLs at which processing will occur. BazPay boards EU low-risk merchants; underwriting is scoped to e-commerce, subscription software and professional services. Restricted verticals are not supported.
How is dispute activity handled during the processing of payment?
Pre-dispute alerts surface in the dashboard where the scheme supports them. When a chargeback opens, the SCA proof and the signals that fed the fraud decision are already attached to the charge and packaged into the evidence template for the scheme.
Is there a sandbox for testing before going live?
Yes. Sandbox keys are self-service and expose the same rails, response shape and webhook contract as production. You can replay approvals, declines, 3-D Secure challenges and dispute states before a single live order.
Start processing a payment on sandbox today
Open a sandbox account and post your first authorisation in the same hour. Prefer a walk-through first? A payments specialist can map your rails, your reporting seam and your real-time analytics setup with you. Related: merchant acquiring, the network payment gateway, open banking and merchant services.