PCI Compliance for Call Centers: What the Rules Say About Your Recordings

Yes, you can take credit card payments over the phone. The card industry's rules only care what happens to the number after the customer says it. Those rules are PCI DSS, short for Payment Card Industry Data Security Standard. The PCI Council publishes a whole guide on phone payments. If your phone system records calls, that guide is about you.

I ran a support team that took 5,000 calls a week, and customers read us their card numbers all day long. My company now processes call recordings for teams that take payments by phone, more than 2 million so far. We sell the tool that removes the card numbers. Keep that in mind as you read.

Across 2,092,769 call recordings processed by CallTutor, 354,470 (about 1 in 6) contained a spoken card number, expiration date, or security code.

CallTutor processing data, August 2026

Can you take credit card payments over the phone?

Yes. Once the customer reads the number out loud, it exists in three places at once. The agent hears it. The agent's screen shows it while they type it into the payment form. And if the call is recorded, the recording has it too.

Training and access controls handle the first two. The recording is the one people forget, because nobody decided to make it. If recording is on, the phone system makes one on every call. It sits wherever that system stores audio, for as long as your retention policy says. On our customers' lines, about one call in six has a card number in it.

What the PCI Council says about recorded calls

The short version: the security code cannot survive the charge, and the card number must be unreadable wherever it sits. The PCI Security Standards Council spells that out in Protecting Telephone-Based Payment Card Data (version 3.0, November 2018). I'll call it the phone guide. Every quote in this section comes from it.

The security code is the three or four digits printed on the card. The phone guide files it under sensitive authentication data, and the rule is short:

"Sensitive authentication data (SAD) must not be stored after authorization, even if encrypted."

The card number (PAN, in the guide's words) has its own rule: "PAN data must be rendered unreadable."

Once the data is recorded:

"If SAD is received and recorded, the entity MUST render all data unrecoverable upon completion of the authorization process."

And for audio specifically:

"If SAD contained within audio recordings can be digitally queried ... it must not be stored."

The part I cut just restates it: "if SAD is easily accessible." Your recordings are easy to reach. An agent opens the ticket and presses play, and so can anyone else with access to that ticket.

The guide would rather the data never got recorded at all:

"Where possible, implement processes and technologies that prevent CHD from entering the telephone environment and prevent SAD from being recorded in the first place."

CHD means cardholder data. When the code is already in the recording, the rule is delete it. When the card number is, make it unreadable.

Is PCI compliance legally required?

No federal law in the United States requires it. PCI DSS is a contract. You agreed to it when you signed up to accept cards, and your processor holds you to it.

The Council says so itself: it manages the standard, but "card-payment brands and acquirers have their own compliance programs." Your acquirer is the bank behind your merchant account.

That matters less than people hope. Your processor can act on a contract faster than any court acts on a law. Nobody schedules a court date.

Does the pause button count?

Only if the audio never gets stored. A pause button stops the recording while the customer reads the card and starts it again after. The manual version depends on a person pressing a button at the right moment, every call. When the audio gets stored anyway, the phone guide says:

"If a technology solution (e.g., pause-and-resume or stop-start) cannot block the audio or video from being stored, the sensitive authentication data (SAD) MUST BE DELETED from the recording as soon as the transaction is processed."

That job is yours, not the phone vendor's. And the card number still has to be made unreadable.

On the manual version, where a person clicks the button:

"Manual pause-and-resume implementations rely completely on agent personnel to pause and restart the recording at exactly the right time."

Then it lists what goes wrong. One is "the agent forgetting to pause the recording at the right time," so the card data gets captured. The other is "the agent forgetting to restart the recording after the transaction," which it says can break regional or local legal requirements and lose other data of value.

It also wants someone checking recordings for card data on a regular basis, "preferably weekly." The small version: pull a few payment calls each week, listen to the payment part, and log who listened and when.

I ran a support team for years, and that matches what I saw: someone forgets on a busy Tuesday, and nobody finds out until much later. Your agents aren't careless, they're human and mid-call. A control that depends on a busy person remembering a step at the right second is not a control. Forgetting is the kind case. We wrote up three real cases of agents stealing card numbers.

A well-built pause tool can take your recording system out of scope. It does nothing for the agent. In the guide's words, "the technology does not reduce PCI DSS applicability to the agent, the agent desktop environment, or any other systems in the telephone environment." The agent still hears the number.

What about deleting the recordings?

Deleting the recording works, and some phone platforms recommend it because they have no other answer. Zendesk's own help center says it plainly: "Zendesk Voice can't redact PII/PCI data from call recording audio files." Its fix, a few lines later, is that "you must delete call recording files." Our Zendesk Talk review goes through what its recordings capture.

Deleting satisfies the rule. It also throws away everything you kept the recording for: quality checks, coaching new hires, and proof of what the customer agreed to when they dispute a charge.

And it leaves a window. The card number sits in the file from hangup until the deletion runs, and someone has to make sure it runs.

What it costs when it goes wrong

Visa publishes what it charges in What To Do If Compromised (version 10.0, effective 25 June 2026). The deadlines and both tables below come from it.

If card data leaks:

1. Report it to Visa's Global Risk Investigations group within three calendar days. The clock starts when you suspect a leak, not when you confirm one.
2. Visa may require a forensic investigation. If it does, you hire an investigator from Visa's approved list within five business days.
3. Deliver a preliminary report within five business days of hiring them.
4. Deliver the final report within ten business days of the investigation ending.

Then come the assessments. Visa charges the Member, which is the bank behind your merchant account, up to $100,000 per incident. That bill reaches you through your merchant agreement, so check what it says you owe the bank after a leak. The amount depends on your merchant level:

Your merchant level	Visa transactions a year	Assessment
Level 3	Up to 100,000	$5,000
Level 3	100,001 to 500,000	$10,000
Level 3	500,001 to 1 million	$25,000
Level 2	1,000,001 to 6 million	$100,000
Level 1	Over 6 million	$100,000

Visa folded Level 4 into Level 3 in 2024, so a small merchant is Level 3. Visa also says the Level 3 amount "can be increased to the $100k threshold if the facts of the case warrant it."

If the investigation is still open four full calendar months after Visa asked for it, Visa may add a second fee:

Your merchant level	Fee
Level 3 and 4	$3,000, once
Level 1 and 2	$10,000 a month

Your acquiring bank has its own program on top, as quoted above. Visa's schedule is only Visa's.

It does not take a hack. In 2019 Vice found one million recorded phone calls from Bank of Cardiff, a San Diego business lender, sitting on an exposed server. Many dated from 2015 to 2017, and many were "still available to download at the time of writing."

Three ways to satisfy the rule

Deleting every recording works, and the section above covers what it costs you. Here are the three ways to comply and keep the recording.

Approach	How it works	The catch
Keep the number off the call	The customer types the card on their phone keypad and the vendor's system masks the tones. Or they pay on a link you text them. Nothing is spoken.	Payment moves to a separate system, and the customer has to change how they pay.
Pause and resume	The recording stops while the number is read, then restarts.	It depends on a person remembering, every call, and on someone checking the recordings afterward.
Remove it after the call	The call happens normally. A tool finds the card number, removes it from the audio and the transcript, and deletes the original.	The number does reach the recording. It has to come out on every call, and you have to prove it did.

Which one fits you:

• If you can move payments off the call, use the keypad or a payment link. Our DTMF masking guide compares the four vendors and what they cost.
• If your agents are few and someone already checks recordings every week, pause and resume can work.
• If you need to keep the recording, remove the number afterward.

The third one is what we do. The audio gets stored, so the data has to come out.

I'm not going to pretend it's the same as never recording the number. It's not. The number exists in the file for a few minutes. Nobody has to remember anything, and you keep the recording.

The tool we sell

This is the problem CallTutor exists to fix. It's our product, so weigh this part accordingly.

It costs $9 a month per Zendesk Talk agent who takes card calls, no contract. The app picks up each recording after the call ends, finds the spoken card numbers, and removes them from the audio and the transcript.

The clean recording posts back to the ticket minutes after hangup, and CallTutor deletes the original. Agents don't have to do anything different.

See it on a real call, before and after, or go straight to the setup guide.

Frequently asked questions

What is PCI in a call center? PCI DSS is the card industry's security standard, and it covers the card data your call center records and stores. For phone calls the rule that matters is Requirement 3.2: never keep the security code after authorization, and store the card number only in a form nobody can read.

Can you record calls and still be PCI compliant? Yes, if the security code does not stay in the recording and any card number in it is unreadable. The phone guide says that if your pause tool cannot keep the audio from being stored, the security code "MUST BE DELETED from the recording as soon as the transaction is processed." The three ways in the table above cover it: keep the number off the call, pause and resume, or remove it after the call.

Is taking a credit card over the phone PCI compliant? Yes, as long as the number does not stay anywhere readable afterward. See the three ways above.

Does encrypting the recordings make them compliant? No. The phone guide says the security code must not be stored after authorization "even if encrypted." Encryption protects the file from outsiders. It does not change what is in the file.

What about an outsourced call center (BPO)? A BPO is still your problem. The phone guide warns that "gaps in security coverage can occur when call and screen-recording services are provided by a third party." It encourages you to ask the operator how they remove the security code from recordings, preferably automatically. One thing the guide does not say: ask them to play you a recording with the security code removed.

---

Sources: PCI Security Standards Council, Protecting Telephone-Based Payment Card Data, version 3.0, November 2018; Visa, What To Do If Compromised, version 10.0, effective 25 June 2026; Zendesk, call transcription FAQ; Vice, One Million Bank Phone Calls Found in Exposed Server, 2019. The call statistics combine all our customers, and we do not disclose any one customer's data. This page explains the standard in plain English, not as legal advice, and your merchant agreement is the document that binds you. The cover photo is an illustration we generated, not a real customer or agent.