TL;DR
A TCPA compliant IVR for payments has to clear three bars at once: prior express written consent for any autodialed call to a mobile, a clean opt-out that works inside the menu and not just at the live-agent layer, and a card-capture flow that never lets the prompts or recordings touch PAN. Get those three right and you can take payments from a mobile number without lawyering up for every collections campaign.
Last updated: 29 May 2026
If you run an outbound payment IVR in the US — collections, billing reminders, renewals, anything that dials a mobile and then offers "press 1 to pay" — the TCPA is the single biggest legal risk in your stack. It's not PCI. PCI fines you in the tens of thousands. The TCPA fines you $500 to $1,500 per call, per violation, and the plaintiffs' bar runs class actions for sport. We've worked with US contact centres that thought they were fine because their dialler was "manual click-to-dial" and the consent text was buried on page 14 of a paper application. They weren't fine. They were one demand letter from a seven-figure settlement.
This guide walks through how we build a TCPA compliant IVR for card-not-present payments. Not a generic "here's what the TCPA says" overview — a step-by-step on the consent record, the dialler config, the IVR menu wording, the opt-out path, the recording rules, and where DTMF masking sits inside all of it. If you want the strategic context first, our TCPA compliance guide covers the legal landscape; this piece is for the person actually configuring the IVR next Tuesday.
What "TCPA compliant IVR" actually means in 2026#
An IVR is an Interactive Voice Response system — the menu the caller hears that takes DTMF keypresses or speech and routes the call. A payment IVR adds card capture: the caller enters the PAN, expiry, and CVV on the keypad, the system tokenises it, hits the processor, and reads back the result. So far so simple. The TCPA layer changes everything because the moment that IVR is involved in an outbound autodialled call to a cell phone, you've moved from "payment compliance" into "telemarketing law," and the rules are different.
The Telephone Consumer Protection Act of 1991 was written for the fax machine era and got rebuilt by the FCC across 2003, 2012, 2015, and most recently 2024. The current state of play: any call to a wireless number that uses an autodialler (ATDS) or an artificial or prerecorded voice needs prior express consent. If the call is for marketing, the consent has to be in writing. Payment reminders for a debt you actually owe sit in a grey area called "transactional" or "informational" — you still need consent, but it doesn't have to be written.
The 2024 one-to-one consent rule rewrote the lead-generation playbook, requiring consent to name the specific caller rather than "trusted partners." That rule was vacated by the Eleventh Circuit in January 2025, then reinstated in parts via FCC rulemaking. As of this writing the field is messy — if you're operating an outbound IVR campaign in 2026, assume one-to-one consent is the safer floor, and revisit with counsel quarterly. We're not your lawyers and this isn't legal advice; we build the system that makes whatever your lawyers say enforceable.
For the payment IVR specifically, "TCPA compliant" means five things at the system layer: the consent is captured and timestamped, the dialler can prove it consulted that consent before placing the call, the IVR opens with a clear caller identification, the opt-out works inside the menu without requiring a live agent, and the call recording captures the consent confirmation but never captures the PAN or CVV. Each of those has a concrete config behind it.
The consent record — what the IVR needs upstream#
Your IVR is downstream of consent capture. It can't fix bad consent, but it absolutely depends on the consent record being clean, queryable, and tied to the specific phone number you're about to dial. The minimum we recommend for a payment IVR campaign:
Capture the consent at a clearly identified opt-in event — web form, paper contract, IVR-based verbal consent recording, or in-person signed disclosure. Store the exact language the consumer agreed to. "I agree to receive automated calls and text messages from Acme Collections at the number above regarding my account, even if that number is on a do-not-call list" is the kind of phrasing courts have upheld. Vague "you may be contacted" clauses lose every time. The full text matters; capture and store it verbatim alongside the timestamp, IP address (for web), or recording URL (for verbal).
Tie the consent to the phone number, not just the account. This is where lots of teams trip up. A customer can have three numbers on file: home landline, work, mobile. Consent for one isn't consent for the others. The TCPA's cell-phone rules apply to whichever line they answered the autodialled call on. Your CRM needs a consent flag per number, with the source, language, and timestamp on each.
Honour revocations across every channel. If a customer says "stop calling me" to a live agent on Monday, the IVR can't autodial them on Wednesday because the revocation lived in the agent's call notes and not in the dialler suppression list. The FCC's 2024 revocation rule made this explicit: any reasonable method of revoking consent is valid, and the suppression has to propagate within ten business days. Honestly, ten business days is generous — we configure clients for same-day propagation through a webhook from the CRM to the dialler suppression DB.
Refresh consent on long-tail accounts. Consent doesn't expire by statute, but the FCC and several federal courts have suggested that consent given five years ago for a one-time purchase doesn't reasonably cover a debt-collection campaign in 2026. We re-prompt for fresh consent on accounts dormant more than 18 months, captured via web portal or signed letter before the IVR campaign launches.
Dialler and IVR architecture — the call flow that survives a TCPA audit#
A TCPA compliant outbound payment IVR has a specific call flow. We've drawn it on whiteboards for clients enough times that the pattern is now muscle memory. The legs:
The dialler queries the consent DB and the DNC suppression list before placing the call. Pre-call, not post-connect. The query needs to come back with three things: is this number consented, when was consent given, and is it on any suppression list (federal DNC, state DNC, internal opt-outs, litigator list). If any flag fires, the number is skipped — not flagged for review later, skipped. Manual review of skipped numbers is a separate process that runs offline.
The dialler must be configurable as "manual" or "predictive" — and "manual" has to mean human-initiated for every call, not just "a human pressed a button at the start of the campaign." The FCC has taken the position that a human in the loop must exercise meaningful choice about whether to place each call. Some safe-harbor diallers show the rep the next number, force a click-to-dial, and timestamp the click. That click is your audit defence. Predictive diallers are easier operationally but they're a per se ATDS — they need explicit prior express consent for every wireless number.
When the call connects, the IVR opens with a clear identification: "This is Acme Collections calling about an account ending in 4321. This call may be recorded for quality and training purposes. To make a payment, press 1. To speak with a representative, press 0. To be removed from our calling list, press 9." That opening does four compliant things at once: identifies the caller, identifies the purpose, gives consent for recording, and surfaces the opt-out before any other choice.
The opt-out path matters more than people realise. "Press 9 to be removed" has to do exactly that. The system needs to write the suppression record before it disconnects — not log a request that a back-office team processes later. We've seen IVRs where pressing 9 just played "Thank you, you'll be removed from our list" but didn't actually update the dialler suppression DB. That's a TCPA violation on every subsequent call to that number, and class-action plaintiffs love finding that pattern.
If the caller presses 1 to pay, the IVR captures the payment via DTMF masking — the prompts say "please enter your card number," the caller's keypresses are intercepted, suppressed from the call audio, and passed encrypted to the payment processor. The IVR receives back an authorisation code, reads it out, and ends with "your payment is authorised, transaction reference is 12345, you'll receive a confirmation by SMS." The call recording captures "please enter your card number" and silence — not the digits.
DTMF masking inside a TCPA compliant IVR — why both matter together#
This is where TCPA compliance and PCI DSS compliance overlap, and it's the part most generic TCPA guides miss. If you're running an outbound payment IVR, you've got two simultaneous compliance regimes pointing at the same call: the TCPA on "can you make this call at all," and the PCI DSS on "what happens to the card data once the call connects."
Without DTMF masking, your IVR captures the keypresses into the call audio stream. The call recording, which TCPA best practice says you should keep for evidence of consent confirmation and opt-out handling, now contains the caller's PAN. That recording is in scope for PCI DSS Requirements 3.2 (no storage of CVV) and 3.4 (PAN must be unreadable). You've solved one compliance problem and created another — and PCI fines compound monthly until you remediate. Our piece on call recording and PCI compliance goes deeper on the audit trap.
With DTMF masking via channel separation, the IVR audio prompts and the caller's voice stay in the call recording for TCPA evidence; the keypresses are pulled out of the audio stream upstream, sent encrypted to the processor, and never written to disk. The recording shows "please enter your card number" followed by a few seconds of silence followed by "please enter your CVV" followed by more silence followed by "thank you, your payment is authorised." That recording satisfies TCPA evidentiary needs and removes the IVR platform from PCI scope at the same time. Our DTMF masking solution is built for exactly this dual-compliance pattern.
The reason this matters for IVR specifically and not just live-agent payments is the audit defence. In a TCPA dispute, plaintiffs' lawyers will subpoena your call recordings. If you've configured the IVR to record the full call, you'd better hope DTMF masking is doing its job, because otherwise you're handing the other side a bag of PANs that proves your PCI compliance is fictional and your TCPA defence rests on the credibility of a system that already failed one audit.
The IVR menu wording — what to say, what not to say#
IVR menu wording is where lots of contact centres slip. The TCPA doesn't dictate exact phrasing, but court decisions and FTC consent decrees have drawn a clear pattern of what works and what gets you sued.
Identify yourself in the first sentence. "This is Acme Collections" not "This is an important message about your account." The FCC's 2013 ruling made disclosure of the calling party an explicit requirement under TCPA §64.1200(b). Saying "Acme" without context isn't enough either — if your trading name and your legal entity differ, use the legal entity. The recipient needs to know who is calling and why before any other content plays.
State the purpose. "Calling about your account" is fine; "calling with a special offer" triggers the marketing rules even if you don't think of yourself as marketing. For payment IVRs the purpose phrasing matters because it determines whether the call is informational (lower TCPA bar, oral consent okay) or marketing (written consent required). Phrase it as "calling about an outstanding balance" or "calling about your upcoming payment" — specific, transactional, and tied to an existing relationship.
Offer the opt-out before the payment prompt. The natural temptation is to put "press 1 to pay" first because that's the conversion goal. Don't. The opt-out should be in the first menu — "press 9 to be removed from our calling list, press 1 to make a payment, press 0 for an agent." Putting the opt-out behind a sub-menu is the kind of dark pattern that ends up cited in TCPA complaints. The FCC's 2024 revocation rule explicitly requires opt-outs to be "simple" and not require the consumer to listen through extensive menus.
Skip the recording disclosure on inbound payment lines; include it on outbound. Inbound calls don't trigger TCPA at all (no autodialler, the consumer initiated). Outbound payment IVRs trigger the federal two-party consent question — the federal rule is one-party consent but eleven states (California, Florida, Illinois, Maryland, Massachusetts, Michigan, Montana, Nevada, New Hampshire, Pennsylvania, Washington) require all-party consent for recording. Your IVR is calling across state lines; you don't know which state the caller is sitting in. Disclose the recording on every outbound call. "This call may be recorded for quality and training purposes" is the standard phrasing; it doesn't need explicit consent under federal law but it satisfies the strictest state rules.
Calling hours, frequency caps, and the FCC's 2024 rules#
The TCPA restricts calling hours to between 8am and 9pm in the called party's local time zone. For an outbound payment IVR, that means your dialler needs to know the area code of the destination number and convert to local time before placing the call. Most diallers do this automatically; check yours actually does. We've seen client setups where the dialler was set to UTC and called Hawaii numbers at 6am local. That's a per-call TCPA violation regardless of consent status.
Frequency caps matter too. The TCPA doesn't have a hard federal cap, but the FCC and several courts have treated "persistent" or "harassing" call patterns as evidence of bad faith. The practical limit most compliance teams set: no more than three attempted calls per day to the same number, no more than seven per week. Some state laws are stricter — Florida and New York have caps at three per week for collections-related calls under state mini-TCPA statutes. Configure the dialler to honour the strictest applicable rule based on destination state.
The FCC's 2024 rulemaking added a quiet-period provision for revoked consent: once a consumer revokes, you must cease calls within ten business days. For payment IVRs that touch the same numbers over long campaigns, ten days is a long time. We default clients to 24 hours — the dialler suppression list updates nightly from the consent DB, and any revocation captured before 8pm is in suppression by 8am the next morning. That's defensible; ten business days is borderline.
State "mini-TCPAs" are the variable layer. Florida's Telephone Solicitation Act, Oklahoma's Consumer Protection Act, Washington's CEMA, Maryland's Telephone Consumer Protection Act — each adds requirements on top of the federal rules, and several have private rights of action with per-call damages. If you're calling all 50 states, the dialler config needs to apply the strictest rule per destination. A good rule of thumb: configure to Florida + California floors, and you're broadly compliant nationally. Our TCPA vs FCC robocall rules piece breaks down how the federal layer and state layer interact.
Recording, retention, and the audit trail#
Call recording is where TCPA meets PCI meets state recording law, and the configuration that satisfies all three takes some thought.
Record the consent confirmation explicitly. If your IVR captures verbal consent at the top of the call — "to confirm you agree to receive automated payment calls from Acme, please say yes or press 1" — that recording is the cornerstone of your TCPA audit defence. Keep it for the federal TCPA statute of limitations (four years) plus a margin. We recommend seven years; storage is cheap, litigation is not.
Don't record the PAN entry. DTMF masking handles this technically; verify it monthly by pulling a random sample of recordings and confirming the keypresses are absent. If your masking layer goes down silently and you record three months of PANs into your recording archive, you've created a PCI breach event with the legal complication of having to notify every cardholder whose data was retained.
Retain the dialler logs separately. The dialler should produce a per-call log showing: destination number, consent status at time of call, suppression list status, time of call, duration, disposition (answered, no-answer, IVR-completed, opt-out, payment-authorised). Retain these logs for the same seven-year window as the recordings. They're often more useful in TCPA defence than the audio because they prove the pre-call check happened.
Build a single "TCPA audit pack" generator. When the demand letter arrives, you want a script that pulls: the consent record (timestamp, language, source), the suppression status at time of call, the dialler log entries for the disputed call, the call recording, and the post-call disposition. If your team can produce that pack in under an hour, your TCPA defence posture is in good shape. If it takes three days because the data is split across four systems, you're already losing.
One-to-one consent and the 2025 vacatur — what to do now#
The FCC's December 2023 one-to-one consent rule was supposed to take effect 27 January 2025, but the Eleventh Circuit vacated it in Insurance Marketing Coalition v. FCC on 24 January 2025. The FCC then proceeded with parts of the rule via separate rulemaking. As of mid-2026 the picture is: lead generators can't bundle consent across "trusted marketing partners" indefinitely, but the strictest one-to-one floor has bounced around in courts and FCC reconsideration.
Practical guidance for payment IVR campaigns: don't rely on third-party lead consent. If you bought leads with consent given to a marketing aggregator, the chain of consent from "agreed to be contacted by trusted partners" to "agreed to receive automated payment IVR calls from Acme Collections" is fragile. Re-paper it with direct opt-in via your own web form or written contract before launching the IVR campaign.
Same goes for in-house consent that's been around for years. Consent given on a 2019 web form for a product purchase doesn't reasonably extend to a 2026 outbound IVR campaign about an unrelated debt or renewal. The TCPA doesn't have a sunset clause for consent, but plaintiffs' lawyers and the FCC have both signalled that "stale" consent loses on the merits. We default clients to re-prompting consent on accounts dormant more than 18 months and on any campaign whose purpose materially differs from the original consent context.
Common configuration mistakes we see in audits#
Most of the TCPA exposure we find when auditing client IVR setups falls into one of five buckets, in rough order of how common they are.
Opt-outs that don't propagate. The IVR captures the press-9, plays the "you'll be removed" message, but the suppression update is a nightly batch job that fails silently when the source DB schema changes. We've seen 60-day gaps where opt-outs were captured but not applied. That's 60 days of TCPA violations on every redial.
Suppression checks at campaign load, not at dial time. The dialler loads a campaign at 8am, applies suppression filters against the 7am suppression snapshot, and dials from that filtered list throughout the day. Any consent revocation captured at 10am isn't applied until tomorrow's campaign load. Fix: check suppression at dial time, not load time.
Time-zone misalignment. The dialler thinks all numbers are local; calls go out at 6am to West Coast numbers because the dialler's clock is Eastern. Or the area code lookup hasn't been updated since the latest NANP releases and 463 area code numbers get classified wrong.
PAN-in-recording. DTMF masking is configured but the failover is recording-on. When the masking layer fails or restarts, the IVR records the keypresses for the duration of the outage. We've seen one client with 45 minutes of recorded PANs from a single masking outage in 2024. Fix: failover to no-payment mode (the IVR says "we're unable to process payment right now, please call back later") not record-the-PAN mode.
Consent records with no language captured. The DB has a consent_given_at timestamp but not the exact opt-in language. In a dispute, the plaintiff's lawyer asks "what specifically did my client agree to," and the answer "we don't have the wording, but they agreed" loses. Capture the verbatim language at consent time and store it indefinitely.
Testing and validating the IVR before campaign launch#
Pre-launch testing on a TCPA compliant payment IVR is where you catch the bugs that turn into class actions. We recommend a four-stage test cycle for every new campaign or material config change.
Stage one is consent-path testing. Pull a sample of 50 numbers across the consent statuses your system tracks — fresh written consent, fresh oral consent, stale consent (more than 18 months), revoked consent, no consent on file. The dialler should attempt only the first two and skip the rest. Cross-check the dialler log against the consent DB for every attempted number. If any "no consent" number was dialled, the suppression logic is broken and you don't launch until it's fixed.
Stage two is opt-out testing. Take a test number with consent, place it through a full IVR flow, press the opt-out key, then attempt to re-dial the same number from the same campaign within five minutes. The second call should be blocked at the pre-dial suppression check. If it goes through, your real-time suppression is broken — typically because the suppression update is queued for batch processing rather than written through to the live DB.
Stage three is recording validation. Run ten test transactions through the IVR with known card numbers (use test PANs from your processor's sandbox — never real cards in test). Pull the audio recordings and listen for the keypresses. If you can hear DTMF tones in the recording, the masking is misconfigured. The recording should contain the prompts and silence where the entry happens, plus the final confirmation. While you're at it, pull the dialler log and the consent record for each test call to confirm the audit pack assembles correctly.
Stage four is calling-hours and frequency-cap testing. Schedule test calls outside the destination time zone's permitted window — the dialler should refuse to place them. Force-queue more than the configured per-day limit to a single test number — the cap should kick in. State-specific tests matter too: queue test calls to Florida, California, and New York numbers and verify the state-specific rules apply (Florida's 8pm cutoff, California's all-party recording rule, New York's separate state DNC).
Run this four-stage cycle on every campaign launch and after any material change to the dialler config, the consent DB schema, the IVR menu wording, or the suppression list propagation logic. Document the test results in a pre-launch sign-off pack — it's also useful in TCPA defence as evidence of your compliance posture.
Working with the FCC's call-blocking and known-bad-actor rules#
Beyond the consent and opt-out rules, the FCC has built out a call-blocking regime that affects outbound payment IVRs even when consent is clean. STIR/SHAKEN call authentication, the Robocall Mitigation Database, and voice-service-provider blocking rules all sit between your dialler and the destination handset, and they can block legitimate compliant calls if your origination posture is wrong.
If your dialler is configured to spoof a different caller ID — say, presenting a customer-service inbound number rather than the outbound campaign's actual originating number — STIR/SHAKEN will sign the call at attestation level B or C, which voice carriers increasingly treat as suspicious. The fix is to present a caller ID that's verifiably yours and registered in the Robocall Mitigation Database. Most legitimate contact centres should be at attestation A, which requires the originating provider to have a verified relationship with the calling party and the right to use the caller ID.
Carrier-level blocking is a real risk too. T-Mobile, Verizon, and AT&T all run analytics-based blocking that flags numbers showing patterns associated with scam or robocall traffic — high call volume, low answer rate, frequent short-duration calls, complaints from recipients. Even a compliant campaign can get a number flagged if the patterns look similar. If your numbers are getting blocked, register them with the Free Caller Registry and submit complaints through the carrier-specific dispute portals. Burning through dialler numbers because they keep getting blocked is a sign the upstream campaign is touching uninterested recipients — fix the targeting before you fix the numbers.
The 2024 FCC ruling on consent revocation also covered "reasonable methods" — consumers can revoke via voice, text, or any reasonable channel. For payment IVRs that means your inbound 800 line, your customer-service email, your web portal, your SMS reply handler, and your IVR opt-out menu all need to feed the same suppression DB. The dialler doesn't care which channel the revocation came through; it cares whether the destination number is in the suppression list at dial time. Centralise the suppression DB and feed it from every consumer-facing channel.
How Paytia plugs into a TCPA compliant payment IVR#
We're not a TCPA platform — we're a PCI Level 1 service provider that sits behind the IVR doing the card capture. The split is clean: your dialler and IVR platform (Five9, Genesys, NICE, Vonage, custom on Twilio or Amazon Connect) handles the TCPA layer — consent enforcement, suppression, calling hours, opt-out propagation. Paytia handles the moment of card entry — the DTMF masking, the tokenisation, the processor handoff, the recording suppression of card data.
For US contact centres that means three things. One, your IVR platform doesn't enter PCI scope because the card data never reaches it — we intercept upstream. Two, your call recordings are TCPA-evidence-clean and PCI-safe at the same time — the audio shows consent confirmation and opt-out handling but no card digits. Three, your audit posture for both regimes converges — one architectural change, two compliance regimes solved together. Clients like Pinnacle Group cut their PCI scope 95% using this pattern; the same architecture removes the PCI tail risk from TCPA-compliant IVR operations.
For the operator running the campaign, the integration is light. The dialler connects the call to the customer; when the IVR prompts for card entry, the IVR initiates a Paytia capture session via API; the keypresses are intercepted by our masking layer and never reach the IVR audio; we return a token and an authorisation code; the IVR confirms the payment to the caller. Total setup time on a campaign of typical complexity is two to four weeks including testing.
Next steps#
If you're running an outbound payment IVR in the US and you've read this far, you've probably spotted at least one config you want to revisit. Start with the suppression-at-dial-time check, the opt-out propagation latency, and the DTMF masking failover behaviour — those three together cover the majority of the TCPA + PCI tail risk we see in audits.
If you want a second pair of eyes on the architecture, book a 15-minute walkthrough of our DTMF masking + IVR integration or talk to our compliance team directly. We can show how the consent capture, the dialler config, and the card-capture leg fit together without you having to scope a full proof-of-concept. The pillar piece on TCPA compliance for payment calls is the wider read; how to capture TCPA consent for payment calls covers the upstream consent record in more detail; and TCPA penalties: worst-case scenarios covers what happens when this goes wrong. Our IVR payments solution page has the architecture detail.
