The Number 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.
Here's the figure that stops conversations: PCI DSS Level 1 compliance costs up to £1.1 million to achieve initially, plus approximately £135,000 per year to maintain. For a platform that processes payments on behalf of its customers, this isn't a theoretical number. It's the cost of doing business if card data touches your environment.
But that 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 six times more stringent than those for merchants.
PCI Level | Merchant Threshold | Service Provider Threshold |
|---|---|---|
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 transactions per year would be 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 per year — roughly 820 per 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)
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 can add £500,000-£800,000 in Year 1.
Representative Year 1 total: £830,000-£1,100,000+
Level 2 Service Provider (Under 300,000 transactions/year)
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 came into full enforcement in March 2025, replacing version 3.2.1. 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 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 tones must be suppressed. 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 reduce PCI compliance cost to near zero: ensure 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 qualifies for SAQ-A. This is the lightest self-assessment level, covering approximately 20 requirements instead of the 300+ in SAQ-D.
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 (SAQ-A) | SAQ-A | £5,000-£15,000 | Minimal |
The cost difference is dramatic. A platform processing 500,000 transactions per year saves £315,000-£540,000 annually by descoping — 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 DTMF masking — the cardholder enters their card number on their phone keypad, and the tones are captured directly by the payment 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 entirely outside their environment across all channels — web, voice, chat, payment links. The platform stays at SAQ-A 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 where compliance is included and scope stays minimal.
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 costs alone typically run £100,000-£500,000. Add 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, with first-year costs exceeding £1 million. Platforms that descope by using a PCI Level 1 certified payment layer reduce that cost to under £15,000 per year.
For most platforms, the decision is clear. Card data handling is not a competitive advantage. It's a liability — an expensive, resource-consuming liability that can be eliminated entirely by choosing the right architecture.