IVR Payments: How They Work and Where They Fail

Last updated: 29 May 2026

US reader? See the US version of this guide with US-specific compliance detail (TCPA, NYDFS, CCPA, FedNow, US PCI scope guidance).

An IVR payment is a card payment a customer makes by pressing the digits on their phone keypad in response to a recorded voice, with no agent on the line. The system reads back the amount, prompts for the card number, expiry, and CVV one piece at a time, and confirms the result. Twenty-four hours a day, no hold music, no callback.

If you've ever paid a council tax bill, settled a parking fine, or topped up an account at midnight, you've probably used one. The reason they exist is dull but practical: most calls into a contact centre that end in a payment are routine. The customer knows what they owe. They just want to pay and get on with their evening. Running those calls through an agent costs the business money and frustrates the customer who'd rather be done in 90 seconds.

This guide covers what an IVR payment actually is, how the call flow works under the hood, where IVR earns its keep, where it falls flat, and the PCI compliance trap that catches most teams the first time they try to build one. We've held PCI DSS Level 1 service-provider status for over a decade and we run IVR payment flows for clients taking thousands of card calls a day, so a fair chunk of this is what we've watched work and not work in real deployments.

How IVR payments actually work#

An IVR payment system is a piece of software sitting between the public phone network and a payment gateway. The customer dials a number — usually a freephone or a local-rate line printed on their bill — and the system answers with a recorded prompt. Modern systems use natural-sounding text-to-speech rather than the stilted 90s voicemail voice, but the structure is the same: a script that asks questions and waits for the answer.

The call flow, step by step

The customer answers by pressing keys on their handset. Each key press generates a DTMF tone (dual-tone multi-frequency — the noise you hear when you press a digit). The IVR captures those tones, converts them back to digits, and uses them to fill out the payment request. A typical call flow looks like this:

1. Customer dials the payment line.
2. The system asks for an account or reference number — say, the invoice number from their bill.
3. It reads back the amount owed and asks them to press 1 to confirm.
4. It prompts for the long card number, one digit at a time via keypad.
5. It prompts for the expiry month and year.
6. It prompts for the CVV.
7. The card details get sent to the payment gateway over an encrypted connection. The gateway authorises with the customer's card issuer.
8. The system reads back "payment approved, your reference is…" and ends the call.

The whole thing takes about a minute once the customer knows the flow. No agent, no queue, no need for the business to be open. For a utility company taking 40,000 bill payments a month, the cost difference between routing those through agents and letting the IVR handle them is the difference between a 60-seat call centre and a 15-seat one.

What's happening underneath the prompts

Underneath the voice prompts, the IVR is doing four things in parallel: running a state machine that tracks where the customer is in the script, decoding DTMF tones against a tolerance window so a wobbly digit doesn't bounce the call, talking to your billing system or CRM to validate the reference number, and holding an authenticated session with the payment gateway ready to fire the auth request. None of that is glamorous, but it's the difference between a flow that works at 3am on Christmas Eve and one that times out the moment the gateway has a slow second.

The gateway side matters more than people expect. Most UK IVR payment providers integrate with Stripe, Worldpay, Adyen, Opayo (the platform formerly known as Sage Pay), Barclaycard, Trust Payments, or a Cardstream-derived processor. The IVR doesn't care which acquirer sits behind the gateway — what it cares about is the API contract, the 3D Secure 2 flow for SCA, and the tokenisation pattern for repeat payments. If your gateway can't return a token within the auth response, the IVR can't offer "pay with the card on file" on the next call.

Voice prompts and customer experience

The script matters more than the technology. We've watched well-built IVR flows fail because someone wrote prompts that sound like an HMRC voicemail from 1998. The rules we apply to our own deployments are mundane: short sentences, the amount before the action ("twelve pounds forty, press 1 to confirm" not "to confirm a payment of twelve pounds forty, press 1"), one piece of information per prompt, and a clear path to a human at every step. Customers who hit "*" or "0" should land in a queue, not be lectured about how IVR is faster.

Two language choices we'd flag. First, if you're taking payments from customers across the UK, "card number" beats "long number on the front of your card" because anyone who's used contactless for five years has forgotten which side the number sits on. Second, never apologise in the prompt — "I'm sorry, that didn't work" turns a recoverable retry into a problem in the customer's head. "Let's try that again" does the same job without the emotional weight.

What the customer doesn't see is what happens to the DTMF tones once they leave the handset. That detail is where the security story gets interesting, and we'll come back to it below.

IVR vs agent-assisted: when to use which#

An IVR payment runs the call without a human. An agent-assisted payment keeps your team on the line right up to the moment the customer enters their card, then masks or separates the card-entry portion so the agent never hears it. Both can be PCI-compliant. They're not in competition — most contact centres run both, and the question is which one fits which call type.

Where IVR fits

IVR earns its keep on routine, high-volume, predictable calls. Bill payments, parking fines, recurring subscriptions, top-ups, statement settlements. The customer arrives with an account number and an amount they expect. There's nothing to discuss. Pushing those calls into an agent queue burns wages and creates abandonment when callers see hold times climb past two minutes.

Where agent-assisted fits

Agent-assisted suits calls where the conversation matters. A customer who's confused about their bill, a new insurance application, an order with multiple items, a complaint that ends in a goodwill credit and a payment for the difference. You want your agent on the line. You don't want the customer dumped into a menu mid-conversation. In those calls, a good agent-assisted flow keeps the agent talking right up to the point of card entry, then quietly masks the tones while the customer presses keys, then brings the agent back to confirm the result. The customer hardly notices the handover.

The honest test

If you're trying to pick between the two for a specific call type, the honest test is this: would a competent agent reading from a script add anything to this call? If the answer is no, route it to IVR. If the answer is yes, keep your agent on the line and use agent-assisted instead. We've written more on the split in our IVR vs agent-assisted comparison.

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.

The security problem: DTMF capture#

Here's the part most teams miss until their first PCI audit. When a customer presses digits on their phone, the DTMF tones travel over the same voice channel as the conversation. If you're recording calls — and most contact centres are, for QA and regulatory reasons — those tones end up on the recording. Anyone who can play back the file can identify which digits were pressed. There's free software online that converts DTMF audio back to the digits in seconds.

Why the recording archive is the real exposure

That's a PCI problem. Storing recordings with audible card numbers and CVVs puts your entire call archive into PCI scope. Practically, that means encrypted storage, strict access logs, annual scope reviews, and an enormous remediation bill the day an auditor asks where the card data lives. We've seen contact centres discover they've got six years of recordings with full PAN data sitting on a backup server nobody's looked at since 2019.

It gets worse in the financial services and insurance space, where FCA rules under SYSC 10A require firms to keep recordings of any call relating to an agreement for five years (longer for some advice). That means the regulator is forcing you to retain audio that, if you've not masked the DTMF, is full of card data you're not allowed to retain under PCI DSS. The two regimes don't contradict each other on paper — PCI permits storage with the right controls — but the controls are expensive, and the right answer is almost always to stop the card data getting into the recording in the first place.

The two architectures that actually work

The fix is to stop the card-entry tones from ever reaching the recording in the first place. Two architectures do this, and they're the two patterns the PCI SSC actually recognises:

• DTMF masking — the tones are replaced with a flat reference tone (usually a steady beep) before the audio is recorded. The card-entry digits exist for milliseconds in the network and never touch storage.
• Channel separation — the card-entry portion of the call is split off entirely. The customer's DTMF tones are routed straight from the phone network to the PCI-compliant payment processor, bypassing your recording infrastructure altogether.

Both keep the audible call alive — the customer is still hearing prompts, the merchant or agent is still on the line — but the sensitive digits never enter your environment. That's the difference between an IVR that descopes your contact centre and one that drags it deeper into PCI scope. There's a longer breakdown of which architecture suits which business in our piece on channel separation and where the revenue case lands.

The "we're encrypted so we're fine" myth

We hear this one weekly. "Our recordings are encrypted at rest, so we're PCI-compliant." Encryption at rest doesn't take you out of scope — it's one control among many that you'd have to apply to the entire recording estate, plus key management, plus access logging, plus annual ROC review. The PCI DSS v4.0.1 guidance is explicit: if card data could end up in your recordings, your recordings are in scope, encrypted or not. The cheap path is to stop the data arriving. The expensive path is to harden everything it touches.

Where IVR payments shine#

IVR pays for itself fastest in three places.

High-volume bill collection

The first is high-volume bill collection. Councils, utilities, telcos, water companies, fuel suppliers — anyone billing a fixed customer base on a regular cycle. A weekly run of 5,000 bills generates a wave of incoming payment calls, and most of them are clean: customer dials, gives reference, pays, hangs up. IVR handles the wave without adding agents. We've watched a UK utility take their average call handling time from four minutes on agent to 70 seconds on IVR for the same payment, with no measurable drop in completion rate.

Housing associations are another quiet winner here. Tenants paying rent on a monthly cycle, often topping up arrears in chunks they decide on the day, often calling outside office hours because their day job doesn't pause for a phone call. The combination of fixed reference (tenancy number), variable amount, and customer-driven timing maps onto IVR almost perfectly. A medium-sized housing association handling 8,000 tenant payment calls a month can shift around 70% of that volume into self-serve IVR within a quarter.

Out-of-hours service

The second is out-of-hours service. A contact centre running 9-to-5 with an IVR payment line stays open for payments 24/7. Customers who'd otherwise be turned away — or worse, dropped to voicemail — can settle their bill at 11pm on a Sunday. For collections teams especially, that matters. Some customers will only call when they've got privacy, and that's rarely during office hours.

Insurance brokers see the same pattern with renewal payments. The customer has had the renewal email for three weeks, finally remembers it at 9pm, doesn't want to fill in a card form on their phone, wants to call and pay and be done. An IVR line tied to the policy number means the broker collects the payment that night instead of losing it to a lapsed renewal a week later. We've watched a London-based broker recover the cost of the IVR build in a single autumn renewal cycle from out-of-hours payments alone.

Overflow during volume spikes

The third is overflow. When call volumes spike — a price change, a billing run, a service outage — the queue grows fast and abandonment follows. An IVR payment option in the opening menu (press 1 to pay your bill now, press 2 to speak to an agent) drains the predictable calls out of the queue and lets your agents handle the conversations that actually need them. We see queues shorten by 30 to 50 percent the week a well-placed IVR payment menu goes live.

Regulated industries with audit needs

One more spot worth mentioning: regulated industries where every payment touchpoint needs an audit trail. IVR systems log every step of the call automatically — timestamps, prompts played, digits captured, gateway response — which makes proving "the customer authorised this payment on this date at this time" trivial. Try doing that consistently with agent notes and you'll be there a while.

For FCA-regulated firms, this matters at renewal audit. The Consumer Duty work in 2024 and 2025 pushed firms to evidence that customers understood what they were paying for, not just that they paid. An IVR script that reads back the amount, the policy reference, and the next billing date before asking for confirmation produces a clean audit trail that ticks the box without the brokerage having to retrofit consent capture into agent calls.

Where IVR payments fail#

We'd rather lose the sale than mislead you here. IVR is a tool, not a magic wand, and the wrong call type in IVR is worse than no IVR at all.

Complex orders and conversations

Complex orders flop in IVR. The moment your customer needs to choose between products, add or remove items, change a delivery address, or apply a discount code, the menu tree starts to feel like a labyrinth and abandonment climbs. There's no replacement for an agent who can say "do you want the small one or the large one?" and adapt.

FX bureaux and travel agents hit this hardest. The customer wants 800 euros but if the rate moves they'll take 750, they might want to split into two cards, they need to know when the delivery arrives, and they want a price held while they ring their partner. None of that survives IVR. Push it to an agent with an agent-assisted card-entry flow at the end and the conversion holds.

Accessibility limits

Accessibility is the other honest weakness. Customers with hearing impairment, customers whose first language isn't the language the IVR speaks, customers with motor impairments who struggle with phone keypads — none of them get a good experience from IVR. A serious contact centre keeps a human path open for these callers and routes IVR rejections to agents quickly, not after five failed retries.

The Equality Act 2010 puts a positive duty on UK service providers to make reasonable adjustments. An IVR-only payment line with no human fallback isn't a reasonable adjustment for a deaf customer, a customer with a stammer, or a customer using a textphone. We build every IVR flow with a single-key escape to a human queue, and we'd push back if a client asked us to remove it.

Brand fit and customer preference

And there's a softer point: some customers simply hate menus. They want a person. If your brand is built on personal service, forcing every caller through IVR before they can reach someone will erode trust no matter how slick the flow is. The right answer there is to make IVR optional — a fast lane for callers who want it — not a gate everyone has to pass through.

Edge cases that catch new IVR builds out

A few failure modes we've watched chew through projects in the first month. Mobile callers with weak signal — DTMF tones over a flaky GSM connection can arrive corrupted, and a strict "exactly 16 digits" check rejects legitimate cards. The fix is a generous tolerance window plus a confirmation prompt, not a tighter validation rule. Foreign cards with non-standard expiry handling on older gateways — anything that triggers a fallback authorisation path can confuse a script written for the happy path. Customers who paste an account number into the dialler from a sticky note that includes spaces — DTMF doesn't carry spaces, but the customer thinks they've entered the right digits and won't understand why the system rejects them.

The unifying lesson is that IVR scripts need to behave like a patient human on the phone, not a strict form validator. Repeat the prompt, accept variants, route to a person when the customer's hit a wall. None of that is technical — it's all script design.

PCI compliance for IVR: what you actually need#

The short version: an IVR payment system handles card data, so PCI DSS applies. The question isn't whether you need to be compliant — you do — it's how to keep your own infrastructure out of scope as far as possible. Our practical IVR payment implementation guide covers the cut-over sequencing that gets you from SAQ D to SAQ A inside a quarter. There are three things that actually matter when you're picking or building an IVR payment platform.

The AOC test

First, the IVR provider should be a PCI DSS Level 1 service provider with a current Attestation of Compliance you can read. If they can't email you the AOC within an hour of your asking, walk away. This isn't optional reading — it's the document that says what they've been audited against and where the boundaries of their environment sit.

What you're looking for on the AOC: a current date (within the last 12 months), the right PCI DSS version (v4.0.1 is the live standard since June 2024, with v4.0 acceptable through the transition), explicit coverage of "Telephone-based payments" or equivalent in the services list, and a QSA signature from a recognised firm. AOCs from sub-scope assessments or self-assessment questionnaires are a red flag for a service provider of any real size.

Card data must not enter your network

Second, the architecture has to keep card data out of your systems. That means DTMF masking or channel separation — the customer's card digits go from their phone keypad to the payment processor without crossing your network. If the IVR vendor's diagram shows card data passing through your servers, your call recorder, or your telephony platform, that's the wrong shape.

Ask the vendor to draw the data flow on a whiteboard. Where do the DTMF tones enter their environment? Where do they exit? Does the audio passing through your SIP trunk or PBX contain the digits, or has it already been replaced by the time it reaches you? The right answer puts the masking or separation at the network edge, before anything you operate touches the audio. Anything else is a vendor trying to shift the compliance burden onto you.

Tokenisation for repeat customers

Third, the integration with your payment gateway should be tokenised. Once a card has been used successfully, the system stores a token, not the card number. Repeat customers can pay again without re-entering their card, and your business never holds a single PAN. There's a much longer treatment of this in our PCI compliance for telephone payments piece, and the principles apply identically to IVR.

PCI DSS v4.0.1 specifics that bite IVR

The move from v3.2.1 to v4 (and the v4.0.1 update) brought a handful of requirements that matter for IVR specifically. Requirement 6.4.3 on payment page scripts technically applies to e-commerce, but the underlying principle — knowing exactly which scripts run in your authorised flow and detecting unauthorised changes — has spilled into how QSAs assess IVR script management. Requirement 8.3.6 on password and MFA strength applies to the admin consoles where IVR scripts and routing rules are edited, which is often the weakest link in a contact centre's PCI posture. Requirement 11.6.1 on change detection means the IVR vendor needs a way to flag if the prompts or routing have been tampered with.

The deadline most teams missed: the date by which all future-dated v4 requirements became mandatory was 31 March 2025. If your IVR vendor is still working to v3.2.1 controls in May 2026, that's a signal their AOC won't survive their next audit and you're inheriting their problem.

SCA and 3D Secure 2 in an IVR context

Strong Customer Authentication under PSD2 applies to most consumer card payments taken in the UK. For e-commerce it means a 3D Secure 2 challenge. For card-not-present payments taken over the phone, including IVR, the standard exemption is the MOTO (mail order / telephone order) exemption — those payments are out of scope for SCA in their current form. That's a feature of the regulation, not a workaround. Most acquirers process IVR payments as MOTO and apply the merchant category code that flags them accordingly.

Two caveats. First, the MOTO exemption only applies if the payment is genuinely initiated by the customer over the phone, not just routed through an IVR as cover. Second, the exemption is under regulatory review — UK Finance and the FCA have flagged that phone payments make up a disproportionate share of card-not-present fraud, and the exemption may narrow in future PSR/FCA guidance. Build your IVR flow assuming MOTO works today but that your vendor needs to be able to support a 3DS challenge over voice (yes, that's a thing) if the rules change.

How IVR compares with the standard alternative model#

Most teams comparing IVR aren't comparing it to nothing — they're comparing it to the standard model where an agent takes the card number verbally and types it into a payment terminal or virtual terminal on their desktop. We'll call that the "agent-typed" model because it's still depressingly common.

Cost per call

Agent-typed payments take three to four minutes including the wrap-up. IVR payments take 60 to 90 seconds and don't pay an agent's salary for the duration. At a UK fully-loaded agent cost of around £18 to £25 per hour for an in-house contact centre (more for outsourced spend), every 1,000 calls shifted from agent-typed to IVR saves between £450 and £1,200 in pure handling time, before you count the value of freed-up agents handling higher-value calls.

PCI scope

Agent-typed is the architecture that puts your contact centre deepest in PCI scope. The agent hears the card number. The recorder captures it. The screen displaying the virtual terminal is in scope. The desktop the agent is using is in scope. The network it sits on is in scope. The headset is in scope. A modest 30-seat contact centre running agent-typed payments faces an annual ROC bill in the £40,000 to £80,000 range. The same contact centre running IVR with channel separation can drop to SAQ A levels of compliance work — a couple of days a year, not weeks.

Customer experience

IVR wins on speed and 24/7 availability but loses on warmth. Agent-typed wins on warmth and complex-call handling but loses on cost, scope, and out-of-hours coverage. The pattern most contact centres land on is to run both, with the menu sorting the calls. Routine payments to IVR. Anything else stays with the agent, who uses an agent-assisted DTMF capture for the card-entry portion so the desk doesn't get dragged into PCI scope.

Is IVR the right fit for your contact centre?#

If you're taking more than a few hundred routine payment calls a week, IVR will pay for itself inside a quarter. The IVR payment setup guide covers the week-by-week rollout plan that gets you live without disrupting your queue. If you're running a small advisory team where every call is a conversation, it probably won't. Most contact centres land somewhere in between and end up running IVR alongside agent-assisted, with the menu doing the sorting. The point isn't to replace your agents — it's to stop them spending half their day typing card numbers.

A quick fit checklist

• Do more than 30% of your inbound calls end in a payment? IVR helps.
• Are most of those payments tied to a known reference (invoice, policy, tenancy)? IVR helps.
• Do you take payments outside agent hours? IVR is the only realistic option.
• Are your calls mostly advisory with a payment at the end? Stick with agent-assisted card capture.
• Are you currently in full PCI ROC scope because of agent-typed payments? IVR plus channel separation is the fastest route to SAQ A.

What a sensible rollout looks like

The rollout pattern that works: pick one payment type (usually recurring bills), build the IVR flow for that, route a small share of calls to it through your existing IVR menu or a separate number on the bill, watch completion rates for two weeks, tune the prompts, then open the tap. We've documented the exact sequencing in our step-by-step guide on how to set up IVR payments. Trying to migrate every payment type at once produces ugly compromises in the script and erodes confidence in the project when one segment underperforms.

If you want to see what a properly descoped IVR payment flow looks like, our IVR payments solution walks through the architecture and the call flow we build for clients. And if you'd like to compare it against alternatives, our piece on SMS payments versus traditional IVR covers the channel that most teams ask about next.

Related reading#

• Pillar guide: complete guide to IVR payments
• SMS Payments vs IVR Payments: Which Works Better?
• IVR vs Agent-Assisted Payments: How to Pick
• PCI Compliance for Telephone Payments
• Channel Separation: The Business Benefits

For the product side, see our IVR payments solution.

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.

Related guides in this cluster#