Secure online payment systems on a direct acquiring platform.
BazPay is a secure online payment system for merchants across the EU, UK, Australia, Canada and New Zealand. Card data lives inside a PCI DSS Level 1 environment, stored credentials become network tokens, webhooks are HMAC-signed and replay-protected, and every dashboard action lands in an audit log. Security is defence in depth, not a single line.
Built for EU, UK and Commonwealth e-commerce sellers, subscription software firms and professional-services businesses. One direct regional acquirer, one signed event stream, GDPR-native data residency and versioned API contracts that survive platform releases.
Why a secure online payment gateway pays back beyond compliance
Compliance is the floor. What matters day to day is fewer footguns in the integration, less scope to defend at audit time and cleaner evidence when a review lands. Four properties keep the security posture stable.
-
Defence in depth by construction
Security is not a single line of defence. Hosted fields keep PAN out of your stack, network tokens replace stored credentials, signed webhooks verify every event, and the PCI-DSS-scoped environment is assessed each year. Each layer stands on its own.
-
PCI scope reduction for your team
Card data lives inside BazPay's PCI DSS Level 1 environment. Merchant SAQ A is the annual return most integrations qualify for — the smallest scope a merchant can hold. No full PCI environment to build and maintain.
-
In-region data residency, GDPR-native
Payment data stays in regional processing regions. A DPA is available on request. There is no off-regional fallback that complicates a data-protection review.
-
Change safety at the API layer
Every request carries a version header. Breaking changes ship on the next major with a documented deprecation window, so an integration built against a stable contract stays stable — a security posture that survives platform changes.
The four security layers of the platform
Four layers make up the security posture of BazPay's secure online payment processing. Each layer has a documented control and stands on its own if the next layer above fails.
-
Transport
Transport-layer security
TLS on every API request, every webhook delivery and every hosted-fields render. Modern cipher suites, no legacy fallback. Nothing about a BazPay integration reaches the internet in the clear.
- TLS
- HTTPS only
- Modern ciphers
-
PCI scope
PCI DSS Level 1 environment
Card data collection, storage and processing live inside our PCI DSS Level 1 scope, assessed each year. Hosted fields serve card inputs from that environment inside your checkout so raw PAN never touches your servers.
- Level 1
- Annual audit
- Hosted fields
-
Tokenisation
Vault + Visa/Mastercard network tokens
Stored credentials are replaced with gateway-side tokens; card renewals refresh through Visa and Mastercard network token services. No PAN in your database, no rebuild after a reissue wave.
- Gateway vault
- Network tokens
- Portable
-
Event integrity
Signed and replay-protected webhooks
Every state change fires an HMAC-signed event with a timestamp header. Replay attacks fail the signature check by design. One handler verifies once and routes on the event type.
- HMAC-SHA256
- Timestamp check
- Replay-protected
The engineering foundation view lives on payment infrastructure. The order-scoring rule engine on payment fraud prevention. The 3-D Secure 2.2 layer up close on secure payment services.
Security controls at every stage of a payment
Six stages sit between checkout and audit trail. Each stage has a named control — TLS transport, PCI-scoped ingestion, tokenisation, authentication, HMAC-signed notification and audit log.
-
Ingest over TLS
The checkout script or mobile SDK loads over TLS and collects payment inputs inside BazPay's PCI environment via hosted fields.
-
Tokenise
Card credentials become gateway-side tokens at first entry; network tokens replace PAN on stored credentials.
-
Score
The inline fraud engine grades each order and applies PSD2 exemption logic — 3-D Secure challenges run only when the risk earns it.
-
Authorise
The tokenised charge posts to the acquirer with the 3-D Secure 2 result bound. Cardholder authentication runs inside the shopper's own issuing bank.
-
Notify securely
A signed charge.succeeded webhook fires to your endpoint. Your handler verifies the HMAC signature and rejects any replay outside the timestamp window.
-
Audit trail
Every dashboard action is audit-logged with actor, timestamp and payload delta. Reviews land on an evidence trail rather than a screenshot.
Secure by construction vs bolted-on security
The choice is not usually between two payment gateways. It is between a platform that treats security as a floor and one that treats it as a premium tier. The comparison below shows where the gap lands during an audit.
| Dimension | BazPay (secure by construction) | Bolted-on security |
|---|---|---|
| PCI scope | Merchant SAQ A via hosted fields | Full PCI where PAN passes servers |
| PAN handling | Never touches your stack | Sometimes flows through your form state |
| Tokenisation | Gateway vault + network tokens default | Vendor-specific vault, no network token refresh |
| Event integrity | HMAC-signed, replay-protected | Unsigned or per-vendor formats |
| API versioning | Version header + deprecation window | Silent breaking changes |
| Data residency | Regional processing regions, GDPR default | Off-regional fallback in the contract |
| Audit trail | Actor + timestamp + diff per action | Screenshot-based review |
Rate structure on the pricing page. The service envelope around the platform on gateway services. Packaged bundles on payments solutions. Related surfaces: issuing and acquiring explained, payment acceptance and the accept online payments walkthrough.
Security features on the standard integration
Every capability below ships to every merchant BazPay boards. There is no premium tier that unlocks hosted fields, network tokens or the signing scheme — the primitives are the platform.
-
Hosted fields
Card inputs served from our PCI environment inside your checkout — raw PAN never enters your DOM, form state or logs.
-
Gateway-side vault
Card credentials stored inside our PCI Level 1 scope, keyed to your merchant, portable if you ever migrate infrastructure.
-
Network tokens
Visa and Mastercard network tokens replace PAN at storage time and refresh automatically after issuer reissue.
-
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.
-
Signed webhooks
HMAC-signed, replay-protected events on every state change. Delivery retries on an exponential schedule for up to 72 hours.
-
Versioned API
Every request carries a version header. Breaking changes ship behind a new major with a documented deprecation window.
-
Audit-logged dashboard
User actions, key rotations, rule changes and payout schedule edits are logged with actor, timestamp and diff — evidence for a compliance review.
-
Idempotency contract
Retry-safe writes across create, capture, refund and payout. A retried request never becomes a double charge, which matters as much for security as for reliability.
Verify every event with a signed webhook
Signed webhooks are the source of truth. Your handler recomputes the HMAC over the raw request body using the shared secret and rejects the request if the signature does not match or the timestamp is outside a small window. Redirect parameters and client-side callbacks are never trusted for authorisation state.
BazPay-Signature: t=1717257600,
v1=8b3f1c...9d2e
{
"id": "evt_02H9",
"type": "charge.succeeded",
"data": {
"object": {
"id": "ch_5F9k",
"amount": 4990,
"currency": "EUR",
"network": "visa"
}
}
}Verification helper libraries and handler samples live in the developer docs. The full event catalogue is in the API reference.
Where security-conscious merchants run BazPay
The four merchant profiles below already rely on BazPay's secure online payment services when their own buyers, auditors or regulators ask for evidence.
-
E-commerce sellers with security-review buyers
DTC brands whose enterprise customers or infosec reviewers ask for PCI scope, encryption and event-integrity evidence before purchasing.
-
Subscription software with compliance-heavy customers
SaaS teams selling into finance, legal or public-sector buyers who need DPA, GDPR and PCI-DSS statements attached to the vendor review.
-
Professional-services firms invoicing regulated clients
Consultancies and B2B service firms handling higher-ticket invoices where the shopper's finance team runs a payment-security check before settling.
-
Digital publishers on regulated content models
Membership businesses whose renewals cannot silently drop when a card is reissued or a webhook replay fails signature check.
Out of scope for BazPay: adult, gambling, CBD, nutraceutical, forex, CFD, crypto-exchange, debt-collection and MLM. BazPay is not a merchant of record, not a card issuer and not a marketplace of third-party PSPs.
Compliance signals for the security review
The floor for a credible secure online payment gateway is PCI DSS Level 1 on the provider's own environment, merchant SAQ A on the integrator's side, authentication via 3-D Secure 2 and named scheme registrations. GDPR-compliant In-region data residency and a versioned API contract round out the checklist auditors actually run.
- 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
- Change management
- Versioned API, published deprecation policy, audit-logged dashboard actions
Questions security and compliance teams ask
What makes an online payment system "secure" in practical terms?
A secure online payment system is a stack that prevents raw card data from touching untrusted environments, tokenises stored credentials, encrypts data in transit and at rest, cryptographically signs event notifications and keeps its scope of collection annually audited. BazPay does all of the above by default — hosted fields keep PAN in our PCI DSS Level 1 environment, network tokens replace stored credentials, TLS covers transit and HMAC signatures cover every webhook.
How is this different from the fraud-prevention page?
The payment fraud prevention page covers the rule engine that scores individual orders and defends against card testing, chargebacks and BIN attacks. This page covers the underlying security architecture — encryption, tokenisation, PCI scope reduction, event integrity and audit trail. Fraud prevention decides which orders to allow; secure online payment systems make sure the surrounding platform cannot be trivially attacked in the first place.
Do I need to run a PCI-DSS environment to use the secure online payment gateway?
No. Hosted fields and gateway-side vaulting keep card data inside BazPay's PCI DSS Level 1 scope, so most integrations qualify for merchant SAQ A on their annual return. Your engineering team never handles a live PAN, which is the point.
How is secure online payment processing signalled to my servers?
Every state change fires an HMAC-signed webhook with a timestamp header. Your handler verifies the signature with a shared secret (rotatable from the dashboard) and rejects requests outside a small timestamp window to prevent replay attacks. The signed event is your source of truth — do not act on unverified redirect parameters.
Which data-residency guarantees apply to the secure online payment solution?
Payment data stays in regional processing regions. A Data Processing Agreement is available on request. There is no off-regional fallback in the standard contract; if your compliance team requires additional territorial guarantees, discuss them during boarding.
How do you handle key rotation and secret exposure?
Live and test API keys, webhook signing secrets and dashboard user roles are managed from the dashboard with an audit log. Rotating a compromised secret is a two-click operation that invalidates the previous secret. Rotating rules and any recent activity are recorded with actor and timestamp for post-incident review.
How is the platform kept safe against breaking-change surprises?
Every API request carries a version header. Breaking changes ship on the next major version and run in parallel with the previous major through a documented deprecation window. New security features are opt-in behind the same header. Integrations built once do not silently regress under a platform release.
Which merchant types can use these secure online payment services?
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. Merchants handling regulated non-payment data (for example clinical PHI) should consult their DPO on where BazPay fits in their broader compliance stack.
Take the security review to a direct regional acquirer
Share your compliance requirements and existing stack. A named engineer will walk the security posture with you and confirm boarding fit inside one working day. See also payment infrastructure, gateway services and payments solutions.