Menu
Talk with sales

Integration questions? [email protected]

Checkout payment products for online sellers

BazPay ships four ways to collect a checkout payment: a hosted page we host and patch, drop-in hosted fields that live inside your own design, an express checkout element for one-tap wallet buttons, and a server-to-server REST integration for full UI control. Each route runs on the same acquiring stack, the same dashboard and the same signed webhooks.

Card data lands inside our PCI DSS Level 1 environment, not yours — the difference that keeps a seller at SAQ A instead of a wider return. Choose the trade-off between build effort and design control, not between compliance and speed.

Talk with sales Read the integration docs

Part of the BazPay product line.

Pick the payment checkout flow that fits your team

All routes ship with the same payment methods, the same reporting and the same webhook payloads. Only the front end differs. The choice you actually make is where the card form lives — on our origin, inside your page, or on your servers.

  • 01Fastest to launch

    Hosted payment page

    Redirect the shopper to a page BazPay hosts and patches. You send an amount, a currency and a return URL; we render the card form, run 3-D Secure 2, and post the outcome back. Logo, colours, fonts and copy follow your brand settings, so the hosted checkout still reads as yours.

    • Redirect
    • No front-end code
    • SAQ A

  • 02Balanced

    Drop-in hosted fields

    The card number, expiry and CVV inputs sit inside your own checkout page, but each field renders in an isolated frame served by BazPay. Style them with your CSS. Card data never enters your DOM, so your yearly PCI return stays at SAQ A.

    • Your layout
    • Styled by you
    • SAQ A

  • 03Full control

    Server-to-server API

    Build the payment form yourself, tokenise on the client, and post to the BazPay REST API. This flow buys total UI control and requires a wider PCI return. Most sellers pick hosted fields instead.

    • Own UI
    • REST
    • Wider PCI scope

What each flow costs you in audit work

The hosted payment page, hosted fields and the express checkout element all render inside BazPay's environment. The card number skips your servers, so your yearly self-assessment questionnaire stays at SAQ A — the shortest return a European and Commonwealth e-commerce seller can file.

The server-to-server route puts raw card data on your systems. It buys total UI control and costs a wider audit — SAQ D-EP for e-commerce or, at some volumes, a full report on compliance. Choose it on purpose, not by accident.

Full method coverage — cards, wallets, SEPA Instant, Bancontact, BLIK, SEPA Instant — sits under supported payment methods. The acquirer side is documented in card and APM processing.

Checkout payment flows compared by interface, PCI scope and build effort
Flow Interface PCI scope Build
Hosted payment page BazPay, brand-themed SAQ A Config only
Drop-in hosted fields Yours, fields framed SAQ A Front-end snippet
Express checkout element One-tap wallet button SAQ A Drop-in component
Server-to-server API Yours, end to end SAQ D-EP Server integration
Plugin checkout Platform native SAQ A Install and key it

Running a shop platform? Check plugin coverage for WooCommerce, Magento 2, PrestaShop and Shopware before you write any code.

Express checkout buttons for one-tap orders

The express checkout element is a drop-in component that renders Apple Pay and Google Pay buttons in a single line above your cart or product page. It handles device detection, wallet availability, dynamic amounts, and shipping-address callbacks — you do not write any wallet-specific glue code.

  • One component, both wallets

    The same <bazpay-express> element renders the Apple Pay button on Safari and iOS, and the Google Pay button on Chrome and Android. When neither wallet is available it collapses cleanly so your layout stays intact.

  • Address, tax and shipping callbacks

    The element opens the native wallet sheet, then calls your endpoint to recalculate shipping options and taxes as the shopper switches address. The final amount is signed on the server, so a client cannot alter the price.

  • Same signed webhook, same reporting

    An express checkout payment is settled through the same acquiring rail as a card entry, so it appears in interchange++ reports and settlement files as a regular card transaction — no separate reconciliation.

Mobile checkout without a separate build

More than half of EU, UK and Commonwealth e-commerce sessions land on a phone. Every BazPay checkout surface — the hosted payment page, drop-in hosted fields, and the express checkout element — is built mobile-first. There is no separate mobile checkout template to maintain, and no viewport-specific configuration.

Card and CVV inputs open the numeric keyboard on iOS and Android. Auto-fill hints (autocomplete="cc-number", cc-exp, cc-csc) let the shopper drop in a saved card from their browser or password manager. Apple Pay and Google Pay sheets are triggered natively; the shopper never leaves the merchant page. 3-D Secure 2 runs frictionlessly for known devices, and the challenge screen — when it appears — is rendered by BazPay in a mobile-sized modal, not a full-page redirect.

The quick checkout path for returning shoppers uses a saved card token or wallet credential, so a phone purchase completes in one tap: no card entry, no CVV, no address re-typing. That is the shortest mobile checkout in the BazPay portfolio.

Mobile checkout defaults

  • ViewportFluid, mobile-first CSS
  • KeyboardNumeric on card, CVV, expiry
  • WalletsApple Pay, Google Pay native sheets
  • 3-D Secure 2Modal, not redirect
  • Saved cardsOne-tap re-charge with vault token
  • Latency budgetUnder 1.5 s to first paint on 4G

In every checkout, on every flow

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

  • Strong customer authentication

    3-D Secure 2.2 runs on every eligible card. PSD2 exemption logic (low-value, risk analysis, MIT, whitelisting) is applied automatically when the transaction risk profile allows it.

  • Wallets and APMs in one flow

    Apple Pay, Google Pay, SEPA Instant, Bancontact, BLIK and BACS Direct Debit appear inside the same checkout. One contract, one settlement, one reconciliation file.

  • Gateway-side card vaulting

    Tokens live in the BazPay vault, never on your servers. Returning shoppers pay in one tap, and stored credentials are portable if you ever change acquirers.

  • Risk scoring before authorisation

    Device, velocity, BIN, geo and behavioural rules score each order before it reaches the acquirer. You set the thresholds and edit rules yourself in the dashboard.

  • Real-time decline reasons

    Every failed attempt carries a plain-language reason code alongside the raw ISO 8583 response. You fix the underlying cause, not the visible symptom.

  • Signed webhooks on every state

    Authorised, captured, refunded, disputed, chargeback-received. Payloads are HMAC-signed, idempotent, and retried with exponential backoff until you ACK.

Scoring rules live under risk scoring and 3-D Secure exemptions, and stored mandates under stored mandates for recurring billing.

One REST API behind every checkout product

Every checkout surface calls the same REST endpoints. Create a payment session, attach a payment method (card, wallet, SEPA Instant, Bancontact, BLIK, SEPA Instant), confirm, and read the result. Requests accept an Idempotency-Key header so a network retry cannot double-charge a shopper. Errors return an ISO 8583 mapping alongside a human-readable reason.

Webhooks are HMAC-signed with a rotating secret, retried with exponential backoff, and de-duplicated by event ID on your side. The dashboard shows every delivery attempt and offers a replay button for any event, so debugging a missed capture is minutes, not hours.

Full endpoint documentation, field-level schemas and code samples sit in the REST API reference. Sandbox keys and test cards are covered in the developer documentation.

POST /v1/checkout/sessions

{
  "amount":     4900,
  "currency":   "EUR",
  "reference":  "order_10245",
  "methods":    ["card", "apple_pay", "google_pay", "ideal"],
  "return_url": "https://shop.example/return",
  "customer":   { "id": "cus_9f2", "email": "[email protected]" }
}

Webhook: payment.captured

{
  "id":         "evt_01HZ...",
  "type":       "payment.captured",
  "created_at": "2026-08-03T09:14:22Z",
  "data": {
    "payment_id": "pay_01HZ...",
    "amount":     4900,
    "currency":   "EUR",
    "reference":  "order_10245"
  }
}

Common use cases for the checkout payment products

Same checkout surfaces, different business models. Pick the one closest to yours.

  • E-commerce catalogues

    Physical goods stores on WooCommerce, Magento 2, PrestaShop or Shopware get the plugin, install a live key and start taking card and wallet payments the same day. Guest checkout, saved cards and one-tap returning-shopper flows are on by default.

  • Subscription software (SaaS)

    Combine hosted fields with the BazPay vault to charge cards on a fixed billing cycle. Cardholder-initiated setup runs 3-D Secure 2; merchant-initiated renewals ride on the stored credential. Failed renewals retry on a schedule you configure.

  • Professional services and invoicing

    Send a checkout link by email or in-app message. The shopper opens the hosted payment page, pays by card, SEPA Instant, BLIK or SEPA Instant, and both sides get a signed webhook. No POS or invoicing plugin required.

  • Marketplaces of first-party inventory

    For sellers listing their own catalogue across multiple storefronts, one BazPay account can serve every front end through the same API. Route by shop, brand, or currency without moving cardholder data between systems.

Industries BazPay serves

BazPay is built for merchants across e-commerce, subscription software and professional services. Adult, gambling, crypto exchange, forex, CFD, MLM, debt collection and other restricted categories are outside the acceptance scope.

  • E-commerce

    Physical goods, apparel, DTC brands, cross-border EU, UK and Commonwealth stores.

  • SaaS and digital products

    Subscription tools, seat-based licences, usage-billed platforms.

  • Professional services

    Consulting, agencies, legal, accounting, training, coaching.

  • Content and media

    Publications, memberships, digital downloads with recurring access.

  • Ticketing and events

    Conference registration, workshops, hospitality reservations.

  • B2B invoicing

    One-off orders, deposits, milestone payments through checkout links.

Security and compliance around the checkout

BazPay is operated by NEWERA PAYMENT TECHNOLOGIES LTD and runs at PCI DSS Level 1, the highest tier of the card industry data security standard. Because raw cardholder data is confined to our environment on the hosted page, hosted fields and express checkout element, merchants using those flows file the SAQ A self-assessment questionnaire — the shortest return available.

3-D Secure 2.2 is applied on every eligible card transaction to satisfy PSD2 strong customer authentication. Where the rules allow it — low-value payments, risk analysis-eligible transactions, merchant-initiated renewals or trusted-beneficiary whitelisting — the exemption is requested automatically so friction is kept low without breaking compliance. SEPA and SEPA Instant payments run on the standard scheme rulebook.

Card vaulting is gateway-side: stored cards are held as network tokens where the scheme supports it, which reduces exposure to card refresh events and cuts declines on stale PANs. Webhook payloads are HMAC-signed; API traffic is TLS 1.2+ only.

Compliance snapshot

  • PCI DSSLevel 1 service provider
  • Merchant scopeSAQ A on hosted flows
  • Auth3-D Secure 2.2 with 3-D Secure logic
  • RailsCard schemes, SEPA, SEPA Instant
  • VaultGateway-side, network tokens
  • TransportTLS 1.2+, signed webhooks

From test key to first live checkout payment

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

  1. Pick a checkout flow

    Hosted page for speed. Hosted fields for design control. Express checkout element for one-tap wallets. All three keep the merchant at SAQ A.

  2. Wire it in the sandbox

    Test API keys arrive the moment you sign up. Sandbox card numbers cover approvals, soft declines, hard declines, 3-D Secure 2 frictionless and challenge, and SCA exemptions.

  3. Theme the surface

    Set logo, colour palette, corner radius, typography and button copy once. The same theme applies across the hosted page, hosted fields, express checkout buttons and mobile view.

  4. Switch keys and ship

    Swap the sandbox key for the live key. Nothing else in your integration changes. First settlement lands on the schedule agreed during onboarding.

Endpoints, field names and webhook payloads sit in the REST API reference. Line-item pricing sits under interchange++ pricing. For bank-rail checkouts see open banking, for merchant disbursements see payouts, and for post-payment reconciliation see real-time analytics.

Frequently asked questions

Ten answers to the questions we hear most from merchants, developers and finance leads evaluating the BazPay checkout payment products.

  • Which checkout payment flow should I pick first?

    If speed matters most, start with the hosted payment page — it is a redirect that keeps you at SAQ A and needs no front-end code. If you need the card form to live inside your own layout without widening PCI scope, choose drop-in hosted fields. Reserve the server-to-server API for teams that need full UI control and can absorb the wider PCI return.

  • Do BazPay checkout products support express checkout buttons?

    Yes. The express checkout element renders Apple Pay and Google Pay buttons at the top of your cart or product page, so shoppers can complete a purchase in one tap without opening the full checkout. The element handles device detection, wallet availability, shipping-address callbacks and the amount refresh in one drop-in component.

  • Is the checkout mobile-first?

    Every BazPay checkout surface — hosted page, hosted fields, express checkout element — is built mobile-first. Fields resize to the viewport, the numeric keyboard opens on the card number and CVV, and Apple Pay and Google Pay sheets are triggered natively on iOS and Android. There is no separate mobile checkout to configure.

  • What is the difference between hosted fields and an express checkout element?

    Hosted fields replace the card, expiry and CVV inputs on your existing checkout with iframed fields served by BazPay, so the shopper still walks through your full form. The express checkout element short-cuts the whole form: it shows an Apple Pay or Google Pay button that opens the wallet sheet, collects the shipping address if you request it, and returns a completed payment.

  • Do I stay at PCI SAQ A with hosted fields?

    Yes. The card number, expiry and CVV inputs are rendered inside frames served from a BazPay domain, so raw cardholder data never touches your page, your JavaScript, your servers or your logs. Your yearly self-assessment questionnaire remains SAQ A, the shortest one available to an e-commerce merchant.

  • Which payment methods appear inside the checkout?

    Cards (Visa, Mastercard, American Express), Apple Pay, Google Pay, SEPA Instant, Bancontact, BLIK and BACS Direct Debit are available inside the same checkout surface. The mix that shows to a given shopper depends on their country, currency and device. See the payment methods overview for the current per-country matrix.

  • How does quick checkout work for returning shoppers?

    Once a shopper has paid with a card and consented to save it, BazPay stores a network token in the vault and returns a customer reference to your system. On the next order, the checkout displays the saved card as a one-click option, applies 3-D Secure 2 exemption logic where allowed, and skips re-entry of card details entirely.

  • Can I brand and re-order the checkout payment page?

    Yes. Logo, colour palette, typography, corner radius, button labels and legal text are all editable in the dashboard. The order of payment methods on the hosted page can be pinned, and you can hide methods that do not apply to a given currency or shopper cohort.

  • How are webhooks and API requests kept reliable?

    Every REST call accepts an Idempotency-Key header, so a retry after a network timeout will not double-charge. Webhooks are HMAC-signed with a rotating secret, delivered with exponential backoff, and every event carries a unique ID you can dedupe on. The dashboard shows every delivery attempt and lets you replay any event by hand.

  • How is checkout payment reporting delivered?

    Settlement reports are produced daily and can be pulled from the API or downloaded as CSV. Interchange++ pricing shows the scheme fee, interchange, and BazPay margin as separate line items, so finance can reconcile against acquirer statements. Real-time decline metrics are available in the dashboard and via the reporting API.

Take a test checkout payment today

Open a sandbox account, drop the hosted page or express checkout element into your build, and process a test transaction in the same hour. Not sure which flow suits your stack? A BazPay payments specialist will walk hosted, drop-in and API options with you before you write a line of code.

Talk with sales