PCI DSS is the compliance framework that every platform encounters when evaluating embedded payments. It's also the framework that most consistently gets over-scoped by vendors trying to sell compliance services and under-scoped by engineering teams who think "we don't store card numbers, so we're fine."
The truth is in between. Your PCI obligations depend entirely on your embedded payments model — and the range between models is enormous. A platform using hosted payment fields might complete a ~30-question self-assessment in an afternoon. A full PayFac managing its own token vault might spend $150K–$250K annually on compliance. Same regulatory framework. Completely different scope.
PCI DSS v4.0 has been the current standard since April 2024 (v4.0.1 published June 2024). The framework's structure didn't change, but v4.0 added requirements — notably script management on payment pages — that affect even fully-outsourced platforms. Everything below reflects v4.0 obligations.
How PCI Scope Works
PCI DSS applies to any entity that stores, processes, or transmits cardholder data. The operative word is "or" — if you touch card data in any form at any point in the transaction flow, you're in scope.
The most important architectural decision you'll make for PCI scope is whether card data ever touches your systems. If it doesn't — if the cardholder enters their card number directly into a processor-hosted iframe or redirect — your scope is minimal. If it does — if your server receives, decrypts, or routes raw card numbers — your scope is significant.
Most modern embedded payments architectures use tokenization and hosted fields specifically to keep platforms out of scope. The card number goes directly from the cardholder's browser to the processor's infrastructure. Your platform never sees it. You work with a token that represents the card but carries no exploitable value.
SAQ Types: What Applies to You
PCI compliance is validated through Self-Assessment Questionnaires (SAQs) or, at higher levels, a Report on Compliance (RoC) conducted by a Qualified Security Assessor (QSA). Which SAQ applies to your platform depends on how you interact with card data.
| SAQ Type | When It Applies | Effort / Cost |
|---|---|---|
| SAQ-A | All payment processing is fully outsourced. You use hosted fields, iframes, or redirects. No card data touches your systems. | 22 questions. Complete in a day. ~$0 incremental cost. |
| SAQ-A-EP | Your website controls the payment page but card data goes directly to the processor (JavaScript-based tokenization). Your server doesn't receive card data, but your frontend code could be compromised to intercept it. | 139 questions. Requires web application firewall, vulnerability scanning, penetration testing. $5K–$25K/year. |
| SAQ-D | Your systems store, process, or transmit cardholder data. Full scope. | 329 questions. Requires network segmentation, encryption, access controls, logging, incident response, and potentially a QSA-conducted RoC. $50K–$250K/year depending on environment complexity. |
PCI by Embedded Payments Model
ISV Referral: SAQ-A in almost all cases. The processor handles the entire payment flow. Your platform links to or embeds their hosted checkout. PCI obligation is minimal — confirm annually that you're using their hosted solution and haven't modified it to capture card data. Cost: essentially zero beyond the time to complete the questionnaire.
PayFac-as-a-Service: Typically SAQ-A or SAQ-A-EP, depending on implementation. Most PFaaS providers supply hosted payment fields that keep you at SAQ-A scope. If you've built a custom checkout page that loads the provider's tokenization JavaScript, you're likely SAQ-A-EP. The provider handles the heavy compliance infrastructure; your obligation is to not accidentally bring card data into your environment.
Full PayFac: SAQ-D or full RoC. You're processing card data, managing tokens, and operating settlement infrastructure. Full PCI scope applies. Most full PayFacs cross the Level 1 Service Provider threshold (300K+ transactions/year) quickly, which mandates an annual on-site assessment (RoC) conducted by a QSA rather than a self-assessment. This is where compliance costs escalate significantly — dedicated security staff, annual penetration testing, quarterly ASV scans, network segmentation, and ongoing monitoring. Budget $100K–$250K annually for a mature compliance program.
The Mistakes That Expand Your Scope
Platforms most often end up in higher PCI scope accidentally. Common mistakes:
- Logging card data. A developer adds verbose request logging that captures POST bodies including card numbers. The data hits your log aggregator. You're now in scope for SAQ-D. This happens more often than anyone admits.
- Custom checkout pages without hosted fields. Your design team wants pixel-perfect control over the payment form, so they build a native form that submits to your server before forwarding to the processor. Card data now transits your infrastructure. SAQ-D.
- Storing card data "temporarily." An engineer stores card details in a session variable or temporary database record to support a multi-step checkout flow. Even transient storage puts you in full scope.
- Support team access. If your customer support team can see full card numbers in your admin tools (even if they're in the processor's dashboard embedded via iframe), verify that the iframe architecture keeps you out of scope. Some implementations leak data into the parent frame.
What Compliance Actually Costs
For the majority of platforms using modern embedded payments architectures (hosted fields, PFaaS), the real compliance cost is:
- Annual SAQ completion: 1–2 hours of internal time
- Quarterly vulnerability scanning (if SAQ-A-EP): $1K–$3K/year from an Approved Scanning Vendor
- Annual penetration test (if SAQ-A-EP or SAQ-D): $5K–$15K
- Ongoing monitoring and policy maintenance (SAQ-D only): $50K–$100K+ depending on environment
The vendors selling $50K compliance packages to platforms using hosted payment fields are over-scoping you. If your architecture keeps card data off your systems, your compliance obligation is a questionnaire, not a program.
How to Stay in Minimal Scope
The architectural decisions that keep your PCI scope minimal:
- Use hosted payment fields (iframes) for all card data entry — never native form inputs
- Never log, store, or transmit raw card numbers, even temporarily
- Use processor-generated tokens for all recurring billing and card-on-file operations
- Ensure your checkout page is served over HTTPS with current TLS (1.2+)
- Review your logging configuration annually to confirm no card data leaks into application logs
- Document your payment data flow diagram — know exactly where card data enters and exits
PCI compliance isn't the cost of embedded payments. It's the cost of a bad architecture decision. Get the architecture right and compliance is a checkbox, not a budget line.
Related: What Embedded Payments Actually Costs includes compliance in the operating cost breakdown by model. For a full review of your compliance posture and architecture, see the advisory engagement.