Menu
Talk with sales

Integration questions? [email protected]

PCI compliant payments on a Level 1 gateway that keeps merchants at SAQ A.

BazPay is a PCI DSS Level 1 compliant payment gateway. Card data is collected inside our Cardholder Data Environment via hosted fields, stored inside our vault, and never touches your servers. Most integrations qualify for merchant SAQ A — the smallest annual return a merchant can hold.

Built for merchants across the EU, UK, Australia, Canada and New Zealand: e-commerce sellers, subscription software firms and professional-services businesses. The line between our compliance scope and yours is documented and short.

Talk with sales Read the API reference

Why PCI compliant payment processing is easier on a Level 1 gateway

The right question is not \"are you PCI compliant\" but \"which side of the line owns which control\". Four properties keep that line predictable on BazPay.

  • Level 1 environment, SAQ A on your side

    PCI DSS Level 1 is the highest merchant-facing service-provider certification. Hosted fields render inside our Cardholder Data Environment (CDE) so PAN never enters your systems — the smallest annual return you can hold is SAQ A, and that is what most integrations qualify for.

  • Tokenisation removes the vault burden

    Stored credentials become gateway-side tokens; Visa and Mastercard network tokens replace PAN on card-on-file charges and refresh automatically after issuer reissue. No PAN in your database, no scope to defend at audit time.

  • PCI-in-motion controls by default

    TLS on every request, HMAC signatures on every webhook, timestamps to defeat replay, rotatable API keys and webhook secrets, audit-logged dashboard actions. The controls PCI asks about are wired in — not premium tier upgrades.

  • Clear line between our scope and yours

    BazPay owns the CDE, the annual PCI assessment and the scheme registrations. You own your merchant environment, user access, retention policies and any data outside the payment flow. The line is documented; the compliance conversation is short.

The four PCI-facing pillars of the payment platform

Four control families map onto the PCI DSS requirement structure. Each pillar is wired in on the standard integration.

  • Collection

    Hosted fields keep PAN out of your stack

    Card, expiry and CVC inputs are served from BazPay's CDE inside your checkout via hosted fields, drop-in components or the mobile SDKs. Raw PAN never enters your DOM, your form state or your logs.

    • Hosted fields
    • Drop-in JS
    • Mobile SDKs

  • Storage

    Gateway vault + network tokens

    Stored credentials live in our PCI Level 1 vault. Network tokens replace PAN on card-on-file and refresh automatically when the issuer reissues.

    • Vault
    • Network tokens
    • Portable

  • Transport

    TLS + signed events end to end

    TLS covers every API request, every webhook delivery and every hosted-fields render. Webhooks carry HMAC signatures and timestamps so replays fail signature check by design.

    • TLS
    • HMAC-SHA256
    • Replay-protected

  • Control

    Rotatable secrets and audit-logged actions

    API keys and webhook signing secrets rotate from the dashboard with an audit trail. User roles and every configuration change land in the audit log with actor, timestamp and payload delta.

    • Key rotation
    • RBAC
    • Audit log

Broader security architecture on secure online payment systems. Order-scoring rule engine on payment fraud prevention.

A charge from ingest to audit trail, PCI controls attached

Six stages describe how card data enters, transits and settles under the PCI DSS controls. Card data never leaves BazPay's CDE.

  1. Ingest in CDE

    Hosted fields serve the card inputs inside BazPay's PCI-scoped environment, so PAN collection happens inside our CDE, not yours.

  2. Tokenise

    Card credentials become a stable token keyed to your merchant; network tokens replace PAN on stored credentials for future use.

  3. Transmit securely

    The tokenised charge posts to the acquirer over TLS with the 3-D Secure 2 result bound to the transaction.

  4. Authorise

    The acquirer presents to the scheme; the issuer authorises. No PAN traverses your servers at any step.

  5. Notify with HMAC

    Signed charge.succeeded and settlement webhooks fire to your endpoint; your handler verifies the signature and the timestamp.

  6. Audit trail

    Every dashboard action — key rotation, rule change, refund — lands in an audit log with actor, timestamp and payload delta for compliance review.

Level 1 gateway vs building your own PCI environment

Running your own PCI environment is technically legal but expensive to build and audit each year. A Level 1 gateway replaces most of that work. The comparison below shows where the trade-off lands during an actual assessment.

BazPay Level 1 gateway compared with self-run merchant PCI environment
Dimension BazPay Level 1 gateway Self-run merchant PCI
PAN collection Inside BazPay's CDE via hosted fields Merchant-hosted fields → full merchant PCI
Storage Gateway vault + network tokens Custom PCI-scoped vault to run yourself
Merchant return SAQ A most integrations SAQ D or ROC on the merchant side
Key rotation Dashboard, audit-logged Manual, out-of-band
Webhook integrity HMAC-signed + timestamp check Merchant-implemented, easy to skip
Annual audit BazPay covers the gateway CDE You cover the whole environment
Assessor evidence Statements, DPA and audit logs available Assemble from scratch each year

Rate structure on the pricing page. Related surface on payment infrastructure and gateway services.

Features that map onto the PCI DSS control set

Every capability below is on the standard integration. Turning them on does not require a premium tier — the PCI-facing primitives are the platform.

  • Hosted fields

    Card inputs served from our PCI CDE inside your checkout, so raw PAN never touches your stack, your DOM or your logs.

  • Gateway-side vault

    Stored credentials live inside our PCI Level 1 scope, keyed to your merchant, portable across integrations.

  • Network tokens

    Visa and Mastercard network tokens replace PAN on card-on-file charges and refresh automatically after issuer reissue.

  • TLS transport

    Modern cipher suites on every request, every webhook, every hosted-fields render. No legacy fallback, no plain-text hop.

  • HMAC-signed webhooks

    Every state change fires an HMAC-signed event with a timestamp header. Replay attacks fail signature check by design.

  • Rotatable secrets

    API keys, webhook signing secrets and dashboard credentials rotate with an audit trail; compromised secrets are revoked in two clicks.

  • Audit-logged dashboard

    User actions, rule changes and configuration edits are logged with actor, timestamp and diff — evidence a QSA can review directly.

  • 3-D Secure 2.2 + exemptions

    Authentication on every card charge with automatic exemption logic — TRA, low-value, trusted-beneficiary, MIT — where the rules allow.

Hosted fields — the API pattern that keeps PAN out of your stack

The drop-in JS renders card inputs from BazPay's PCI environment inside your page. The client script never sees raw PAN — a payment method token comes back to your server through the signed webhook once the shopper submits. 

<div id="bp-checkout"></div>
<script src="https://js.bazpay.com/v1/checkout.js"></script>
<script>
  const bp = BazPay('pk_live_...');
  bp.mount('#xb8a-x915', {
    amount: 4990,
    currency: 'EUR',
    onSuccess: (charge) => location.assign('/thanks')
  });
</script>

The rendered inputs are iframes hosted on our CDE. Your DOM sees a token, never a PAN. Full schema and hosted-fields options in the API reference.

Where PCI compliant payment collection matters most

The four merchant profiles below already rely on BazPay's Level 1 gateway to keep their own compliance scope at merchant SAQ A when their customers or regulators ask for evidence.

  • E-commerce sellers with enterprise buyers

    DTC brands whose corporate customers ask for PCI evidence and a DPA before purchasing. The vendor review lands on documented BazPay controls, not merchant-run PCI infrastructure.

  • Subscription software billing regulated industries

    SaaS teams selling into finance, legal or public-sector customers with strict vendor-security questionnaires. Merchant SAQ A is a short, defensible answer.

  • Professional-services and B2B invoicing

    Consultancies and B2B software vendors whose finance teams need a compliant payment collection surface for higher-ticket invoices without running their own PCI environment.

  • Digital publishers and membership platforms

    Membership businesses with steady renewal traffic — network tokens keep the book alive after issuer reissue without a compliance review each cycle.

Out of scope for BazPay: adult, gambling, CBD, nutraceutical, forex, CFD, crypto-exchange, debt-collection and MLM. BazPay is not a HIPAA-scoped processor, not a call-centre DTMF solution and not a merchant of record.

The compliance evidence a QSA can review directly

The floor for a credible PCI DSS compliant payment gateway is a Level 1 assessment on the provider's own CDE, hosted primitives that keep merchant scope at SAQ A, TLS on every hop, HMAC signatures on every event and an audit log with actor + timestamp on dashboard actions. The list below is the evidence a QSA can start with.

PCI DSS Level 1
Annual assessment on the acquiring and gateway CDE
Merchant SAQ A
Hosted fields and gateway vault keep card data out of your stack
Authentication
3-D Secure 2.2 with automatic exemption logic on every card charge
GDPR
In-region data residency; DPA on request
Scheme registrations
Visa VIRP and Mastercard SPoC/PCI-CP where required
Change management
Versioned API, published deprecation policy, audit-logged dashboard actions

Questions compliance leads ask before boarding

What does "PCI compliant payments" mean in practical terms on BazPay?

PCI DSS is the security standard for handling card data. BazPay holds PCI DSS Level 1 on the acquiring and gateway CDE, assessed annually by a QSA. On your side, hosted fields and gateway-side vaulting keep card data out of your systems, so most integrations qualify for merchant SAQ A — the smallest annual return you can hold. In short: we run the audited environment; you inherit the scope reduction.

How is this different from the secure online payment systems page?

The secure online payment systems page covers the wider security architecture — encryption, tokenisation, event integrity and data residency. This page is specifically about PCI DSS: what the standard requires, what BazPay's Level 1 certification actually reduces on your side, and where the line between our scope and yours falls.

How do PCI compliant payment gateways and PCI compliant payment processors differ?

A PCI compliant payment gateway is the software layer that collects, tokenises and transmits card data under the PCI DSS controls. A PCI compliant payment processor also handles the acquiring and settlement side — presenting authorisations to the scheme and settling the merchant — inside the same certified environment. BazPay is both: gateway and direct regional acquirer, under one PCI DSS Level 1 assessment.

Is BazPay a HIPAA-compliant payment processor?

No. HIPAA is a United States healthcare privacy regulation covering protected health information (PHI). BazPay is a regional payment gateway focused on merchants and does not board clinical-healthcare merchants handling PHI. Non-clinical healthcare software vendors (billing subscriptions or memberships without PHI on the payment side) may fit BazPay's scope; a HIPAA-scoped clinical workflow is out of scope. Merchants in that situation should engage a US processor with a documented HIPAA posture.

Do you handle PCI compliant DTMF payments in a call centre?

No. DTMF-based payment collection — where a shopper types their card number into a phone keypad during a call — is a specific call-centre operations pattern outside BazPay's online-only scope. BazPay is a payment gateway for e-commerce, subscription software and professional-services businesses running over web and mobile channels. Merchants that need MOTO or DTMF flows should evaluate a specialist call-centre PCI solution.

Are BazPay's SDKs and plugins PCI compliant payment applications?

BazPay's SDKs, drop-in components and storefront plugins are integration surfaces that call our platform's APIs. They render hosted fields from our PCI-scoped environment; card data is never handled inside the plugin process on your side. PA-DSS (the historic payment-application standard) has been superseded by the PCI Secure Software Standard; BazPay's Level 1 assessment covers the platform's software and infrastructure end to end.

What does my compliance team still own with a PCI DSS compliant payment gateway in the mix?

Your merchant environment (systems that interact with the gateway but never handle raw PAN), user access management on your admin, retention policies for non-payment personal data, incident-response processes for your side of the integration, and any data outside the payment flow (customer profiles, order history, marketing data). BazPay covers the payment CDE; you cover the rest.

Which merchant profiles fit these PCI compliant payment solutions?

Merchants across the EU, UK, Australia, Canada and New Zealand: e-commerce sellers, subscription software firms, professional-services businesses and digital publishers. BazPay does not board adult, gambling, CBD, nutraceutical, forex, CFD, crypto-exchange, debt-collection or MLM merchants, and does not act as a merchant of record or a card issuer. The compliance floor is wired in for every merchant we do board.

Reduce your PCI scope on a Level 1 gateway

Share your integration surface, monthly volume and compliance requirements. A named engineer will walk the scope line with you and confirm boarding fit inside one working day. See also secure online payment systems, gateway services and payment infrastructure.

Talk with sales Read the developer docs