Menu
Talk with sales

Integration questions? [email protected]

Payment infrastructure built on cards, APMs and SEPA Instant.

BazPay is the payment infrastructure a small engineering team can actually build on: one versioned REST API, one canonical charge object, a gateway-side vault, a signed event stream and mobile SDKs that share the web integration's data model.

Built for EU, UK and Commonwealth e-commerce sellers, subscription software firms and professional-services companies. One direct regional acquirer under the hood — no aggregated MID, no reseller middle layer, no vendor-specific data shape to normalise.

Talk with sales Read the API reference

What a unified payment infrastructure gives you

Four properties separate a platform you can build on from a set of vendor APIs your team spends every sprint normalising. All four are default here.

  • One unified data model

    Cards, wallets, local APMs and instant rails resolve to the same charge object. Your database schema, ledger and reporting queries stay stable whichever rail carries the money.

  • One event stream, one signature scheme

    Authorisation, capture, refund, dispute, payout and maintenance events all flow through one signed webhook envelope. Your handler verifies once — the rest is routing on the event type.

  • Tokenisation you can build on

    Gateway-side vault issues stable payment tokens keyed to your merchant, with automatic PAN refresh via Visa and Mastercard network tokens. No PAN handling on your servers, no rebuild when a card is reissued.

  • Observable by default

    Real-time analytics, signed maintenance events and a public status page give your on-call the same operational visibility that BazPay engineers use to run the platform.

The four pillars of the payment processing infrastructure

Four layers make up the platform your team integrates against. Each layer has a stable contract and a documented change policy.

  • API

    REST API and idempotency contract

    One versioned endpoint creates a charge across every rail. Idempotency headers make retries safe end to end. Breaking changes ship behind a version header with a documented deprecation window, so an integration built against v1 keeps working when v2 lands.

    • Versioned
    • Idempotent
    • Deprecation policy

  • Data

    Canonical charge object

    Every rail returns the same shape — network, exemption, MID and metadata are first-class fields. Downstream events keep the same envelope, so your ledger reconciles against one schema.

    • One shape
    • First-class metadata

  • Tokens

    Vault + network tokens

    Stored credentials sit inside our PCI DSS Level 1 scope. Network tokens refresh automatically after reissue and stay portable if you ever migrate infrastructure.

    • PCI Level 1
    • Portable

  • Mobile

    Mobile payment infrastructure

    iOS and Android SDKs render hosted card fields, Apple Pay and Google Pay natively and produce the same charge object as the web integration, sharing the signed webhook stream.

    • iOS SDK
    • Android SDK
    • Apple Pay
    • Google Pay

The routing layer above the processor lives on payment orchestration. The wider network view lives on network payment gateway.

Request through settlement, on one infrastructure

Six stages describe how a payment moves through the platform, from checkout signal to settled dollar. Every stage is instrumented and observable.

  1. Ingest

    The checkout script or mobile SDK collects device and session signals inside our PCI environment before any network hop.

  2. Enrich

    BIN metadata, IP geo and merchant reputation on the payer are attached to the request before it hits the risk engine.

  3. Decide

    The fraud engine and PSD2 exemption logic decide the 3-D Secure path — frictionless, step-up, review or block — inline, sub-second.

  4. Route

    The processor posts to the acquirer or the selected APM connector with the authentication result bound to the transaction for issuer scoring.

  5. Emit

    Approval, decline, capture, refund and dispute events fire through the signed webhook stream, keyed to the same charge ID across rails.

  6. Reconcile

    Settlement events per scheme cycle carry interchange, scheme fees and processor margin. Payouts land in your local settlement account with one signed event per cycle.

Unified infrastructure vs stitched vendor stack

The choice is not usually between two payment gateways. It is between one unified platform and a stack you assemble from acceptance, billing, fraud, payouts and reporting vendors. Below is where the trade-off actually shows up in engineering hours.

BazPay unified infrastructure compared with a stitched vendor stack
Dimension BazPay (unified infrastructure) Stitched vendor stack
Data model One charge object across every rail Vendor-specific shapes to normalise
Event stream One signed envelope, one HMAC scheme Different formats per vendor
Tokenisation Gateway vault + network tokens by default Vendor vault lock-in per rail
Sandbox Production-parity replay Best-effort mock endpoints
API versioning Version header + deprecation window Silent breaking changes
Observability Status page + signed maintenance webhooks Twitter or nothing
Mobile parity SDKs share the same charge object Separate mobile back-office

Statement structure on the pricing page. Plugin coverage on integrations. The service envelope around the API on payment gateway services. Vertical example built on the same infrastructure: the payment gateway for digital goods and fintech payment solutions. Buyer's shortlist on payment processors. The build motion for embedding this infrastructure inside your own product lives on integrated payment solutions.

Infrastructure features your team touches every week

Everything below ships to every merchant on the standard integration. Turn features on with a request flag or a dashboard toggle — no premium tier that unlocks the sandbox or the changelog.

  • Versioned REST API

    One endpoint per resource, one version header on every request. Breaking changes ship on the next major and never quietly on v1.

  • Idempotency keys

    Retry-safe writes across create, capture, refund and payout. A network blip never becomes a double charge on any rail.

  • Signed webhooks

    HMAC-signed, replay-protected events for every state change. Delivery retries on an exponential schedule for up to 72 hours.

  • Sandbox parity

    Sandbox replays production-shaped traffic, decline codes, 3-D Secure 2 flows and dispute events, so tests match the live surface byte for byte.

  • Real-time analytics API

    Approval, decline and payout data available as a rolling stream — push it into your existing observability stack via webhooks or CSV.

  • Public status page

    Rail-level health per network, planned maintenance and post-incident timelines published in the open. Signed maintenance events land in your webhook stream too.

  • Mobile SDKs

    iOS and Android SDKs handle hosted fields, Apple Pay, Google Pay and 3-D Secure 2 challenge rendering — the same charge object as the web integration.

  • Data export

    CSV export for every ledger view. Push settlement, refund and dispute lines into your data warehouse without a custom ETL.

Optimize your payment infrastructure through the same API

One versioned REST endpoint creates a charge across every rail. Idempotency keys make retries safe. Signed webhooks confirm state changes even if your service was down when the event fired. Everything below is production traffic — sandbox uses the same payload shape. 

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": { "order_id": "ORD-10842" }
}

The response returns a canonical charge object with the authorisation code, the network it landed on, the exemption applied and the version it was created under. Read the full schema in the API reference and handler samples in the developer docs.

Where merchants build on BazPay's payment infrastructure

The infrastructure is scoped to the four merchant profiles BazPay boards. Each gets the same API surface, the same webhook envelope and the same tokenisation model.

  • SaaS platforms

    Recurring billing on network-tokenised cards, dunning-aware retries and MIT exemptions — infrastructure that survives a card-reissue wave without silent churn.

  • Multi-country e-commerce

    One integration reaches every regional market. Card, wallet, APM and instant rails converge on the same charge object, so the storefront code stays uniform.

  • Mobile-first commerce

    Native iOS and Android checkout with Apple Pay and Google Pay share the web integration's charge model — no duplicated mobile payment infrastructure to maintain.

  • Digital publishers

    Instant-fulfilment webhooks and per-SKU metadata reconcile ebooks, streaming subscriptions and paywall unlocks against your product ledger in real time.

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. Rail-level detail on Single Euro Payments Area processing; single method example: iDEAL payments.

Security, versioning and change safety

The platform runs inside a PCI DSS Level 1 environment assessed each year. Hosted fields, gateway-side vaulting and network tokens keep your annual return at merchant SAQ A. Every API change ships behind a version header with a documented deprecation window, so infrastructure built against a stable contract stays stable.

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 engineering leaders ask about payment infrastructure

What does payment infrastructure mean in this context?

Payment infrastructure is the foundational platform an engineering team builds against — the API, the data model, the tokenisation vault, the event stream, the SDKs and the observability surface. It sits below the product features. BazPay ships all of those primitives as one unified platform for merchants across the EU, UK, Australia, Canada and New Zealand.

How is payment infrastructure different from payment orchestration?

Payment orchestration is a routing and decisioning layer that sits above one or more processors and picks where each transaction goes. Payment infrastructure is the underlying platform — the API, data model, vault, event stream — that a processor exposes to its merchants. BazPay is a direct processor and acquirer, so its infrastructure is the platform you integrate against, not a router placed on top of other processors.

What does it take to optimize payment infrastructure once you have chosen a platform?

The high-leverage moves are: consolidate on one canonical charge object across every rail, use idempotency keys on every write, verify webhooks in a single shared handler and push settlement events straight into your data warehouse. Those four decisions collapse most of the accidental complexity that stitched-vendor stacks accumulate. BazPay is designed for that shape from day one.

Does the payment processing infrastructure include a mobile SDK?

Yes. iOS and Android SDKs render hosted card fields, Apple Pay and Google Pay natively and produce the same canonical charge object as the web integration. The mobile payment infrastructure shares the signed webhook stream, so the fulfilment handler you already run for web works for mobile without changes.

How are breaking changes handled?

Every API request carries a version header. Breaking changes ship on the next major version, and the previous major runs in parallel through a documented deprecation window. Old integrations do not silently break when we release a new version; new features become available under an opt-in header.

What data does the platform give my observability stack?

Signed webhooks fire on every state change — approvals, declines, refunds, disputes, payouts and platform maintenance. Real-time analytics and CSV exports round out the surface for dashboards. Push whichever stream your on-call watches into your existing alerting; the infrastructure does not require you to adopt a new operational tool.

Is the infrastructure suitable for merchants with regulated data?

For payment data, yes — the platform runs inside a PCI DSS Level 1 environment and handles regional data under GDPR. For non-payment regulated data (protected health information, gambling KYC, speculative financial products), BazPay is out of scope. Underwriting is limited to merchants in the EU, UK, Australia, Canada and New Zealand — e-commerce, subscription software, professional services and digital publishers.

What happens to my infrastructure when I move from another processor?

Vault imports and network-token portability are supported under scheme-approved migration, subject to the receiving bank's consent letters. During cutover the old and new webhook streams typically run in parallel until traffic is proven on the new stack. The API contract, sandbox parity and versioning policy make the switch predictable rather than an open-ended integration project.

Scope your platform build with a named engineer

Share your stack, your existing processor and your target rails. An integration manager will confirm boarding fit and map the migration inside one working day. See also payment gateway services, payment processors, merchant acquiring, open banking and payouts.

Talk with sales Read the developer docs