You can store the cardholder's name, the last four digits of the card number, and the expiration date. You cannot store the full card number, CVV, or PIN under any circumstances.

The rules come from PCI DSS (Payment Card Industry Data Security Standard), which all businesses that handle cards must follow. The standard is enforced by Visa, Mastercard, American Express, and Discover — not by a single government agency. If you store card data and get breached, you face fines from the card networks, liability lawsuits, and mandatory forensic audits that cost tens of thousands of dollars.

The safest approach for most small businesses is not to store card data at all. Instead, use a payment processor like Stripe, Square, or PayPal that stores the data on their servers and gives you a token — a unique reference number — to charge the card later. You keep the token; they keep the card number. This shifts the security burden to a company built to handle it.

Key Takeaways

  • You may store the cardholder name, last four digits, and expiration date only; the full card number, CVV, and PIN are forbidden under PCI DSS rules.
  • The safest method is to never store card data yourself — use a payment processor that issues you a token instead.
  • If you do store card data, you must encrypt it at rest, use secure networks, and conduct annual security audits.
  • A data breach involving stored card numbers can trigger fines from card networks, lawsuits, and mandatory forensic investigations.
  • PCI DSS compliance is required by Visa, Mastercard, American Express, and Discover, regardless of your business size.

What data you can keep on file

The PCI DSS allows you to store these fields from a card transaction:

  • Cardholder name
  • Last four digits of the card number (sometimes called the PAN suffix)
  • Expiration date
  • Card brand (Visa, Mastercard, etc.)

That is the complete list. You can use this data to show a customer which card they used, to send them a receipt, or to match a card to a stored token. You cannot use it to charge the card again — you need the token for that.

Some businesses store the cardholder's billing address and ZIP code as well. This is allowed under PCI DSS, though it is not required and adds no real security benefit. If you do store it, treat it the same way you treat the last four digits: keep it encrypted and limit who can see it.

What you absolutely cannot store

The PCI DSS explicitly forbids storing these fields, even in encrypted form:

  • Full card number (PAN) — the 16-digit number on the front of the card
  • CVV or CVC — the three- or four-digit security code on the back
  • PIN — the personal identification number used at ATMs or chip readers
  • Magnetic stripe data — the encoded information on the back of the card
  • IIBAN or equivalent — the international bank account number for ACH or wire transfers

These restrictions exist because storing the full card number and CVV together gives a thief everything needed to make a fraudulent purchase online. Even if you encrypt the data, a breach exposes you to massive liability. Card networks fine merchants who store forbidden data, and the fines are separate from any lawsuit damages.

Using tokens instead of storing card data

A token is a unique reference string that a payment processor creates when you first process a card. It looks like a random string of letters and numbers — for example, `tok_visa_4242` — and it has no value to a thief. You store the token in your database, and when you need to charge the card again, you send the token to the processor, not the card number.

This is the industry standard for recurring charges, subscriptions, and saved cards. When you use a token, you are not storing card data yourself; the processor is. You are only storing a reference to it. This keeps you out of PCI DSS scope entirely for that transaction.

Most payment processors issue tokens automatically. When you process a card through Stripe, for example, Stripe returns a token you can save. The next time you want to charge that customer, you send the token to Stripe, and Stripe looks up the card number on their end and processes it. You never see the full card number after the first transaction.

PCI DSS compliance if you do store card data

If your business model requires you to store card data (which is rare), you must meet the full PCI DSS standard. This involves:

  • Encrypting card data both in transit (over the network) and at rest (in your database)
  • Using a firewall and intrusion detection system
  • Limiting employee access to card data on a need-to-know basis
  • Conducting an annual security audit by a may have access to assessor
  • Maintaining detailed logs of who accessed card data and when
  • Using strong passwords and multi-factor authentication for any account that can access card data

The annual audit alone costs $5,000 to $15,000 depending on your business size and complexity. If you fail an audit, you must remediate the issues and pay for a re-audit. Card networks can also fine you $5,000 to $100,000 per month for non-compliance, depending on the violation and how long it persists.

For most small businesses, the cost and complexity of PCI DSS compliance make it impractical to store card data yourself. Using a payment processor is cheaper, faster, and safer.

What happens if you store forbidden data

If you store a full card number, CVV, or PIN and your system is breached, the card networks will investigate. They will determine whether you were PCI DSS compliant at the time of the breach. If you were not, you face fines ranging from $5,000 to $100,000 per month, depending on the card network and the severity of the violation.

You will also be liable for fraudulent charges made with the stolen data. If 10,000 cards were exposed and each one sees $500 in fraud, you may owe $5 million in chargeback liability. Your payment processor may terminate your account, and you will be blacklisted from processing cards with that network for a period of time.

Beyond the fines, you will face lawsuits from cardholders whose data was stolen. These lawsuits often proceed as class actions, and settlements can reach millions of dollars. You will also be required to pay for credit monitoring for affected customers, forensic investigation costs, and notification expenses.

State and federal laws that overlap with PCI DSS

PCI DSS is a private standard set by the card networks, but several laws reinforce it. The Gramm-Leach-Bliley Act requires financial institutions to protect customer data; if you process cards, you are handling financial data and must comply. The California Consumer Privacy Act (CCPA) and similar state laws give consumers the right to know what data you store about them and to request deletion.

If you store card data and a breach occurs, you must notify affected individuals under state breach notification laws. Most states require notification within 30 to 60 days. Notification costs money and damages your reputation, making the case for using a payment processor even stronger.

Frequently Asked Questions

Can I store a card number if I encrypt it?

No. PCI DSS forbids storing the full card number, CVV, and PIN under any circumstances, even if encrypted. Encryption protects the data in transit and at rest, but it does not change the rule. If your database is breached and decrypted, you are still liable for storing forbidden data.

What if a customer asks me to save their card for future purchases?

Use a payment processor to tokenize the card instead. Ask the processor to issue a token, store the token in your system, and use it to charge the customer later. The customer's card data stays with the processor, not with you. This is what "save my card" actually means in practice.

Do I need to be PCI DSS compliant if I use a payment processor?

It depends on the processor. If you use a hosted payment form (like Stripe Checkout or Square's payment page), the processor handles all card data and you are out of scope. If you build your own form and send card data to the processor, you are in scope and must comply. Always use the processor's hosted form or tokenization method.

What is the difference between a token and a card number?

A token is a unique reference string with no value to a thief. A card number is the actual 16-digit number that can be used to make purchases. You store the token; the processor stores the card number. If your database is breached, the thief gets tokens, not card numbers.

Can I store a card number if my business is very small?

No. PCI DSS applies to all businesses that store, process, or transmit card data, regardless of size. A one-person business storing card numbers is subject to the same rules and fines as a large retailer. Using a payment processor is the only practical option for small businesses.