The average data breach now costs USD 4.88 million, a 10% jump in a single year (IBM Cost of a Data Breach Report 2024). For a merchant that fails to maintain PCI DSS compliance, the bill goes well beyond breach cleanup. Card brands can levy USD 5,000 to USD 10,000 per month for the first three months of non-compliance, escalating to USD 50,000 to USD 100,000 per month after seven months (Secureframe, 2024). On top of that, a confirmed cardholder data environment (CDE) breach can attract a USD 50 to USD 90 fine per affected customer.

When Target was breached in 2013, the eventual cost reached USD 292 million (Secureframe). TJX paid USD 256 million. Both incidents cited PCI compliance failures.

The PCI Attestation of Compliance (AoC) is the document at the center of all of this. With PCI DSS 4.0.1 fully enforceable as of March 31, 2025, the bar has moved meaningfully higher. This article unpacks what an AoC is, the four merchant levels and which SAQ applies to each, what changed in PCI DSS 4.0.1, the real cost of getting it wrong, and how Juspay Hyperswitch (a PCI DSS v4.0 Level 1 Service Provider) reduces a merchant's audit scope from SAQ D to SAQ A through a PCI-compliant vault and hosted payment fields.

What Is a PCI Attestation of Compliance?

A PCI Attestation of Compliance (AoC) is a signed declaration confirming that a merchant or service provider has met the requirements of the Payment Card Industry Data Security Standard (PCI DSS). It is not a certificate, and it is not optional for any business that stores, processes, or transmits cardholder data. The AoC accompanies one of two underlying assessment documents:

• A Self-Assessment Questionnaire (SAQ) for merchants below the highest transaction tier
• A Report on Compliance (ROC) for Level 1 merchants and service providers, completed by a Qualified Security Assessor (QSA)

The AoC is what the merchant actually shares with its acquirer or the card brands. The SAQ or ROC stays largely internal.

SAQ vs ROC vs AoC

The Four PCI Merchant Levels

PCI DSS classifies merchants into four levels based on annual card transaction volume across all card brands. Level determines what assessment route is required.

A Level 1 audit by a QSA typically costs USD 40,000 to USD 200,000+ depending on environment complexity. A Level 4 SAQ with no card data on the merchant's systems can be self-completed in days. The gap between these two outcomes is largely determined by your payment architecture.

The Self-Assessment Questionnaires (SAQs)

There are nine SAQ types. Three matter most for online merchants, and the difference between them is the single biggest lever a merchant has on compliance cost.

SAQ A

Applies when all cardholder data functions are outsourced to a PCI DSS compliant third party. The merchant's systems never store, process, or transmit account data. Roughly 22 questions. Suitable for merchants who use full-redirect or iframe checkouts where the card data goes directly from the customer's browser to the payment service provider.

SAQ A-EP

Applies when the merchant outsources card processing but controls the page where the customer enters their card. For example, JavaScript-based payment elements that send card data directly to a PSP, but the merchant's web server delivers the page hosting them. Roughly 195 questions.

SAQ D (Merchant)

Applies when the merchant stores, processes, or transmits cardholder data on its own systems, or does not meet the criteria for any other SAQ. Roughly 329 questions covering all 12 PCI DSS requirements.

Why the SAQ Type Matters

Numbers reflect typical mid-market e-commerce ranges. The difference between SAQ A and SAQ D for the same business is often six figures of recurring annual cost, plus the engineering time to maintain in-scope systems.

What Changed in PCI DSS 4.0.1 (Enforceable March 31, 2025)

PCI DSS 4.0 was published in March 2022 with a long transition period. PCI DSS 4.0.1 was published in 2024 as a "limited revision," meaning no new or removed requirements, just clarifications. The deadline that matters: as of March 31, 2025, all 51 previously future-dated requirements are mandatory and validated during every assessment (PCI Security Standards Council, 2024).

The four most consequential changes:

1. MFA on all CDE access (8.4.2 / 8.5): Multi-factor authentication is required for every account with access to the cardholder data environment, not just administrative accounts.
2. Targeted Risk Analysis (12.3.1): Several controls now allow risk-based scheduling instead of fixed annual or quarterly cycles, but only if a documented Targeted Risk Analysis (TRA) justifies the chosen frequency.
3. Payment page script integrity (6.4.3 and 11.6.1): Every script loaded on the payment page must be inventoried, justified, and monitored for tampering. This is a direct response to Magecart-style supply chain attacks.
4. Software Bill of Materials (6.3.2): Bespoke and custom software in the CDE must maintain an up-to-date inventory of components, including third-party libraries and dependencies.

For most merchants, the script integrity (6.4.3) and SBOM (6.3.2) requirements are the hardest to meet without architectural changes. If your checkout page loads JavaScript from your own domain that touches card data, you are now responsible for tamper detection on every script that runs on that page.

How Juspay Hyperswitch Reduces Your PCI Audit Scope

Juspay Hyperswitch is an open-source payment orchestration platform connected to 300+ processors and payment methods. It is independently certified as a PCI DSS v4.0 Level 1 Service Provider, the highest level of certification for service providers. That certification is what makes scope reduction available downstream to merchants.

What "PCI DSS Level 1 Service Provider" Buys the Merchant

Juspay Hyperswitch undergoes:

• Annual on-site PCI DSS audit by an independent Qualified Security Assessor (QSA).
• Quarterly external vulnerability scans by a PCI-approved Approved Scanning Vendor (ASV).
• ISO 27001:2022 certification in addition to PCI DSS, covering the broader information security management system.

Because Juspay Hyperswitch is the in-scope service provider, the merchant inherits scope reduction for any cardholder data flow that touches Juspay Hyperswitch's environment instead of the merchant's. Concretely, the merchant's checkout pages can move out of SAQ D scope and into SAQ A scope.

The Vault Architecture That Enables SAQ A

Juspay Hyperswitch ships with a dedicated card vault that handles all PCI-sensitive data. Several elements are designed specifically for scope reduction:

• Signed and encrypted in transit: The Hyperswitch App Server signs card details with its private key and encrypts them with the vault's public key. Validation and decryption happen inside the vault, not on application servers.
• AES at rest, on top of database-level encryption: Decrypted data is re-encrypted with AES inside the vault, then stored in a database that itself is encrypted at rest.
• Per-merchant Data Encryption Keys (DEKs): Each merchant has a unique DEK. DEKs are further encrypted via a secrets manager (AWS KMS in cloud deployments). Connector API keys, merchant info, and customer PII are all encrypted under the merchant's DEK.
• Optional Key Manager Service: For merchants pursuing the stricter PCI SSS certification (not required for PCI DSS), a separate Key Manager Service handles DEK generation and lifecycle. PCI DSS alone does not require KMS.
• Sensitive data masked in logs: Juspay Hyperswitch is built in Rust and uses a Secret<T> wrapper type that masks sensitive fields in all logs as *** alloc::string::String ***. This addresses one of the most common PCI audit findings (logs containing PAN data).

Hosted Payment Collection: SDK, Iframe, and Vault SDK

To qualify for SAQ A, card data must never touch the merchant's web servers. Juspay Hyperswitch supports several patterns:

• Hyperswitch SDK / Unified Checkout: Card data is captured into Juspay Hyperswitch's PCI-compliant environment via SDK fields. The merchant's page hosts the SDK; the merchant's server never receives the PAN.
• Iframe redirection: For merchants who prefer an iframe-based flow, the entire card capture happens inside an iframe served from Juspay Hyperswitch's PCI environment.
• Vault SDK / Payment Method Management SDK: A standalone SDK that gives merchants tokenized card storage and management without integrating the full payment orchestration layer.
• Server-to-server vault API: For PCI-compliant merchants who want to send card data directly to the vault from their own backend.

All four patterns mean the merchant's server never receives, stores, or transmits PAN data, which is the criterion for SAQ A eligibility.

Sharing the Hyperswitch AoC With Your Processors

A practical issue: many PSPs disable raw card acceptance by default, which can block a merchant from using Juspay Hyperswitch's tokenization with that PSP. Juspay Hyperswitch handles this with a documented process:

• A redacted version of Juspay Hyperswitch's PCI DSS AoC is available to Cloud users under NDA, downloadable from the Compliance section in the Dashboard.
• Merchants share that AoC with the PSP's support team to enable raw card acceptance for their merchant account.
• This is specifically required for Stripe, which no longer allows raw card acceptance via its Merchant Dashboard alone.

This sounds like operational paperwork but it is the unblocking step that lets merchants combine Juspay Hyperswitch's vault with any of the 300+ processors and payment methods supported.

What Juspay Hyperswitch Owns vs What the Merchant Owns

This split is what turns a Level 1 e-commerce merchant's compliance project from a multi-quarter SAQ D audit into a focused SAQ A self-assessment.

Worked Example: SAQ D to SAQ A

A merchant doing 8 million annual transactions (Level 1) with a custom-built checkout currently runs an in-house tokenization service:

• Before: SAQ D-equivalent ROC, full QSA on-site audit, quarterly ASV scans on the entire web tier, code review of any in-scope custom application, SBOM for the tokenization service. Estimated annual compliance cost: USD 150,000 to USD 250,000.
• After migrating to Juspay Hyperswitch with iframe checkout and Vault storage: ROC scope shrinks to the orchestration layer (no card data on merchant systems), checkout pages move to SAQ A scope, ASV scan footprint reduces, no in-house tokenization SBOM. Estimated annual compliance cost: USD 30,000 to USD 60,000.

The architectural change pays for itself in the first compliance cycle.

How to Complete an AoC: Step by Step

For merchants completing an AoC for the first time:

• Determine your merchant level by adding annual transaction volumes across all card brands (Visa, Mastercard, American Express, Discover, JCB).
• Identify the right SAQ based on how cardholder data flows through your environment.
• Map your cardholder data environment: every system, network segment, and third-party that touches PAN data.
• Reduce scope first, then assess: deploy a PCI-compliant vault and hosted payment collection (such as Juspay Hyperswitch's Vault plus iframe checkout) before starting the SAQ. Reducing scope before the assessment is the single highest-ROI compliance move.
• Complete the SAQ honestly: every "Not Applicable" requires documented justification.
• Engage an Approved Scanning Vendor (ASV) for quarterly external vulnerability scans. Required for SAQ A-EP and above.
• Sign the AoC and submit it to your acquirer. Renew annually.

Common Mistakes That Trigger Failed Audits

• "We don't store card data" but your logs do: Application logs that capture full HTTP request bodies often contain PAN. This pulls the logging system into PCI scope. Juspay Hyperswitch's Secret<T> masking solves this at the framework layer for the orchestration tier.
• Out-of-scope systems with network connectivity to the CDE: Any system that can reach the CDE is in scope. Network segmentation must be testable.
• Iframe checkouts on a self-hosted page that loads its own JavaScript: Triggers SAQ A-EP, not SAQ A. Under PCI DSS 4.0, also subject to script integrity controls.
• Ignoring the SBOM requirement: Merchants with custom code in scope underestimate the work to inventory third-party dependencies.
• Treating compliance as point-in-time: PCI DSS 4.0 emphasizes continuous monitoring. An annual snapshot is no longer enough.

Frequently Asked Questions

Is PCI DSS legally required? PCI DSS is a contractual requirement enforced by card brands and acquirers, not a law. However, several US states (notably Nevada and Washington) have referenced PCI DSS in legislation, and non-compliance often triggers regulatory scrutiny under broader data protection laws.

How long does it take to get an AoC? For SAQ A, a few weeks if the architecture is already compliant. For SAQ D with a QSA-led ROC, three to nine months is typical for a first audit.

What happens if I don't have a current AoC? Your acquirer can refuse to process transactions, increase your processing fees, levy monthly non-compliance fines (USD 5,000 to USD 100,000 depending on duration), or terminate the relationship.

Does using Juspay Hyperswitch make me automatically PCI compliant? No platform makes a merchant automatically compliant. Juspay Hyperswitch is itself a PCI DSS Level 1 Service Provider, which means the merchant inherits scope reduction for any flow that runs through Juspay Hyperswitch's environment. The merchant still owns its own systems, API keys, webhooks, and operational controls.

Can I download Juspay Hyperswitch's AoC? Yes. A redacted version is available to Hyperswitch Cloud users under NDA, downloadable from the Compliance section in the Dashboard. Merchants typically share it with their PSPs to enable raw card processing through Juspay Hyperswitch's vault.

Is the Key Manager Service required for PCI DSS? No. The Key Manager Service is optional and only required for the stricter PCI SSS (Software Security Standard) certification. PCI DSS works with the application's built-in key management.

What is the difference between PCI DSS 4.0 and 4.0.1? 4.0 (March 2022) introduced 64 new requirements with a long transition period. 4.0.1 (June 2024) is a clarification revision with no new or removed requirements. The 51 future-dated requirements from 4.0 became mandatory on March 31, 2025.

Closing Perspective

PCI DSS 4.0.1 is now fully in force. The merchants who built their payment architecture around handling card data themselves are facing the highest compliance bills in PCI history, with new SBOM, MFA, and script integrity requirements stacked on top of existing controls. The merchants who isolated card data inside a PCI-compliant vault years ago are spending a fraction of that on annual SAQ A self-assessments.

The Attestation of Compliance is the visible artifact, but the real determinant of cost and risk is your architecture. Juspay Hyperswitch is a PCI DSS v4.0 Level 1 Service Provider, audited annually by a QSA, scanned quarterly by an ASV, with a vault designed so merchants never have to receive PAN data on their own systems. Combined with 300+ processors and payment methods through a single API, it removes the architectural reason most merchants are still stuck on SAQ D.

Explore Juspay Hyperswitch on GitHub or read the PCI compliance documentation to understand how the Vault, SDKs, and AoC sharing process fit into a PCI-minimal architecture.