Quick answer: taking card payments over the phone is fine under PCI DSS. What matters is how the card number travels. If your agents hear it, type it, or your call recordings capture it, your phone system, recordings, agent desktops and staff all fall inside PCI DSS scope. The compliant patterns keep the card number out of your environment entirely: the caller types it on their phone keypad and the digits route straight to the payment gateway (agent-assisted DTMF capture), or the caller pays through an automated IVR flow with no agent on the line. Implemented correctly, both patterns take those systems out of scope and cut your compliance validation down to a fraction of the alternative.
Phone payments are a card-not-present channel the card brands call MOTO (mail order / telephone order). Every business that takes them has the same tension: the phone is where payments actually complete, and it's also the channel where card data most easily leaks into systems that were never meant to hold it. This guide covers what PCI DSS actually requires for phone payments, the patterns that keep you compliant, what US call recording laws add on top, and how to choose between the approaches.
Why phone payments create a PCI problem
PCI DSS applies to every system that stores, processes or transmits cardholder data, plus everything connected to those systems. The PCI Security Standards Council's guidance on telephone payments is explicit: when card numbers are spoken on a call, the "telephony environment" is in scope. That means:
Your phone system. VoIP platforms, SIP trunks and call routing all carry the spoken card number.
Your call recordings. A recording that captures a card number is stored cardholder data. Storing the security code (CVV) after authorization is prohibited outright, in any form, recording included.
Your agents' desktops. If the agent types the number into a virtual terminal, the workstation, its network and everything connected to it are in scope.
Your people. Staff who hear or see card numbers become part of the compliance surface: vetting, training and monitoring all follow.
For a business taking a handful of phone payments a month, that scope might be manageable. For a call center taking hundreds a day, it means the whole operation lives inside the card data environment, with the assessments, controls and audit burden that brings.
The compliant patterns, compared
There are three established ways to take a card payment on a phone call while keeping card data away from your people and systems, plus two fallbacks worth having.
Agent-assisted DTMF capture
The agent stays on the call. When it's time to pay, the caller types their card number on their phone keypad. The keypad tones (DTMF) route directly to the payment gateway; the agent's line carries flat tones or silence, and their screen shows only masked progress, so the conversation continues while the card number never enters your phone system, recordings or screens.
This is the pattern to reach for when payments happen inside a conversation: the agent can resolve the query, agree the amount, and take payment without transferring the caller anywhere. It's how DTMF payment capture works in detail.
IVR self-payment
The caller pays through an automated keypad flow with no agent involved: they call in (or are transferred), enter a reference and their card details, and get a confirmation. Because no member of staff is on the line, it's an unattended transaction, and when the IVR is hosted by a validated provider it typically qualifies the merchant for the lightest self-assessment route.
IVR absorbs high-volume, low-exception payments: bill payments, balances, renewals. Agents handle the calls that need a human.
Pause-and-resume recording
The agent pauses the call recording while the caller reads out their card number, then resumes it after. This pattern is widely deployed and can be operated compliantly. Its weakness is operational: the card number still enters your phone system and your agent's ears, so those stay in scope, and the protection depends on the pause actually happening on every call. A missed pause means a recording with a card number in it. Automated triggers reduce that risk; they don't remove the underlying scope.
The fallbacks that save real calls
Phone payments fail in predictable ways, and the compliant answer isn't "read me the number after all":
Payment links. Caller's card is in another room, or the call drops mid-payment: send a link by SMS or email and they finish on their own device.
Bank payment on the call. Caller prefers not to use a card: take a bank transfer without leaving the conversation. See ACH and bank payments over the phone.
What US call recording laws add
PCI DSS is not the only constraint on a US phone-payment operation. Call recording consent is governed by federal and state law, and a number of states, California among them, require the consent of all parties to record a call. Most call centers already handle this with a recording notice, but it interacts with payments in one useful way: patterns that keep card data out of recordings entirely (DTMF capture, IVR) mean your recording practices and your payment compliance stop being tangled together. The recording can run for quality and dispute purposes without ever containing a card number.
What this does to your PCI validation
Merchant PCI DSS validation runs from SAQ A (a short self-assessment for merchants whose card data is fully handled by compliant third parties) up to SAQ D and full on-site assessments (hundreds of controls when card data touches your own systems). Where a given phone operation lands depends on the details and is worth confirming with your acquirer or assessor, but the direction is consistent: keypad capture and IVR patterns that keep card data out of your environment typically support the lighter end of that spectrum, and letting agents hear or key in card numbers pushes you toward the heavy end.
The provider you use matters too: under PCI DSS, service providers that handle card data on your behalf must themselves be validated, and Level 1 is the strictest tier. Our guide to choosing a PCI compliant service provider covers what to check.
How Shuttle handles PCI compliant phone payments
Shuttle provides both compliant phone patterns through one layer:
Agent-assisted capture and IVR self-payment run on Twilio's voice infrastructure. Shuttle is Twilio's chosen provider to enable Twilio Pay for many payment gateways.
Card details are tokenized with the payment gateway itself. Shuttle holds no card vault of its own, so there is no new place where card data accumulates.
Your gateway, not ours. Shuttle works with 40+ payment gateways, so phone payments settle through the merchant account you already have. Voice capture works on many supported gateways; payment links cover the rest.
The fallbacks are built in. Payment links by SMS or email and bank payments on the call, so a failed card moment doesn't become a lost payment.
Multi-client routing. If you take payments on behalf of many clients, each with their own merchant account (billing services, answering services, collections servicers), payments route to the right client's account automatically. See taking payments on behalf of your clients.
Choosing between the approaches
Agent-assisted DTMF | IVR self-payment | Pause-and-resume | Payment link | |
|---|---|---|---|---|
Agent on the call | Yes | No | Yes | Optional |
Card data enters your systems | No | No | Yes (spoken) | No |
Recording can run throughout | Yes | Yes | No (must pause) | Yes |
Best for | Payments inside conversations | High-volume routine payments | Legacy operations | Fallback and async |
Most phone-heavy operations end up running two of these side by side: IVR for the routine volume, agent-assisted capture for the conversations, with links as the recovery path.
PCI compliant phone payments FAQ
Is it legal to take card payments over the phone?
Yes. Phone payments are a standard card-not-present channel (MOTO). The card brands and PCI DSS permit them; the requirements govern how the card data is handled, not whether the channel is allowed.
Can my staff write down card numbers during a call?
They shouldn't. A written card number is stored cardholder data on paper, in scope and hard to control, and writing down the security code is prohibited after authorization in any form. Keypad capture removes the need entirely.
Do call recordings break PCI compliance?
They can. A recording that contains a card number is stored cardholder data, and storing the security code post-authorization is prohibited in any form. Either pause recording during card capture, or use DTMF or IVR capture so recordings never contain card data in the first place.
What's the difference between agent-assisted capture and IVR payments?
Agent-assisted capture keeps a person on the call while the caller types their card number on the keypad; it suits payments that happen inside a conversation. IVR is fully automated with no agent involved; it suits routine, high-volume payments. Both keep card data out of your environment.
Does using a compliant phone payment provider make my business PCI compliant?
It takes the phone channel's heavy lifting off you, but your business still validates its own compliance. The gain is scope: with card data kept out of your systems, your validation typically shrinks to the lighter self-assessment routes. Confirm your exact SAQ level with your acquirer or assessor.
Can I take phone payments for multiple clients through one system?
Yes, if the system supports per-client merchant account routing. Each client connects their own merchant account, and every payment routes to the right one, which matters for billing services, answering services and other businesses collecting on behalf of clients.
Related reading
Virtual Terminal Payments: PCI Rules and Secure Alternatives
DTMF Payment Processing: PCI Compliant Capture, Clamping & Masking
PCI Compliance Service Providers: Levels, Scope and What to Check
Want phone payments out of your PCI scope? Talk to us. If you'd rather explore the technical side first, docs.shuttleglobal.com covers the flows, with sandbox accounts available for testing.