PCI compliant payments

PCI compliant payments — Level 1 vault for every sub-merchant.

topropay holds PCI DSS Level 1 service-provider posture. Merchants integrate as sub-merchants and inherit the posture: card data captures into the vault before it touches the merchant origin, vault tokens drive every subsequent operation, and SAQ scope shrinks to A or A-EP depending on the integration shape.

Book a compliance review Read the API docs
4012 •••• •••• 1234 PCI DSS Level 1 vault topropay audited annually VAULT TOKEN vt_9421 PAN in · vault token out · merchant stores token only
Sub-merchants inherit Level 1 posture.
PCI L1
service-provider posture inherited
Vault
PAN never touches merchant origin
Annual
on-site assessment + quarterly ASV scans
Signed
webhook delivery, replay-safe

Key benefits

Why orchestrated pci compliant payment processing wins on every axis

Four outcomes that show up consistently once the merchant runs cards through the platform's Level 1 vault instead of carrying PCI scope on its own systems.

  1. 01

    PCI compliant payments inherited via the sub-merchant model

    topropay holds PCI DSS Level 1 service-provider posture — annual on-site assessment, quarterly ASV scans, the full control set. Merchants integrate as sub-merchants and inherit that posture rather than carrying separate PCI scope themselves. SAQ shrinks; engineering work shrinks; audit prep shrinks.

  2. 02

    Card data captures into the vault, not the merchant origin

    Hosted checkout, hosted fields and the SDK all capture PAN data inside the platform's PCI DSS Level 1 vault before it reaches the merchant's systems. Refunds, retries and recurring run on vault tokens — the merchant's stack never handles raw PAN, and SAQ A or SAQ A-EP scope applies depending on the integration shape.

  3. 03

    PCI compliant payment processors behind one API

    Every connected acquirer and processor inherits the platform's PCI posture for the part of the flow that lands on them. From the merchant's perspective it's one API; from the auditor's perspective it's one service-provider relationship with topropay rather than many per-provider relationships to evidence individually.

  4. 04

    3DS2 / SCA and signed events out of the box

    Selective 3DS2 / SCA on the authorisation path, signed and replay-safe webhook delivery, scoped API keys, IP allow-lists and full audit logs are wired across every connected provider through one configuration plane — not redone per provider integration.

How it works

From integration to inherited pci dss compliant payment processing in five stages

Five concrete stages between picking the integration shape and audit-ready posture. The merchant's PCI scope shrinks at every step.

  1. 01

    Pick the integration shape

    Hosted page (SAQ A scope), embedded hosted fields (SAQ A-EP scope), or low-level SDK with hosted fields where sensitive inputs render in iframes the merchant origin doesn't touch.

  2. 02

    Drop in the API and webhook handler

    JSON-over-HTTPS REST surface with idempotency and signed webhooks. The merchant verifies webhook signatures with the SDK helper and stores the vault token, not the PAN.

  3. 03

    Capture into the vault

    First authorisation captures PAN data into the PCI DSS L1 vault and issues a vault token. The merchant's database stores the vault token; PAN data never lands in the merchant's logs, backups or telemetry.

  4. 04

    Run subsequent operations on the vault token

    Refunds, partial refunds, captures, retries and recurring all reference the vault token — never the underlying PAN. The merchant doesn't carry SAQ D scope, and rotation / revocation happens server-side.

  5. 05

    Audit-ready posture, no per-provider re-certification

    Sub-merchants inherit annual on-site assessment, quarterly ASV scans and the full control set. Per-provider re-certification doesn't apply because there's one service-provider relationship — topropay's.

Main use cases

Where pci compliant payment solutions earn their keep

Six merchant shapes that share the same inherited PCI posture but stress it differently — DTC, SaaS, marketplaces, PSPs, agent-assisted phone payments and B2B.

  • DTC

    Online retail and DTC brands

    Hosted checkout drops in and the merchant's PCI scope collapses to SAQ A on the card side. Local methods, wallets and BNPL inherit the same posture. Engineering doesn't manage PAN data anywhere in the stack.

  • SaaS

    SaaS and subscription billing

    Vault tokens drive renewals, smart retries and account updaters. PCI compliant payment collection for recurring charges runs server-to-server against the vault — the merchant's billing system never sees PAN, even on month-30 renewals.

  • Plat

    Marketplaces and platforms

    Per-tenant sub-merchant onboarding under the platform's PCI posture. Sellers ride the inherited compliance; the marketplace doesn't need to extend its own PCI scope to its sub-merchants.

  • PSP

    PSPs and ISVs reselling capacity

    Resellers inherit the platform's posture for their downstream merchants. The PSP's own PCI scope stays minimal because PAN data lives inside topropay's vault, not theirs.

  • Telephony

    Agent-assisted phone payments (DTMF capture)

    PCI compliant DTMF payments — where a phone agent guides the buyer to enter card digits on the keypad while the digits are masked from the agent — are delivered through partner telephony providers that capture into topropay's vault. The agent never hears the PAN; the merchant inherits the same vault-token posture as the web side.

  • B2B

    B2B invoicing and high-trust verticals

    B2B counterparty cards captured via hosted-field or SDK flows, with vault tokens driving any subsequent capture, refund or recurring debit. Treasury and finance teams never touch raw PAN.

Platform features

Capabilities behind the pci compliant payment system on topropay

What the platform actually ships for PCI posture — beyond the high-level claim, the controls and surfaces that make the inherited posture stand up in an audit.

  • PCI DSS Level 1 service-provider posture

    Annual on-site assessment plus quarterly ASV scans on the platform cycle; AOC available under NDA.

  • Hosted vault tokenisation

    PAN data captures into the platform vault; merchants store vault tokens, never raw PAN, anywhere in their stack.

  • Hosted page (SAQ A)

    Drop-in checkout via redirect or iframe; the merchant's site never touches PAN data; smallest SAQ scope.

  • Hosted fields (SAQ A-EP)

    Card-number, expiry and CVV rendered as iframes inside the merchant's checkout; smallest SAQ scope for embedded surfaces.

  • Network tokens & updaters

    Network tokens by default plus scheme account updaters; saved cards stay alive across re-issuance without re-prompting the customer.

  • 3DS2 / SCA orchestration

    Selective 3DS2 on the authorisation path; PSD2 / SCA-compliant in Europe without breaking conversion.

  • Signed webhooks

    HMAC-signed, replay-safe webhook delivery; SDK helpers for signature verification in every supported back-end language.

  • Scoped API keys & IP allow-lists

    Per-environment API keys with granular scopes; optional IP allow-lists for server-to-server endpoints.

  • Audit log of every operation

    Operator actions, refund events, cancel events and key rotations logged with actor identity, reason code and timestamp; SIEM-friendly export.

  • Sanctions screening

    OFAC / EU / UN sanctions screening at onboarding and on transaction-level metadata where regulator requires it.

  • Data residency

    Regional data-residency options for merchants under regulators that require it; EU-resident traffic stays in-region by default.

  • Partner DTMF telephony

    PCI compliant DTMF payments delivered through partner telephony providers that capture into the same vault as web flows.

Trust & compliance

Compliance posture summary

The full posture inherited via the sub-merchant relationship — PCI DSS, SCA / PSD2, sanctions / AML and audit log. AOC available under NDA.

PCI DSS Level 1
Annual on-site assessment plus quarterly ASV scans run on the platform cycle and inherited by sub-merchants. AOC available under NDA on request.
SAQ scope reduction
Hosted-page integrations land in SAQ A; embedded hosted-fields integrations land in SAQ A-EP. Both reduce the merchant's own PCI scope dramatically vs holding PAN data on the merchant origin.
SCA & PSD2
Selective 3DS2 on the authorisation path keeps approval high in Europe without skipping the compliance bar.
Vault-token-only data model
Vault tokens replace PAN everywhere downstream of capture — refunds, retries, recurring, exports. PAN never leaves the platform.
Signed events & audit log
Replay-safe webhook delivery, scoped API keys and a SIEM-friendly audit log of every operator action.
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 integration shape.

Ready to shrink scope

PCI DSS Level 1 posture, inherited by every sub-merchant.

A 30-minute compliance review walks through the integration shape that matches your stack, the SAQ scope it reduces you to, and an NDA-gated path to the AOC for your auditor.

Book a compliance review Read the API docs

Frequently asked

Buyer questions about pci compliant payments on topropay

Questions buyers ask before committing — PCI scope reduction, the HIPAA boundary (out of scope on the PHI side), DTMF capture, payment-applications certification and how to evidence the inherited posture for an auditor.

  1. 01

    What does topropay mean by pci compliant payments?

    PCI compliant payments on topropay means the merchant integrates as a sub-merchant on the platform's PCI DSS Level 1 service-provider posture. PAN data captures into the platform vault before it touches the merchant origin; refunds, retries and recurring run on vault tokens. The merchant's own PCI scope shrinks to SAQ A (hosted page) or SAQ A-EP (hosted fields) instead of full SAQ D.

  2. 02

    Is the platform among the pci compliant payment gateways merchants can integrate with?

    Yes. topropay sits among the pci compliant payment gateways — it operates as a PCI DSS Level 1 service provider, with annual on-site assessment and quarterly ASV scans run on the platform cycle. Sub-merchants inherit the posture; AOC (Attestation of Compliance) is available under NDA on request.

  3. 03

    How does topropay compare to other pci compliant payment processors?

    Other pci compliant payment processors typically run one acquirer relationship behind their PCI posture. topropay runs many — and the orchestration layer's PCI posture covers the integration surface (the vault, the API, the webhook delivery, the operator portal). The underlying acquirers run their own PCI posture; the merchant inherits both via the sub-merchant model.

  4. 04

    What is pci compliant payment processing in practice on the platform?

    PCI compliant payment processing in practice means: card data captures into the platform vault inside hosted-field iframes the merchant origin doesn't touch; the authorisation, capture, refund and recurring lifecycle runs against vault tokens; signed webhooks deliver state changes; operator actions land in an audit log. The merchant's engineering team never handles raw PAN at any step.

  5. 05

    Is the platform a pci dss compliant payment gateway specifically?

    Yes. topropay is a PCI DSS compliant payment gateway under the SSC's service-provider scheme, at Level 1 — the highest tier, required for service providers handling 300,000+ Visa transactions per year. The AOC is renewed annually following the QSA's on-site assessment.

  6. 06

    Does topropay support hipaa compliant payment processing?

    HIPAA covers protected health information (PHI) — patient demographics, diagnoses, treatment data — not payment card data. topropay is NOT a HIPAA-covered entity and does not operate in healthcare claim adjudication. For a US healthcare merchant accepting card payments for services, topropay handles the PCI side (vault, tokenisation, processing); the merchant's own systems remain responsible for any PHI they store under HIPAA. PCI and HIPAA are separate regulatory domains; topropay's posture only addresses the former.

  7. 07

    What does pci dss compliant payment processing add beyond just running cards?

    PCI DSS compliant payment processing adds the control set the standard requires: vault tokenisation, signed event delivery, scoped API keys, audit logs of every operator action, regular ASV scans, annual on-site assessment, sanctions screening at onboarding. Running cards without those controls is processing; running them with the controls is PCI DSS compliant processing.

  8. 08

    Are there pci compliant payment solutions for specific vertical needs?

    Yes — pci compliant payment solutions on the platform cover the standard surfaces (web checkout, embedded fields, SDK), plus partner-delivered surfaces for specific verticals (DTMF telephony capture for agent-assisted phone payments, point-of-sale terminal capture for in-store). All of them capture into the same vault; all inherit the same PCI posture.

  9. 09

    Are these compliant payment solutions priced separately?

    Compliant payment solutions on topropay don't carry a separate compliance fee — the PCI posture is included in the per-authorisation pricing. There's no platform retainer, no monthly minimum and no per-merchant compliance line. Sub-merchant inheritance of the posture is the design, not an upsell.

  10. 10

    How are pci compliant dtmf payments handled?

    PCI compliant DTMF payments — where a phone agent guides the buyer to type card digits on the keypad while the digits are masked from the agent — are delivered through partner telephony providers. The partner's DTMF-suppression infrastructure prevents the agent's audio from including the PAN tones; the captured digits go directly into topropay's PCI L1 vault. The merchant inherits the same vault-token posture as the web side; the contact-centre PCI scope shrinks to the partner's scope.

  11. 11

    What does pci compliant payment collection look like for invoice flows?

    PCI compliant payment collection for invoice flows typically means a hosted payment-page link delivered alongside the invoice — the customer clicks through, lands on topropay's hosted checkout, captures into the vault, and the resulting authorisation triggers a webhook back to the merchant's billing system. The invoice and the receipt link reference the vault token, never the PAN.

  12. 12

    Is topropay a pci compliant payment system suitable for high-trust merchants?

    Yes — topropay is a PCI compliant payment system suitable for high-trust merchants (subscription, travel, ticketing, regulated financial services, licensed gaming). The Level 1 posture is the standard; the additional scheme programmes (Visa VDMP / VAMP, Mastercard ECP / EFMP) and sanctions / AML screening sit on top.

  13. 13

    What about pci compliant payment applications — does the platform certify any?

    PCI compliant payment applications (PA-DSS / PCI SSF Software Security Framework) is a separate certification for software applications that touch PAN data. topropay's hosted surfaces (checkout, hosted fields) don't run on the merchant's hardware, so they aren't installed applications in the PA-DSS sense. Where a merchant ships an in-house application that touches PAN, the merchant carries the application-level certification — but the orchestration shape on topropay is designed to keep PAN out of the merchant's applications entirely.

  14. 14

    How does the platform stay current with PCI DSS version changes?

    PCI DSS is currently at v4.0.1, with the v4 transition complete for service providers. topropay tracks version changes as part of the annual assessment cycle and updates controls ahead of each effective date. Merchants inherit the current version's posture via the sub-merchant relationship; no per-merchant migration project is required when the standard rolls forward.

  15. 15

    Where can I get evidence of the PCI L1 posture for our own audit?

    Evidence — Attestation of Compliance (AOC) from the QSA, summary of in-scope systems, last ASV scan summary and a brief overview of the control set — is available under NDA on request. The merchant's auditor typically attaches the AOC to the merchant's own ROC / SAQ as evidence of the inherited service-provider posture.

Related

Related on the topropay platform