Anyone managing subscription billing or recurring card payments is automatically in scope for PCI DSS. The reason is structural: to charge a card in the absence of the cardholder (recurring payment), the merchant must retain a reference to the card data that enables future authorisation. This reference - whether a plain PAN or a token - determines the compliance perimeter. Card-on-file tokenization is the technical solution that enables scalable subscription management without building a proprietary vault.
Subscriptions and PCI DSS: why you are automatically in scope
A subscription requires the merchant to retain a reference to the customer's card in order to charge it periodically without a new explicit authorisation from the cardholder. This is defined by PCI DSS as a card-on-file scenario: the card is "on file" with the merchant. If the merchant stores the PAN directly, all systems that access that archive are in scope. If the merchant stores the token of a certified vault, the scope is reduced to the components that send the token to the vault to obtain authorisation.
A frequent mistake is thinking that using a PSP for recurring payments eliminates PCI obligations. If the PSP stores the card and the merchant uses its own internal tokens to trigger payments, the merchant is still in scope for the management of those tokens and for the flow that sends them to the PSP. Effective scope reduction depends on how the technical integration is structured and what data actually passes through the merchant's infrastructure.
Card-on-file tokenization for subscription billing
With PCI Proxy EU's card-on-file tokenization, the subscription flow works as follows: at the time of initial registration, the customer enters card data into the payment page hosted by PCI Proxy EU. The system returns to the merchant a persistent token linked to that card. The merchant stores the token in its own database alongside the customer profile and subscription plan. At subsequent billing dates, the merchant sends the token to PCI Proxy EU, which retrieves the PAN and transmits it to the PSP for authorisation.
This approach allows the merchant to manage billing logic (amount calculation, period management, expiry notifications, retry on failure) within its own systems without ever touching the PAN. The merchant's database contains only tokens, customer identifiers and plan data: none of these elements constitute sensitive PCI data. Full flexibility in billing logic is maintained because the token is persistent and can be reused for an unlimited number of subsequent authorisations.
What remains the merchant's responsibility even with tokenization
Tokenization does not eliminate all of the merchant's PCI obligations. The components that send the token to PCI Proxy EU for authorisation (application server, job scheduler, billing system) remain in scope for the part connected to the vault API. These systems must have appropriate access controls, API access logs, secure management of API credentials and documented procedures for rotating authentication keys. The applicable SAQ in this scenario is typically SAQ D for Merchants, but with a much smaller number of in-scope systems compared to an architecture without tokenization.
Managing expired cards also requires a defined process: when a card expires, the merchant must have a flow to update the token with the customer's new card (via redirect to a new payment page) or to trigger subscription cancellation. PCI Proxy EU supports automatic card updates for networks that offer this capability, reducing involuntary churn without requiring the customer to manually re-enter data.
Frequently asked questions
Can I use the PCI Proxy EU token to reprocess an expired subscription?
Yes, the token is persistent and can be used for subsequent charge attempts as long as the underlying card is valid in the vault. If a charge fails due to an expired card, the token becomes unusable for new authorisations. The merchant must trigger a card update flow: PCI Proxy EU supports Account Updater for networks that allow it, or the merchant can send the customer a link to manually update their data.
How do I manage card data updates in a subscription?
The standard flow involves sending the customer a notification with a link to the PCI Proxy EU payment page to enter new card data. Once completed, the system issues a new token that the merchant associates with the existing customer profile. The old token is invalidated. This process requires no changes to the merchant's billing logic: only the token ID in the database is updated.
Does a SEPA mandate eliminate PCI DSS obligations?
Yes, but only if recurring payments are managed exclusively through SEPA direct debit (SDD). A SEPA mandate uses IBAN rather than card data, which falls outside the PCI DSS perimeter. However, if the business accepts both SEPA and credit card for subscriptions, card payments remain in PCI scope. Many businesses use both instruments in parallel, so SEPA does not eliminate PCI obligations but can reduce the volume of in-scope card transactions.
Subscriptions without PAN in your stack: you manage the billing logic, we safeguard the card data. Discover PCI Proxy EU.