Attestation of Compliance for Payment Platforms
Learn what an attestation of compliance is, when PCI DSS validation is required, how to obtain and renew it, and what it means for your payment platform.
A payments lead gets an email from an acquirer asking for an AoC, or attestation of compliance, just as a major merchant is waiting for onboarding approval. Someone sends a generic PCI document. The acquirer asks for the correct form, the legal entity name doesn't match, or the validation path is unclear. Checkout expansion pauses while revenue, engineering, and compliance teams work out which PDF proves what.
That confusion is expensive. An attestation of compliance isn't a decorative certificate and it isn't a substitute for the assessment behind it. It's the formal evidence that connects a specific entity, environment, PCI DSS version, scope, and validation path to a signed compliance declaration. For a payment platform, getting those details right protects more than audit readiness. It helps preserve processor relationships, merchant onboarding, recurring revenue, and the ability to route payments through more than one provider.
Table of Contents
- What an Attestation of Compliance Actually Is
- Anatomy of the Attestation Document
- Merchant Attestations vs Service Provider Attestations
- PCI Levels and When an Attestation Is Required
- How to Obtain an Attestation of Compliance
- What an Attestation Does Not Cover
- Renewing and Maintaining an Attestation Year After Year
- Attestations in Multi-Processor and Agent-Led Payment Flows
- Quick Reference Glossary for Attestation Terms
- Practical Next Steps for Payments and Revenue Teams
What an Attestation of Compliance Actually Is
An Attestation of Compliance, or AoC, is the formal PCI DSS validation artifact that an assessed merchant or service provider submits as evidence that the relevant assessment was completed and the applicable controls were in place. The official form records the assessed entity, scope, PCI DSS version, validation path, compliance conclusion, and supporting signatures. The PCI SSC merchant AoC form is the recognized template for that evidence.
The AoC sits beside the underlying assessment. A Report on Compliance, or ROC, documents a detailed assessor-led review. A Self-Assessment Questionnaire, or SAQ, is the structured self-assessment route used where the applicable validation criteria allow it. The AoC confirms the conclusion of that ROC or SAQ. It doesn't replace either document.
Why payment partners ask for it
Acquirers, payment brands, processors, and enterprise merchants use the AoC to verify that the counterparty's stated PCI position has a defined basis. They may also ask for the associated ROC, SAQ, scope statement, or responsibility notes when the document alone doesn't answer their questions.
That makes the AoC a commercial control. An expired document can slow onboarding, complicate contract renewal, and create pressure in a processor relationship. The standard was first released as PCI DSS version 1.0 on December 15, 2004, creating a standardized framework for merchants and service providers to document compliance, as described in this PCI DSS history and overview.
Practical rule: Send the AoC that matches the assessed legal entity, service, scope, DSS version, and validation path. A signed PDF with the wrong scope is not useful evidence.
Treat the document as an operational record with an owner, renewal date, evidence trail, and approved sharing process. That mindset keeps a compliance request from becoming a last-minute revenue blocker.
Anatomy of the Attestation Document
A PCI AoC should be readable as a structured declaration, not a mysterious compliance PDF. Start by checking the identity of the assessed organization. The legal entity and described service should match the business relationship being reviewed, especially where a platform operates multiple products, subsidiaries, or payment flows.
The document then establishes the assessment basis:
- Entity and level: It identifies the merchant or service provider being assessed and the applicable validation category.
- PCI DSS version: It states the version used for the assessment. The document must match the version accepted by the requesting party and the assessment period.
- Scope: It describes the cardholder data environment, including systems that store, process, or transmit cardholder data and connected systems that affect security.
- Validation path: It identifies whether the conclusion rests on a ROC, SAQ, or another applicable assessment route.
- Declaration and signatures: It records the compliance conclusion and signatures from the organization and, where applicable, the qualified assessor or authorized representative.
Fields worth checking before acceptance
| Document Block | What It Confirms | What To Verify |
|---|---|---|
| Assessed entity | Which organization made the declaration | Legal name, service description, and contracting entity |
| DSS version | Which standard informed the assessment | Version accepted by the requester |
| Scope | Which environments and services were assessed | Vaults, integrations, applications, and relevant checkout surfaces |
| Validation path | How compliance was evaluated | ROC, SAQ, or service-provider assessment |
| Signatures and appendices | Who supports the conclusion and what details supplement it | Dates, assessor credentials, listings, responsibility notes, and referenced attachments |
A platform using tokenization may have shared-responsibility language or appendices explaining which controls sit with the vault provider and which remain with the platform. Don't assume that a tokenized architecture removes every obligation. It can change the assessed boundary, but the integration, access, scripts, logging, and operational controls around that boundary still need accurate treatment.
The practical test is simple. Can a merchant or acquirer understand who was assessed, what was assessed, how it was assessed, and when the conclusion applied? If not, request the supporting ROC, SAQ, scope statement, or responsibility summary before treating the AoC as complete evidence.
Merchant Attestations vs Service Provider Attestations
The most common classification error is treating a payment platform like a merchant. A merchant accepts cards for its own products or services. A service provider stores, processes, or transmits cardholder data on behalf of other organizations, or supports those activities through payment infrastructure.
A subscription business may complete its own merchant validation for its checkout and billing operations. A platform that tokenizes card details, provides a vault, or routes transactions for that subscription business generally needs to address its service-provider responsibilities separately. The merchant can use the provider's evidence to understand and reduce its own scope, but the provider's AoC doesn't automatically make the merchant compliant.
| Aspect | Merchant AoC | Service Provider AoC |
|---|---|---|
| Primary role | Accepts payment for its own goods or services | Supports card payment activity for other organizations |
| Scope | Merchant systems, checkout, billing, and connected environments | Services, infrastructure, vaulting, processing, routing, and client-facing integrations in scope |
| Typical validation path | SAQ where eligibility permits, or ROC where required | Service-provider ROC or applicable validation path defined by the requesting parties |
| Commercial requester | Acquirer, payment brand, or processor | Enterprise customers, acquirers, payment brands, and platform partners |
| Customer impact | Shows the merchant's own validation position | Helps customers evaluate shared responsibility and provider-related scope |
For platforms, the service description matters as much as the signature. A document that says a provider is compliant but doesn't clearly identify whether tokenization, stored credentials, routing, or agent-assisted payment surfaces were assessed leaves the buyer with more work.
FloPay's card storage terms describe the contractual context around secure card-storage services. In any vault-backed architecture, merchants should still map their own checkout, billing, access, and integration responsibilities rather than assuming a provider document transfers every obligation.
A provider's AoC can reduce merchant scope. It can't erase merchant accountability for systems and processes that remain in the merchant's environment.
The strongest setup separates raw card-data handling from merchant application logic, then documents that separation clearly. That supports a processor-neutral card-on-file layer while giving each party a defensible view of its own controls.
PCI Levels and When an Attestation Is Required
PCI validation levels depend on transaction volume and the rules applied by the relevant acquirer or payment brand. The baseline merchant thresholds cited in merchant guidance are 6 million or more transactions for Level 1, 1 million to 6 million for Level 2, 20,000 to 1 million eCommerce transactions for Level 3, and fewer than 20,000 eCommerce transactions, plus other merchants up to 1 million transactions, for Level 4. See the merchant PCI compliance guidance from Square for the stated thresholds and validation packages.
| Merchant Level | Merchant Threshold | Typical Merchant Validation Path |
|---|---|---|
| Level 1 | 6 million or more transactions annually | ROC and AoC, with assessor involvement and other required validation evidence |
| Level 2 | 1 million to 6 million transactions annually | SAQ or ROC, depending on eligibility and requester rules |
| Level 3 | 20,000 to 1 million eCommerce transactions annually | SAQ and AoC where eligible, plus required supporting validation |
| Level 4 | Fewer than 20,000 eCommerce transactions, and other merchants up to 1 million transactions annually | SAQ and AoC where eligible, with requirements set by the relevant parties |
These rows describe merchant classifications only. Do not use them to infer a service-provider level or assessment path. The PCI Security Standards Council's guidance explains that compliance-accepting entities, typically payment brands and acquirers, determine validation and reporting methods for merchants and service providers. Provider criteria can depend on service type as well as transaction volume, and a brand program may define only Levels 1 and 2. Confirm the required classification and evidence directly with each applicable payment brand and acquirer. They may also impose merchant requirements that are stricter than a volume-based assumption, such as asking for a ROC when the merchant believes an SAQ should be sufficient.
FloPay maintains PCI DSS Level 2 through an annual SAQ and quarterly network scans. The company also uses intruder.io for continuous penetration testing and attack-surface monitoring, while its current posture does not include SOC 2 or ISO 27001. That distinction matters in procurement. Don't promise a certification the provider doesn't hold, and don't accept a level designation without checking which entity, service, and validation package it covers.
How to Obtain an Attestation of Compliance
A signed AoC is the final step in a validation workflow. The first step is scope, and scope is where payment teams either protect themselves or create years of avoidable audit work.
Map every system that stores, processes, or transmits the PAN, meaning the full card number. Include connected systems that can affect the security of the cardholder data environment. Then identify what can be removed from that environment through edge tokenization, hosted payment capture, or an independent PCI-compliant vault. Raw card numbers should stay out of merchant and platform systems wherever the architecture allows it.
Build the evidence package
Once the boundary is agreed, collect the evidence an assessor needs to evaluate it:
- Define the environment: Document data flows, integrations, access paths, network boundaries, vault relationships, and production responsibilities.
- Collect control evidence: Gather policies, diagrams, configurations, scan reports, penetration-test results, access records, change records, and incident procedures.
- Review and remediate: A QSA, or Qualified Security Assessor, tests the evidence and identifies gaps. Teams should fix scope errors before polishing the final document.
- Sign and file: The ROC or SAQ supports the conclusion. The AoC is the signed declaration that confirms the assessment result.
Plan the assessment timeline with the QSA before committing to a launch or onboarding date. The schedule depends on a stable scope. A new processor integration, vault replacement, or previously undiscovered payment endpoint can force the assessor to revisit the work and derail the schedule.
Use FloPay's fraud, risk, and compliance guidance alongside your own QSA process to keep security controls connected to payment operations. The AoC should be the output of an accurate environment, not a document assembled independently from how checkout works.
Watch how FloPay connects compliance controls to payment operations
What an Attestation Does Not Cover
An AoC confirms that the assessed environment met the applicable PCI DSS requirements during the stated assessment period. It doesn't make the business breach-proof, and it doesn't certify every system the organization owns.
The boundary is the critical qualifier. An excluded subsidiary, unlisted production environment, new payment integration, or changed checkout script may sit outside the conclusion. If PAN enters an environment that the assessment excluded, the document no longer accurately describes the actual payment flow.
An AoC also doesn't validate commercial or operational properties that revenue teams care about every day:
- Processor neutrality: The document doesn't prove that saved payment methods can move between gateways.
- Availability: It doesn't guarantee uptime, routing continuity, or successful failover.
- Payment accuracy: It doesn't confirm that refunds, captures, retries, and reconciliation behave correctly.
- Non-card flows: Wallets, bank methods, and other APMs need their own operational and contractual analysis.
- Agent surfaces: AI or human-assisted payment endpoints aren't automatically covered unless they fall within the assessed scope.
The same distinction applies to stored credentials. A subscription rebill can use a token rather than a raw PAN, but the merchant still needs correct consent, stored-credential indicators, retry logic, and payment-event handling.
Read FloPay's guide to credit card on file for the commercial implications of saved payment methods. The key point is that a processor-neutral card-on-file layer can reduce gateway dependency while an AoC documents the security boundary. These are related decisions, not interchangeable promises.
Compliance evidence tells you what was assessed. Architecture determines how much damage a processor outage, integration error, or scope mistake can cause.
A platform can hold a current AoC and still create a single point of failure if every saved card and recurring payment depends on one gateway. Revenue resilience requires both defensible security controls and a payment design that gives the business more control.
Renewing and Maintaining an Attestation Year After Year
An AoC is generally treated as a 12-month compliance artifact, so annual renewal isn't optional housekeeping. The PCI DSS overview and assessment history describes the recurring validation cadence that keeps payment organizations aligned with their current obligations.
The work should run continuously, not begin when an assessor sends a calendar invitation.
A workable operating rhythm
- Scope refresh: Review payment flows, systems, vendors, processors, vaults, scripts, and ownership. Record changes before they disappear into product release history.
- Evidence collection: Keep policies, access reviews, scan results, training records, tickets, logs, and change approvals available as controls run.
- Security testing: Maintain required external scanning, internal testing, dependency checks, and remediation records on their required cadence.
- Assessment preparation: Compare the live environment with the current DSS version and the last assessment. Resolve drift before the formal review.
- Renewal and distribution: Obtain the signed AoC, file the supporting package, and share it only with authorized requesting entities under the applicable rules.
PCI DSS v4.x makes a sprint-before-audit mindset especially weak. Authentication controls, vulnerability management, security awareness, change management, payment-page scripts, and targeted risk analyses need owners and recurring evidence. The assessment should confirm an operating process, not discover that the process existed only in a spreadsheet.
Reassessment may be necessary after a material scope change, new processor integration, vault replacement, or significant incident. Ask the QSA before assuming a refreshed signature is enough. The right answer depends on what changed and whether the change affects the assessed environment or control conclusions.
Attestations in Multi-Processor and Agent-Led Payment Flows
Subscription businesses, marketplaces, and digital-product merchants rarely operate a single, static payment path. They store payment methods for rebills, add wallets and APMs, route transactions through multiple providers, and increasingly support checkout assisted by sales agents or software agents. Each choice changes the system boundary an assessor needs to understand.
A tokenized payment method can keep the raw PAN out of merchant systems, but the token lifecycle still matters. Teams need to document where tokenization happens, which provider can detokenize or use the token, how access is controlled, and how stored credentials support customer-initiated and merchant-initiated transactions. A prepaid card may approve the first charge and fail a later rebill. That is a payment recovery problem, but the supporting vault and billing controls still need accurate scope treatment.
Routing doesn't erase assessment responsibility
Multi-provider routing can support payment resilience and lower processor concentration risk. It doesn't mean every gateway integration is automatically outside scope. The integration layer, credentials, webhooks, payment events, fallback logic, and operational access still need mapping.
Agent-assisted checkout adds another layer. A human support agent or AI agent may initiate payment actions, select a saved method, trigger authentication, or pass information between systems. Those endpoints and automated decisions need ownership, logging, access control, and clear boundaries. An agent isn't a compliance shortcut.
PCI DSS v4.x also catches teams that treat scripts and authentication as implementation details. Payment-page scripts, application and API authentication, customized controls, and targeted risk analyses need evidence that matches the actual design. A processor-neutral architecture can make future routing easier, but only if the AoC and supporting scope documents describe the architecture accurately.
The commercial recommendation is direct. Keep Stripe as a processor if it works for your business, but don't make Stripe your entire payment continuity strategy. A gateway-independent vault and orchestration layer can support card-on-file portability today and create a foundation for agentic payments tomorrow, without pretending that routing removes PCI responsibilities.
Quick Reference Glossary for Attestation Terms
You shouldn't need to translate every line of an AoC before making a commercial decision. These are the terms that matter most when a merchant, acquirer, assessor, or enterprise buyer reviews the evidence.
| Acronym | Meaning |
|---|---|
| AoC | Attestation of Compliance, the signed declaration supporting a PCI DSS validation conclusion |
| SAQ | Self-Assessment Questionnaire, a structured validation path completed by an eligible merchant or service provider |
| ROC | Report on Compliance, the detailed assessment report that records how applicable PCI DSS requirements were evaluated |
| QSA | Qualified Security Assessor, an assessor organization qualified within the PCI SSC program to perform and support formal assessments |
| ASV | Approved Scanning Vendor, a PCI-recognized provider of required external vulnerability scanning |
| PAN | Primary Account Number, the full card number that defines a central part of cardholder-data scope |
| CDE | Cardholder Data Environment, the systems and processes that store, process, transmit, or can affect the security of cardholder data |
| DSS | Data Security Standard, the PCI standard that defines the applicable security requirements |
| PCI SSC | Payment Card Industry Security Standards Council, the body that publishes PCI standards and validation materials |
| Tokenization | Replacing sensitive card data with a token that can be used within defined payment flows |
| Cardholder data | Payment card information subject to applicable PCI DSS protection requirements |
| Sensitive authentication data | Authentication information that requires strict handling and may have different retention restrictions |
| Scope | The systems, people, processes, integrations, and environments included in an assessment |
| Compensating control | An alternative control used where a stated requirement can't be met directly, supported by the required analysis and documentation |
The distinction between a ROC and an AoC is especially important. The ROC explains the assessment work. The AoC is the signed conclusion that counterparties commonly request first.
Likewise, an ASV scan isn't the same as a penetration test, and neither one is the same as the AoC. Each produces different evidence. Keeping those artifacts together makes procurement reviews faster and gives your engineering team a clearer remediation list.
Practical Next Steps for Payments and Revenue Teams
Run a posture check before an acquirer or enterprise buyer asks for proof. Start by locating the current AoC, or the relevant SAQ confirmation and supporting documents, then verify four fields:
- Entity name: Confirm the assessed legal entity matches the contracting entity and the processor merchant-account records.
- DSS version: Check that the assessment uses the version accepted for the relationship and reflects the current validation position.
- Scope: Compare the document with the live card-data flow, including checkout scripts, vaults, processors, billing services, webhooks, and agent-assisted surfaces.
- Validity and signatures: Confirm the assessment dates, renewal status, declaration, signatures, and referenced appendices.
Next, draw the actual payment flow. Follow the PAN from capture to tokenization, then trace the token through storage, subscription rebilling, routing, refunds, retries, and support actions. If raw card data touches an environment excluded from the AoC, stop treating the document as a complete description of the system.
Then test the commercial dependency. Ask whether your saved payment methods are portable across supported providers, whether a processor outage would interrupt recurring revenue, and whether a new gateway integration would change the assessed scope. A vault-backed, processor-neutral card-on-file layer can give revenue and engineering teams more flexibility, but the architecture and responsibility split must be documented.
Schedule a pre-audit review against PCI DSS v4.x requirements before the formal assessment. Include authenticated access, vulnerability scanning, targeted risk analyses, payment-page scripts, dependency management, change control, and evidence ownership. Book the QSA early if your validation path requires one, and treat the AoC as a renewable commercial asset that supports onboarding, continuity, and customer trust.
FloPay provides payment orchestration, embedded checkout, and a processor-neutral card-on-file layer through Flo Vault, with tokenized payment methods designed to support routing across supported providers while keeping raw card data out of merchant systems. Review your current scope and processor dependency, then visit FloPay to explore a vault-backed approach to payment resilience and recurring revenue protection.