Payment card data is any information that identifies a card, its holder, or the transaction—and PCI DSS requires you to protect it whether you store it or just see it once

Payment card data under PCI DSS (Payment Card Industry Data Security Standard) includes the card number itself, the expiration date, the security code on the back, the cardholder's name, and billing address. It also includes the card's magnetic stripe data, the chip data from EMV cards, and any token or reference number created to stand in for the card in your system. If you process, store, or transmit any of these elements—even briefly—PCI DSS applies to you.

The standard divides this data into two categories: full Primary Account Number (PAN) data, which is the most tightly controlled, and truncated PAN data, which you can display or store under looser rules. A truncated PAN shows only the last four digits (the part customers recognize on receipts). The moment you capture the full card number, you enter a higher compliance tier, which is why many businesses use payment processors or tokenization to avoid storing it themselves.

Key Takeaways

  • PCI DSS covers the card number, expiration date, security code, cardholder name, and billing address—plus any token or reference created to replace the card number in your system.
  • Full card numbers are the most restricted; you can display or store only the last four digits without triggering the highest security requirements.
  • Data you transmit, store, or process all fall under PCI DSS, even if you never see the full number because a payment processor handles it.
  • Magnetic stripe data, chip data, and any authentication codes generated during a transaction are all considered payment card data and must be protected.
  • If you use a third-party processor or payment gateway, you still bear responsibility for ensuring card data is protected during transmission to and from that vendor.

What counts as payment card data

The PCI DSS defines payment card data as any information that can identify a payment card or its holder. This includes:

  • The full card number (Primary Account Number or PAN)
  • Expiration date
  • Card verification value (CVV or CVC)—the three- or four-digit security code on the back
  • Cardholder name
  • Billing address
  • Magnetic stripe data (the encoded information on the back of the card)
  • Chip data (the information stored on an EMV chip)
  • Tokens or reference numbers created to replace the card number in your system
  • Authentication codes or cryptograms generated during a transaction

Any single piece of this information, or any combination of pieces, counts as payment card data. You do not need to store the full card number for PCI DSS to apply—even storing just the expiration date and cardholder name alongside a token is considered payment card data and must be protected.

The difference between full and truncated card numbers

PCI DSS treats full card numbers and truncated card numbers very differently. A full Primary Account Number is the complete 13- to 19-digit card number. A truncated PAN shows only the last four digits, usually formatted as XXXX-XXXX-XXXX-1234.

If you store or transmit a full card number, you must meet the highest level of PCI DSS compliance, which includes encryption, regular security testing, and strict access controls. If you store or display only the last four digits, the rules are much lighter—you can keep truncated PANs in plain text, log them in audit trails, and display them on receipts without triggering the most expensive compliance requirements.

This is why most businesses use payment processors or tokenization: they let you process a card without ever storing the full number yourself. The processor stores the full number in their secure vault and gives you back a token (a random reference number) that you can use to charge the card again without ever seeing the real digits.

Data you must protect even if you do not store it

PCI DSS applies to payment card data you transmit or process, not just data you store. If you accept a card over the phone, through a form on your website, or in person at a payment terminal, you are processing payment card data even if your system never saves it. The moment the data enters your network—even for a fraction of a second—it is subject to PCI DSS.

This means you must protect the transmission channel itself. If you collect card data through an unencrypted website form, you are violating PCI DSS even if you immediately send it to a processor and delete it from your server. The data was exposed in transit, which is a breach of the standard.

The same applies to data you receive from a payment processor or payment gateway. If a third party sends you transaction details that include card data, you must protect that data while it is in your possession, even if you plan to delete it after reconciliation. Many businesses receive settlement files or transaction reports that contain truncated PANs or tokens—these files must be encrypted or stored securely.

What is not considered payment card data

PCI DSS does not cover information that cannot identify a specific card or cardholder. Transaction amounts, merchant category codes, authorization response codes, and timestamps are not payment card data. Customer names and addresses that are not linked to a card number are not payment card data.

Tokenized data—a random reference number with no mathematical relationship to the original card number—is not payment card data, which is why tokenization is so useful. Once a card is tokenized, you can store and transmit the token freely without triggering PCI DSS requirements. However, the token itself must be generated and stored securely by the tokenization service, and you must protect the link between the token and the card number.

Deleted or destroyed card data is also not subject to PCI DSS, but only if it is truly gone. Overwriting data, encrypting it with a key you then destroy, or physically shredding a document all count as destruction. Simply deleting a file from your computer does not—the data can often be recovered from the hard drive.

Who is responsible for protecting payment card data

Every organization that touches payment card data is responsible for protecting it under PCI DSS, regardless of size or whether you are the one who collected it. If you are a merchant who accepts cards, you are responsible. If you are a payment processor, you are responsible. If you are a third-party vendor who receives card data from a client, you are responsible.

This responsibility does not disappear when you hire a vendor. If you use a payment gateway to process cards, you are still responsible for ensuring the data is protected during transmission to and from that gateway. If a processor you hired suffers a breach, you may still face liability and fines, which is why PCI DSS requires you to audit your vendors and ensure they are compliant.

The PCI Security Standards Council does not enforce PCI DSS directly—your card networks (Visa, Mastercard, American Express, Discover) and your acquiring bank do. If you suffer a breach, the card networks investigate and may impose fines, require you to pay for credit monitoring, or suspend your ability to process cards.

How to know if you are handling payment card data

Ask yourself: does my system ever see, store, or transmit a card number, expiration date, security code, cardholder name, billing address, or any token or reference created from these elements? If the answer is yes, you are handling payment card data and PCI DSS applies to you.

If you use a payment processor or payment gateway and never see the card number yourself, you are still handling payment card data—you are just handling it indirectly. You are responsible for ensuring the processor is compliant and for protecting any card data the processor sends you in reports or settlement files.

If you are unsure whether your system handles payment card data, document what data flows through your network and ask your payment processor or acquiring bank. They can tell you whether PCI DSS applies and at what level.

Frequently Asked Questions

Does PCI DSS apply if I only store the last four digits of a card?

PCI DSS applies, but at a much lower level. Storing truncated PANs (last four digits only) does not trigger the highest compliance requirements. However, you must still protect the data and document how you store it. If you store the last four digits alongside other card data like the expiration date or cardholder name, you must treat the combination as payment card data and protect it accordingly.

What if a customer gives me their card number over the phone?

The moment you hear or record the card number, you are processing payment card data and PCI DSS applies. You must never record the full number on a call or in an email. Instead, use a PCI-compliant phone system or ask the customer to enter the number into a secure payment form. If you accidentally record a full card number, you must delete it immediately and report the incident to your processor.

Do I need to comply with PCI DSS if I use a payment app like Square or Stripe?

You do not handle the full card number, so you are not subject to the highest PCI DSS requirements. However, PCI DSS still applies to any card data you receive from the processor, such as truncated PANs in settlement reports. You must protect those files and ensure your network is secure. Your processor handles the bulk of compliance on your behalf.

Is a token the same as payment card data?

A token is not payment card data if it is a random reference number with no mathematical link to the original card. However, the token must be generated and stored securely by a PCI-compliant tokenization service. You can store and transmit tokens freely, but you must protect the connection between the token and the card number.

What happens if I store payment card data without PCI DSS compliance?

If you suffer a breach, your card networks will investigate and may fine you, require you to pay for customer credit monitoring, or suspend your merchant account. You may also face lawsuits from customers whose data was exposed. The cost of a breach almost always exceeds the cost of compliance, which is why using a processor or tokenization is the safer choice.