How PCI DSS applies to subscriptions and card-on-file billing
Consider a business that bills customers' cards every month for a membership and keeps those cards on file so each renewal can be charged without the customer re-entering data. (This is an illustrative example.) PCI DSS applies in full to every card the business stores. Storing a card for recurring charges does not move the business outside the standard, and the customer's consent does not change that. Two rules shape the design from the start: the card verification code cannot be kept for later charges, even if the customer asks for it to be remembered, and the stored primary account number (PAN) must be made unreadable wherever it rests.
The organization owns its controls. It decides how the billing platform stores card references, who can reach them, and how long they are kept. An implementation partner can configure the platform, prepare network and data-flow diagrams, and collect the evidence an assessor will sample. Only a Qualified Security Assessor (QSA) completing a Report on Compliance, or the self-assessment route the acquirer accepts, produces the Attestation of Compliance. Ask the acquirer which validation route applies before design work starts, because it determines what evidence you need to keep.
Before choosing a billing design, confirm three things with your acquirer and your billing provider: whether the provider keeps any card verification data for later authorizations, whether the stored card reference is a payment token outside the provider's token environment, and how the retention period for stored card data is set in your policy. The retention question matters because PCI DSS sets no fixed storage period, so your own legal and business justification must drive the limit. Document each answer, since assessors will ask for it.
What customer consent does not change
Many billing teams assume that a customer's written permission makes stored card data acceptable. Under PCI DSS, consent does not change what may be stored, how long it may be kept, or whether the stored data is protected. The cards below cover the misconceptions we see most often in subscription and card-on-file environments.
Customer permission to keep codes
Card verification codes may be collected before an authorization but may not be kept afterward. PCI SSC FAQ 1280 says they are not needed for card-on-file or recurring charges such as a monthly membership, and they may not be stored for those purposes even with the customer's permission. Check that your checkout deletes the code after the first authorization and that no retry queue, log or support tool keeps it.
Vaults or apps holding codes for consumers
A password manager, browser or app that saves card codes so a consumer can pay faster is storing those codes on the consumer's behalf. PCI SSC FAQ 1574 says organizations whose software runs on consumer devices may not store card verification codes for future purchases, even when the consumer asks. The FAQ does not cover consumers entering their own data, so confirm which side of that line your wallet or autofill feature sits on.
Full PAN kept for convenience
Keeping the full card number so that renewals and plan changes run without a token provider is still stored account data. Requirement 3.5.1 lists the accepted ways to render stored PAN unreadable: strong one-way hashes of the entire PAN, truncation, index tokens, or strong cryptography with key management. Ask which of these your billing system uses, and confirm that every copy, including backups and exports, follows the same method.
Indefinite retention of subscriber data
PCI DSS sets no minimum or maximum period for storing cardholder data (PCI SSC FAQ 1318). The limit comes from your own retention policy under Requirement 3, which must restrict storage to what legal, regulatory or business purposes require. A cancelled subscriber's card should have a documented end date, and the retention policy should name who approves exceptions and how deletion is verified.
Tokens treated as out of scope by default
An EMVCo Payment Token used under the EMV Payment Tokenisation Specification and outside the token service provider's data environment is not account data for merchants and acquirers (PCI SSC FAQ 1326). That status depends on the design. If the system that issues or stores the token also handles PAN, or connects to systems that do, it stays in scope. Document where the token is created, where the PAN is held, and which systems can reach both.
Making stored PAN unreadable for recurring charges
Requirement 3.5.1 of PCI DSS v4.0.1 lists the ways a stored primary account number (PAN) can be made unreadable. The four accepted methods are a one-way hash of the entire PAN based on strong cryptography, truncation, index tokens, and strong cryptography with key-management processes. For a subscription business, the practical question is which of these still lets you charge the card next month. A recurring billing system usually needs a reference it can reverse into a live card number at the moment of each charge, so strong cryptography with key management or a payment token is the typical path. A one-way hash cannot be reversed to charge a card, and truncation leaves only part of the number, so neither works alone for renewals.
Hashing and truncation still have narrow uses. FAQ 1089 explains how hashing a PAN affects scope, and FAQ 1308 covers the risks of correlating hashed or truncated PANs across datasets, which can let someone rebuild the original number. Before relying on either method, confirm with your assessor whether the design meets 3.5.1 and whether the hash or truncated value is still in scope. If your team plans to use an index token, confirm who holds the mapping between the index and the PAN, and where that mapping is stored. Token vaults, key stores and the systems that read them are part of the design the assessor will examine.
Write down the chosen method and the reason for it in your data-flow documentation and key-management records before the assessor visits. Ask your payment provider or token service provider which PCI DSS responsibilities they assume and which remain yours. The organization owns the decision and the evidence, and only the assessor can confirm that the chosen method satisfies the requirement. Make that confirmation part of your readiness plan, including the key-rotation procedures, access restrictions on decryption and the logs that show who used them.
How payment tokens change PCI DSS scope
A payment token defined and used under the EMV Payment Tokenisation Specification is not account data when it is used outside the token service provider's token data environment. PCI SSC FAQ 1326 explains that merchants and acquirers can treat such a token as out of PCI DSS scope for that purpose. The scope question then moves to your own systems: the token has to be stored, passed and logged in ways that never bring PAN into your environment.
- Token-only storage: Your billing database, logs and support tools hold the token and never the PAN, so they are not account data stores.
- Shared systems: If the same application, database or log pipeline also handles PAN for another payment flow, that shared component stays in scope.
- Connected systems: Any system that connects to a PAN-bearing system stays in scope, even if it only reads tokens.
- Token service boundaries: Confirm with the token service provider where its token data environment begins and ends, and whether detokenization is possible from your side.
Before relying on this approach, ask your acquirer or QSA to confirm the scoping in writing for your architecture.
A card vault that you operate stores PAN on your side and returns a reference, or token, for later charges. The vault is account data storage, so it sits inside the cardholder data environment and must meet the storage, encryption, key management and access requirements that apply to any PAN store. Your token is only a reference, and its value is what keeps the vault in scope.
- Full scope for the vault: The vault, its databases, backups and key stores are assessed as account data storage.
- Reference tokens do not reduce that scope: A reference generated by your own vault is not a provider-issued payment token, so the vault remains in scope.
- Encryption and keys: PAN must be rendered unreadable wherever it is stored, with key management controls for the keys that protect it.
- Access and logging: Only defined roles can access the vault, and access must be logged and reviewed.
- Upstream and downstream systems: Billing, reporting and support systems that receive PAN or can retrieve it are also in scope.
Ask the team whether the vault is needed at all, since a provider-issued token may remove most of this scope.
Many subscription platforms run both models: a provider token for most charges and a local PAN store for a legacy customer base, failover, or a second processor. Scope is then set by the most sensitive path, not the average one. Any component that can see both a token and PAN, or that can convert between them, is likely to be in scope for the full set of requirements.
- Dual paths: If a subscription job can call a local PAN store as a fallback, the job and its credentials are in scope.
- Mapping tables: A table that links your internal customer IDs to provider tokens is account-linked data, so confirm with the assessor how it is classified and protected.
- Migration periods: While cards move from a local vault to tokens, both stores are in scope until PAN is removed and the removal is verified.
- Shared logs and analytics: Data pipelines that copy both forms into one warehouse widen scope to that warehouse.
- Reconciliation exports: Files sent to finance or a third party must be checked for PAN.
Map every data flow before deciding the hybrid scope, and confirm the classification with your QSA or acquirer.
How a recurring-billing PCI DSS assessment runs
The sequence moves from drawing the cardholder data environment around billing, renewal and portal systems to a signed Attestation of Compliance. Each phase produces a document or check the next phase depends on, so the assessor can trace every stored card to a tested control.
Define the cardholder data environment
Your team lists every system that stores, processes or transmits card data for recurring charges: the billing platform, renewal and dunning jobs, the customer portal, payment gateway connectors, databases, backups, logs, support tools and any vendor that holds stored credentials. Include the systems that could affect their security. The output is a scoping document with a data-flow diagram showing where each card number and token enters, moves and rests. You know it is done when someone outside the billing team can trace a card from signup to the last renewal charge without finding an unlisted system.
Choose the SAQ or ROC with the acquirer
Confirm with your acquirer or the payment brands which validation level applies to your transaction volume and channel, and whether a Self-Assessment Questionnaire or a Report on Compliance is required. Ask whether the acquirer expects a service provider SAQ or a full assessment for the billing platform. Record the answer in writing. The output is a validation decision that names the form, the assessor type and the due date set by the acquirer, so the rest of the work targets the correct template.
Remediate stored data and codes
Find every location where card verification codes or full card numbers are kept after authorization, including retry queues, logs, support screenshots, webhook payloads and exported reports. Delete card verification codes and do not keep them for later recurring charges, even with customer consent. Render any stored PAN unreadable using an accepted method under Requirement 3.5.1, and set a retention rule that limits storage to what legal, regulatory or business purposes require. The output is a remediation log with each finding, the fix and the date verified. You know it is done when a fresh search of the environment finds no retained codes and no readable PAN.
Confirm tokens sit outside card data
If the billing provider uses payment tokens, document how each token is issued, where it is stored and whether the token service provider keeps the token in its own data environment. Test whether any system can convert the token back to a PAN or connects to a system that still holds one. Confirm that the token meets the conditions for being outside account data. The output is a token justification memo with the architecture evidence. You know it is done when the memo shows no path from token to PAN inside your environment, or when those systems are placed back in scope.
Gather evidence for each requirement
Collect the evidence that shows each in-scope control operates: configuration exports, access review records, log samples, vulnerability scan reports, change tickets, policy documents, retention settings and vendor responsibility matrices. Ask the billing vendor for its own attestation and the matching responsibility split for each requirement. The output is an evidence index that maps each requirement to the artifact, the owner and the date it was produced. You know it is done when every control in scope has at least one artifact an assessor can sample without help from the team.
Run assessor testing
The assessor, either a Qualified Security Assessor for a ROC or the party your acquirer accepts for an SAQ, interviews staff, inspects configurations, samples records and may test the billing environment directly. Expect questions on how renewal jobs handle codes, who can view stored tokens and how the portal prevents card data from reaching logs. Respond with the evidence index and track each open question to closure. The output is a set of findings or a clean result for each requirement. You know it is done when the assessor has no remaining open items for the scope.
Sign the Attestation of Compliance
Once the findings are closed, the authorized officer of your organization reviews the completed template and signs the Attestation of Compliance, and the assessor or QSA signs where the template requires it. The attestation records the scope, the requirements tested and the result. Submit it to the acquirer and any other party that asks for it. The output is a signed AOC with the supporting ROC or SAQ. You know it is done when the acquirer confirms receipt. A certificate or logo does not replace this document.
What to verify before the assessor arrives
Card-on-file billing creates stored account data in more places than most teams expect. The checks below follow the data from the first card save through renewals, retries and reporting, so you can find stray PAN and retained codes before an assessor does.
Inventory every PAN location
List every database table, application log, backup, data warehouse extract, support export and message queue that holds a primary account number. Subscription platforms often copy card references into billing history and analytics tables that nobody flagged as cardholder data. For each location, record the owner, the purpose and whether the PAN is stored in full, masked or tokenized. Your inventory should match what the data-flow diagram shows.
Confirm code deletion across systems
Search for stored card verification codes in databases, retry queues, cached authorization payloads, webhook archives and debug logs. Only a search that covers every system can show that codes are gone after the first authorization. Any retained code is a finding, even when it is encrypted or the customer agreed to keep it. If a vendor says it can still retrieve codes for later charges, ask for the assessment that confirms they are not stored in any form.
Document the retention schedule
Write down how long each card-related record is kept, which law or business reason supports that period and what triggers deletion. PCI DSS sets no fixed storage period, so the schedule must come from your legal, regulatory and business needs. Check that canceled subscriptions, expired cards and failed-payment records follow the same rules. Confirm that the scheduled deletion jobs have run and that you can show the logs.
Test the rendering method and key custody
Identify how each stored PAN is made unreadable, whether by truncation, index token, one-way hash or strong cryptography with key management. Confirm who can access the encryption keys, where they are stored and how they rotate. Test that a database dump, backup restore or staging copy does not reveal readable PAN. Hashes of the full PAN need their own review because they can be correlated with other data.
Map token references to PAN
Where you use a payment token, confirm that the token is issued and used under the token provider's rules and that your systems never hold the PAN behind it. Check the mapping table or vault that links your customer records to tokens, and who can query it. If a system can reach the PAN through a token lookup, it is still in scope. Ask your processor for written confirmation of the token scope.
Review renewal and dunning messages
Pull a sample of renewal reminders, failed-payment notices, receipts and monthly statements, and search them for full card numbers, expiry dates and partial values that could be combined. Include PDF invoices, email templates and in-app notifications. Messages sent by third-party marketing or support tools are often missed. Remove any PAN found, then trace how it got there so the template or export is fixed.
Who owns what in a card-on-file program
This table shows who does what across six areas of a card-on-file program: the organization, its implementation partner, and the QSA or assessor. Read each row as a question to answer before the assessment starts, since gaps usually appear where no one has been named as the owner. The main takeaway is that the partner can build and document controls, but the assessor tests them and only the organization signs its Attestation of Compliance.
| Area | Organization | Implementation partner | QSA or assessor |
|---|---|---|---|
| Code handling | Decides whether card verification codes are collected at all and confirms no retry, stored or replay path exists | Configures checkout and token flows so codes are not written to databases, logs or queues | Tests code paths and logs, and assesses any service claiming to remove codes for later use |
| Data retention policy | Sets retention periods for stored card data and subscription records, tied to legal and business need | Implements scheduled purging jobs and documents where card data lives | Checks the written policy against actual stored data and deletion evidence |
| Rendering and key management | Owns the chosen method for making stored PAN unreadable and the key custodians and procedures | Builds encryption, tokenization or truncation components and key handling as specified | Reviews the design, key lifecycle records and whether stored PAN is unreadable in practice |
| Token vendor oversight | Holds the contract, reviews the vendor's PCI DSS evidence and tracks which systems still see PAN | Connects the vendor's tokens to the application and maps data flows | Confirms tokens sit outside the vendor's token data environment and that no PAN path remains |
| Testing | Commissions and accepts scanning, penetration testing and change review on in-scope systems | Runs or coordinates scans, fixes findings and retains the results | Reviews test results and samples evidence, and may perform its own testing |
| Attestation of Compliance | Signs the AOC and is accountable for the accuracy of every statement in it | Supplies evidence and drafts documentation on request | Completes the Report on Compliance or validation form and issues the report to the organization |
Questions buyers ask about recurring billing and PCI DSS
Can we keep card verification codes so we can charge monthly memberships?
No. Card verification codes may be collected before a purchase is authorized but not kept afterwards, and they are not needed for card-on-file or recurring charges such as a monthly membership. PCI SSC FAQ 1280 says they may not be stored for those purposes even with the customer's permission. The practical driver is design: the billing flow has to authorize the first charge with the code, then rely on the stored credential or token for later charges. Ask your engineers to confirm that no table, log, cache, backup or vendor system holds the code after authorization. If a vendor claims it can remove codes but still retrieve them for later authorizations, PCI SSC FAQ 1280 says a QSA or ISA must assess that claim.
Does customer consent allow us to store card verification codes for future charges?
No. Customer permission does not change the rule. PCI SSC FAQ 1280 states that card verification codes may not be stored for card-on-file or recurring purposes even when the customer agrees. The same position applies to apps, browsers and password vaults running on consumer devices: PCI SSC FAQ 1574 says those organizations may not store card verification codes on consumers' behalf for future purchases, even on request. That FAQ does not cover consumers entering their own data or issuing functions. Consent still matters for other data you keep, such as stored PAN for a legitimate business purpose, but it does not remove any PCI DSS obligation.
Can we use payment tokens to take the stored card data out of scope?
Partly, and only when the token is defined and used correctly. An EMVCo Payment Token used under the EMV Payment Tokenisation Specification, and held outside the token service provider's token data environment, is not account data and is out of PCI DSS scope for merchants and acquirers, according to PCI SSC FAQ 1326. The scope reduction is lost if any system still handles the PAN or connects to systems that do. Subscription platforms often keep the PAN with a processor, store tokens in the application database, and log card details during failed charges. Map every path where a PAN appears before assuming the token removes a system from scope, and confirm the token model with your acquirer and assessor.
How long can we keep stored cardholder data for recurring billing?
PCI DSS does not set a fixed period. PCI SSC FAQ 1318 states that the standard sets no minimum or maximum time for storing cardholder data. Instead, your retention policy under requirement 3.2.1 must limit storage to what legal, regulatory or business purposes require. For subscriptions, the drivers are the active contract, the refund and dispute window, tax and accounting rules, and any card-network rules that govern stored credentials. Write a retention schedule per data element, including the PAN, the expiry date, tokens and logs, and delete or tokenize data when the purpose ends. Ask your legal and finance teams to confirm the periods that apply in each market you serve.
Which SAQ or ROC applies to a subscription business that stores cards?
It depends on how your business stores, processes and transmits card data, and on your annual card volume and the validation level your acquirer or payment brand assigns. A business that only redirects customers to a hosted payment page and stores no PAN may fit a short SAQ. A business that stores PAN in its own systems, even encrypted, generally needs a broader questionnaire. Some subscription platforms that handle card data for other merchants fall under service provider duties and may need a Report on Compliance from a Qualified Security Assessor. The payment brands decide who must validate and how, so confirm the level and the required form with your acquirer before choosing a route.
What does the work need from our internal team?
Your team owns the decisions and the evidence, even when an outside provider does the engineering. Expect to name an accountable owner for PCI DSS, supply architecture and data-flow diagrams, give engineers access to billing, database, logging and vendor configurations, and approve retention rules and token design. Finance and legal must confirm retention periods, and support staff need a process for card updates and failed payments that does not expose codes. Ask any provider to set out in writing which tasks it performs, which your staff keep, and which sit with the assessor. Those lines should appear in the fixed scope before work starts.
Can a partner handle the recurring billing work without a QSA or ISA?
A partner can prepare the work, but it cannot validate it. An implementation partner such as DeployOpen can plan, implement, harden and document self-hosted platforms in your own infrastructure, and prepare the systems and evidence. Only an independent assessor issues the Report on Compliance or the Attestation of Compliance, and PCI SSC FAQ 1220 confirms that certificates are not recognized as validation. Where a token or code-removal claim needs confirmation, PCI SSC FAQ 1280 requires a QSA or ISA to assess it. Keep consulting and assessment separate where possible, and ask any assessor to confirm its independence rules in writing.
Where recurring billing projects usually stall
Most recurring billing projects stall on card verification codes that turn up where nobody planned for them. A team may remove the code field from the stored-card form, yet the value still appears in application logs, payment gateway debug traces, webhook payloads or support tickets where agents pasted a card to re-run a failed charge. Before the project can close, someone needs to search every log store, ticketing tool and queue for the three-digit or four-digit code and confirm that the retention settings on each one do not keep it. Under PCI SSC FAQ 1280, a service that claims to drop these codes but can still retrieve them for later authorizations must be assessed by a QSA or ISA, so a finding of stored codes can turn a configuration fix into an assessment question. Confirm the search scope with your assessor before you start, not after.
The second common stall is a legacy billing engine that cannot change how it renders the stored account number. Older platforms often print or display the full PAN on invoices, receipts, customer portals and internal screens, and they may hold the number in a database column that other batch jobs read directly. Requirement 3.5.1 accepts several ways to make stored PAN unreadable, including truncation, index tokens and strong cryptography with key management, but the choice depends on whether the engine can apply it to every consumer of that field. If the vendor cannot deliver a change to the rendering layer, the project may need a wrapper service or a tokenization step in front of the engine. Ask the vendor in writing which rendering and storage methods the product supports, and which of them it has tested against your current version.
The third stall is undocumented token dependencies. Many billing stacks pass a gateway token, a network token or a provider-specific reference through several systems, and only one of those systems knows which tokens are still valid for future charges. An EMVCo Payment Token used under the EMV Payment Tokenisation Specification can sit outside PCI DSS scope for a merchant, but under PCI SSC FAQ 1326 any system that also handles PAN, or connects to systems that do, stays in scope. Before a migration, map which services read, write or reconcile each token type, and record who owns the reconciliation job that runs at month end. A missing dependency usually surfaces when a renewal fails, so test failed-payment and card-update flows in the mapped environment before you retire the old path.
How DeployOpen prepares recurring billing systems and evidence
DeployOpen works on the self-hosted and open-source parts of a recurring billing stack inside your own infrastructure. We scope the systems that store, tokenize or handle card-on-file data, build the controls around them, and document the evidence your qualified assessor will review. DeployOpen prepares systems and evidence but does not issue validation reports or attestations.
How we scope
- We map every system where a stored card, token or billing record could appear, including retry and dunning services.
- The written scope states which card verification code handling checks are included and how they will be tested.
- We confirm with your acquirer and assessor which data elements the billing platform keeps and for how long.
How we build
- We configure the billing platform so card verification codes are never written to databases, logs or queues after authorization.
- We render any stored primary account number unreadable using an approved method and document the key management around it.
- We integrate the payment token service and restrict PAN access to the systems that need it for charges.
How we hand over
- You receive configuration records, data-flow diagrams, retention settings and test results mapped to each relevant requirement.
- Runbooks cover token lifecycle, card updater events, key rotation and the process for deleting expired stored data.
- Deliverables are agreed in writing before work starts, and your assessor or QSA reviews the evidence directly.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- Retainers can cover billing platform upgrades, configuration drift checks and periodic review of retention and token settings.
- Any change to how cards are stored or retried should be scoped in writing before it reaches production.
Sources and further reading
- PCI SSC FAQ 1280: card verification codes for card-on-file or recurring transactions ↗
- PCI SSC FAQ 1574: card verification codes and consumer-device software ↗
- PCI SSC FAQ 1318: maximum period cardholder data can be stored ↗
- PCI SSC FAQ 1326: EMVCo Payment Tokens ↗
- PCI DSS v4.0 Self-Assessment Questionnaire D for Service Providers ↗
