TCPA-Compliant Payment IVR — Setup Guide

Last updated: 29 May 2026

If you run an outbound payment IVR in the US — collections, billing reminders, renewals, anything that dials a cell phone 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, uncapped, and the plaintiffs' bar runs class actions for sport. We've worked with US contact centers that thought they were fine because their dialer 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 dialer 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 tokenizes 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 autodialed 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 (47 U.S.C. § 227) 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 after the Supreme Court's 2021 Facebook v. Duguid ruling: an "automatic telephone dialing system" (ATDS) now means equipment that uses a random or sequential number generator to store or produce numbers — a narrower bar than the old FCC interpretation. But prerecorded and artificial voice calls still need prior express consent regardless of dialer technology, and any call to a wireless number that uses a prerecorded voice, an artificial voice, or an ATDS needs consent. If the call is for marketing, the consent has to be in writing. Payment reminders for a debt you actually owe sit in the "informational" lane — you still need consent, but it doesn't have to be written.

The FCC's 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 Insurance Marketing Coalition v. FCC in January 2025, then reinstated in parts via subsequent 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 dialer 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, wireless. Consent for one isn't consent for the others. The TCPA's cell-phone rules apply to whichever line they answered the autodialed call on. Your CRM needs a consent flag per number, with the source, language, and timestamp on each.

Query the FCC's Reassigned Numbers Database before every campaign. Since November 2021 the RND has been live, and using it shields you from TCPA liability when a consented number was reassigned to a new subscriber without your knowledge. That safe harbor only applies if you actually queried the database — not if you could have. Build the RND query into your pre-dial pipeline and log the result for every number. If the RND says the number was reassigned after the consent date, drop it from the campaign and re-paper consent through your inbound channels.

Honor 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 dialer 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 dialer 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.

Dialer 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 dialer queries the consent DB, the Reassigned Numbers Database, and the DNC suppression lists before placing the call. Pre-call, not post-connect. The query needs to come back with four things: is this number consented, when was consent given, has the number been reassigned since consent, 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 dialer 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 dialers show the rep the next number, force a click-to-dial, and timestamp the click. That click is your audit defense. After Facebook v. Duguid, predictive dialers that don't use a random or sequential number generator may sit outside the strict ATDS definition, but prerecorded and artificial-voice rules still apply — and the FCC's 2023 enforcement signals plus state mini-TCPAs (Florida FTSA in particular) have re-introduced ATDS-like rules at the state level. Treat any predictive dialer as needing prior express written consent unless your counsel says otherwise for a specific jurisdiction.

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 realize. "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 dialer 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 authorization code, reads it out, and ends with "your payment is authorized, 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 authorized." 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 defense. 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 defense 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 centers 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. If you're a debt collector subject to the FDCPA, you also need to comply with the Mini-Miranda disclosure ("this is an attempt to collect a debt and any information obtained will be used for that purpose") on the first communication of the day with the consumer.

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 autodialer, the consumer initiated). Outbound payment IVRs trigger the federal-vs-state recording consent question — federal law is one-party consent but eleven states require all-party consent for recording (California, Connecticut, Florida, Illinois, Maryland, Massachusetts, Michigan, Montana, Nevada, New Hampshire, Pennsylvania, Washington — and Oregon for in-person). 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 dialer needs to know the area code of the destination number and convert to local time before placing the call. Most dialers do this automatically; check yours actually does. We've seen client setups where the dialer 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. For debt collection specifically, the CFPB's Regulation F caps debt collectors at seven calls per seven days per debt and bans further calls within seven days of having a phone conversation with the consumer. Even if you're not a third-party collector, that's the ceiling most compliance teams target as defensible practice — three attempted calls per day to the same number, no more than seven per week. Florida's Telephone Solicitation Act caps three sales calls in 24 hours to the same person on any subject. Configure the dialer to honor 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 dialer 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 (FTSA), Oklahoma's Telephone Solicitation Act (OTPA), Washington's Commercial Electronic Mail Act (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. Florida and Oklahoma in particular have generated heavy class-action volume since 2021 because they apply ATDS-style restrictions that survived Duguid. If you're calling all 50 states, the dialer 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 defense. 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 under state breach-notification statutes (50 states, plus DC and the territories — each with its own timing rule).

Retain the dialer logs separately. The dialer should produce a per-call log showing: destination number, consent status at time of call, RND check result, suppression list status, time of call, duration, disposition (answered, no-answer, IVR-completed, opt-out, payment-authorized). Retain these logs for the same seven-year window as the recordings. They're often more useful in TCPA defense 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 RND check result for the date of the call, the suppression status at time of call, the dialer 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 defense 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 signaled 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 dialer 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 and reassigned-number drift. The dialer thinks all numbers are local; calls go out at 6am to West Coast numbers because the dialer'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. Or the team skipped the RND query and dialed three numbers that were reassigned to new subscribers — each call now uncovered by the safe harbor.

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.

Wondering whether your current IVR setup would survive a TCPA demand letter? Have a quick chat with us — we'll walk through the consent, dialer, and recording layer with you in 30 minutes.

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, RND-flagged reassigned, no consent on file. The dialer should attempt only the first two and skip the rest. Cross-check the dialer log against the consent DB for every attempted number. If any "no consent" or "reassigned" number was dialed, 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 dialer 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 dialer 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 FTSA caps, 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 dialer 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 defense as evidence of your compliance posture.

STIR/SHAKEN, carrier blocking, and the origination layer#

Beyond the consent and opt-out rules, the FCC's STIR/SHAKEN framework affects outbound payment IVRs even when consent is clean. STIR/SHAKEN is the call authentication standard the FCC mandated for all originating voice service providers — calls are signed with one of three attestation levels (A, B, or C) describing how confident the originating carrier is in the caller's right to use the displayed caller ID. Attestation A means the carrier knows the customer and verified their right to the number; B means the carrier knows the customer but can't verify the number; C means neither.

If your dialer 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 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 FCC's Robocall Mitigation Database. Most legitimate contact centers 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 analytics blocking is a real risk too. T-Mobile, Verizon, and AT&T all run analytics-based blocking (Hiya, First Orion, TNS) 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 flagged as "Scam Likely" or "Spam Risk," register them with the Free Caller Registry (Hiya), call-blocking dispute portals at each carrier, and the analytics partners individually. Burning through dialer 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 (STOP, QUIT, UNSUBSCRIBE, END, CANCEL, REVOKE, OPT OUT), and your IVR opt-out menu all need to feed the same suppression DB. The dialer doesn't care which channel the revocation came through; it cares whether the destination number is in the suppression list at dial time. Centralize 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 dialer and IVR platform (Five9, NICE CXone, Amazon Connect, RingCentral, Talkdesk, Vonage, custom on Twilio) handles the TCPA layer — consent enforcement, RND queries, suppression, calling hours, opt-out propagation. Paytia handles the moment of card entry — the DTMF masking, the tokenization, the processor handoff (Stripe, Authorize.Net, Chase Paymentech, NMI), the recording suppression of card data.

For US contact centers 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 dialer 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 authorization 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 RND query, the suppression-at-dial-time check, the opt-out propagation latency, and the DTMF masking failover behavior — those four 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 dialer 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. Or call us on +1 628 295 2250.

This piece is part of our TCPA compliance guide cluster — start there for the legal landscape and work back into IVR setup, consent capture, penalties, and the FCC robocall rules.