The Cost That Catches Platforms Off Guard
Most platform CTOs know PCI DSS compliance isn't free. Few realise how expensive it actually is, or that the thresholds for platforms are dramatically lower than they expect.
PCI DSS Level 1 compliance is expensive to achieve and expensive to maintain. For a platform that processes payments on behalf of its customers, this isn't a theoretical cost. It's the cost of doing business if card data touches your environment.
But a single headline figure only tells part of the story. The real cost of PCI compliance for platforms includes direct audit expenses, infrastructure changes, ongoing monitoring, staff time, and the opportunity cost of engineering resources diverted from your core product.
The Threshold Trap
This is where most platforms get caught.
PCI DSS defines two categories of entities: merchants and service providers. Merchants accept payments for their own goods and services. Service providers process, store, or transmit cardholder data on behalf of other businesses.
Platforms that embed payments for their customers are classified as service providers. And the thresholds for service providers are far lower than those for merchants: Level 1 starts at 300,000 transactions a year on a single card brand for a service provider, against 6,000,000 for a merchant.
PCI Level | Merchant Threshold (per card brand) | Service Provider Threshold (per card brand) |
|---|---|---|
Level 1 | 6,000,000+ transactions/year | 300,000+ transactions/year |
Level 2 | 1,000,000-6,000,000 | Under 300,000 |
A platform processing 500,000 Visa transactions a year would sit below Level 2 as a merchant but is Level 1 as a service provider. Level 1 is the most expensive and rigorous tier, requiring a full onsite audit by a Qualified Security Assessor (QSA), not just a Self-Assessment Questionnaire.
At 300,000 transactions a year on one card brand, roughly 820 a day, you hit the Level 1 threshold. For a growing platform, that number arrives faster than expected.
Cost Breakdown by Level
Level 1 Service Provider (300,000+ transactions/year per card brand)
This is the tier most growing platforms will reach. The costs:
Component | Annual Cost |
|---|---|
QSA audit (onsite assessment) | £80,000-£120,000 |
Remediation (fixing gaps found in audit) | £150,000-£250,000 |
Penetration testing (external + internal) | £40,000-£75,000 |
Vulnerability scanning (quarterly ASV scans) | £5,000-£15,000 |
Security automation and monitoring tools | £30,000-£50,000 |
Staff training and awareness | £10,000-£20,000 |
Documentation and policy maintenance | £15,000-£25,000 |
Typical annual total | £330,000-£555,000 |
First-year costs are substantially higher because of initial infrastructure changes. Network segmentation, encryption implementation, key management systems, access control overhauls, and logging infrastructure all add to the Year 1 bill.
Level 2 Service Provider (Under 300,000 transactions/year per card brand)
Level 2 service providers complete a Self-Assessment Questionnaire (SAQ-D) rather than a full onsite audit. The costs are lower but still substantial:
Component | Annual Cost |
|---|---|
SAQ-D completion and validation | £15,000-£30,000 |
Penetration testing | £15,000-£30,000 |
Vulnerability scanning | £5,000-£10,000 |
Security tooling | £15,000-£30,000 |
Remediation | £20,000-£50,000 |
Typical annual total | £70,000-£150,000 |
The jump from Level 2 to Level 1 is steep. Platforms approaching the 300,000 transaction threshold should plan for the cost increase 12-18 months in advance.
What PCI DSS 4.0 Changed
PCI DSS 4.0 replaced version 3.2.1, which was retired on 31 March 2024. The requirements that 4.0 marked as future-dated became mandatory on 31 March 2025. The changes increased both the technical requirements and the cost of compliance.
Key changes that affect platforms:
Stronger encryption requirements. All cardholder data must be encrypted with current, strong cryptographic algorithms. Deprecated algorithms must be phased out: this often requires infrastructure changes.
Mandatory multi-factor authentication (MFA). MFA is now required for all non-console access to the cardholder data environment, not just remote access. This extends to internal access by administrators, developers, and operations staff.
Continuous monitoring. Version 4.0 shifts the model from point-in-time assessment to continuous validation. Automated log monitoring, real-time alerting on security events, and regular security control testing are now baseline requirements.
Targeted risk analysis. Organisations must perform formal risk analysis for any requirement where they use a "customised approach" rather than the defined method. This adds documentation and justification overhead.
Client-side security. New requirements for monitoring and controlling JavaScript loaded on payment pages, addressing Magecart-style attacks. Platforms with web-based checkout flows need content security policies, script inventories, and integrity monitoring.
The net effect: compliance is more expensive, more technically demanding, and requires more ongoing attention than under version 3.2.1.
How Channels Expand PCI Scope
Every channel that touches card data adds to your PCI scope. This is where platforms underestimate the cumulative cost.
Web checkout. The most common channel. If your platform renders a checkout page where cardholders enter details, that page and its infrastructure are in scope. Even with iframes or hosted fields, the hosting page needs to meet PCI DSS 4.0's client-side security requirements.
Voice payments. If your platform takes card details over the phone (whether through an IVR system, agent-assisted calls, or AI voice agents), the voice infrastructure is in PCI scope. Call recording systems must pause during card capture. DTMF digits must never reach the agent. Agent screens must be masked. The telephony infrastructure itself needs segmentation and monitoring.
Chat payments. If customers type card details into a chat interface (whether live chat, messaging, or an AI chat agent), that channel is in scope. Chat logs containing card data must be encrypted, access-controlled, and purged according to retention policies.
Email and SMS. Payment links sent via email or SMS can be designed to keep card data out of your environment (the cardholder enters details on a hosted page). But if card details are ever communicated back through these channels, they're in scope.
Each channel you add doesn't just add its own cost: it expands the boundary of your cardholder data environment, which increases the scope of every audit, every penetration test, and every monitoring requirement.
The Descoping Strategy
There is a way to cut PCI compliance cost substantially: make sure card data never enters your environment.
If cardholder data is captured, processed, and stored entirely by a PCI DSS Level 1 certified third party (and never passes through or is accessible to your systems), your platform's PCI scope is typically much smaller.
Approach | PCI Level | Annual Cost | Ongoing Effort |
|---|---|---|---|
Self-certified (card data in your environment) | Level 1 SP | £330,000-£555,000 | High |
Self-certified (card data in your environment) | Level 2 SP | £70,000-£150,000 | Medium |
Descoped via certified provider | Reduced scope | £5,000-£15,000 | Minimal |
The cost difference is dramatic, before accounting for the engineering time freed up.
How Descoping Works in Practice
The principle is simple: card data flows directly between the cardholder and the certified payment provider. Your platform initiates the payment flow and receives the result, but the sensitive data takes a path that bypasses your infrastructure entirely.
For web payments, this means hosted checkout pages or payment fields rendered in iframes from the payment provider. For voice payments, this means secure keypad capture: the cardholder enters their card number on their phone keypad, and the digits are captured by the certified provider rather than passing through your telephony system. For chat and messaging, this means payment links that redirect the cardholder to a hosted page.
Shuttle is PCI DSS Level 1 certified, ISO 27001 certified, and SOC 2 certified. Platforms integrating through Shuttle keep card data outside their environment across web, voice, chat and payment links, which limits their PCI scope. The platform's PCI scope is typically much smaller, regardless of how many PSPs are processing transactions underneath, because the card data boundary sits with Shuttle, not with the platform.
This is the difference between building payment infrastructure in-house, where PCI scope expands with every feature, and using a payment layer that is already PCI DSS Level 1 certified, so your scope stays limited.
Non-Compliance Risk
Platforms sometimes weigh PCI compliance costs against the risk of non-compliance. The maths on that calculation is not favourable.
Fines. Card networks can impose fines of $5,000-$100,000 per month on acquiring banks for non-compliant merchants and service providers. Those fines flow downstream.
Breach liability. If a data breach occurs and the organisation is non-compliant, liability exposure increases substantially: forensic investigation, notification costs, legal fees, regulatory penalties, and brand damage.
Loss of processing capability. In severe cases, card networks can revoke a service provider's ability to process card payments. For a platform whose customers depend on payment processing, this is existential.
The cost of PCI compliance is significant. The cost of non-compliance is worse.
The Bottom Line
PCI DSS compliance is not optional for platforms that handle card data. The question is how much it costs, and that's largely determined by whether card data enters your environment.
Platforms that process card data directly face costs of £330,000-£555,000 per year at Level 1, and more in the first year. Platforms that descope by using a PCI Level 1 certified payment layer reduce that cost substantially.
For most platforms, the decision is clear. Card data handling is not a competitive advantage. It's a liability, an expensive and resource-consuming one, and choosing the right architecture limits it sharply.