Integrated payment solutions that drop into your existing product.
BazPay ships payments as a set of primitives you embed inside the product your customers already use — hosted fields inside your checkout, drop-in components inside your admin and maintained plugins inside your storefront. One integration reaches cards, wallets, local APMs and SEPA Instant.
Built for merchants across the EU, UK, Australia, Canada and New Zealand and ISV products serving them. Direct regional acquiring under the hood, one versioned REST API and a signed webhook stream that respects your existing observability.
Why integrated payment processing beats a bolted-on portal
A bolted-on payment portal costs a conversion step at checkout and a context switch for staff. Four properties keep BazPay integrated inside your product surface instead.
-
Drop-in wherever your customers already are
Hosted fields render inside your existing checkout. Drop-in JS components render inside your existing admin. Plugins install into your existing storefront. Nothing about the shopper flow forces a redirect.
-
One integration, every rail
Cards, wallets, local APMs and SEPA Instant account-to-account rails share the same charge object and the same webhook envelope. You do not stitch three vendors together for one checkout.
-
Low PCI scope by construction
Hosted fields keep raw PAN out of your stack. Your integration stays at merchant SAQ A regardless of how deep the embed goes — no full PCI environment to run for the payment surface.
-
Change-safe by contract
Every API request carries a version header, breaking changes ship on the next major and follow a documented deprecation window. Integrations built once do not silently regress under a vendor release.
The four integration surfaces on the integrated payment platform
Four surfaces let you choose where BazPay meets your product. Every one uses the same underlying charge object and event stream — pick the surface that matches your build, not the other way round.
-
Plugins
Storefront plugins
Maintained plugins for WooCommerce, Magento 2, PrestaShop and Shopware install into your existing storefront in minutes. Checkout, refunds, capture, webhooks and recurring billing are covered out of the box; you configure keys, save, done.
- WooCommerce
- Magento 2
- PrestaShop
- Shopware
-
Front-end
Hosted fields + drop-in JS
Card, expiry and CVC inputs render inside your existing checkout inside our PCI environment. Drop-in components render inside your admin without pulling raw PAN into your DOM.
- Hosted fields
- Drop-in components
- 3-D Secure 2 render
-
API
REST API for custom builds
One versioned endpoint creates a charge across every rail. Idempotency headers make retries safe. The response shape stays stable — your product code stays uniform whichever rail the shopper picks.
- Versioned
- Idempotent
- One charge object
-
Mobile
Mobile SDKs for in-app checkout
iOS and Android SDKs render hosted fields, Apple Pay and Google Pay natively inside your app and produce the same charge object as the web integration.
- iOS SDK
- Android SDK
- Apple Pay
- Google Pay
Full plugin list on the integrations directory. Hosted checkout and drop-in primitives on hosted checkout products. Getting-started walkthrough on accept online payments; vertical fit for storefronts on payment gateway for ecommerce and retail payment solutions.
From sandbox to live integrated payments
Six stages describe how an integration goes from the first API call to steady-state operations. A named integration engineer signs off on the sandbox before live keys are enabled.
-
Sandbox
Sandbox keys, webhook signing secret and dashboard invites issued the moment you sign up — no demo call before integration work begins.
-
Wire the API
Install a plugin or call the REST endpoint. Verify a signed webhook. Everything else is the shape of your own product.
-
Test
Sandbox replays production-shaped decline codes, 3-D Secure 2 flows and dispute events, so a test run matches the live surface byte for byte.
-
PR review
A named integration engineer reviews your first pull request and signs off on the sandbox before live keys are enabled.
-
Go live
Live keys enabled. Real-time analytics show approval quality from the first hour and a shared channel monitors the cutover window.
-
Iterate
Rule changes and payout schedules stay self-service in the dashboard. API version headers let you adopt new features without breaking the integration.
Integrated vs bolted-on: where the trade-off lands
The choice is not usually between two gateways. It is between wiring payments into your product and sending staff or shoppers to a separate payments portal. The comparison below shows where each approach shows its cost.
| Dimension | BazPay (integrated) | Bolted-on portal |
|---|---|---|
| Shopper flow | Stays inside your checkout via hosted fields | Redirect to third-party portal |
| Admin surface | Drop-in components inside your admin | Separate portal for staff |
| PCI scope | Merchant SAQ A via hosted fields | Full PCI where PAN passes servers |
| Integration surface | One REST API + plugins + SDKs | Per-rail SDK per vendor |
| Event stream | One signed envelope across every rail | Different formats per vendor |
| API versioning | Version header + deprecation window | Silent breaking changes |
| Change safety | Named engineer reviews first PR before live keys | Self-serve, no PR review |
Fees and settlement on the pricing page. Buyer's shortlist on payment processors; ongoing service envelope on gateway services. Vertical fits: fintech payment solutions, payment gateway for digital goods and the German-checkout method on iDEAL payments.
Features engineered for a build-and-integrate motion
Every capability below ships on the standard integration. No premium tier gates the sandbox, the plugins, the SDKs or the webhook contract — the build primitives are the platform.
-
Storefront plugins
Maintained plugins for WooCommerce, Magento 2, PrestaShop and Shopware 6 — checkout, refunds, capture, webhooks and recurring billing configured on install.
-
Hosted fields
Card, expiry and CVC inputs served from our PCI environment inside your existing checkout, so raw PAN never touches your stack.
-
Drop-in components
Prebuilt payment forms and checkout summaries drop into an admin or a portal with a few lines of JS — styled to match your product.
-
REST API + signed webhooks
One versioned endpoint per resource; every state change emits an HMAC-signed, replay-protected event to your integration.
-
Mobile SDKs
iOS and Android SDKs render hosted fields, Apple Pay and Google Pay natively and share the same charge object as web.
-
Idempotency contract
Retry-safe writes across create, capture, refund and payout. A network blip never becomes a double charge inside the integrated flow.
-
Sandbox parity
Sandbox replays production-shaped traffic and edge cases, so integration tests exercise the same paths the live platform runs.
-
Client libraries and helpers
Webhook verification helpers and lightweight client libraries ship maintained; the primitives your team already writes against.
The API contract behind every integrated flow
One versioned REST endpoint creates a charge. The response object is stable across cards, wallets, local APMs and SEPA Instant. Idempotency headers make retries safe end to end. Whichever integration surface you use — plugin, drop-in, custom REST or mobile SDK — the payload is the same.
POST /v1/charges
Idempotency-Key: 8f1c-2b3a-9e4d
BazPay-Version: 2026-04-01
{
"amount": 4990,
"currency": "EUR",
"payment_method": "card",
"capture": "auto",
"three_d_secure": "required_if_needed",
"metadata": { "invoice_id": "INV-10842" }
} The response returns a canonical charge object with the authorisation code, the network it landed on and any exemption applied. Full schema in the API reference; handler samples in the developer docs.
Where merchants and ISVs run integrated payments
The four profiles below already use BazPay-shaped integrated flows in production. Each gets the same API surface, the same webhook envelope and the same PCI scope reduction.
-
ISV products embedding payments
SaaS products that want to charge their own customers inside their existing admin — subscription plans, one-off invoices, add-on charges — without sending users to a third-party portal.
-
Multi-country e-commerce storefronts
DTC brands running Shopware, Magento 2, WooCommerce or PrestaShop across several regional markets. One plugin, one contract, one payout balance.
-
ERP and finance software
ERP and accounting products that need to accept card payments on customer invoices reconciled inside the ledger, not in a separate payments dashboard.
-
Membership and content platforms
Digital publishers, courses and membership sites embedding subscription checkout inside the platform's own account area, with card-on-file renewals.
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 act as a marketplace of third-party PSPs.
Security and compliance across the integrated surface
Card handling runs inside a PCI DSS Level 1 environment assessed each year. Hosted fields, drop-in components and the mobile SDKs keep raw PAN out of your integration — merchant SAQ A stays intact regardless of how deep the embed goes. Authentication runs on every card charge with 3-D Secure 2.2 and automatic exemption logic.
- 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
- Change management
- Versioned API, published deprecation policy, audit-logged dashboard actions
Questions integration teams ask before boarding
What does "integrated payment solutions" actually mean for a product team?
It means payments wired inside your existing product — hosted fields inside your checkout, drop-in components inside your admin, plugins inside your storefront — instead of a separate portal your customers or staff switch to. BazPay ships the primitives (API, hosted fields, drop-in JS, plugins, mobile SDKs) so the integrated experience matches how your product already looks.
How do integrated payment systems differ from a hosted checkout link?
A hosted checkout link redirects your customer to a page BazPay serves. Integrated payment systems keep the shopper inside your checkout, with hosted fields serving the sensitive inputs from our PCI environment. Both are supported — the integrated route wins when your brand and conversion metrics are worth defending.
Which platforms are covered for integrated payment processing out of the box?
Maintained plugins cover WooCommerce (WordPress), Magento 2 / Adobe Commerce, PrestaShop and Shopware 6 — each handles checkout, refunds, capture, webhooks and recurring billing on install. Custom stacks integrate directly against the REST API; the endpoints are the same the plugins call.
What does "integrated payment system issuer" mean, and is BazPay one?
In payments terminology the issuer is the bank that issues the cardholder's card and authorises the transaction on their side of the network. BazPay is not an issuer. BazPay is the merchant-facing gateway and regional acquirer that accepts, authorises with the issuer through the card scheme and settles the merchant. Integration on the BazPay side is on the acceptance rails, not the issuing side.
What integrations companies typically look for in an integrated payment platform?
Named MID for clean chargeback attribution, hosted fields for SAQ A scope, signed HMAC webhooks for reliable state, an idempotency contract for retry safety, and a versioned API that respects a deprecation window. BazPay ships all five as defaults, not as premium tier upgrades.
How is compliance handled inside an integrated flow?
Card data enters BazPay's PCI DSS Level 1 environment via hosted fields, so your integrated product stays at merchant SAQ A. Authentication runs on every card charge with 3-D Secure 2.2 and automatic exemption logic. GDPR runs on In-region data residency by default; a DPA is available on request.
Which merchant types are eligible for integrated payments companies with BazPay?
Merchants across the EU, UK, Australia, Canada and New Zealand: e-commerce sellers, subscription software firms, professional-services businesses, digital publishers and ERP or ISV products that charge their own customers. BazPay does not board adult, gambling, CBD, nutraceutical, forex, CFD, crypto-exchange, debt-collection or MLM merchants, and does not support marketplace-style MOR resale.
Can I embed BazPay in a multi-seller marketplace or as embedded finance?
No. BazPay is not a merchant of record and does not act as a marketplace of third-party PSPs, so embedded-finance resale and multi-seller MOR patterns are outside the platform's scope. Each merchant that accepts payments needs its own direct BazPay contract and named MID.
Wire payments into your product this sprint
Share your stack, your existing processor (if any) and your integration surface. A named engineer will confirm boarding fit and scope the wiring inside one working day. See also merchant acquiring, gateway services and payment processors.