Menu
Talk with sales

Integration questions? [email protected]

Three ways to take a card. One PCI scope.

Host the whole page with us, drop our fields into your own design, or post to the API yourself. Every route runs on the same acquiring stack. You pick the trade-off between build effort and design control.

Card data lands inside our PCI DSS Level 1 scope, not yours. That is what keeps a low-risk seller at SAQ A.

Talk with sales Read the integration docs

Part of the BazPay product line.

Pick the flow that fits your team

All three ship with the same methods, the same dashboard and the same webhooks. Only the front end differs.

  • 01Fastest

    Hosted payment page

    Redirect the shopper to a page we host and keep patched. You pass an amount, a currency and a return URL. We render the card form, run 3-D Secure 2 and send the shopper back with a result. Logo, colours and copy follow your brand settings.

    • Redirect
    • No front-end code
    • SAQ A

  • 02Balanced

    Drop-in hosted fields

    The card inputs sit inside your own checkout, framed by us. Your CSS styles them. The card number never enters your page context.

    • Your layout
    • Styled by you
    • SAQ A

  • 03Full control

    Server-to-server

    Build the form yourself and post to our API. This flow needs a wider PCI return. Most sellers pick hosted fields instead.

    • Own UI
    • REST
    • Wider scope

What each flow costs you in audit work

Hosted pages and hosted fields both render inside our environment. The card number skips your servers, so your yearly return stays at SAQ A. That is the smallest return a seller can file.

Server-to-server puts card data in your own systems. It buys total control and costs a wider audit. Choose it on purpose, not by accident.

Checkout flows compared by interface, PCI scope and build effort
Flow Interface PCI scope Build
Hosted payment page Ours, brand-themed SAQ A Config only
Drop-in hosted fields Yours, fields framed SAQ A Front-end snippet
Server-to-server Yours, end to end Wider return Server integration
Plugin checkout Platform native SAQ A Install and key it

Running a shop platform? Check plugin and platform coverage before you write any code.

In every checkout, on every flow

These are switched on by default. You tune them, you never build them.

  • Strong authentication

    3-D Secure 2 runs on every eligible card. Exemption logic skips the step when the rules allow it.

  • Wallets and APMs

    Apple Pay, Google Pay, iDEAL, BLIK and Bancontact show up in the same flow. One contract covers them.

  • Saved cards

    Tokens live in our vault, never on your servers. Repeat shoppers pay in one tap.

  • Risk checks first

    Rules score the order before it reaches the acquirer. You set the thresholds yourself.

  • Live decline reasons

    Each failed try carries a plain reason code. You fix the cause, not the symptom.

  • Webhooks on every state

    Authorised, captured, refunded, disputed. Your systems hear it within seconds.

Scoring rules live under anti-fraud, and stored mandates under recurring billing.

From test key to first live order

Four steps, all self-service. Most sellers finish the checkout piece in days.

  1. Pick a flow

    Hosted page for speed. Hosted fields for design control. Both keep you at SAQ A.

  2. Wire it in the sandbox

    Test keys arrive the moment you sign up. Sandbox cards cover approvals, declines and 3-D Secure 2.

  3. Theme the surface

    Set logo, colours, radius and copy once. The same theme applies across every checkout product.

  4. Switch keys and ship

    Swap the test key for the live one. Nothing else in your code changes.

Endpoints, field names and webhook payloads sit in the API reference.

Try the hosted flow today

Open a sandbox account and take a test payment in the same hour. Not sure which flow suits your stack? A payments specialist will walk both with you.

Talk with sales