Pause and Resume in Contact Centres | Paytia

Pause and resume is the oldest trick in the contact-centre PCI playbook. It does one job: stop the call recording before the customer reads their card number, then start it again once the payment's done. The recording never contains card data, so the recording storage drops out of PCI scope.

That's useful, but it solves about a third of the problem. The agent still hears the digits. The agent still types them into a payment page. The phone call itself is still carrying cardholder data. And anyone who can listen to the live call - a supervisor on a monitor session, a screen-recording tool, a CCaaS quality-management bolt-on - can capture the card number whether the recording is paused or not.

We see pause and resume on most legacy PCI compliance checklists, and we still see contact centres treating it as their entire control. It's not. Here's how it actually works, what it does cover, and where it leaves gaps that DTMF masking closes.

How pause and resume works

Two flavours: automatic and manual.

Manual pause and resume. The agent clicks a button on their softphone or recording client just before asking for the card number. The recorder stops writing audio to the call file. The agent reads the card details into a payment page or terminal. When done, the agent clicks resume and the recorder starts again. The final stored recording has a gap where the card data would have been.

Automatic pause and resume. Some workforce engagement and recording platforms can detect when the agent has navigated to a specific payment screen in the CRM. When the payment URL or window loads, the recorder pauses automatically. When the agent moves off the payment screen, recording resumes. It removes the human-error problem of agents forgetting to click pause.

Either way, the technical outcome is the same: the audio file for that call has a silent section, or a section the recorder simply didn't write. The cardholder data isn't in the stored recording.

What pause and resume actually solves

The control covers exactly one PCI DSS requirement family: storage of sensitive authentication data (SAD) after authorisation. PCI DSS v4.0.1 is blunt - SAD (which includes the CVV, full track data, PIN block, and in practical terms the rest of the card-not-present payload during the call) must not be stored after authorisation, even if encrypted. Recording an agent reading out a CVV creates a stored copy of SAD. That's a hard fail.

Pause and resume stops that recording happening. Recording storage, transcription archives, and any downstream analytics tool that ingests the audio file all drop out of the SAD problem. That's the win.

What pause and resume does not solve

Three big gaps.

1. The agent still hears the card number

This is the obvious one. Pause and resume protects the recording. It does nothing about the live call. The agent on the line hears every digit. They can write the number down, photograph their screen, or simply remember a few of the high-value cards they take that day. Internal fraud from contact-centre agents is a real and measured category - the cost of contact-centre fraud stays high precisely because the agent is the weak point.

From a PCI DSS scope view, an agent who hears card data is still a person in scope. The workstation they're using is in scope. The network segment that workstation sits on is in scope. None of that changes when you pause the recording.

2. The screen still shows the card number

The agent types the digits into a payment form. The payment form holds the full PAN, expiry, and CVV in browser memory and in the form fields. Screen recording, screen sharing, supervisor screen-monitor sessions, and remote-desktop tools all capture that screen. If any of those are running, you're back in scope - pause and resume on the audio recorder hasn't helped you.

3. Background voices and noise still get captured

Audio recorders that pause don't always pause cleanly. We've seen real recordings where the pause kicks in half a second late, or stops half a second early, and the first or last digits of the PAN are still audible in the stored file. Auditors do listen to samples. If they hear card data in a recording you said was paused, you've got a finding.

Where it fits in a real PCI strategy

Pause and resume is a useful belt-and-braces control alongside something that actually removes the card data from the conversation. On its own, it's a 2008 control trying to pass a PCI DSS v4.0.1 assessment, and it's increasingly being marked down by QSAs who understand contact-centre flows.

The current standard for taking card payments over the phone is to never let the cardholder say the digits aloud. The customer keys their card number into their phone's keypad during the call. The keypad tones (DTMF) are intercepted before they reach the agent, masked into a flat tone, and routed to the payment processor through a separate PCI-compliant path. The agent stays on the line, hears the customer keying digits as a uniform tone, and sees only a tokenised version on screen (asterisks plus the last four).

That removes all three gaps pause and resume leaves open. The recording's clean (no digits ever spoken). The agent doesn't hear the number. The screen doesn't show the number. The CCaaS platform, the recorder, and the agent's workstation are all out of cardholder-data scope.

Pause and resume vs DTMF masking

The practical comparison comes down to who's protected and who isn't:

Pause and resume protects: the recording, the transcript, downstream analytics ingestion of the audio.

Pause and resume does not protect: the agent, the agent's screen, the live audio stream, supervisor monitor sessions, screen recording, the workstation, the network segment, or the CCaaS platform itself.

DTMF masking protects: all of the above. The card data never enters the contact-centre environment at all - it goes straight from the customer's phone keypad to the payment processor.

If you're filling in a PCI SAQ and your only control is pause and resume, you're answering yes to questions you can't actually justify. Most QSAs will pick that up on a desk review before they even visit the site.

When pause and resume is still the right tool

One genuine use case: outbound campaigns where the customer is reading card details from a physical card or a tab on their computer, the call is short, and the contact centre doesn't have a CCaaS integration for DTMF capture. Pause and resume keeps the recording clean while you implement something better. It's a stopgap, not a solution.

The other case is internal calls that happen to touch payments tangentially - billing escalations, refund discussions - where the actual transaction is on a different system and the recording just happens to be live. Pausing keeps the recording defensible. The transaction itself runs through a properly scoped channel.

What a QSA will ask about your pause-resume implementation

If pause and resume is part of your PCI documentation, expect the assessor to ask:

• How does pause trigger - manual or screen-state automatic?
• What's the latency between trigger and recorder stopping?
• How do you sample recordings to confirm no card data leaked in?
• What happens if pause fails (recorder crash, network drop, agent forgets)?
• Who has access to live audio during the paused section?
• Is screen recording on the agent workstation? If so, is the screen capture also pausing?
• How do supervisor monitor sessions interact with pause and resume?

The last three are where most contact centres fail. Pause covers the recorder but leaves the screen capture, the supervisor session, and the agent workstation completely exposed.