Every payment service provider faces the same dilemma: their merchants must be PCI DSS compliant, but most of them lack the technical expertise, internal resources, and budget to achieve and maintain compliance on their own. The result is a chain of liability where non-compliant merchants create risk for the PSP - reputational risk in case of a breach, financial risk through card scheme fines, and operational risk from increased support overhead. Yet for many PSPs, merchant compliance has traditionally been treated as the merchant's own problem.
This approach is changing. Forward-thinking PSPs across Europe are recognising that merchant compliance is not just a risk to manage - it is an opportunity to monetise. By offering compliance-as-a-service, using a tokenisation infrastructure to simplify their merchants' PCI obligations, PSPs can generate new revenue, reduce merchant churn, accelerate onboarding, and differentiate their offering in an increasingly competitive market.
- Fewer than 30% of organisations maintain full PCI DSS compliance between annual assessments - non-compliant merchants create direct risk exposure for their PSP.
- PSPs can offer compliance-as-a-service via shared tokenisation infrastructure, reducing merchant PCI scope to SAQ A and generating a new revenue stream.
- Merchants using the PSP's compliance platform show higher retention, faster onboarding, and lower support overhead - a win for both parties.
The Current State of Merchant PCI Compliance
The reality on the ground is stark. The majority of small and medium-sized merchants in Europe struggle with PCI DSS compliance. According to Verizon's Payment Security Report, fewer than 30% of organisations maintain full PCI DSS compliance between annual assessments. For smaller merchants - those processing fewer than six million transactions annually, typically classified as Level 3 or Level 4 - the compliance rate is even lower.
The reasons are predictable. PCI DSS is complex; v4.0 now includes more than 250 individual controls in the full SAQ D. Most small merchants have no dedicated security staff. They rely on their payment provider for guidance, but the guidance they receive is often limited to "fill in this Self-Assessment Questionnaire" with little practical help on actually achieving compliance. The result is a compliance gap that exposes both the merchant and the PSP to risk.
Why PSPs Should Care About Merchant Compliance
PSPs have a direct interest in their merchants' compliance posture for several interconnected reasons. First, the liability chain: when a merchant suffers a data breach, card schemes can impose fines on the acquiring bank, which passes them to the PSP, which in turn may attempt to recover them from the merchant. In practice, small merchants often cannot absorb these fines, leaving the PSP exposed. The total cost of a breach - including forensic investigation, notification, remediation, and scheme penalties - can easily reach six or seven figures.
Second, reputational risk. A breach at a merchant using your platform reflects on you, especially if the merchant was handling card data insecurely. European consumers are increasingly sensitive to data security, and news of a breach can push merchants - and their customers - toward competing platforms. Third, operational overhead: non-compliant merchants generate more support tickets, more integration issues, and more complex onboarding processes. Merchants handling raw card data require more assistance, more security reviews, and greater involvement in incident response from the PSP team.
The Compliance-as-a-Service Model
The compliance-as-a-service model flips the traditional dynamic. Instead of leaving merchants to solve PCI compliance independently, the PSP provides the infrastructure that makes compliance automatic - or as close to automatic as possible. The central mechanism is tokenisation: by intercepting card data before it reaches the merchant's systems and replacing it with non-sensitive tokens, the PSP can dramatically reduce the merchant's PCI scope.
How PCI Proxy Makes This Possible
PCI Proxy sits between the merchant and the payments ecosystem, tokenising card data at the point of capture. Whether the card is entered via a web form, mobile SDK, API call, or call centre agent, PCI Proxy intercepts the PAN, replaces it with a token, and stores the original in a secure, PCI DSS Level 1 certified vault. The merchant's systems handle only tokens - they never see, store, or transmit raw card data.
For the PSP, this means merchants can reduce their compliance scope from SAQ D (over 300 controls) to SAQ A or SAQ A-EP (fewer than 30 controls). The annual compliance process that previously took weeks or months of effort becomes a straightforward, manageable questionnaire. Merchants who previously struggled to complete even a basic self-assessment now have a clear, achievable path to compliance.
Revenue Generation Through Compliance Services
Tokenisation-as-a-service is not just a risk reduction tool - it is a revenue opportunity. PSPs can package compliance services as a premium tier: a monthly or per-transaction fee that includes tokenisation, secure card storage, and simplified SAQ support. For merchants, this fee is far less than the cost of achieving compliance independently (which can reach tens of thousands of euros annually for SAQ D). For the PSP, it represents a new recurring revenue stream with high margins - the infrastructure cost of tokenisation scales efficiently, while the value to each merchant is substantial.
Faster Merchant Onboarding
One of the less obvious benefits is onboarding speed. Merchants that need to handle card data in their own environment face longer integration timelines - they must demonstrate PCI compliance before going live, which often involves security questionnaires, vulnerability scans, and infrastructure reviews. With tokenisation built into the PSP's offering, merchant integration inherently reduces scope from day one. Onboarding times shrink from weeks to days because the heavy lifting of compliance is handled by the tokenisation infrastructure, not the merchant's development team.
Technical Implementation for PSPs
Multi-Tenant Tokenisation Architecture
PCI Proxy supports multi-tenant deployments where a single PSP account can manage tokenisation for hundreds or thousands of merchants. Each merchant's tokens are logically isolated - Merchant A cannot use Merchant B's tokens - and access controls ensure that detokenisation requests are scoped to the requesting merchant's token set. The PSP maintains a single integration with PCI Proxy and provisions merchant-specific configurations via an administrative API.
Merchant-Specific Token Vaults
Within the multi-tenant architecture, each merchant receives a logically separate token vault. This separation ensures compliance boundaries are maintained: a merchant's PCI scope assessment applies only to their own token set, and audit trails are merchant-specific. The PSP can configure per-merchant policies for token format (format-preserving or opaque), detokenisation permissions, IP whitelisting, and token expiry - all without affecting other merchants on the platform.
White-Label Options
PSPs can offer the tokenisation service under their own brand. Secure card input fields, hosted payment pages, and compliance documentation can all carry the PSP's visual identity. From the merchant's perspective, the compliance service is a natural extension of their payment provider's platform - there is no third-party brand to explain or manage. This reinforces the PSP's value proposition and deepens the merchant relationship.
Integration simplicity
PSPs integrate once with PCI Proxy's REST API. Merchants integrate with the PSP platform as usual - the tokenisation layer is transparent. No merchant-side development is required beyond replacing standard card input fields with PCI Proxy secure fields, a task completable in under an hour.
Business Benefits for PSPs
New Revenue Stream
Compliance-as-a-service generates high-margin recurring revenue. Merchants are willing to pay for a service that saves them thousands in annual compliance costs, reduces their liability exposure, and simplifies operations. Per-transaction or monthly subscription models provide predictable revenue that scales with merchant growth.
Reduced Merchant Churn
Merchants who rely on your platform for compliance are significantly less likely to switch providers. Tokenisation creates a natural lock-in effect - not through contractual restrictions, but through genuine value. The merchant's card-on-file data is stored in your platform's vault, and their compliance posture depends on your service. Migrating to a competitor means rebuilding compliance from scratch.
Competitive Differentiation
In the European PSP market, where processing fees are increasingly commoditised, compliance services provide meaningful differentiation. A PSP that can say "we handle your PCI compliance" has a stronger commercial proposition than one that simply offers payment processing. This is particularly relevant for mid-market merchants who lack in-house security expertise and are actively looking for providers that simplify their regulatory burden.
Lower Support Costs
Merchants not handling raw card data generate fewer security incidents, fewer integration issues, and fewer compliance-related support requests. The tokenisation layer eliminates entire categories of support tickets - "how do I encrypt card data at rest?", "how do I pass a vulnerability scan?", "what do I do with this PCI report?" - questions that consume significant support team bandwidth simply disappear.
Case Study: A Mid-Sized European PSP
Consider a mid-sized European PSP processing payments for 2,000 merchants across retail, e-commerce, and hospitality. Before implementing compliance-as-a-service, the PSP faced a familiar set of challenges: only 40% of merchants could demonstrate PCI DSS compliance at any given time; onboarding a new merchant averaged 3–4 weeks due to compliance reviews; the support team spent approximately 20% of its time handling compliance-related queries; and two merchants had suffered minor data breaches in the previous 18 months, with scheme fines and forensic investigation costs totalling over €200,000.
After integrating PCI Proxy as a white-label tokenisation layer, the PSP offered compliance-as-a-service as a premium tier at €49 per month per merchant. Within 12 months, 1,200 of the 2,000 merchants had adopted the service, generating €58,800 in new monthly recurring revenue. Merchant compliance rates rose from 40% to over 90% because most merchants now qualified for SAQ A rather than SAQ D. Average onboarding time dropped from 3–4 weeks to 3–5 days. Compliance-related support tickets fell by 65%. And the PSP recorded zero data breaches among merchants using the tokenisation service.
Results summary
- €58,800/month new recurring revenue (60% adoption rate)
- Compliance rates: 40% → 90%+
- Onboarding time: 3–4 weeks → 3–5 days
- Compliance support tickets: −65%
- Data breaches among tokenised merchants: zero
Conclusion
The PSP's role in the payments ecosystem is evolving. Transaction processing is table stakes - competitive advantage now lies in the value-added services a PSP can build around its core offering. Compliance-as-a-service, powered by a tokenisation infrastructure like PCI Proxy, is one of the most compelling. It addresses a genuine pain point for merchants, generates significant recurring revenue for the PSP, reduces risk across the merchant portfolio, and creates a sticky relationship that makes churn less likely.
For European PSPs navigating the complexities of PCI DSS v4.0, GDPR, and an increasingly security-conscious market, the ability to offer compliance as a built-in feature - rather than a burden transferred to merchants - represents a meaningful strategic advantage. The technology to enable this exists today. The question is not whether to offer compliance-as-a-service, but how quickly you can bring it to market.
If you are a PSP exploring this model, discover how PCI Proxy is designed for payment service providers, or contact our team to discuss a white-label implementation for your platform.