Security-first · PCI L1 · SCA · signed events

Secure online payment systems, layered, from vault to receipt.

topropay's security posture is layered — PCI DSS Level 1 vault, network-token tokenisation, selective 3DS2 for SCA, sanctions and AML screening, signed webhooks and audit-grade logging. Every layer is inherited by every sub-merchant across every acceptance channel.

Book a security review Read the API docs
Layered defence PCI DSS Level 1 VTS · MDES · tokenisation Selective 3DS2 · SCA Signed webhooks · audit
Six layers · one shield · one contract.
PCI L1
service-provider vault inherited by every sub-merchant
3DS2
selective SCA on the authorisation path
Signed
webhooks with replay-safe IDs
Audit
every state transition logged for evidence

Key benefits

Six defence layers behind the secure online payment gateway

Six layers work together to give the merchant a single security posture rather than a checklist. No single layer is the whole boundary; each covers a different failure mode.

  1. PCI DSS Level 1 vault

    Card data captures into topropay's PCI DSS Level 1 vault before any acquirer or PSP sees it. Vault tokens drive refunds, retries and recurring — the raw PAN never lands in merchant systems or on the merchant origin.

  2. Network tokens & scheme updaters

    Network tokens via VTS and MDES replace static PANs across recurring and stored-credential flows. Scheme account updaters keep tokens alive across re-issuance without failing renewals or forcing re-authentication.

  3. Selective 3DS2 / SCA

    EMV 3DS2 challenges fire per PSD2 exemption logic, per-issuer behaviour and per-transaction risk score. Frictionless flows pass through; high-risk authorisations step up to challenge without hard-coding a single behaviour.

  4. Risk & fraud controls

    Velocity rules, list management (allow / block lists per BIN, email, IP, device fingerprint), and partner-agnostic fraud-engine connectors layer on top of the routing engine — configurable per merchant, per vertical.

  5. Sanctions & AML alignment

    Sanctions screening on onboarding for every sub-merchant; AML monitoring tuned per merchant vertical, volume, counterparty pattern and geography. FATF Travel Rule handled by licensed partner gateways on crypto rails.

  6. Signed events & audit-grade logging

    Every lifecycle event (authorise, capture, settle, refund, dispute) fires a signed webhook with a replay-safe ID. Every operator action logs the actor identity, reason code, IP and timestamp for SOC / ISAE / audit evidence.

How secure online payment processing runs

From vault capture to signed receipt in five steps

What actually happens between the buyer submitting card data and the merchant's accounting system seeing a settled receipt.

  1. 01

    Capture via hosted surface

    Card data captures through the hosted checkout, embedded hosted fields (iframes) or the low-level SDK. The merchant's PCI scope shrinks to SAQ A or SAQ A-EP depending on the surface.

  2. 02

    Tokenise into the vault

    The vault issues a topropay vault token; for card the network-token flow issues a VTS / MDES token underneath. The raw PAN never touches the merchant's server or database.

  3. 03

    Route the authorisation

    The routing engine picks the top-ranked connected acquirer per BIN, currency, country pair and risk score. Soft declines cascade to the next ranked lane inside the same authorisation.

  4. 04

    Authenticate where required

    Selective 3DS2 fires per PSD2 exemption logic and per-issuer behaviour; frictionless flows pass through. Step-up challenges are surfaced only when the transaction warrants it.

  5. 05

    Emit signed events

    Signed webhooks for authorisation, capture, settlement, refund and dispute. Every state transition logs actor identity, reason code, IP and timestamp for audit and reconciliation.

Main use cases

Where a secure online payment solution earns its keep

Six merchant shapes where the layered security posture makes an outsized difference — DTC, SaaS, marketplaces, travel, regulated finance and PSP reselling.

  • DTC

    Cross-border DTC with high card-not-present exposure

    CNP fraud is the dominant loss driver for DTC. The PCI L1 vault plus per-BIN routing and selective 3DS2 reduce exposure without breaking conversion on legitimate traffic.

  • SaaS

    Recurring SaaS billing on network tokens

    Network tokens keep card-on-file recurring alive across re-issuance; the vault handles credential rotation without asking the customer to re-enter card details.

  • Plat

    Marketplaces with sub-merchant onboarding

    Sub-merchants inherit the PCI posture across the panel; sanctions and KYB checks run at onboarding so bad actors don't sit inside the merchant portfolio.

  • Travel

    Travel and ticketing with delayed capture

    Auth-only at booking, capture at fulfilment, refunds on cancellation — all against the same vault token. Audit-grade logging surfaces every state transition for finance and dispute defence.

  • Fin

    Regulated financial services

    Where the merchant is itself a regulated financial-services operator, the platform's compliance posture (PCI, SCA, sanctions, AML) inherits cleanly into the merchant's own compliance evidence.

  • PSP

    PSPs reselling secure infrastructure downstream

    PSPs and resellers inherit the platform's security posture and pass it to their downstream merchants. The PSP keeps the merchant relationship; the platform handles the vault, tokens and SCA.

Platform features

Capabilities behind the secure online payment services

Twelve concrete capabilities the platform ships once and reuses across every merchant — the primitives that make the security posture consistent regardless of channel.

  • PCI DSS Level 1 vault

    Annual on-site assessment plus quarterly ASV scans; sub-merchants inherit the posture without carrying separate certifications.

  • Hosted, embedded & SDK surfaces

    Three integration shapes that shrink PCI scope to SAQ A or SAQ A-EP — pick per merchant PCI and UI constraints.

  • Network tokens (VTS, MDES)

    Network tokens by default for card; recurring renewals ride tokens rather than static PANs; scheme updaters keep them alive.

  • Selective 3DS2 / SCA

    Per-transaction exemption logic honours PSD2 without hard-coding a single behaviour; frictionless where allowed, challenge where required.

  • Sanctions & AML at onboarding

    KYB / KYC on onboarding; sanctions screening at the platform level filters bad actors before they can transact.

  • Velocity rules & list management

    Allow / block lists per BIN, email, IP, device fingerprint; velocity rules per merchant, vertical and MCC.

  • Fraud-engine connectors

    Partner-agnostic connectors for the merchant's chosen fraud engine (Sift, Signifyd, Riskified, in-house rules).

  • Signed webhook events

    Every lifecycle event fires a signed webhook with a replay-safe ID; verification signature carried in the header.

  • Operator-side controls

    Refund operations require justification; every refund logs actor identity, reason code, IP and timestamp.

  • Audit-grade event log

    Every state transition (authorise, capture, settle, refund, dispute) logged per invoice / order for SOC / ISAE evidence.

  • Encryption in transit & at rest

    TLS 1.2+ for every transport channel; envelope-encrypted storage for card credentials and PII inside the platform.

  • Key-rotation & access controls

    Per-merchant API keys with rotation on demand; role-based dashboard access with per-role audit.

Industry relevance

Built for licensed merchants where security posture matters

topropay's security posture targets licensed merchants operating across EU, UK, APAC and LATAM markets where regulated compliance-bound verticals need inherited PCI, SCA, sanctions and AML capabilities without carrying their own certifications.

  • DTC with cross-border CNP volume
  • SaaS with recurring card-on-file
  • Marketplaces with sub-merchants
  • Travel & ticketing (delayed capture)
  • Regulated financial services
  • Licensed gaming (where licensed)
  • Adult content · out of scope
  • Unlicensed gambling · out of scope
  • Grey / black-market · out of scope

Trust & compliance

Certifications, programmes and posture rows

One audited environment underpins every merchant on the platform. The rows below are what the merchant inherits without carrying separate certifications.

PCI DSS Level 1
Annual on-site QSA assessment plus quarterly ASV scans; scope covers vault, switch, tokenisation, dashboard and webhook infrastructure.
SCA & PSD2
Selective 3DS2 on the authorisation path; issuer-side behaviour honoured; step-up only where required by regulation or per-transaction risk score.
Sanctions & AML alignment
Sanctions screening at onboarding for every sub-merchant; AML monitoring tuned per vertical, volume and counterparty pattern.
Scheme programmes
Visa VDMP / VAMP / VFMP and Mastercard ECP / EFMP positions surfaced per acquirer; routing weights can rotate around at-risk lanes to protect merchants from programme escalation.
Data protection alignment
Encryption in transit and at rest; role-based access; per-merchant API key rotation; regional data-residency where the acquirer relationship requires it.
Licensed verticals only
Licensed gaming, regulated financial services and other compliance-bound verticals supported only where current operating licences exist. Grey and black-market verticals are out of scope regardless of security posture.

Ready to inherit the posture

Ship on secure online payment infrastructure — without the audit workload.

A 30-minute security review walks through the PCI, SCA, sanctions and audit-log rows that will land in your compliance evidence pack — followed by a sandbox to test against before any commercial commitment.

Book a security review Read the API docs

Frequently asked

Buyer questions about secure online payment systems on topropay

Vault mechanics, webhook replay defence, key rotation, data residency and the practicalities of inheriting the platform's security posture.

  1. 01

    What makes secure online payment systems 'secure' in this context?

    Secure online payment systems on topropay combine PCI DSS Level 1 vault storage of card credentials, network-token tokenisation (VTS / MDES), selective EMV 3DS2 for SCA, sanctions and AML screening, signed webhook events, and audit-grade logging of every state transition. The layers work together; no single layer is the security boundary.

  2. 02

    How does the secure online payment gateway side of topropay actually operate?

    The secure online payment gateway on topropay is a hosted / embedded / SDK surface backed by the PCI DSS Level 1 vault. Card credentials capture into the vault before any downstream processor sees them; vault tokens then drive refunds, retries and recurring. The gateway is the same one that routes authorisations across the connected acquirer panel.

  3. 03

    Is secure online payment processing PSD2 / SCA compliant?

    Yes. Secure online payment processing on topropay honours PSD2 and Strong Customer Authentication through EMV 3DS2. Selective challenges fire per issuer, per transaction risk score and per exemption logic — frictionless flows pass through, high-risk authorisations step up. The behaviour is per-transaction, not per-merchant.

  4. 04

    Can topropay be considered a single secure online payment solution?

    Yes — a secure online payment solution on topropay bundles vault, tokenisation, routing, SCA, dispute queue and reconciliation into one contract. The merchant integrates once; the security posture (PCI, SCA, sanctions, AML, signed events, audit logging) is inherited across every acceptance channel.

  5. 05

    How are secure online payment services delivered day-to-day?

    Secure online payment services on topropay are delivered as a managed platform. The vault, switch, tokenisation and dispute queue are run by the platform; the merchant integrates against a stable REST API and monitors activity through the dashboard. Security updates, PCI reassessment cycles and 3DS2 issuer-behaviour tracking happen platform-side.

  6. 06

    What happens to raw PAN data on this platform?

    Raw PAN data captures directly into the PCI L1 vault via hosted / embedded card fields; the vault issues a topropay vault token (and, for card, a network token under the hood). The raw PAN is never written to the merchant's server, database, log files or code — it lives only inside the vault.

  7. 07

    How are refunds secured against operator misuse?

    Refunds are gated by operator-side controls: every refund requires justification (a reason code plus optional notes), and every refund event logs actor identity, IP, timestamp and the vault token being refunded. Bulk refunds require a second-operator approval where the merchant's policy demands it.

  8. 08

    How does topropay defend against replay of webhook events?

    Every signed webhook carries a replay-safe event ID. The merchant's endpoint verifies the signature (HMAC of body + timestamp with the shared secret), rejects events with timestamps older than the merchant's tolerance window, and de-duplicates on the event ID before applying the state change.

  9. 09

    What's the platform's stance on data residency?

    Data residency follows the acquirer relationship: EU acquirers require EU-resident data, US acquirers require US-resident data. The vault is regionalised where the underlying acquirer contract demands it; the dashboard and reporting API surface the residency posture per merchant.

  10. 10

    How is card-not-present (CNP) fraud specifically defended against?

    CNP fraud is defended in layers — the PCI L1 vault removes the merchant-side attack surface for stolen credentials; selective 3DS2 shifts issuer-side liability where SCA is required; device fingerprinting and velocity rules score authorisations; and per-BIN routing steers CNP volume to the acquirers with the best CNP-fraud handling for that BIN range.

  11. 11

    Do sub-merchants inherit the platform's PCI posture automatically?

    Yes. Sub-merchants riding topropay's sub-merchant model inherit the PCI Level 1 posture at the service-provider level. The merchant carries only the responsibilities of their integration surface (typically SAQ A for hosted checkout, SAQ A-EP for embedded fields).

  12. 12

    How are keys and secrets protected?

    API keys are per-merchant, per-environment (live / sandbox), rotatable on demand from the dashboard, and can be scoped to specific IP ranges. Webhook signing secrets rotate independently. Access to the dashboard is role-based with per-role audit; sensitive actions require reauthentication.

  13. 13

    What does the platform log for audit and dispute defence?

    Every authorisation attempt (successful or declined, with acquirer response code), every capture / refund / dispute, and every operator action logs to an audit-grade event stream — actor identity, IP, timestamp, reason code where applicable. The log is exportable as CSV or via API for SOC / ISAE attestation evidence and for dispute representment.

  14. 14

    How quickly can a merchant integrate a secure online payment surface?

    Hosted checkout can be live in days — the merchant's PCI scope shrinks to SAQ A and no card data touches their systems. Embedded hosted fields typically take 1–3 weeks including PCI scope review. Low-level SDK integrations follow the merchant's own release cycle.

  15. 15

    Is topropay a good fit for regulated financial-services merchants?

    Yes, for licensed financial-services merchants operating in supported markets. The compliance posture (PCI, SCA, sanctions, AML) inherits cleanly into the merchant's own compliance evidence. Merchants without the relevant operating licence — or in unlicensed grey / black-market verticals — are out of scope regardless of security posture.

Related

Related on the topropay platform