Europe & UK
PCI DSS paired with PSD2 / SCA. Selective 3DS2 keeps approval high while clearing the regulatory bar; merchants benefit from one compliance posture across SEPA, the UK and the EEA.
PCI DSS Level 1 · service provider
PCI payment, end-to-end, under one Level 1 posture.
Gateway, processor, services, solutions, compliance and applications all run inside topropay's audited PCI DSS Level 1 boundary. Sub-merchants inherit the certification; raw card data never lands in the merchant's systems regardless of which surface a buyer transacted through.
- PCI L1
- service-provider posture inherited
- 7 surfaces
- from gateway to application
- 60+
- connected acquirers under one vault
- Signed
- webhook delivery, replay-safe
Product surfaces
Seven PCI payment surfaces, one audited boundary
Each surface is a different way merchants integrate against the same Level 1 posture. Picking a surface is an integration-shape decision; the compliance shape stays constant.
- Gateway
PCI payment gateway
Hosted page, hosted-fields and SDK surfaces all submit through the same Level 1 tokeniser. PAN never lands on the merchant origin; the gateway issues a vault token the merchant stores and re-uses.
- Processor
PCI payment processor
Connected processors run inside the audited boundary. Vault tokens detokenise just-in-time at the processor edge under TLS; raw PAN doesn't traverse the merchant's network.
- Services
PCI payment services
Card, ACH, crypto (via licensed partner gateways), facilitation and subscriber services all ride the same posture. Adding a service is a dashboard step; the certification doesn't have to be re-earned per category.
- Solutions
PCI payment solutions
Out-of-the-box solutions — checkout, recurring, marketplace payouts, BNPL — wrap the gateway primitives in opinionated flows. The PCI heavy-lifting stays platform-side.
- Compliance
PCI payment compliance
Annual on-site assessment by a QSA plus quarterly ASV scans, internal/external penetration testing, segmentation testing and policy attestation. Sub-merchants inherit the posture, not the assessment work.
- Application
PCI payment application
The merchant-facing app — dashboard, virtual terminal, MOTO entry, refund console, dispute queue — runs inside the audited environment. Operator access is logged with actor identity per action.
- Vault
PCI vault & tokens
Card data captures into the platform vault before any provider sees it. Network tokens by default for card-on-file; vault tokens drive refunds, retries and recurring without ever returning the PAN to the merchant.
Key benefits
Why merchants pick a Level 1 pci payment partner
Four buying signals that show up in every coverage review for pci payment compliance, posture and product breadth.
- 01
Inherited posture
Sub-merchants ship to live without carrying the PCI DSS Level 1 assessment themselves. The platform's QSA report covers the data-handling boundary; the merchant attests SAQ A or SAQ A-EP based on the integration shape they chose.
- 02
Smaller compliance surface
Hosted-page and hosted-fields integrations keep the merchant in SAQ A / SAQ A-EP. Card-number, expiry and CVV never enter the merchant's HTML; the audit shrinks proportionally.
- 03
One vault across the connected panel
Vault tokens are platform-issued, not provider-issued. Switching the routing weight across processors doesn't break saved cards; account-updater calls keep tokens fresh across re-issuance.
- 04
Signed event delivery
Webhooks ship with a signature header derived from a per-merchant secret. Receivers verify and reject replays; the audit trail covers the event-delivery boundary.
How it works
From card capture to one ledger — without expanding scope
Five steps in the lifecycle of a PCI payment on the platform — from capture inside the audited boundary to a single reconciliation feed at the finance side.
- 01
Capture inside the audited boundary
Card-number / expiry / CVV are entered into hosted-page or hosted-field iframes served from the platform's PCI-audited origin. The merchant's HTML never sees the raw values.
- 02
Tokenise immediately
The tokeniser exchanges the PAN for a vault token before any provider edge sees it. The token is what the merchant stores and re-references for refunds, retries and recurring.
- 03
Route across connected processors
The routing engine picks the highest-likelihood acquirer per authorisation. Detokenisation happens just-in-time at the provider edge, under TLS, inside the audited boundary.
- 04
Sign every outbound event
Captures, refunds, chargebacks and disputes ship out as signed webhooks. Replay-safe; the merchant's webhook receiver doesn't have to maintain a separate trust channel.
- 05
Reconcile in one ledger
Settlements, fees, refunds and chargebacks across every connected provider normalise into one feed. The PCI boundary is invisible from the finance side — finance sees one ledger.
Main use cases
Where pci payment solutions earn their keep
Six merchant shapes where inheriting a Level 1 posture changes the integration economics — DTC, SaaS, marketplaces, B2B, licensed high-risk and PSP resellers.
- DTC
DTC brands shrinking PCI scope
A DTC brand replaces an in-house card-form with hosted fields. PCI scope collapses from SAQ D to SAQ A-EP; no behavioural change for buyers; no engineering re-platform.
- SaaS
SaaS storing card-on-file safely
Recurring SaaS billing relies on platform-issued network tokens. The SaaS company doesn't store PANs; renewals run server-side under the platform's compliance umbrella.
- Plat
Marketplaces with sub-merchant onboarding
A marketplace onboards sub-merchants through facilitation. Sub-merchants get a SAQ A attestation by default; the marketplace doesn't carry per-seller PCI exposure.
- B2B
B2B virtual-terminal entry
Sales teams take MOTO orders through the dashboard's virtual terminal. The terminal is inside the audited environment; operator actions log with actor identity for review.
- High-risk
Licensed high-risk merchants
Licensed high-risk merchants inherit the same Level 1 posture as mainstream merchants. Scheme programme exposure (VDMP / VAMP / ECP) is monitored via the same dashboard.
- PSP
PSPs reselling the posture
PSP resellers extend the Level 1 posture to their merchants. The PSP keeps the relationship and pricing; the platform owns the certification and audit cadence.
Platform features
Capabilities behind the pci payment processor surface
Twelve primitives shared across every PCI payment surface on the platform — the building blocks the gateway, processor, services and solutions all reuse.
-
PCI DSS Level 1 service-provider posture
Annual on-site assessment by a QSA, quarterly ASV scans, internal and external pen-testing, segmentation testing and policy attestation.
-
Hosted-page, hosted-fields and SDK surfaces
All three submit through the same tokeniser; PAN never lands on the merchant origin regardless of which surface they pick.
-
Vault tokens that survive routing
Platform-issued tokens, not provider-issued — switching routing weight across processors doesn't break saved cards.
-
Network tokens by default
Card-on-file uses network tokens for recurring and one-off re-charges; lifecycle managed via scheme updaters.
-
3DS2 / SCA orchestration
Selective challenges per authorisation — PSD2-compliant in Europe without skipping the compliance bar or breaking conversion.
-
Signed webhook delivery
Replay-safe event delivery with per-merchant signing secrets; the audit trail covers the event boundary.
-
Audited dashboard & virtual terminal
Operator access is logged per action with actor identity; MOTO entry and refund console run inside the audited environment.
-
Just-in-time detokenisation
Vault tokens detokenise at the processor edge under TLS; raw PAN doesn't traverse the merchant's network.
-
Segmented network & hardened secrets
PCI-scope segments are firewalled; secrets rotate on schedule with HSM-backed storage.
-
Sub-merchant inheritance
Sub-merchants attest SAQ A / SAQ A-EP based on integration shape; the platform's certification covers the data-handling boundary.
-
Annual reassessment cadence
AOC re-issued annually; merchants and PSPs receive a current copy on request through the dashboard's compliance pack.
-
Aligned regional regimes
SCA / PSD2 in Europe, scheme programme alignment (VDMP / VAMP / ECP / EFMP) with Visa and Mastercard, AML / sanctions screening at onboarding.
Industry relevance
PCI payment compliance across regions and verticals
PCI DSS is the global card-data standard, but the regional regimes it pairs with differ. The platform's posture aligns with what each region's regulators expect on top of the base standard.
North America
PCI DSS paired with NACHA mandate handling on the ACH side. Scheme programmes (VDMP / VAMP, ECP / EFMP) monitored per acquirer with position-vs-limit visibility in the dashboard.
APAC & LATAM
PCI DSS paired with local-rail certifications via licensed partner gateways (PIX in BR, India connectivity via licensed partners, regional wallets across APAC). One PCI boundary regardless of the regional rail.
Trust & compliance signals
What sits behind the pci payment services posture
One audited environment underpins every PCI payment surface. Merchants inherit the posture rather than carrying separate certifications themselves.
- PCI DSS Level 1
- Annual on-site assessment plus quarterly ASV scans; AOC re-issued annually and available through the dashboard's compliance pack.
- SCA & PSD2
- Selective 3DS2 on the authorisation path keeps approval high in Europe without skipping the compliance bar.
- Scheme programmes
- Visa VDMP / VAMP / VFMP and Mastercard ECP / EFMP positions surfaced per acquirer; routing weights can rotate around at-risk providers.
- Sanctions & AML alignment
- Sanctions screening on onboarding; AML monitoring tuned per merchant vertical, volume and method mix; FATF Travel Rule via partner gateways where relevant.
- Operator audit trail
- Dashboard and virtual-terminal actions log with actor identity, timestamp and IP; refund and chargeback evidence flows feed the same audit trail.
- 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.
Compliance pack on request
Inherit a Level 1 pci payment posture without earning it.
A 30-minute coverage review covers the surfaces relevant to your traffic — gateway, processor, services, solutions — and walks through what an SAQ A or SAQ A-EP attestation looks like for your integration. The current AOC is available on request.
Frequently asked
Buyer questions about pci payment on topropay
Questions buyers ask before committing — gateway vs processor, services vs solutions, application scope, sub-merchant inheritance and how PCI relates to ACH, crypto and SCA.
- 01
What does topropay mean by pci payment?
PCI payment on topropay covers any payment flow handled under the platform's PCI DSS Level 1 service-provider posture — card capture, vault tokenisation, routing across connected processors, refunds, retries and recurring. The compliance boundary is platform-side; the merchant integrates against vault tokens, not raw PANs.
- 02
How does the pci payment gateway differ from a standalone gateway?
The pci payment gateway on topropay is one surface inside an orchestration layer. The same vault token issued at the gateway is portable across every connected processor in the routing panel — a standalone gateway typically issues provider-locked tokens that don't survive a switch.
- 03
What does a pci payment processor look like on the platform?
A pci payment processor on the platform is any connected acquirer or PSP that authorises and settles through the audited boundary. Detokenisation happens at the processor edge under TLS; the merchant doesn't carry PAN handling regardless of which processor a given authorisation routes to.
- 04
What pci payment services does the catalogue cover?
PCI payment services include card services (one-off, recurring, card-on-file, MOTO via the virtual terminal), ACH payment services with NACHA mandate handling, crypto via licensed partner gateways, payment-facilitation services for sub-merchant onboarding, and subscriber services for recurring billing. All ride the same Level 1 posture.
- 05
How are pci payment solutions packaged?
PCI payment solutions are opinionated wrappers around the gateway primitives — hosted checkout, recurring billing, marketplace payouts, BNPL, virtual terminal. Each solution inherits the PCI boundary; the merchant doesn't compose a separate compliance shape per solution.
- 06
How does pci payment compliance flow down to sub-merchants?
PCI payment compliance flows down through the service-provider model. The platform carries the Level 1 AOC for the audited boundary; sub-merchants attest SAQ A (hosted-page) or SAQ A-EP (hosted-fields) based on the integration shape they chose. The compliance pack with the current AOC is available in the dashboard.
- 07
What is a pci payment application in this context?
A pci payment application on the platform is the merchant-facing app — dashboard, virtual terminal, MOTO entry, refund console, dispute queue — that runs inside the audited environment. Application activity logs with actor identity per action so audit and ops queries share the same trail.
- 08
Does the platform support direct MID merchants as well as sub-merchants?
Yes. Direct-MID merchants can integrate against the same PCI vault and gateway; their MID lives at the connected acquirer rather than under the platform's facilitation MID. The PCI posture is identical; the underwriting model and pricing differ.
- 09
How is card data captured without expanding the merchant's PCI scope?
Card-number, expiry and CVV are entered into hosted-page or hosted-field iframes served from the platform's PCI-audited origin. The merchant's HTML never sees the raw values; the tokeniser returns a vault token to the merchant's back-end. Scope sits at SAQ A or SAQ A-EP depending on the surface.
- 10
What happens to vault tokens when routing weights change?
Vault tokens are platform-issued, so they don't change when routing weights shift across processors. A token captured today and re-charged six months from now via a different acquirer is the same token; the platform detokenises at the new processor's edge.
- 11
How are recurring charges handled under the PCI boundary?
Recurring charges run server-side against the vault token. Network tokens by default for card-on-file recurring; scheme account updaters keep tokens fresh across re-issuance. The merchant doesn't store PANs to keep recurring alive.
- 12
How does the platform handle dispute and chargeback evidence under PCI?
The unified dispute queue keeps evidence packs (tokenised receipts, vault-backed transaction references, signed webhook history) inside the audited environment. Evidence assembly doesn't pull PANs back into the merchant's systems; the queue serves them via tokens.
- 13
Is the AOC available to merchants for their own assessors?
Yes. The current AOC and supporting compliance pack (network-segmentation summary, pen-test scope, ASV-scan attestation) are downloadable from the dashboard's compliance pack. Annual reassessment refreshes the pack.
- 14
Does the PCI boundary apply to crypto and ACH services too?
PCI scope is specific to card data. ACH services run under NACHA mandate handling rather than PCI; crypto rails via licensed partner gateways run under MiCA / VASP-relevant frameworks. Where a customer flow crosses card data, the PCI boundary applies — for ACH-only or crypto-only flows the boundary is the relevant non-card framework.
- 15
Can a merchant migrate to the PCI vault without re-onboarding cardholders?
Yes. The platform supports network-token migration and card-data migration under a signed Data Transfer Agreement with the prior provider. Saved cards continue to charge against the same buyer relationship; the merchant doesn't lose recurring revenue at the cut-over.
Related
Related on the topropay platform
- Posture PCI compliant payments The sibling page on inherited PCI posture — vault, tokens, SAQ A inheritance and webhook signing.
- PCI Payment Card Industry PCI compliance Deeper PCI overview — service-provider levels, controls and assessment cycle.
- Controls Risk & fraud controls Velocity rules, list management and fraud-engine connectors layered on top of the PCI posture.
- Catalogue Payment services catalogue The wider service catalogue the PCI surfaces ride — card, ACH, crypto, facilitation and subscriber.
- Compliance Compliance posture overview Wider compliance shape topropay sits inside — PCI, SCA, AML and scheme programmes together.
- Taxonomy Types of e payment system The six payment-system categories that the PCI posture sits underneath — card, bank rail, wallet, BNPL, crypto, recurring.