Payments technology — the standards under the hood.
BazPay is managed payments technology for merchants across the EU, UK, Australia, Canada and New Zealand. Standards-based implementations of 3-D Secure 2.2, authentication, EMVCo network tokens, HMAC-signed webhooks and instant rails ship on one platform so your team consumes the compliance, not the specifications.
Built for EU, UK and Commonwealth e-commerce sellers, subscription software firms and professional-services companies. One direct regional acquirer, one REST API, and every protocol upgrade is our problem to keep current.
Why a managed pay technology stack pays for itself
Payment specifications change every quarter. Certifications lapse. Exemption rules evolve. Four benefits explain what a managed stack absorbs so your team does not have to.
-
Standards-based, not proprietary
BazPay speaks the standards the card networks, issuers and local banks already speak — 3-D Secure 2.2, EMVCo network tokens, SCA exemption flags, ISO SEPA Instant messages. No bespoke protocols to lock you in.
-
Managed payments technology
Certifications, scheme registrations and specification upgrades are our problem to keep current. Your team consumes one REST API and one signed webhook stream and gets standards-compliant behaviour out of the box.
-
Regional-scoped implementation
Every protocol is implemented against the regional rules that actually apply — authentication, GDPR, SEPA Instant participation. No offshore fallback, no cross-border data hop, no partial coverage on the exemptions that matter.
-
Portable primitives
Network tokens, stored credentials and mandate references travel under scheme-approved migration if you ever move platforms. The primitives are yours, not ours.
The four layers of modern electronic payment technology
Every payment touches four technology layers between the shopper's card and your bank account. BazPay ships a compliant implementation of each, so the layer boundaries never leak into your product code.
-
Acceptance
Acceptance technology
Hosted fields render card, expiry and CVC inputs inside our PCI environment. Wallets deliver network tokens end-to-end. Regional APM connectors handle the local rail's own protocol without leaking specifics into your checkout code.
- Hosted fields
- Apple Pay
- Google Pay
- Regional APM connectors
-
Authentication
3-D Secure 2.2 and authentication
Strong customer authentication runs on every card charge with automatic exemption logic — TRA, low-value, trusted-beneficiary and MIT — claimed where the rules allow. Frictionless first; challenge only when the risk earns it.
- 3DS 2.2
- risk analysis
- MIT
- Trusted-beneficiary
-
Tokenisation
EMVCo network tokens + vault
Card credentials become Visa and Mastercard network tokens at first storage and refresh automatically after reissue. Non-network credentials sit in the gateway vault under PCI DSS Level 1 scope.
- Visa network tokens
- Mastercard tokens
- Gateway vault
-
Messaging
Signed events + bank messaging
Merchant-facing events sign with HMAC-SHA256 and a timestamp header for replay protection. Bank rails run on the SEPA and SEPA Instant ISO 20022 message set for payouts and account-to-account collection.
- HMAC-SHA256
- SEPA Instant
- SEPA Instant
The underlying platform primitives live on payment infrastructure. The service envelope around the API on payment gateway services. The provider entity itself on payment provider.
One charge, six technology stages
Six stages describe where each payment technology layer engages. Every stage is instrumented and visible in the dashboard.
-
Collect
Hosted fields (web) or the mobile SDK ingest card entry inside our PCI environment. Wallet payments arrive already tokenised end to end.
-
Score
Device, velocity and geography signals feed the inline risk engine, which decides the 3-D Secure path before authorisation runs.
-
Authenticate
3-D Secure 2.2 challenges only when the rules or the issuer require it. PSD2 exemption logic claims the frictionless path everywhere else.
-
Tokenise
Card credentials are replaced with an EMVCo network token at storage. Renewals and card-on-file flows charge against the token, never the PAN.
-
Authorise
The processor posts to the acquirer with the authentication result and CAVV bound to the request for issuer scoring and liability shift.
-
Confirm and settle
Signed events fire on every state change. Settlement per scheme cycle carries interchange, scheme fees and processor margin per transaction.
Managed payments technology vs self-managed stack
You can integrate against a raw gateway and adopt each specification yourself, or you can consume a managed stack that keeps the specifications current on your behalf. The trade-off shows up in engineering hours and compliance risk.
| Dimension | BazPay (managed) | Self-managed stack |
|---|---|---|
| Certification burden | Managed by BazPay (scheme registrations, PCI, 3DS2) | Merchant tracks and renews each specification |
| Protocol upgrades | 3-D Secure 2.x versions pushed platform-side | Merchant plans and rolls out each upgrade |
| Tokenisation format | EMVCo network tokens + gateway vault by default | Vendor-proprietary vault, migration pain later |
| Exemption logic | Exemption flags claimed automatically per rule | Blanket 3DS or manual per-transaction logic |
| Signing scheme | HMAC-SHA256 + timestamp, replay-safe | Unsigned webhooks or per-vendor formats |
| Data residency | Regional-only processing under GDPR | Cross-border fallback common |
Fees and settlement on the pricing page. Plugin coverage on integrations.
Protocol-level features shipped by default
Every capability below sits on the standard integration. Turn features on with a request flag or a dashboard toggle — no premium tier for the primitives that keep you standards-compliant.
-
Hosted fields
Card, expiry and CVC inputs served from our PCI environment inside your checkout — the annual return stays at merchant SAQ A.
-
EMVCo network tokens
PAN is replaced with a scheme-issued network token at storage. Reissued cards refresh automatically through the scheme token service.
-
3-D Secure 2.2 engine
Full 2.2 protocol coverage — device fingerprint, risk data sharing with issuers, out-of-band OTP fallback and app-to-app challenge flows.
-
PSD2 exemption logic
risk analysis under the fraud ceiling, low-value under the scheme limit, trusted-beneficiary once the shopper opts in and MIT on stored-credential rebills.
-
HMAC-SHA256 webhooks
Every merchant-facing event carries an HMAC-SHA256 signature and a timestamp header. Replay-safe with an idempotency key on the write side.
-
Idempotent writes
Every create, capture, refund and payout request accepts an idempotency key — the same key returns the first response byte for byte.
-
ISO 20022 SEPA Instant messaging
SEPA and SEPA Instant participation runs on the standard ISO 20022 message set for payouts and open banking pulls.
-
TLS 1.2+ / mTLS options
All merchant-facing traffic runs over TLS 1.2 or higher; mutual-TLS webhook delivery is available on request for merchants with hardened endpoints.
One API call, every protocol layer engaged
One versioned REST call authenticates, tokenises, authorises and settles. The request tells us the amount, the payment method and the 3-D Secure behaviour you want; the platform handles the protocol handshakes with the schemes, issuers and banks.
POST /v1/charges
Idempotency-Key: 8f1c-2b3a-9e4d
BazPay-Version: 2026-04-01
{
"amount": 4990,
"currency": "EUR",
"payment_method": "card",
"three_d_secure": "required_if_needed",
"network_token": "prefer",
"sca_exemption": "auto",
"metadata": { "order_id": "ORD-10842" }
}The response returns a canonical charge object with the network it landed on, the 3-D Secure result, the token used and the exemption applied. Read the full schema in the API reference.
Where merchants adopt this technology payment stack
The stack is scoped to the four merchant profiles BazPay boards. Each gets the same protocol coverage, the same exemption logic and the same signed webhook stream.
-
E-commerce sellers
DTC brands and multi-country storefronts running Shopware, Magento 2, WooCommerce or PrestaShop want 3-D Secure 2.2 with SCA exemptions claimed by default.
-
Subscription software
SaaS teams need MIT exemptions on rebills and network-token refresh so reissued cards do not silently churn a paying account.
-
Professional services
Agencies and consultancies invoicing higher tickets want enforced 3-D Secure 2 over a threshold and named-payer trust lists inside the exemption engine.
-
Digital publishers
Publishers with membership renewals want stored-credential authentication so paywall unlocks stay frictionless across sessions.
Out of scope for BazPay: adult, gambling, CBD, nutraceutical, forex, CFD, crypto-exchange, debt-collection and MLM. BazPay is not a merchant of record and not a marketplace of third-party PSPs.
Security signals and standards coverage
The platform runs inside a PCI DSS Level 1 environment assessed each year. Hosted fields, EMVCo network tokens and gateway-side vaulting keep your annual return at merchant SAQ A. Authentication runs on every card charge with automatic exemption logic where the rules allow.
- 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
- Encryption in transit
- TLS 1.2+ everywhere; mTLS webhook delivery on request
Questions merchants ask about payments technology
What is payments technology, in one paragraph?
The stack of protocols, cryptographic primitives and messaging standards that let a merchant accept money and reconcile it — 3-D Secure 2 for authentication, EMVCo tokenisation for card storage, HMAC signing for event integrity, ISO 20022 for bank messaging, PCI DSS for card-data handling. A payments technology platform bundles a compliant implementation of each layer behind a single API so merchants do not implement each spec themselves.
How is BazPay's managed payments technology different from a raw gateway?
A raw gateway typically ships the API and leaves protocol-level compliance work to you — 3DS2 version upgrades, PSD2 exemption logic, scheme-token integration, HMAC signature verification. Managed payments technology means the platform absorbs the certification, the version upgrades and the exemption rules and exposes standards-compliant behaviour through one stable API. Your team ships product features instead of tracking scheme bulletins.
How should we approach when we implement new payments technology?
Pick a boundary first. Migration works best when you converge on one canonical charge object across every rail, verify webhooks in one shared handler and push settlement events straight into your data warehouse. On the network side, EMVCo network tokens and PSD2 exemption logic should be enabled from day one so the migration itself does not regress your approval rates. BazPay's integration engineers work this plan with you during onboarding.
Which authentication protocol version is supported?
3-D Secure 2.2 is the current live version, with the device-signal, risk-data and challenge flows that scheme rules currently require. As newer versions are certified by the schemes, they are rolled out platform-side without a merchant integration change; older versions remain available through a version header during the deprecation window.
What does the tokenisation layer look like end to end?
Card credentials collected via hosted fields or a wallet are converted into EMVCo network tokens at storage and stored in the gateway vault under PCI DSS Level 1 scope. Subsequent charges reference the network token rather than the PAN. When the underlying card is reissued, the token refreshes automatically through the Visa and Mastercard token services.
How does the platform sign events and how do we verify them?
Every merchant-facing webhook carries an HMAC-SHA256 signature over the raw request body, keyed to the endpoint secret from the dashboard, plus a timestamp header for replay protection. Verification examples in Node, Python, PHP and Go live in the developer docs; a canonical signature-verification helper is shipped in the client libraries.
Is the online payment technology stack the same on mobile as on web?
Yes. iOS and Android SDKs render hosted card fields, Apple Pay and Google Pay natively and produce the same canonical charge object as the web integration. The same signed webhook stream fires on both surfaces; there is no separate mobile back-office to maintain.
Which merchant types is this technology stack suitable for?
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 it is not a marketplace of third-party PSPs.
Adopt a managed payments technology stack
Share your existing stack, your target rails and your timeline. An integration manager will confirm boarding fit and map the migration inside one working day. See also card and APM processing, merchant acquiring, recurring billing and real-time analytics.