Build EU payments on one REST API.

One base URL. One auth model. Cards, open banking, payouts, subscriptions and fraud share the same objects. Test keys arrive at sign-up. No demo call stands in the way.

  • REST + JSONPredictable resources
  • IdempotentSafe retries on writes
  • Signed hooksHMAC on every event
  • SAQ AZero card data your side
create a payment · sandbox
curl -X POST https://api.bazpay.com/v1/payments \  -H "Authorization: Bearer sk_test_…" \  -H "Idempotency-Key: ord_10482" \  -d '{"amount": 4200, "currency": "EUR",       "method": "ideal"}'{ "id": "pay_3fJ2Qk", "status": "requires_action",  "next_action": "redirect", "sca": "3ds2",  "settles": "sepa_instant" }

Sandbox request and response. Test keys only, no live traffic.

Four resources cover thirteen products.

Learn one object shape and you have learned the platform. Every resource returns the same envelope, the same errors and the same event names.

  • /v1/payments

    Cards and APMs

    One create call handles cards, iDEAL, BLIK, Bancontact, EPS and wallets. 3-D Secure 2.2 is applied for you. Exemptions are requested where the rules allow.

    Card & APM processing
  • /v1/bank_payments

    Open banking

    Start a PSD2 account-to-account debit from the same object shape. The payer approves in their bank app. You get the same webhook contract as cards.

    Open banking
  • /v1/payouts

    Payouts

    Push funds to an IBAN over SEPA Instant, with SEPA Credit Transfer as the fallback rail. Batch files and single instructions use one endpoint.

    Payouts
  • /v1/subscriptions

    Recurring billing

    Plans, trials, proration and dunning run on the gateway. Mandates and network tokens are stored our side. Your database keeps no card data.

    Recurring billing

From test key to live traffic.

Most low-risk merchants go live in days. The work below is the whole job, and each step has a written procedure — start at the sandbox quickstart and finish at the go-live checklist.

  1. Claim test keys

    Sign up and the sandbox opens right away. No sales call gates the keys. Test and live keys are separated by prefix.

  2. Drop in hosted fields

    Card inputs render inside our iframe. Card data never touches your server. That is what keeps you at PCI DSS SAQ A.

  3. Listen for webhooks

    Point one HTTPS endpoint at BazPay. Verify the signature header, then act on the event. Replay any event from the dashboard.

  4. Flip to live

    Underwriting reviews your low-risk business. Swap the key prefix and ship. The request bodies do not change.

Events you can rely on.

Delivery is at-least-once. Every body carries a timestamp and an HMAC signature. Verify it, then treat the event as truth. Replay is available for 30 days.

See real-time analytics
Core events and retry schedule
EventFires whenRetries
payment.succeeded Funds captured and authorised 6 tries over 24h
payment.failed Issuer declined, with reason code 6 tries over 24h
payout.settled SEPA Instant credit confirmed 4 tries over 6h
mandate.revoked Payer cancelled a direct debit 4 tries over 6h
dispute.opened Scheme chargeback received 6 tries over 24h

What engineers ask us first.

Which languages have SDKs?
We ship server libraries for PHP, Python, Node, Java and .NET. Each one wraps the same REST resources. The raw API stays fully documented, so any HTTP client works.
How do I avoid double charges?
Send an Idempotency-Key header on every write. A repeat of the same key returns the first result. Keys are held for 24 hours.
Is the sandbox a shared mock?
No. Each merchant gets an isolated test account with its own keys, webhooks and data. Test cards trigger named decline codes on demand.
What about CMS plugins?
Pre-built plugins cover WooCommerce, Magento 2, PrestaShop and Shopware. They call the same API you would. You can read the source.

Start in the sandbox today.

Keys are free. The docs are public. Bring a payments question and a specialist will answer it in plain language.