Taking credit card payments over the phone is one of the more lightly-regulated payment channels in the US — until something goes wrong. There's no federal equivalent of Europe's Strong Customer Authentication mandate, no FCA-style payment-services regulator, and no single set of telephone-payment rules sitting on a federal statute book. What you get instead is a layered model: PCI DSS as the operational floor, the FTC's Section 5 authority as the unfairness-and-deception backstop, a patchwork of state recording-consent laws, breach-notification statutes in every state, and your acquirer's MOTO interchange rules deciding what each transaction actually costs you.
This guide walks through each layer in the order it tends to bite, so a US business setting up a phone payment process — or auditing the one it already runs — knows what to satisfy and where the real exposure sits. We've been a PCI DSS Level 1 service provider for US and international call centers since 2016, and we run phone payment flows for clients processing thousands of card transactions a day. Most of what's below is what we've watched go wrong in the field.
PCI DSS: the floor, not the ceiling#
Looking for the full pillar guide? Our complete walk-through on taking credit card payments over the phone covers every method (DTMF masking, channel separation, IVR), the SAQ D → SAQ A descope, costs, and a buyer's checklist — read it alongside this post.
PCI DSS is set by the Payment Card Industry Security Standards Council, backed by Visa, Mastercard, American Express, Discover and JCB, and enforced through your merchant agreement with your acquiring bank. v4.0.1, mandatory since 31 March 2025, is the version that applies in 2026. It's not federal law and the FTC doesn't enforce it directly, but in practice every US merchant taking card payments has agreed to PCI compliance in writing as a condition of accepting cards.
The central issue for phone payments is where the card data goes during a transaction. When a customer reads their card number to an agent, the data passes through your telephony system, your agent's workstation, and your payment processing infrastructure. Every system that touches that data — including call recording platforms — falls within your PCI cardholder data environment and must meet the relevant requirements.
v4.0.1 added explicit requirements around DTMF tones. If your telephony system logs raw audio including keypress tones, those logs may contain card data entered via keypad, and they must be treated under the same controls as other cardholder data. This catches out businesses that assumed keypress-based entry was automatically safe — it's only safe if the DTMF tones are actively suppressed before they can be captured.
The standard also addresses call recordings directly. Sensitive authentication data — including the CVV/CVC — must not be stored post-authorization. If your call recordings capture a customer reading out their CVV, those recordings contain sensitive authentication data and must either have the CVV portion redacted or be handled under strict access and retention controls.
Which Self-Assessment Questionnaire you need to complete depends on how you handle card data. Businesses where agents take card numbers verbally and enter them into systems typically need SAQ D, which runs to around 329 requirements. Those that have moved to DTMF-based capture systems — where card digits go directly to a certified payment processor without passing through the agent or internal network — can often qualify for SAQ A or SAQ A-EP, because their scope is genuinely reduced.
Call recording consent — the layer most teams underestimate#
Recording phone calls in the US sits on two stacked rules. Federal wiretap law (18 USC § 2511) is one-party consent: if at least one party to the call knows the recording is happening, it's lawful at federal level. That's usually the business, because the business is the one doing the recording. So far, so easy.
Then come the states. About a dozen US states are two-party (or all-party) consent — California, Connecticut, Delaware, Florida, Illinois, Maryland, Massachusetts, Michigan, Montana, Nevada, New Hampshire, Pennsylvania, Washington, and (depending on how you read the case law) Oregon. In those states every party to the call has to be made aware the call is being recorded, or you've broken state law and you're exposed to civil penalties and, in some, criminal liability.
For a US call center handling inbound calls from across the country, the practical answer is to assume two-party consent applies on every call. That's why the standard "this call may be recorded for quality and training purposes" disclosure has become a fixture — it's the cheapest way to be safe regardless of where the caller is sitting. The disclosure has to be at the start of the call, before any conversation that could be considered sensitive, and the caller has to have the chance to hang up if they object.
When payment data is involved, the disclosure obligation goes further. A customer who's told their call may be recorded should understand what that means for their card details. Businesses that record calls routinely should consider whether their standard notification adequately describes what happens to payment data — and whether the recording actually needs the card portion in it at all.
The pause-and-resume approach — manually stopping the recording while the customer reads card details — is widely used but unreliable. When agents forget to pause, card details enter the recording archive. A single forgotten pause creates a compliance incident across PCI, state privacy law, and the FTC's deception authority all at once. Technical solutions that prevent card data from reaching the audio channel — DTMF masking, where the customer enters card digits via keypad and the tones are suppressed before they can be recorded — are more reliable than procedural controls that depend on agent behavior.
FTC scope: the deception backstop#
The Federal Trade Commission has Section 5 authority over "unfair or deceptive acts or practices" in commerce. They've used it repeatedly against US businesses that took card payments and either misrepresented their security posture or failed to maintain reasonable security around stored card data. The cases that draw the largest penalties typically combine a public claim about security (a privacy policy, a marketing page, an SLA) with actual practice that fell visibly short of the claim.
For a phone-payment business this lands in two places. The first is the security disclosures on your website and in your contracts — if you say card data is encrypted in transit and at rest, it needs to actually be. The second is incident response. The FTC pursues businesses that handled breaches badly more often than businesses that prevented them perfectly. Knowing what was breached, telling affected customers promptly, and demonstrating a coherent remediation plan all matter at FTC enforcement time.
The honest path through Section 5 exposure is to design the system so the claims you make about it are demonstrably true. If you've descoped your call center to the point where card data never enters your network, claims about not storing card data hold up cleanly. If your architecture still relies on agents and recordings to keep PAN out of storage, every internal failure becomes a Section 5 risk.
Want to see this working in your setup? Book a working-demo call — we'll wire up your actual phone system and show you a live capture.
State privacy laws — the consumer-data overlay#
California (CCPA/CPRA), New York (SHIELD Act), Virginia (CDPA), Colorado (CPA), Connecticut, Utah, Texas and over a dozen others have enacted general consumer privacy laws that overlap with payment data. The threshold question on each statute is what counts as protected information and what constitutes a breach.
For most of these laws, an unencrypted card number combined with the cardholder's name triggers breach notification. Some go further. Illinois BIPA pulls in voice biometrics, which matters if your QA stack does speaker recognition — voice fingerprints captured during a payment call can themselves become regulated data under BIPA.
The 50-state breach-notification patchwork is the operational headache. Notification windows range from 30 to 90 days depending on the state. Some states require AG notification at a low threshold; others only at large counts of affected residents. If a US call center handling customers nationwide has a card-data breach, the legal team is going to be writing notification letters under a dozen statutes at once.
The defensive answer is the same as for PCI: if card data never enters your environment, the data class that triggers most of these statutes isn't yours to lose.
MOTO interchange — what each transaction actually costs you#
Phone-payment transactions in the US clear under the card brands' MOTO (Mail Order / Telephone Order) interchange categories, which sit alongside but distinct from card-present and ecommerce interchange. For Visa they're the "Card Not Present" tiers, for Mastercard they're the "MOTO" range; either way they're priced higher than card-present and broadly comparable to standard ecommerce.
What moves a transaction within MOTO is the data quality submitted with it. AVS (Address Verification Service) on the billing address, CVV captured at point of sale, and risk-screening data attached to the authorization message can keep a transaction in the standard MOTO tier. Missing those, or sending a transaction with stale data, can trigger downgrade to a more expensive tier — sometimes adding 50 to 80 basis points to the interchange cost per transaction.
For a call center this has a real implication. If your DTMF masking flow captures the card number cleanly but skips the CVV (because the CVV would have to be spoken aloud and then it ends up on the recording), you're descoped on PCI but you're paying downgrade rates on every transaction. The right architecture captures both the PAN and the CVV via keypad through the masking layer, so the data quality stays high and the transaction clears at the standard MOTO tier. Across a year of phone payments at scale, that interchange difference is the conversation worth having with your acquirer.
ACH as the alternative#
For US businesses that take recurring or large-ticket phone payments, ACH (Automated Clearing House) is worth keeping in the picture. NACHA — the rule-making body for ACH — runs WEB and TEL authorization standards specifically for telephone-initiated debits, and the per-transaction cost is dramatically lower than card MOTO interchange. The trade-off is settlement timing (1-3 business days versus near-real-time on a card auth) and a different risk profile around chargebacks.
For utility bills, B2B invoices, and any payment over $500 where the customer is comfortable with their checking account, offering ACH alongside card as a phone-payment option can lower acquiring costs sharply without much UX disruption. The NACHA TEL rules require a recording of the customer's authorization (or a verifiable equivalent) — which loops back to recording consent if you're operating in a two-party state, and which interacts with PCI scope if you're storing those authorizations in the same archive as your card-payment recordings.
How these layers connect#
The overlapping nature of these frameworks means that a single architectural decision — how to handle call recordings — has implications across PCI, state recording-consent law, state privacy law, and the FTC's deception authority all at once. A call recording containing a card number is a PCI DSS problem (sensitive authentication data), a state privacy problem (personal data needing protection), a recording-consent problem if the customer wasn't told their card data was being captured to a long-term archive, and an FTC Section 5 problem if your public claims said something different.
Solving the recording problem once addresses all of them. If card data never enters the audio channel — because the customer enters it via keypad and the DTMF tones are suppressed — there's nothing to redact, nothing to secure in the archive, and nothing to explain to the customer about how their data was handled. The compliance surface area shrinks considerably.
Paytia is built for this. Our DTMF masking infrastructure means card data bypasses the agent and the call recording entirely. Because we're a PCI DSS Level 1 certified service provider, the card data processing sits under our certification rather than yours. Your PCI scope drops to SAQ A territory, your state-law breach exposure on card data falls away because the card data isn't in your environment, your call recordings stay clean, and your FTC narrative becomes simple to defend. Paytia has processed over $500M in card payments under this architecture and our US office is at 447 Broadway, New York.
What to do next#
If you're not certain where your telephone payment process currently stands against these requirements, the cheapest first move is to walk through a real call with your QSA or internal compliance lead and document where the card data goes second by second. Most teams find a hop they hadn't realized was in scope. From there, the conversation is whether the next architecture move is full DTMF masking on assisted calls, IVR for repeat collections, ACH for high-value recurring billing, or some combination — and which acquirer relationship gets you the best MOTO interchange profile for whatever mix you land on.
PCI-compliant phone payments without rebuilding your call center
Paytia integrates with Five9, NICE CXone, Amazon Connect, RingCentral, Talkdesk, Zoom, 3CX, and most major call-center platforms. PCI DSS Level 1 since 2016. Most setups go live within days.
