Can Merchants Store Card Data? Rules and Risks

A returning customer expects a subscription renewal or one-click checkout to work without entering their card number again. For the merchant, that convenience raises a critical question: can merchants store card data without creating unacceptable security, compliance and commercial risk? The answer is yes, in limited circumstances, but storing raw card data is rarely the right design choice.

For most online businesses, particularly those operating across markets or managing recurring payments, tokenisation delivers the customer experience of saved cards without placing sensitive card numbers throughout the merchant’s systems. The distinction matters. It affects PCI DSS scope, fraud exposure, breach impact, acquiring relationships and the time your technical team spends maintaining payment infrastructure.

Can merchants store card data under PCI DSS?

Merchants may store certain cardholder data when there is a legitimate business need and when they meet the applicable Payment Card Industry Data Security Standard (PCI DSS) requirements. A cardholder’s primary account number, or PAN, may be retained, but it must be protected with strong controls. This is not simply a matter of encrypting a database and moving on. PCI DSS applies to the systems, people and processes that store, process or transmit cardholder data.

The more significant restriction concerns sensitive authentication data. After authorisation, merchants must not store the full contents of a card’s magnetic stripe or chip equivalent, the card verification value such as CVV or CVC, or the PIN and PIN block. This prohibition applies even if the information is encrypted. A customer may enter their CVV during checkout to support an authorisation, but it cannot be kept for a later transaction.

Card data storage also has a narrower definition than many teams assume. A database containing card numbers is clearly in scope, but so can application logs, customer service tools, backup files, screen recordings, email inboxes and test environments. A single PAN copied into an unsecured support ticket can create a serious compliance problem. That is why the safest approach is to minimise where payment information appears in the first place.

The commercial cost of storing raw card details

Raw card data creates obligations long after the payment has been accepted. Merchants must maintain access controls, vulnerability management, encryption and key management, monitoring, secure development practices, incident-response procedures and regular validation. The precise validation route depends on the payment flow and card scheme requirements, but the underlying principle remains the same: more card data means a larger cardholder data environment and a heavier compliance burden.

There is also a direct operational cost. Developers must ensure that card fields never leak into logs or analytics platforms. Operations teams must control who can retrieve customer records. Security teams must review integrations and suppliers. If a breach occurs, the business may face forensic investigation costs, card-scheme penalties, customer notification duties, fraud losses and damage to acquiring continuity.

For high-risk and subscription-led businesses, the stakes can be higher still. A merchant that experiences elevated chargebacks or fraud will already be under closer scrutiny from acquirers. Holding unnecessary card data adds another avoidable source of risk at precisely the point where payment reliability and approval performance need protection.

Tokenisation is usually the better route

Tokenisation replaces the PAN with a unique, non-sensitive reference known as a token. Your application stores and uses the token, while the payment provider or token vault retains the underlying card data in a controlled PCI DSS environment. When the customer returns, the merchant submits the token to initiate a payment rather than handling the card number again.

This supports the use cases merchants actually need: saved cards, recurring billing, instalments, account updater services, refunds and merchant-initiated transactions. It can also help preserve a consistent customer experience across web, mobile and customer-service payment channels.

Tokenisation does not remove every compliance obligation. A merchant still needs secure systems, clear access governance and a compliant checkout implementation. However, it can substantially reduce exposure to raw cardholder data and simplify the practical scope of PCI DSS. A PCI DSS Level 1 gateway can host the sensitive payment collection layer while the merchant receives a token and transaction status through its integration.

There are two concepts that are often grouped together but serve different purposes. Gateway or vault tokenisation creates a reusable reference for a stored payment method within a payment platform. Network tokenisation replaces a PAN with a token issued through the card networks and can improve authorisation resilience, particularly when cards expire or are replaced. The strongest payment setups may use both, depending on the acquiring strategy and markets served.

Choose the right payment collection design

The way card details enter your checkout determines much of your exposure. A fully hosted payment page shifts card entry away from the merchant’s website. Hosted payment fields and embedded checkout components can provide a more branded experience while keeping sensitive fields within the payment provider’s controlled environment. An API integration that sends card data through your own servers gives greater control, but it also creates the greatest compliance responsibility.

There is no universal winner. A straightforward hosted checkout may be right for a business that wants rapid deployment and lower compliance overhead. A larger merchant may need embedded fields, mobile SDKs or API-led orchestration to manage a tailored checkout, multiple acquirers and regional payment methods. The key is to avoid selecting a more complex integration merely because it appears more flexible.

Before implementation, establish exactly where the card data travels. Does it touch your browser code only, your servers, a third-party tag manager, a mobile app, or support tools? Are payment scripts protected against tampering? Who can access tokens, issue refunds or change routing rules? These questions should be addressed during solution design, not after a security questionnaire arrives.

Consent, recurring payments and customer expectations

Secure storage alone does not give a merchant permission to charge a card whenever it chooses. For card-on-file payments, the customer must understand what they are agreeing to. The checkout should clearly explain whether the payment is a one-off purchase, a recurring subscription or an authorisation for future merchant-initiated charges.

For recurring billing, retain evidence of the customer’s agreement, including the terms presented, the date and time, the payment method reference and the billing schedule. Make cancellation practical. If the amount or frequency changes, communicate it clearly and follow the relevant scheme and regulatory requirements. Clear consent reduces disputes, protects customer trust and gives your chargeback team stronger evidence when a transaction is challenged.

Data protection law also applies. A PAN is personal data where it relates to an identifiable customer, so merchants need a lawful basis for processing, appropriate retention rules and transparent privacy information. Do not retain payment-related information indefinitely because it might be useful later. Keep what is necessary for the stated purpose, then delete or anonymise it according to documented policy.

A practical control framework for stored payment methods

Whether you store PANs directly or, more commonly, tokens, payment credentials should be treated as high-value assets. Four controls deserve particular attention:

• Minimise data exposure. Use hosted fields or hosted checkout so raw card data does not pass through merchant servers. Never collect card details in email, chat or ordinary web forms.
• Separate duties and restrict access. Limit payment administration, refunds and token use to named roles. Require multi-factor authentication and review permissions regularly.
• Protect payment flows from fraud. Combine 3D Secure v2, velocity controls, device and behavioural signals, fraud rules and real-time monitoring. Stored credentials can improve repeat conversion, but they can also be attractive to account-takeover fraudsters.
• Plan for continuity. Maintain clear records of token ownership, migration options, transaction history and acquirer routing. A saved-card programme should not become a barrier to changing providers or adding acquiring capacity.

The final point is often overlooked. A token may be specific to a gateway, acquirer or merchant account configuration. Before committing to a provider, understand whether tokens can be migrated, whether network tokens are supported, and what happens to active subscriptions if your acquiring setup changes. For international merchants, this is a commercial design decision as much as a technical one.

When direct storage may be justified

A small number of merchants may have a genuine reason to store PANs themselves, such as a highly specialised payments operation with established PCI DSS capability and strict internal security governance. Even then, the business case should be tested carefully against a managed token vault. Direct storage may offer particular control, but it transfers substantial accountability to the merchant.

For most e-commerce businesses, the better question is not whether card data can be stored, but which party should hold it. Keeping the PAN inside a purpose-built payment environment while using tokens in your own platform usually delivers the balance that matters: convenient repeat payments, lower exposure, support for recurring revenue and a checkout designed to convert.

A well-designed card-on-file programme should make repeat payment feel simple for customers while making security and compliance less burdensome for the business. Start with data minimisation, choose an integration that matches your operating model, and make tokenisation part of the payment architecture from the outset.