The BazPay API, field by field.

One base URL covers cards, open banking, payouts and subscriptions. Objects share a shape. Errors share a code list. This page is the contract you build against.

  • 6Core endpoints listed below
  • 25 / 100Default and max page size
  • 24hIdempotency key lifetime
  • 30dWebhook replay window
request headers · response envelope
GET https://api.bazpay.com/v1/payments/pay_3fJ2QkAuthorization: Bearer sk_test_9f2c…BazPay-Version: 2026-04-01Idempotency-Key: ord_10482{ "id": "pay_3fJ2Qk", "object": "payment",  "amount": 4200, "currency": "EUR",  "status": "succeeded", "method": "ideal",  "created": "2026-04-12T09:31:07Z" }

Sandbox example. Amounts are minor units; 4200 is 42.00 EUR.

Auth, versions and formats.

Four settings decide whether your first request works. Read them once. They hold for every endpoint on this page, and the rules behind them — scopes, version pinning, idempotent retries — are set out in the authentication guide.

  • Base URL

    api.bazpay.com/v1

    One host serves every product. TLS 1.2 or higher is required. Plain HTTP requests are refused, never redirected.

  • Keys

    sk_test_ · sk_live_

    The prefix tells you the mode. Test keys touch no real money. Secret keys stay server side, always.

  • Versioning

    BazPay-Version

    Versions are dated, like 2026-04-01. Your account pins one. Send the header to test a newer one first.

  • Format

    JSON in · JSON out

    Bodies are JSON or form-encoded. Amounts are minor units, so 4200 means 42.00 EUR. Times are UTC.

Six routes, thirteen products.

Learn one object and you have learned the platform. Each route below returns the same envelope and the same event names. Worked examples for each one live in the payments guide.

Browse the product pillars
Core resources and what each one does
Route What it does Product
POST /v1/payments Create a card or APM charge, with 3-D Secure 2 applied for you Cards and APMs
POST /v1/bank_payments Start a PSD2 account-to-account debit the payer approves in-app Open banking
POST /v1/payouts Send funds to an IBAN over SEPA Instant, with SCT as fallback Payouts
POST /v1/subscriptions Open a plan with trial, proration and dunning handled our side Recurring billing
POST /v1/refunds Refund part or all of a captured payment on the original rail Checkout products
GET /v1/reports Pull settlement, decline and interchange data as JSON or CSV Real-time analytics
Error codes and the right response
Status Code Meaning Do this
400 parameter_invalid A field is missing or malformed Fix the body and resend
401 key_invalid The secret key is wrong or revoked Rotate the key in the dashboard
402 card_declined The issuer refused the charge Show the reason, offer another method
409 idempotency_conflict A key was reused with a new body Use a fresh key per request
429 rate_limited Too many calls in the window Back off, then retry with the same key
5xx gateway_error Our side failed to complete Retry safely; writes are idempotent

Errors you can act on.

Every error returns a stable machine code beside the HTTP status. The message is for your logs. The code is for your logic. Decline reasons pass through from the issuer, so support can answer the buyer.

How fraud rules affect declines

Four habits that keep ledgers clean.

These four rules cover most support tickets we see. Apply them and integration stays boring.

  1. Retry with a key

    Every write accepts an Idempotency-Key header. Repeat the key and you get the first result back. Keys live 24 hours.

  2. Page with cursors

    List calls return a cursor, not an offset. Pass it as starting_after. The default page size is 25 and the cap is 100.

  3. Verify every webhook

    Each event body carries an HMAC signature and a timestamp. Check both, then act. Delivery is at-least-once.

  4. Expand, do not poll

    Use the expand parameter to inline related objects. One call replaces three. Polling a payment status is never needed.

Test keys, then live traffic.

The sandbox mirrors this reference exactly. Card data stays inside our hosted fields, so you remain at PCI DSS SAQ A. Bring a question and a specialist will answer it in plain language.

Prefer email? Write to [email protected].