PCI DSS Compliance for Subscription Businesses: Scope, Recurring Billing, and SAQ Choices

Subscription businesses do not have a separate version of PCI DSS, but recurring billing creates payment flows that are easy to misunderstand. The important question is not whether you charge customers monthly, annually, or whenever usage crosses a threshold. It is where payment account data travels, which systems can affect its security, and whether your checkout, billing platform, customer portal, support tools, integrations, and recurring-payment process bring your environment into PCI DSS scope.

Copy the payment-event review record to map signup, renewals, retries and card updates.

For many subscription companies, the safest and operationally simplest model is to let a PCI DSS compliant payment provider collect and vault card details, while the subscription application stores only provider-issued customer and payment-method identifiers. That architecture can dramatically reduce PCI exposure, but outsourcing payment processing does not make PCI DSS disappear. The PCI Security Standards Council specifically states that merchants remain responsible for validating compliance, checking relevant service-provider compliance, maintaining appropriate agreements, and understanding shared responsibilities even when payment processing is outsourced.

As of September 2026, PCI DSS v4.0.1 is the current PCI DSS version available through the PCI Security Standards Council Document Library. The future-dated v4.x requirements became effective on March 31, 2025, so a compliance plan based on the old transition period is now historical rather than current guidance.

Start With the Payment Flow, Not the Subscription Platform

A common mistake is to begin PCI planning with a question such as, “We use Stripe, Adyen, Braintree, Worldpay, or another processor, so are we PCI compliant?” The provider name alone cannot answer that question.

Two subscription companies can use the same processor while having very different PCI scope. One redirects customers to a payment page hosted entirely by the processor. Another renders its own card fields and sends card numbers to the processor through JavaScript. A third collects card details through its backend before calling the provider API. Those implementations may look nearly identical to a customer, but they create very different security boundaries.

The table is a scoping guide, not a substitute for the eligibility criteria in the applicable Self-Assessment Questionnaire. PCI SSC advises merchants to confirm that they meet all criteria for a particular SAQ and to confirm validation expectations with the organization receiving their compliance submission, such as their acquirer.

Why Subscription Billing Creates More Than One Payment Event

A one-time checkout can be comparatively simple: the customer enters a credential, the payment is authorized, and the order is completed. A subscription creates a longer payment lifecycle.

• Initial signup: the customer provides a payment credential and agrees to future billing.
• Credential vaulting: the processor or another payment service stores the credential or creates a token for future use.
• Recurring charges: future payments may be initiated without the customer entering the card again.
• Dunning and retries: failed charges may trigger scheduled retries, account restrictions, emails, or another payment attempt.
• Card updates: customers may replace expired cards, and some payment ecosystems provide account-updater services.
• Plan changes: upgrades, downgrades, prorations, usage charges, and add-ons can create additional billing events.
• Cancellation and reactivation: the system must stop or restart future transactions in accordance with the customer’s authorization and applicable payment rules.
• Webhooks and APIs: payment status changes often move from the processor into the subscription application through machine-to-machine interfaces.

This is why PCI scoping should follow the entire card-payment lifecycle rather than stopping at the checkout screen. If you are diagramming subscription APIs, webhooks, administrative endpoints, and third-party callbacks at the same time, the API security checklist for SaaS founders provides a useful companion framework for inventorying endpoints, authentication, authorization, logging, webhook verification, and integration failure paths.

Do Not Store CVV for the Next Subscription Charge

This rule deserves its own section because recurring billing makes the temptation obvious: if a customer will be charged next month, why not keep every credential needed for another authorization?

Do not retain the card verification code after authorization. PCI SSC states that card verification values such as CVV2, CVC2, CID, and similar values are sensitive authentication data and cannot be stored after authorization, including for card-on-file or recurring payments. Encryption does not turn post-authorization CVV storage into an acceptable practice.

The Council’s guidance on card verification codes for recurring transactions specifically notes that these codes are not needed to process future card-on-file or recurring transactions.

That prohibition should influence more than the billing database. Check application logs, exception traces, analytics payloads, customer-support tickets, CRM fields, session recordings, debugging tools, screenshots, exports, queues, backups, and observability platforms. A billing database that correctly deletes CVV does not help if an error logger quietly copied the original checkout payload into a long-lived monitoring account.

Tokenization Helps, but “We Store Only Tokens” Is Not the End of the Analysis

Most subscription businesses should have a strong architectural reason before storing raw primary account numbers themselves. A processor-hosted vault can instead return a customer identifier, payment-method identifier, or another token that the application references when requesting future charges.

That can shrink the number of systems exposed to actual cardholder data. It does not automatically make every connected system out of scope.

PCI SSC’s tokenization guidance explains that tokenization can reduce the amount of cardholder data in a merchant environment and potentially reduce assessment scope. However, systems that perform tokenization or detokenization, can retrieve the original PAN, or remain connected to an in-scope cardholder data environment may still be in scope.

A useful design objective is therefore not simply “use tokens.” It is:

• keep raw PAN away from merchant application servers wherever practical;
• prevent ordinary application systems from converting a token back into PAN;
• separate payment-provider credentials from general application credentials;
• restrict who can change payment integrations or retrieve sensitive payment information;
• ensure logs, exports, support tools, analytics, and data warehouses receive only the payment information they actually need.

Choosing Between SAQ A, SAQ A-EP, and a Broader Assessment

The correct Self-Assessment Questionnaire is determined by the payment environment and the questionnaire’s eligibility criteria, not by whether the company calls itself SaaS, subscription commerce, membership software, or a startup.

SAQ A

SAQ A is intended for certain card-not-present merchants that outsource payment account data functions to PCI DSS compliant third parties and do not electronically store, process, or transmit account data on their own systems or premises.

For e-commerce implementations, payment-page design matters. PCI SSC explains that all payment-page elements involved in collecting payment account data must originate from the compliant third-party provider for the merchant to fit the relevant SAQ A model.

There is also an important current e-commerce wrinkle. The revised SAQ A introduced an eligibility condition requiring an e-commerce merchant using an embedded third-party payment form to confirm that its site is not susceptible to script attacks that could affect the e-commerce system. PCI SSC’s SAQ A script-attack guidance explains that this particular condition applies to implementations with an embedded TPSP payment page or form and not in the same way to simple redirects or fully outsourced payment functions.

SAQ A-EP

SAQ A-EP becomes relevant to certain e-commerce merchants whose websites can affect the security of the payment transaction even though those websites do not directly receive account data. A common example is a merchant-generated payment page that posts card data directly from the customer’s browser to the payment processor.

That distinction matters because a compromised merchant page could alter the payment form, change its destination, load malicious JavaScript, or otherwise interfere with the payment experience before the processor ever sees the transaction.

When the environment becomes broader

If your own server receives card data, your staff manually copy card numbers between systems, raw PAN appears in queues or databases, or several payment channels are mixed together, do not assume an abbreviated e-commerce SAQ applies. Map the full environment and confirm the appropriate validation path with your acquirer, payment provider, or a qualified PCI professional where necessary.

The financial difference between a tightly outsourced environment and a custom card-processing environment can also be substantial. The related PCI DSS compliance cost guide for small businesses explains why architecture, scanning, remediation, assessment support, security tooling, and internal labor often matter more than company size alone.

Outsourced Checkout Does Not Mean an Unprotected Website

The modern e-commerce attack surface has pushed more attention toward the merchant webpage itself. Attackers do not necessarily need access to the payment processor if they can compromise the storefront and redirect a customer, inject a skimming script, replace a payment component, or alter browser-side behavior.

PCI DSS v4.0.1 includes e-commerce controls addressing payment-page scripts and unauthorized changes. Requirements 6.4.3 and 11.6.1 became effective on March 31, 2025. PCI SSC later removed those individual requirements from the revised SAQ A reporting form while adding the script-attack eligibility condition described above. That reporting change does not mean browser-side payment security stopped mattering.

There is another detail that small outsourced merchants can easily miss: PCI SSC clarified in June 2026 that PCI DSS v4.x SAQ A includes external vulnerability scanning requirements for merchant e-commerce webpages, including websites that redirect transactions to a third-party service provider or contain an embedded provider iframe. The Council’s current SAQ A ASV scanning FAQ explains that scans used to satisfy the relevant PCI requirement must be performed using an approved scanning vendor solution.

In other words, outsourcing the fields can reduce exposure to card data, but your storefront cannot be treated as decorative scenery. It may still be part of the path an attacker would use to compromise a payment.

Treat the Payment Processor as a Shared-Responsibility Relationship

A provider’s PCI status is important, but “our processor is PCI compliant” is not a complete third-party risk program.

PCI SSC states that merchants outsourcing payment processing remain responsible for confirming that the provider is PCI DSS compliant for the services being used, maintaining appropriate written agreements, monitoring provider compliance status at least annually, and understanding which PCI responsibilities belong to each party.

For each payment-related provider, maintain evidence that answers four questions:

• What service are we actually using? Hosted checkout, token vault, recurring billing, fraud tooling, account updater, gateway, customer portal, or something else?
• Does the provider’s PCI validation cover that service? A logo or generic compliance statement is weaker evidence than documentation tied to the relevant service and entity.
• What does the provider secure for us? Payment fields, card vault, infrastructure, scanning, authentication, logging, or only a subset?
• What remains ours? Website security, access management, integration configuration, API secrets, scripts, incident response, provider monitoring, and validation frequently remain shared or merchant-side responsibilities.

If the commercial contract is vague about security ownership, the SaaS security addendum checklist provides a useful method for reviewing data scope, incident notification, subprocessors, security responsibilities, deletion, audit evidence, and contractual gaps. For a repeatable supplier-review process, the vendor security questionnaire template can help turn “they seem secure” into documented evidence and follow-up questions.

Recurring Payments Also Have Card-Network Rules

PCI DSS protects payment account data. It is not the complete rulebook for creating a subscription agreement or initiating recurring transactions.

Card networks separately maintain stored-credential and recurring-transaction rules. For example, the current Visa Core Rules and Visa Product and Service Rules include requirements concerning stored credentials and future transactions, including disclosures about how the credential will be used, transaction amount or how it will be determined, timing or frequency where applicable, and relevant subscription terms.

This distinction matters operationally. Your subscription system may need to distinguish the customer’s initial transaction from later merchant-initiated recurring transactions and send the correct transaction information through the gateway or acquirer. Do not invent your own transaction classification from a checkbox in the billing UI. Confirm the integration behavior and recurring-payment requirements with the processor or acquirer supporting your account.

UK Subscription Businesses Need to Separate PCI DSS From SCA

PCI DSS is an industry security standard used internationally, so the fundamental PCI scoping exercise does not become a different standard merely because the merchant is in the United Kingdom.

UK merchants do, however, operate alongside separate payment-authentication requirements. The FCA Handbook rules on Strong Customer Authentication state that SCA applies when a payer creates, amends, or first initiates a series of recurring transactions with the same amount and same payee, while subsequent transactions in that series may be initiated without SCA subject to the applicable conditions.

The practical lesson is simple: passing a PCI assessment does not prove that a UK recurring-payment flow has been implemented correctly for SCA, and implementing SCA does not prove PCI DSS compliance. Treat payment-data security, customer authorization, card-network recurring-payment rules, and UK regulatory authentication requirements as connected but distinct workstreams.

A Practical PCI DSS Workflow for a Subscription Company

Instead of beginning with a questionnaire and trying to reverse-engineer the architecture from the answers, use the architecture to determine the validation path.

1. Draw the payment-data flow

Document the initial checkout, card update flow, recurring charge, retry process, customer billing portal, refund process, support workflow, webhooks, analytics, logs, backups, and administrative tools.

For every step, identify whether raw PAN, truncated PAN, a payment token, or no payment credential is present.

2. Find accidental card-data storage

Search more broadly than the production billing database. Inspect logs, debug traces, support systems, CRM notes, exports, analytics, recordings, temporary files, queues, backups, and development environments.

If staff can paste card details into a ticket or chat field, that workflow deserves attention even if the official checkout never exposes card data to your servers.

3. Identify every third party that can affect payment security

Include the gateway, processor, hosted checkout provider, billing platform, cloud environment, security providers, managed service providers, and other parties whose service can affect the security of the payment environment.

Then document PCI status, responsibility boundaries, renewal or review dates, and the evidence you rely on.

4. Confirm your SAQ or assessment path

Compare the real architecture with the current eligibility criteria rather than assuming last year’s questionnaire still applies. If the architecture does not cleanly match the criteria, ask your acquirer or a qualified PCI specialist before filing the wrong form.

5. Secure the merchant webpage and integrations

Control changes to checkout code, minimize unnecessary scripts, maintain vulnerability management, protect administrative access, secure API credentials, validate payment webhooks, and monitor the parts of the site that could alter the payment path.

6. Keep compliance evidence alive

PCI compliance becomes fragile when all evidence is assembled once a year by archaeological expedition. Keep provider attestations, responsibility documentation, scan evidence where applicable, access reviews, system inventories, incident procedures, change records, and validation materials attached to named owners throughout the year.

The Subscription Features Most Likely to Change PCI Scope

A subscription product can remain stable for months and then quietly acquire a broader payment environment after one feature request. Revisit PCI scope before introducing changes such as:

• replacing a hosted payment page with custom card fields;
• moving payment collection into a mobile application;
• adding telephone payments handled by support staff;
• adding an internal “charge customer” administration tool;
• sending payment details through a new CRM, analytics, or fraud platform;
• migrating from one token vault to another;
• adding a marketplace or connected-account payment model;
• allowing employees to retrieve full card numbers;
• adding new JavaScript to checkout or changing how the payment iframe is embedded;
• acquiring another subscription business with a different payment stack.

The useful governance question for every billing change is not merely, “Will payments still work?” Add a second gate: “Does this change alter where account data flows or which systems can affect payment security?”

When to Bring in a PCI Specialist

A small subscription business using a straightforward hosted checkout may be able to manage much of its compliance work internally with support from its processor and acquirer. Specialist help becomes more useful when the boundary is genuinely unclear.

Consider involving a Qualified Security Assessor or another appropriately qualified PCI professional when raw PAN appears in merchant systems, several payment channels are mixed together, you cannot determine which SAQ applies, segmentation is being used to reduce scope, an enterprise customer requires more formal assurance, a major payment architecture migration is planned, or an incident may have exposed cardholder data.

The reason to hire help is not to purchase a ceremonial compliance stamp. It is to resolve a material scoping, control, evidence, or assessment question that your team cannot responsibly answer on its own.

PCI DSS Compliance Checklist for Subscription Businesses

• Map the initial transaction and every later recurring-payment flow.
• Confirm whether your systems ever receive or store PAN.
• Verify that CVV and other prohibited sensitive authentication data are not retained after authorization.
• Use processor-hosted collection and tokenization where it fits the product architecture.
• Check the current eligibility criteria before selecting SAQ A, SAQ A-EP, or another validation route.
• Review scripts and changes that can affect the e-commerce payment path.
• Confirm whether ASV scanning applies to your current validation path.
• Review payment service providers and their compliance evidence at the required cadence.
• Document written responsibility boundaries with relevant third parties.
• Protect payment-provider API keys and authenticate webhooks.
• Keep payment data out of logs, tickets, analytics, recordings, and debugging systems unless there is a validated need and appropriate protection.
• Reassess scope whenever checkout or billing architecture changes.
• Confirm recurring-payment rules separately from PCI DSS, including applicable card-network requirements and UK SCA rules where relevant.

Review date / event / owner:
Billing platform, gateway and integration version:
Entry page or initiating system / actor:
Card-entry fields hosted by / submission destination:
Provider-issued identifiers used / retrieval permissions:
Application, webhook, queue, support and logging path:
Expected data at each system / observed test result:
Provider documentation or confirmation reference:
Account-data exposure or unverified behavior:
Who can initiate or alter this event / access-review reference:
Provider/acquirer confirmation needed for transaction handling:
PCI validation path confirmed by / reference:
Required fix or follow-up / owner / due date:
Next review trigger:

Frequently Asked Questions

If Stripe or another processor stores our cards, are we automatically PCI compliant?

No. Using a PCI DSS compliant processor can substantially reduce the amount of payment data your systems handle, but merchants still have PCI responsibilities. Your integration method, website, third-party relationships, data flows, and validation requirements still need to be assessed.

Can a subscription company store CVV so it can retry a failed payment later?

No. PCI SSC prohibits storage of card verification codes after authorization, including for future card-on-file and recurring transactions.

Does storing a payment token instead of the card number remove PCI scope?

It can reduce scope, but the result depends on the implementation. A system may remain in scope if it can retrieve PAN, participates in tokenization or detokenization, stores other account data, or remains connected to an in-scope environment.

Do small subscription businesses need PCI DSS?

Business size alone does not create an exemption. PCI DSS applies based on involvement with payment account data and payment processing. What can differ is the validation method required by the merchant’s acquirer or payment brand program.

Is PCI DSS the same as SOC 2?

No. PCI DSS is specifically concerned with payment account data and the systems that store, process, transmit, or can affect its security. SOC 2 is a different assurance framework used for controls at service organizations. A subscription company may have obligations or customer expectations involving both, but one does not substitute for the other.

The Best PCI Architecture Usually Removes Card Data Before Adding Controls Around It

Subscription businesses naturally accumulate complexity: retries, upgrades, credits, card updates, customer portals, webhooks, finance tooling, support workflows, and increasingly elaborate billing logic. PCI work becomes expensive when all of that complexity is allowed to grow around raw payment credentials.

The cleaner strategy is usually architectural. Keep card collection and storage inside an appropriately validated payment service wherever practical. Store tokens rather than PAN in the subscription application. Prevent CVV retention completely. Minimize the scripts and systems capable of changing the payment path. Verify provider responsibilities instead of assuming them. Then select the current PCI validation method that actually matches the resulting environment.

That approach does not make PCI DSS vanish. It turns the problem from “secure card data everywhere” into the much more manageable task of proving exactly where payment risk exists, who owns each control, and what evidence shows those controls are still working.

Payment-event worksheet reviewed: 2026-10-23. Added a blank lifecycle review record and checked PCI SSC FAQ 1280 on recurring-transaction verification codes. No billing flow or commercial revenue outcome was tested.