Menu
Talk with sales

Integration questions? [email protected]

Everything you need to put BazPay into production.

Six guides, written in the order the work happens. Take a test key, make the first call, get 3-D Secure right, listen for the event, then switch the prefix and go live. Each page states the rule it rests on, so nothing here has to be taken on trust.

Start with the quickstart Jump to the API reference
  • 6 guidesFirst key to live traffic
  • 2026-04-01The version these pages describe
  • SAQ AThe PCI scope you keep throughout
  • 31 July 2026Last full review of the library
first call · sandbox 
# the whole of hello world, sandbox keys onlycurl -X POST https://api.bazpay.com/v1/payments \  -H "Authorization: Bearer sk_test_9f2c…" \  -H "BazPay-Version: 2026-04-01" \  -H "Idempotency-Key: ord_10482" \  -d '{"amount": 4200, "currency": "EUR",       "method": "ideal", "return_url": "…"}'​{ "id": "pay_3fJ2Qk", "object": "payment",  "status": "requires_action",  "next_action": { "type": "redirect" } }

A live iDEAL payment differs from this only in the key prefix. Amounts are minor units, so 4200 is 42.00 EUR.

Three ways in. Pick before you read.

All three end at the same objects and the same events. They differ in how much of the checkout you own. None of them puts card data on your servers.

  • Hours

    CMS plugin

    WooCommerce, Magento 2, PrestaShop, Shopware

    Install, paste two keys, choose which methods to show. The plugin calls the same public API you would, and the source is readable.

    • No code to write
    • Refunds from the admin panel
    • Updates ship with the gateway
    See the plugin list
  • 2 to 5 days

    Hosted fields

    Custom checkouts that want their own layout

    You build the checkout. The card inputs render inside our iframe, so the PAN never touches your server and your scope stays at SAQ A.

    • Your markup, your styling
    • 3-D Secure 2 handled for you
    • One object covers cards and APMs
    Read the payments guide
  • One day

    Hosted checkout

    Teams that want the shortest path live

    Create a payment, redirect to the page we host, take the webhook. Method selection, localisation and retries are ours to maintain.

    • No card form to build
    • Fifteen EU languages
    • Method mix follows the payer's country
    See checkout products

The library, in reading order.

Read straight through and you have a working integration. Read one page and you have the answer to one question. Both are supported — every guide states its prerequisites.

Get started

Keys, the first request, and the rules that govern every call after it.

Move money

Taking the payment, and then knowing — reliably — that it succeeded.

Go to production

Proving the integration under every outcome, then switching the keys.

Rules that hold on every call.

These eight are assumed by every guide and every sample. Learn them once here and no page has to repeat them. If a document contradicts this list, the list is right and the document is stale — tell us and it gets fixed.

Field-level reference
  • api.bazpay.com/v1 One host serves every product. TLS 1.2 or higher; plain HTTP is refused, not redirected.
  • Minor units Amounts are integers in the currency's smallest unit. 4200 with EUR means 42.00 euro.
  • RFC 3339, UTC Every timestamp is UTC with a Z suffix, for example 2026-04-12T09:31:07Z. No local offsets.
  • Dated versions Versions look like 2026-04-01. Your account pins one; the header overrides it per request.
  • Prefixed ids Object ids carry their type — pay_, po_, sub_, evt_, dis_. Treat the string after the prefix as opaque.
  • Cursor paging List calls return a cursor for starting_after. Default page size 25, maximum 100. Offsets are not supported.
  • Stable codes Errors pair an HTTP status with a machine code. Branch on the code; log the message.
  • At-least-once Webhooks can arrive twice and out of order. Key your handler on the event id.
Recent API and documentation changes
Date Version Change
Added 12 June 2026 2026-04-01 Decline reason codes pass through from the issuer on payment.failed, alongside our normalised code.
Added 28 May 2026 2026-04-01 Payout instructions accept a batch of up to 500 credits under one idempotency key.
Version 01 April 2026 2026-04-01 Version 2026-04-01 released. Bank payments return debtor_agent so reconciliation can match on BIC.
Changed 19 February 2026 2025-11-01 Webhook replay window extended from 7 days to 30. Existing signatures unchanged.

What changed, and when.

Dated versions mean a change can only reach you when you ask for it. Nothing in this list altered the behaviour of an existing pinned version. Breaking changes get their own dated release and a migration note beside it.

Where these documents stop.

Four things you will not find here, and where to look instead. Saying so up front costs less than a support thread that ends in the same sentence.

  • Scheme rulebooks

    We summarise the Visa and Mastercard rules that change your integration. The rulebooks themselves are licensed documents and we cannot republish them.

  • Tax and invoicing

    We report what settled, when and at what rate. VAT treatment of your sales is between you and your accountant.

  • High-risk verticals

    BazPay underwrites low-risk merchants only. Nothing here describes an onboarding path for restricted or adult categories.

  • Legacy API versions

    Pages describe 2026-04-01. Older dated versions stay callable, and their differences live in the changelog rather than in the prose.

Open a sandbox, then open page one.

Test keys are free and immediate. Every sample in this library runs against them unchanged. When something in a document does not match what the API did, send us the request id — a wrong page is a bug like any other.

Talk with sales Read the quickstart