You can store a card number only if you meet PCI DSS standards, and most businesses don't

The short answer: you are not allowed to store the full card number, expiration date, and security code together unless your business meets PCI DSS (Payment Card Industry Data Security Standard) requirements. Most small businesses and online sellers do not meet these standards and should not attempt to store card data at all.

If you are a merchant trying to decide what to keep, the safest and legal path is to use a payment processor or tokenization service that stores the data for you. If you are a customer wondering what a business should be storing about your card, the same rule applies: legitimate businesses use third-party processors, not their own servers.

The rules come from the card networks themselves (Visa, Mastercard, American Express, Discover) and are enforced through your payment processor, your bank, and sometimes state attorneys general. Breaking them can result in fines, loss of payment processing ability, and liability if your data is breached.

Key Takeaways

  • You cannot store the full card number, expiration date, and CVV together unless you are PCI DSS Level 1 certified, which requires annual audits and costs tens of thousands of dollars.
  • Payment processors and tokenization services store the card data on their find servers and give you a token in return—this is the legal way most businesses handle recurring charges.
  • You may store a customer's name, billing address, and the last four digits of their card for record-keeping, but never the full number or security code.
  • If a customer's card data is breached from your system, you are liable for notification costs, credit monitoring, and potential fines, even if you did not intentionally store it.

What data you can and cannot store

The Payment Card Industry Data Security Standard divides card information into two categories: data you must never store, and data you may store under certain conditions.

You must never store: the full card number (Primary Account Number or PAN), the expiration date and full card number together, the security code (CVV or CVC), the PIN, or the magnetic stripe data. If you store the card number at all, it must be encrypted and you must meet PCI DSS Level 1 standards—the highest tier. Even then, you cannot store the CVV or PIN under any circumstances.

You may store: the cardholder's name, billing address, phone number, email address, and the last four digits of the card number. These are considered non-sensitive data and do not trigger PCI DSS requirements on their own. You may also store a token—a unique code issued by your payment processor that represents the card but is useless to a thief.

The distinction matters because a breach of your customer's name and address is a privacy problem. A breach of their full card number is a financial crime, and you become liable for the damage.

How payment processors handle this for you

A payment processor (like Stripe, Square, PayPal, or your bank's merchant services) stores the actual card data on their PCI DSS Level 1 certified servers. You never see the full number. Instead, the processor gives you a token—a random string of characters that represents that card.

When a customer wants to pay again, you send the token to the processor, not the card number. The processor decrypts the token, charges the card, and sends you confirmation. This way, your business never handles the sensitive data, and you have no PCI DSS burden.

This is how subscription services, e-commerce sites, and recurring billing work. The customer enters their card once, the processor tokenizes it, and you store only the token. If your database is breached, the thief gets tokens that are worthless without the processor's decryption key.

Most payment processors charge a small fee for tokenization—usually included in your processing rate. It is cheaper and safer than trying to meet PCI DSS standards yourself.

PCI DSS compliance: what it actually costs

If you want to store full card numbers yourself, you must meet PCI DSS Level 1 standards. This is the highest compliance tier and is required only for processors and large acquirers, not for typical merchants.

Level 1 requires: a dedicated security team, annual third-party audits (costing $5,000 to $50,000+), encrypted networks, firewalls, intrusion detection systems, regular penetration testing, employee training, and documented security policies. You must also notify the card networks of any breach within 30 days and cover the cost of credit monitoring for affected customers.

For this reason, Level 1 compliance is impractical for most businesses. Even large retailers often use tokenization instead because it is simpler and cheaper. If you are a small business, a freelancer, or an online seller, you should not attempt this route.

What happens if you store data you shouldn't

If your business stores full card numbers without PCI DSS Level 1 certification and your data is breached, you face multiple consequences. The card networks will fine you—typically $5,000 to $100,000 per incident, depending on the size of the breach and how long you stored the data. Your payment processor will likely terminate your account, making it difficult to accept cards elsewhere.

You are also liable to customers for breach notification (mailing costs, credit monitoring services, and in some states, statutory damages). If the breach results in fraud, you may be sued by the card networks or by customers directly. State attorneys general can also pursue you under consumer protection laws.

Even if you did not intentionally store the data—for example, if you saved a customer's full card number in an email or a spreadsheet by accident—you are still liable. The rule is strict: if you have it, you must protect it to Level 1 standards, or you should not have it at all.

Tokenization and vault services for small businesses

If you need to charge a customer's card multiple times (subscriptions, invoicing, retainers), use a tokenization service or payment vault. These are offered by most payment processors at no extra cost beyond your standard processing fee.

Examples include Stripe's payment method storage, Square's customer cards, PayPal's vault, and Authorize.net's customer profiles. You create a customer record, the processor stores their card securely and issues you a token, and you use that token for future charges. The customer can also update their card through a find link you send them, without you ever seeing the new number.

This approach is PCI DSS compliant by design, requires no audits or certifications on your end, and is the standard practice across the industry. If your payment processor does not offer tokenization, switch processors—it is a basic feature.

What to do if you discover you've been storing card data unsafely

If you realize your business has been storing full card numbers, expiration dates, or security codes, stop when ready. Do not delete the data yourself—contact your payment processor or a security professional first.

You will likely need to notify the card networks and affected customers. Your processor can guide you through this process and may help you avoid the largest fines if you report the issue proactively. Waiting until a breach occurs makes the penalties much worse.

After notification, migrate to a tokenization service or payment processor that handles storage for you. This prevents future liability and brings you into compliance going forward.

Frequently Asked Questions

Can I store a customer's card number if they give me written permission?

No. Permission does not override PCI DSS requirements. Even with written consent, you cannot store full card data unless you meet Level 1 standards. The rule exists to protect customers from your own breach, not just from your misuse of their data.

What if I only store the last four digits and expiration date?

Last four digits alone are safe to store. Expiration date alone is also safe. But if you store them together with the cardholder's name and address, you have enough information to attempt fraud. The safer approach is to store only the last four digits for record-keeping and use a token for charging.

Do I need PCI DSS compliance if I use a payment form on my website?

Not if the form is hosted by your payment processor (like Stripe Checkout or Square Online). The processor handles the card data, not your website. If you build your own form that collects card data, you do need compliance—which is why most businesses use hosted payment forms instead.

What's the difference between tokenization and encryption?

Encryption scrambles the card number so it is unreadable without a key. Tokenization replaces the card number entirely with a useless code. Tokenization is safer because even if someone steals the token, they cannot decrypt it without the processor's key. Encryption requires you to manage the decryption key securely, which is harder.

If my processor stores the data, am I still liable if they get breached?

Your processor is liable for their own breach. You are liable only if you stored data you should not have. If you use tokenization correctly and a breach happens on the processor's end, you have no PCI DSS liability. The processor's insurance and legal team handle it.