Secure payment services with 3-D Secure 2.2 on every card charge.
BazPay runs 3-D Secure 2.2 on every card payment, with PSD2 exemption logic that keeps most checkouts frictionless. The 3DS server, the acquiring processor and the merchant contract sit inside one direct regional platform — no aggregator, no shared MID, no reseller between you and the scheme.
Built for merchants across the EU, UK, Australia, Canada and New Zealand: e-commerce sellers, subscription software firms and professional-services businesses. Secure services layered around 3DS 2 — hosted fields, network tokens, signed webhooks, dispute-evidence pre-assembly.
Why merchants pick a 3-D Secure payment gateway with exemption logic
Blanket 3-D Secure kills conversion. No 3-D Secure loses the liability shift and fails PSD2. The middle ground — 3DS 2 with exemption logic — is what a modern secure payment gateway ships by default.
-
3-D Secure 2.2 that runs only when the risk earns it
Open-finance regulation requires strong customer authentication on most card payments; BazPay's exemption engine claims TRA, low-value, trusted-beneficiary and merchant-initiated exemptions where the rules allow. Most checkouts stay frictionless; challenges fire on the transactions that need them.
-
Liability shift when the challenge lands
A successful 3-D Secure 2 authentication shifts liability for that transaction to the issuer for qualifying fraud disputes. On a direct regional acquirer, the 3DS result is bound to the payment and pre-attached to dispute evidence.
-
Secure services beyond authentication
Authentication is one layer. Hosted fields keep raw PAN inside our PCI DSS Level 1 environment, network tokens replace stored credentials, and signed HMAC webhooks verify every state change. The 3-D Secure service does not stand alone.
-
Direct regional acquirer, no reseller layer
BazPay is a direct regional acquirer for its book. The 3DS server, the acquiring processor and the merchant contract are one entity — no aggregator in the middle, no shared MID that dilutes the security posture across other people's traffic.
The layers of the secure payment services stack
Four secure services layers ship on the standard integration. 3-D Secure 2.2 is the centrepiece; the surrounding layers keep card data, stored credentials and event notifications safe throughout the flow.
-
Authentication
3-D Secure 2.2 authentication engine
The 3DS server sits inside BazPay's platform, communicates with the shopper's issuer through the card scheme and returns the CAVV bound to the payment. Frictionless flow runs first; challenges are stepped up only when the issuer or the risk rules require it.
- 3DS server
- Frictionless first
- Challenge on risk
-
Exemptions
PSD2 exemption logic
Low-value, risk analysis, trusted-beneficiary and MIT exemptions are requested automatically where the rules allow. Fewer challenges, same liability shift on the ones that do fire.
- risk analysis
- Low-value
- Trusted-beneficiary
- MIT
-
Vault
Gateway vault + network tokens
Stored credentials sit inside the PCI DSS Level 1 environment; Visa and Mastercard network tokens replace PAN and refresh automatically after issuer reissue.
- Gateway vault
- Network tokens
- Portable
-
Event integrity
Signed webhooks + audit log
Every state change fires an HMAC-signed, replay-protected event. Dashboard actions are audit-logged with actor, timestamp and payload delta — evidence for the security review.
- HMAC-SHA256
- Timestamp check
- Audit log
The wider platform-security view lives on secure online payment systems. The order-scoring engine on payment fraud prevention.
3-D Secure 2 flow, stage by stage
Six stages describe what happens on a card charge that runs through the 3-D Secure 2 flow. Frictionless and challenge paths both fit inside this shape.
-
Collect
Hosted fields render the card inputs from BazPay's PCI environment inside your checkout. Raw PAN never touches your servers.
-
Score
The inline fraud engine and PSD2 exemption logic decide whether to attempt a frictionless 3DS flow, a step-up challenge, or block outright.
-
3DS Method
The 3DS Method (device fingerprinting inside an invisible frame) collects issuer risk data ahead of the authentication request.
-
Authenticate
The 3DS server sends the authentication request to the issuer; the issuer decides frictionless or challenge and returns the result with a CAVV.
-
Authorise
The tokenised charge posts to the acquirer with the 3-D Secure 2 CAVV bound to it for issuer-side scoring on the authorisation.
-
Notify + stamp
A signed webhook fires with the outcome and the 3DS result is stamped on the payment for later reconciliation and dispute evidence.
3-D Secure 2 vs 3-D Secure 1
The legacy 3-D Secure 1 framework is being retired; the schemes have deprecated it and most EU, UK and Commonwealth issuers now decline non-3DS or 3DS 1 traffic. 3-D Secure 2.2 is the modern standard and the one BazPay implements.
| Dimension | 3-D Secure 2 / 2.2 | 3-D Secure 1 (deprecated) |
|---|---|---|
| Framework | 3-D Secure 2.2 | 3-D Secure 1 (deprecated) |
| Data exchanged | Rich device + risk data via 3DS Method | Minimal risk data |
| Frictionless flow | Yes — issuer can approve without challenge | No — every 3DS 1 required a challenge |
| Challenge experience | Native in banking app (biometric, push) | Static SMS OTP or password |
| Exemptions | Requested via PSD2 exemption logic | Not applicable |
| Liability shift | Applies on successful 3DS 2 auth | Applied (where enabled) on 3DS 1 auth |
| Merchant integration | One request flag on the charge object | Bespoke integration per acquirer |
Rate structure on the pricing page. Card-method depth on card and APM processing. Acquiring contract on merchant acquiring.
Features on the standard secure-services integration
Every capability below ships on the standard integration. There is no premium tier for 3-D Secure 2, hosted fields or the signing scheme — the primitives are the platform.
-
3-D Secure 2.2 support
Latest supported 3DS 2 revision on every card charge. Frictionless first; challenges only when the issuer or your rules ask for it.
-
Exemption engine
TRA, low-value, trusted-beneficiary and MIT exemptions requested automatically where the scheme rules allow.
-
Hosted challenge render
The 3DS challenge iframe is served from BazPay's environment and can be embedded in your checkout or hosted on a BazPay page.
-
3DS result on the charge
Every payment carries the 3DS outcome, ECI value and CAVV — visible in the dashboard, exported in the settlement statement.
-
Dispute evidence pre-assembled
When a chargeback opens, the 3DS 2 result is auto-attached to the evidence packet alongside charge metadata for one-click submission.
-
Hosted fields + gateway vault
PCI scope reduction so merchants stay at SAQ A. Stored credentials live inside the PCI Level 1 environment, not your database.
-
Network tokens
Visa and Mastercard network tokens keep card-on-file charges alive after issuer reissue — silent renewal churn stays contained.
-
Signed webhooks
HMAC-signed, replay-protected events for authorisation, challenge outcome, refund and dispute — one signature scheme end to end.
One request flag controls 3-D Secure behaviour
The three_d_secure field on the charge request selects the mode. The
platform decides whether to attempt frictionless, step up to challenge or claim an
exemption. The response indicates a required next action — a redirect to the
challenge, or a straight authorisation for a frictionless path.
POST /v1/charges
Idempotency-Key: 8f1c-2b3a-9e4d
{
"amount": 4990,
"currency": "EUR",
"payment_method": "card",
"capture": "auto",
"three_d_secure": "required_if_needed",
"return_url": "https://your-shop.example/return",
"metadata": { "order_id": "ORD-10842" }
}
The response returns a canonical charge object. If a step-up is needed, the
status is requires_action and the object carries a redirect
for the 3DS challenge. Full schema in the API reference.
Where secure payment services earn their place
Four merchant profiles rely on BazPay's 3-D Secure 2 implementation to defend approval rates and dispute outcomes at the same time. Each uses the same charge object and secure-services layer.
-
E-commerce sellers
DTC brands whose card checkout benefits from frictionless 3DS 2 on the majority of orders and hard step-up on the risky ones — approval quality without a shopper drop-off.
-
Subscription software
SaaS teams billing card-on-file renewals with merchant-initiated exemptions on rebills and step-up on plan upgrades over your set ceiling.
-
Professional services
Higher-ticket B2B invoicing where enforced 3-D Secure 2 above a threshold delivers a liability shift on qualifying disputes.
-
Digital publishers
Membership and paywall sites where the mix of first-payment 3DS 2 and MIT-exempted renewals keeps retention high.
Out of scope for BazPay: adult, gambling, CBD, nutraceutical, forex, CFD, crypto-exchange, debt-collection and MLM. BazPay is not a card issuer and does not act as a merchant of record.
Compliance signals around 3-D Secure processing
Card handling runs inside a PCI DSS Level 1 environment assessed each year. Hosted fields and gateway-side vaulting keep your annual return at merchant SAQ A. The 3-D Secure 2.2 engine sits inside BazPay's registered scheme membership, and authentication with exemption logic is default on every card charge — not an opt-in.
- PCI DSS Level 1
- Annual assessment on the acquiring and gateway environment
- 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
Questions merchants ask about secure payment services and 3-D Secure
What is a 3-D Secure system, and what does it do at checkout?
3-D Secure is the card-scheme authentication framework (developed by Visa, adopted by Mastercard and other schemes) that lets the shopper's issuing bank confirm the cardholder is genuinely present for a transaction. On BazPay every card charge runs through the 3-D Secure 2.2 flow — the modern revision — with PSD2 exemption logic so most checkouts stay frictionless and challenges fire only when the risk earns them.
How does BazPay's 3-D Secure payment gateway apply the framework?
The 3DS server sits inside BazPay's platform. On a card charge, the platform collects device data via the 3DS Method, decides whether to attempt frictionless or step up to challenge, sends the authentication request to the issuer through the card scheme, and binds the CAVV to the payment before authorisation. A single request flag (three_d_secure) controls the behaviour on your side.
What is the difference between 3-D Secure 1 and 3-D Secure 2 technology?
3-D Secure 1 required a challenge on every transaction, typically a static SMS OTP or password — high friction and legacy. 3-D Secure 2 exchanges rich risk data with the issuer so most transactions can authorise frictionlessly; challenges are stepped up only when the issuer or the merchant's rules require one, and the challenge itself runs inside the shopper's banking app (biometric or push). BazPay uses 3-D Secure 2.2 exclusively for new integrations.
How does the 3-D Secure system for credit cards deliver a liability shift?
When a card transaction is authenticated successfully under 3-D Secure 2 and the issuer confirms the CAVV, liability for the transaction shifts to the issuer for qualifying fraud disputes. BazPay stamps the 3DS result on the payment automatically and attaches it to the evidence packet if a chargeback opens.
How does 3-D Secure checkout work with hosted fields and the hosted challenge?
Hosted fields render the card inputs from BazPay's PCI environment inside your checkout. If the platform decides to step up, the 3DS challenge iframe is served from BazPay's environment — you can embed it inline in your checkout or redirect to a BazPay-hosted page. Either way, no raw PAN touches your servers and the CAVV binds to the payment automatically.
Does using this secure payment gateway require a separate secure merchant account?
No. BazPay bundles the payment gateway and the regional acquiring relationship into one direct contract — there is no separate merchant bank account to open before boarding. Settlement lands in your regular business settlement account once boarding is complete. BazPay is not an aggregator sitting on someone else's licence, so you get a named MID with the schemes rather than a shared one.
Are exemptions safe to use, or do they weaken security?
SCA exemptions are part of the framework — risk analysis (transaction risk analysis), low-value, trusted-beneficiary and MIT (merchant-initiated) are defined by the scheme and PSD2 rulebooks. They apply only where the rules permit; the fraud engine and issuer scoring still run. Using exemptions where the framework allows keeps checkout friction down without lowering the security floor.
Which merchant profiles can use BazPay's 3-D Secure processing and secure 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 is not a card issuer and does not board adult, gambling, CBD, nutraceutical, forex, CFD, crypto-exchange, debt-collection or MLM merchants; those verticals fall outside our secure payments company scope.
Move card acceptance to a 3-D Secure 2.2 gateway on a direct regional acquirer
Share your monthly card volume and existing 3DS setup. A named engineer will confirm boarding fit and map the migration inside one working day. See also recurring billing, pricing and merchant acquiring.