The short answer
PCI DSS does not allow card security codes (CVV or CVC) to be kept after a payment is authorised, and that includes audio recordings. Any card number that is stored, in a recording or a transcript, must be protected like any other stored card data. The safest approaches keep card details out of the conversation entirely, through a secure IVR or DTMF masking. Pause and resume only works if it never misses, and transcripts and notes need masking too.
What PCI DSS says about card data on calls
The Payment Card Industry Data Security Standard (PCI DSS) applies to every organisation that stores, processes or transmits card data, and that includes card details spoken on a call. The current version is PCI DSS v4.0.1. The requirements that v4.0 introduced as future-dated became mandatory on March 31, 2025.
| Requirement | What it says | What it means for calls |
|---|---|---|
| 3.3.1 | Sensitive authentication data is not kept after authorisation, even if encrypted. | The card security code must not stay in a recording, transcript or note once the payment is authorised. |
| 3.3.1.2 | The card verification code is not kept once authorisation is complete. | The same rule, for the three- or four-digit code specifically. |
| 3.4.1 | The card number is masked when displayed, showing at most the BIN and last four digits, unless the viewer has a business need. | Transcripts, notes and QA screens should not show full card numbers. |
| 3.5.1 | The card number is rendered unreadable anywhere it is stored. | Full card numbers in recordings or transcripts are stored card data, and the standard applies to them. |
The PCI Security Standards Council's FAQ 1210 is direct about audio: keeping card validation codes in a recording after authorisation breaks requirement 3.3.1. Where codes cannot be kept out of a recording, they should be securely deleted once the payment is authorised.
Where card data leaks on a call
- The recording, when the customer reads out the card number and security code.
- The transcript, if calls are transcribed for QA, analytics or live agent assist.
- Notes and CRM fields, when agents type what they hear.
- Screens and reports, if card numbers appear in a QA tool or a shared report.
- The desk, if agents write numbers down.
Ways to take card payments by phone
| Approach | How it works | Strength | Weakness |
|---|---|---|---|
| Manual pause and resume | The agent pauses the recording before card details and resumes after. | Cheap, and works with most recorders. | Relies on the agent remembering every time. The agent still hears the card number. |
| Automatic pause and resume | The recorder pauses when the payment step starts. | Removes the reliance on memory. | Depends on the payment step being detected. The agent still hears the card number. |
| Secure IVR transfer | The agent transfers the customer to an automated payment line, then takes them back. | Card details never reach the agent or the recording. | Customers can drop off, so the hand-off must be smooth. |
| DTMF masking | The customer keys in the card number; the tones are hidden from the agent and the recording. | The agent stays on the line, and card data stays out of the call audio. | Needs telephony integration and costs more to set up. |
| Payment link | The customer pays through a secure link sent by text or email. | Card data never enters the call. | Not every customer can, or will, use it mid-call. |
The Council's information supplement Protecting Telephone-Based Payment Card Data (v3.0, November 2018) covers these approaches in detail, including DTMF masking and pause and resume.
Don't forget transcripts and AI tools
Many centres now transcribe every call, for QA, analytics or live agent assist. A transcript can contain a card number even when the recording was paused, if transcription ran on the live audio. Treat transcripts the way you treat recordings:
- Mask card numbers and security codes in the text before it is saved, not afterwards.
- Make sure card details are never sent unmasked to an AI model or a vendor's cloud.
- Keep card data out of logs and crash reports too.
- Ask vendors exactly what is masked, where and when, and whether the recording is muted as well as the transcript.
What QA should check on payment calls
- Was the customer moved to the secure payment method before giving card details?
- Did any card number or security code reach the recording, the transcript or the notes?
- Was the payment confirmed back to the customer with the last four digits only?
- If something slipped through, was it reported and deleted under your incident process?
These checks suit automated scoring, because a slip on 1 payment call in 100 is easy to miss in a sample. See how to QA every call.
Where Orian fits
How Orian keeps card data off the record
- When a customer starts reading a card, the agent is prompted to pause and transfer to the secure IVR.
- Card numbers are masked in the transcript before it is saved, and card, bank and ID numbers are muted in the recording.
- Unmasked text exists only in memory, for a moment. The AI model only ever sees masked text.
- Logs and crash reports are scrubbed of content before they are kept.
- Recordings and transcripts stay inside your network, and are deleted when each programme's retention period ends.
This guide is general information about running contact-centre programmes, not legal advice. Rules change and vary by state, country and client contract, so confirm your requirements with your compliance team or counsel.