CCPA and Payment Data: What California Merchants Need to Store (and Not Store)

The phrase CCPA payment data merchants keeps coming up in support tickets because two different rulebooks touch the same information. PCI DSS is the card-industry standard that governs how you handle card numbers. The California Consumer Privacy Act, as amended by the CPRA and enforced by the California Privacy Protection Agency, governs the personal information of California residents more broadly. Payment data sits in both. This post explains what you must keep, what you must never keep, and how to think about the gray zone in between. It is not legal advice; confirm your specific obligations with your processor and counsel.

Who CCPA/CPRA actually applies to

CCPA does not apply to every corner shop. It applies to for-profit businesses that do business in California and meet one of the thresholds: annual gross revenue above a set figure (check the current inflation-adjusted number), buying, selling, or sharing personal information of a large number of consumers or households per year, or deriving half or more of annual revenue from selling or sharing personal information. Many mid-size e-commerce brands, subscription companies, and multi-location retailers cross the revenue line without realizing it. Service providers and contractors handling data for a covered business inherit contractual obligations even if they are not covered themselves.

What PCI already forbids, regardless of CCPA

Before CCPA enters the picture, PCI DSS sets hard rules for anyone who stores, processes, or transmits cardholder data:

• Never store the full magnetic stripe or chip data after authorization.
• Never store the CVV/CVC security code, ever, even encrypted.
• Never store PIN blocks.
• If you store the primary account number (PAN), it must be rendered unreadable (strong encryption, truncation, or tokenization) and access must be restricted and logged.

Most merchants have no legitimate reason to store a PAN at all. A processor that offers tokenization replaces the card number with a token you can charge later; the real number lives in the processor's vault. That single decision removes card numbers from your systems, shrinks your PCI questionnaire, and keeps them out of your CCPA inventory.

What counts as personal information in a payment flow

CCPA's definition is broad. In a typical checkout it includes name, billing and shipping address, email, phone, IP address, device identifiers, purchase history, and any inferences you draw from it (for example, a "likely to churn" flag). Card numbers and bank account numbers are personal information too, and under the CPRA's "sensitive personal information" category, financial account credentials that allow access to an account carry heightened obligations and a right to limit use.

The practical effect: even if your card data is tokenized, the surrounding transaction record is still personal information. You need to know where it lives (gateway, CRM, email platform, accounting software, spreadsheets) and who has access.

What you need to keep, and for how long

Deletion requests are the point where CCPA and payment operations collide. A customer can ask you to delete their personal information, but CCPA has exceptions, including completing the transaction, complying with a legal obligation, and handling security incidents. In payments terms:

1. Keep transaction records long enough to respond to chargebacks. Cardholders can dispute for up to 120 days on many reason codes, and some extend further. A transaction ID, amount, date, descriptor, and delivery proof are your evidence.
2. Keep what tax and accounting rules require. Federal and California record-retention periods for sales records run for years.
3. Keep ACH authorizations for the period NACHA requires (generally two years after termination or revocation; check the current rule).
4. Keep subscription consent records under California's Automatic Renewal Law so you can prove the customer agreed to the renewal terms.

Write these periods into a retention schedule. When a deletion request arrives, you delete the marketing profile and the saved payment token, and you retain the minimal ledger entries under the legal-obligation exception. That is a defensible, honest answer. "We keep everything forever" is not.

What you should stop storing today

Walk your business and look for these: card numbers written on paper order forms, spreadsheets of customer card details for "repeat orders," screenshots of cards in a shared inbox, full card numbers in your CRM notes, and old POS exports sitting in a downloads folder. Each one is a PCI violation and a CCPA exposure. Replace them with card-on-file tokens through your gateway, use hosted fields so card data goes straight from the customer's browser to the processor, and shred the paper.

Breach obligations and why scope matters

CCPA includes a private right of action for data breaches involving certain categories, including financial account numbers with security codes, when a business failed to maintain reasonable security. Card-brand breach costs (forensics, fines, card reissuance) come on top. The less card data you hold, the smaller both exposures are. A merchant whose card numbers never leave the processor's vault is answering very different questions after an incident than one who kept a spreadsheet. A proper PCI compliance program is the operational side of this; the privacy policy and consumer-rights process are the legal side, and the two should agree with each other.

The safest payment-data posture for a California merchant is also the simplest: tokenize card numbers, keep the ledger you legally need, delete the rest on schedule, and be able to explain the whole thing to a customer, an auditor, or a regulator in one paragraph.