US merchants still take a staggering volume of card orders by phone. Collections, renewals, hotel reservations, medical billing, trade counters, utility arrears, professional services. Anywhere the customer has a question or needs a human, the phone wins. And anywhere the phone wins, card data ends up somewhere it shouldn't unless you've actively designed it out.
There are four real ways to take a card payment on a call. They're not interchangeable, and picking the wrong one for your business either costs you more than it should or leaves you carrying PCI scope you didn't need.
Why the agent hearing the card number is the problem
The moment a customer reads their 16-digit card number out loud on a call, three things happen. Your agent hears it, your call recording captures it, and your screen-reading software or call notes capture it. All three drag the systems they touch into PCI DSS scope. Suddenly your recording platform is in scope. Your CRM is in scope. Your phone system is in scope. Your agent's workstation is in scope.
Scope is the expensive bit of PCI. The standard's roughly 300 sub-requirements don't change, but the number of systems they apply to is what drives the cost and the audit burden. Every phone payment approach worth using is, at heart, a scope-reduction design.
Approach 1: DTMF masking
The customer stays on the call with the agent and keys their card number into their own phone keypad. Each keypress generates a DTMF tone, and the masking platform sits in the call path, replaces those tones with a flat monotone for everything downstream, and routes the actual digits directly to the payment gateway.
The agent hears the conversation as normal but hears a beep instead of the card number. The call recording captures the beep. The CRM only ever sees a tokenized response. Because the tones never reach your systems, those systems drop out of PCI scope. This is the approach we run at Paytia, and it's the lightest-touch option for keeping the human conversation going. For the mechanics, our DTMF suppression page walks through it in more detail.
Approach 2: IVR payments
The agent transfers the caller to an automated IVR payment flow. The customer enters their card details into the IVR, which talks directly to the gateway, and the call either returns to the agent or ends.
This is genuinely out-of-scope for the agent environment because the agent isn't even on the line while the card is entered. It's a great fit for self-service scenarios and for high-volume inbound lines where you want the agent off the call for the payment portion. Downside: the customer experience is colder, and if something goes wrong mid-payment they're back in the queue. For collection calls and renewals where the conversation is the point, IVR payments can feel abrupt.
Approach 3: Pause-and-resume
The call recorder pauses while the customer reads out their card details, then resumes once the payment is done. The idea is that the recording doesn't capture PAN or CVV so the recording storage stays out of scope.
It sounds tidy and it is still widely sold. It also solves only half the problem. The agent still hears the number. The agent's workstation still sees it if they're typing it in. The phone call itself, in transit, still carries the PAN. Pause-and-resume can reduce the scope of the recording platform, which is worth having, but it doesn't take agents out of scope and it doesn't take your telephony or desktop out of scope. Treat it as a partial mitigation, not a full solution.
Approach 4: Payment links
The agent sends the customer a secure payment link over SMS or email during the call. The customer taps it, gets a hosted payment page, enters their details, and pays. The agent sees the status update in their CRM when the payment clears.
This is now a mature approach in the US, especially for consumer collections and field services. The card data never touches your phone system at all. The experience is familiar to anyone who's paid a doctor's bill online. Downside: completion rates can drop off if the customer hangs up before paying, and some older demographics find the link flow unfamiliar. A good phone payment platform lets you use payment links as a fallback when DTMF masking isn't the right fit for the call.
How the four compare on PCI scope
DTMF masking and IVR payments both take your agent environment substantially out of scope when implemented properly. Payment links remove card data from the phone system entirely. Pause-and-resume reduces recording scope but doesn't address the telephony or agent workstation. If you're aiming for a short-form attestation like SAQ A, you want one of the first three, not pause-and-resume.
Picking the right approach for your business
For outbound collection and renewal calls where keeping the human in the conversation matters, DTMF masking wins. The agent stays on the line, the customer never has to remember a 6-digit code or navigate an email inbox mid-call, and completion rates stay high.
For high-volume inbound lines where the conversation is largely transactional (bill payment, prescription refill, top-up), IVR payments win on cost-per-call and on scope.
For mobile-first customer bases where the email or SMS workflow is more natural than the phone keypad, payment links win. Trade counters and field-service dispatch have moved heavily toward links over the last three years.
For legacy setups where ripping out the telephony isn't possible, pause-and-resume is better than nothing but shouldn't be the destination.
Most US contact centers we work with end up with a blend: DTMF masking as the default for agent-assisted calls, IVR payments for repetitive transactional calls, and payment links as the fallback when the customer can't or won't enter card digits on the phone. The telephone payments solution overview covers how those three fit together on a single platform.
Contract and telephony dependencies
One thing worth raising with your operations team before you lock in an approach. Every serious phone payment solution sits in the call audio path, which means it interacts with your telephony infrastructure. If you're on a modern cloud contact center like Amazon Connect, Genesys Cloud, Five9, or Talkdesk, the integration is usually a SIP trunk configuration change and an API credential. If you're on a legacy on-premise PBX or a regional telephony provider, the integration may need a media gateway or a middle-hop provider, which changes the vendor shortlist.
The second constraint is your call-recording platform. Some older call-recording products need explicit configuration to respect a pause-and-resume signal or to accept masked media from a third party, and some PCI-forensics products won't see the masked tones as compliant unless the vendor is on their approved list. Ask your recording vendor before you commit. It saves a painful rip-and-replace later.
Card present, card not present, and the phone channel
A quick note on PCI terminology that gets misapplied. Phone payments are card-not-present transactions for interchange purposes, regardless of whether the customer is in front of you or not. That sets the interchange rate tier (CNP rates run higher than card-present) and the dispute-code structure. It also determines which SAQ type applies: a phone-only merchant lands in SAQ A, A-EP, or D depending on how the card data is handled. DTMF masking done properly lands you in SAQ A. Pause-and-resume with agents hearing the PAN typically lands you in SAQ D. That's a ten-times difference in audit burden.
If you're rebuilding a phone payment flow and want help scoping it, we're happy to walk through the options without a sales script.
