If your business takes payments from people in California — and unless you've geofenced your checkout, you almost certainly do — the California Consumer Privacy Act is part of your compliance picture. It treats card data, billing addresses, and payment history as personal information, which means Californians have legal rights over how you collect, use, and share that data.
This isn't a privacy-policy tweak. It's a different way of thinking about who owns the data that flows through your payment workflow, and it has real penalties attached. Here's what the law says, who it applies to, and where it bites for anyone running a payment operation.
CCPA, CPRA — what's the difference?#
The CCPA (California Consumer Privacy Act) came into effect on 1 January 2020. It was the first sweeping US state privacy law, and it caught a lot of mid-market US companies by surprise because they were used to thinking of privacy regulation as a European problem.
The CPRA (California Privacy Rights Act) is the 2023 upgrade. Californians voted it in via ballot proposition in 2020, and it took effect on 1 January 2023. It didn't replace the CCPA — it strengthened it. CPRA added new consumer rights, created a new enforcement body (the California Privacy Protection Agency, or CPPA), and introduced the concept of "sensitive personal information" with extra protections.
People still say "CCPA" as shorthand for both. We'll do the same here.
Does CCPA apply to you?#
You're in scope if you do business in California, you process the personal information of California residents, and you hit at least one of these thresholds:
- Annual gross revenue over $25 million
- You buy, sell, or share the personal information of 100,000 or more California consumers or households
- You derive 50% or more of your annual revenue from selling or sharing California consumers' personal information
The first one catches most serious B2C operations. The second catches a lot of B2B and marketing tech companies. The third is aimed at data brokers.
Importantly, you don't have to be a California company. If you're a contact center in Texas taking phone payments from Californians and you tick a threshold, you're in scope.
Card data is personal information#
This is the bit a lot of payments teams miss. Under CCPA, personal information explicitly includes financial information — and that covers card numbers, billing addresses, expiry dates, and transaction history tied to an identifiable consumer.
That matters because every consumer right under CCPA now potentially applies to data sitting in your payment systems:
- Right to know. Consumers can ask what personal information you've collected about them, why, and who you've shared it with.
- Right to delete. Consumers can ask you to delete their personal information, subject to certain exceptions (one of which is data needed to complete a transaction or comply with another law — including PCI DSS retention requirements).
- Right to opt out of sale. Consumers can tell you to stop selling their data.
- Right to opt out of sharing. CPRA added this — it covers sharing for cross-context behavioral advertising, even if no money changes hands.
- Right to correct. Consumers can ask you to fix inaccurate information.
- Right to limit use of sensitive personal information. A new CPRA right.
- Right to non-discrimination. You can't penalise someone for exercising any of these rights.
The payment-processor angle#
CCPA splits the world into two main roles: "businesses" (you, the merchant) and "service providers" (vendors processing data on your behalf under a written contract). A payment processor is almost always a service provider when it's processing transactions you've initiated.
That has practical implications:
- You need a written service provider contract that meets CCPA's specific requirements — restricting the processor from using the data for its own purposes, requiring confidentiality, and so on.
- When a consumer makes a deletion request to you, you usually need to forward it to your processor (with exceptions for data needed to complete transactions or comply with other laws).
- You're responsible for what your processor does with the data, even though they're a separate company.
If your processor is using transaction data for anything beyond providing the payment service — for example, building its own fraud models or selling aggregated insights — and that use isn't authorized in your contract, you could end up jointly liable.
What about phone payments specifically?#
Phone payments create a particular CCPA wrinkle because the data flows through more systems than a website checkout. A typical inbound payment call touches:
- The PBX or contact-center platform
- The call recording system
- The agent's screen and CRM
- The payment gateway
- The acquiring bank
Each of those is a potential location where personal information lives, and each is a potential point where a deletion or access request needs to land. If a customer in San Francisco asks you to delete their data, and you've got a call recording from three months ago where they read out their card number, you've got a problem. Even if you can suppress the card number under PCI requirements, the rest of the recording is still personal information you've got to address.
This is one of the practical reasons DTMF masking pays for itself in a CCPA context — if the card number was never in the recording in the first place, your deletion request is much simpler to honour.
What the penalties look like#
The California Attorney General and the new CPPA can levy administrative fines:
- $2,500 per violation for unintentional violations
- $7,500 per intentional violation
- $7,500 per violation involving a minor's data
That "per violation" wording is the part that hurts. A single incident affecting 10,000 California consumers is potentially 10,000 violations.
There's also a private right of action — but only for specific data breach scenarios involving unencrypted or unredacted personal information. Statutory damages there run $100 to $750 per consumer per incident, or actual damages if higher.
Recent enforcement gives a sense of the calibration:
- Sephora paid $1.2 million in 2022 over allegations it had failed to disclose data sales to third parties and didn't honour Global Privacy Control signals.
- DoorDash paid $375,000 in 2024 over a data-broker arrangement the CA AG said constituted a sale without disclosure.
Neither figure is going to bankrupt a company that size, but the corrective action requirements — auditing data flows, building consumer-rights infrastructure, retraining staff — typically cost more than the fine.
What good looks like for a payment operation#
If you're trying to get a payment workflow into a CCPA-defensible state, the checklist is roughly:
- Document every system where customer payment information lives, and how long it stays there
- Confirm you've got a written service-provider contract with your processor that meets CCPA's contractual requirements
- Build a consumer rights workflow — receiving requests, identifying the consumer, fulfilling within the 45-day deadline (90 with extension)
- Reduce the surface area: less personal information sitting in places it doesn't need to be is less work when a request comes in
- Update your privacy policy with the specific CCPA disclosures (categories of information collected, purposes, third parties)
- Honour Global Privacy Control signals — the CA AG has been active here
Where Paytia fits#
Paytia is a PCI DSS Level 1 service provider with our US base in New York. We've been certified since 2016 and we've handled over $500 million in card payments through our DTMF-masking platform.
From a CCPA perspective, we act as a service provider when we process payments on your behalf. We don't sell your customers' data, we don't use card numbers for our own purposes, and we don't store data beyond what's needed to complete the transaction and meet PCI retention requirements. We can sign the service-provider contract terms CCPA needs, and we keep card numbers out of the call recordings, agent screens, and CRM systems where they'd otherwise complicate every consumer rights request you receive.
If you want to talk through how a payment workflow lands under CCPA — including what data we'd handle and what would stay with you — get in touch with our New York team.
What about the other state privacy laws?#
Once you've got a CCPA-compliant payment workflow, the rest of the US state privacy laws get easier. Colorado, Virginia, Connecticut, Utah, Texas, Oregon, Montana, Tennessee, and others have passed their own laws, and several more are in the queue. They aren't identical to California, but the bones are similar: thresholds for who's in scope, consumer rights (know, delete, opt out, correct, in most cases), contractual obligations on processors, and a notice-and-consent model for sensitive data.
The two practical differences worth flagging:
- No private right of action. Most of the post-CCPA laws don't give consumers the ability to sue directly — enforcement is by the state AG only. That changes the risk calibration but doesn't change the compliance work.
- Different definitions of sensitive data. Some states include precise geolocation, immigration status, or union membership in ways California doesn't. If your payment data could be paired with any of those, the requirements get tighter.
If your CCPA work is real and well-documented, extending it state by state is mostly a mapping exercise rather than a rebuild.
The bottom line#
CCPA isn't going away, and it's not getting easier. The trend across other states is to copy the California model with local tweaks, so the work pays off across the country. If you build your payment workflow to satisfy California, you're most of the way to satisfying the rest.
Start by knowing where your customers' card data lives. That's the question every consumer rights request will eventually ask.
