IVR Payment (Interactive Voice Response Payment)

An IVR payment is a card payment taken through an Interactive Voice Response system — the customer dials a number, follows an automated menu, and types their card details into the phone keypad. No human agent hears the digits. It's how businesses take card payments by phone without dragging their staff, telephony, and call recordings into the noisy end of PCI scope.

There are two flavours worth knowing. Hosted IVR (or self-service) runs end to end: the customer calls a dedicated payment line, pays, hangs up. Agent-assisted IVR is the contact-centre version: a live agent qualifies the call, transfers the caller into the IVR for the card-capture moment only, then picks the call back up to wrap things up. Both shapes keep the merchant out of the card-data path.

How it works on a call

The flow is much like you'd expect. The caller is identified (account number, reference, postcode), the amount is confirmed, and an automated voice walks them through entering their card number, expiry, and security code on the keypad. The system reads back a confirmation and usually sends an SMS or email receipt. Start to finish, two to four minutes — no queue, no agent time, available at 3am on a Sunday if that's when the bill needs paying.

What's actually happening on the wire

When the caller presses a digit, the phone generates a DTMF tone — two simultaneous frequencies that the network carries alongside the voice audio. A hosted IVR payment platform intercepts those tones at the network edge, before they reach the merchant's telephony or any recording. The tones are translated into card data, sent over a TLS connection to the acquirer or payment service provider, and replaced in the audio stream with flat tones or silence. The agent (if there is one) hears nothing useful. The call recording, if one exists, never contains the digits — they were stripped before the recorder saw them.

This is the bit that matters for PCI scope. Card data was present on the call as audio, but it never touched the merchant's systems in a form that could be captured, stored, or exfiltrated. That's why an descoped IVR setup can move a merchant from SAQ D (the long, painful self-assessment) to SAQ A (the short one).

Authorisation and response

Once the IVR has the card details, it submits the authorisation to the payment processor in real time. The response — approved, declined, or referred — comes back within a couple of seconds. The IVR voice reads the result to the caller, plays the authorisation code if approved, and writes a transaction record back to the merchant's CRM or billing platform via API or webhook. The merchant sees the outcome; they never see the PAN.

Where you'd actually use one

IVR earns its keep wherever routine, repetitive payments need to happen at scale without tying up staff. Utility and telecoms bill payments, council tax, parking, charity donations, recurring debit catch-up, after-hours payment lines, and overnight ticket sales are the bread and butter. The common thread: the caller knows what they owe and just wants to pay it, so a human conversation adds nothing. If you're weighing up whether phone payments fit your setup, our free phone payment tools let you estimate scope and savings before you commit. IVR is less useful for complex situations — split payments, refunds, anything that needs explaining — which is where agent-assisted IVR or live agent flows come in.

Real-world flows we see most often

Utility bill payment. A water company sends a paper bill with a freephone number. The customer calls, taps in the 10-digit account number from the bill, hears the outstanding balance read back, and confirms with #1. The IVR prompts for the long card number, expiry, then CVV. Auth runs, approval plays back, an SMS receipt lands before they hang up. Total call time: 90 seconds. Cost to the utility: pennies. No agent involved, available 24/7, peaks handled without staff overtime.

Council parking fine. A driver gets a Penalty Charge Notice with a 14-day discount window. They call the IVR line at 11pm on a Saturday from their kitchen, key in the PCN number, pay £35 instead of £70, done. The council would have lost the discount payment entirely if it had needed an agent during office hours only.

Agent-assisted catch-up call. A subscription business calls a customer whose direct debit bounced. The agent talks them through the failed payment, asks if they'd like to settle by card, and presses a button to transfer into the IVR card-capture step. The agent stays on the line but hears flat tones during the digits. Once the auth comes back, the IVR drops out and the agent resumes — confirms the next billing date, thanks them, ends the call.

After-hours emergency payment. A boiler-repair company takes a job at 8pm. The engineer leaves at 10pm with the work done. The customer needs to pay the same evening to settle the call-out. An IVR line on the invoice lets them pay before bed, with no need to staff a payment desk overnight.

What IVR payment systems do for PCI scope

This is the reason most merchants buy one. Card data spoken aloud over the phone — or typed by an agent into a CRM — pulls the merchant's call recording, telephony platform, agent desktops, network, and CRM into PCI scope. That's a huge surface area. A hosted IVR payment system carries the card data over its own network and infrastructure, which is PCI DSS certified as a service provider. The merchant's systems never see the PAN.

The practical effect: a merchant taking 1,000 phone payments a week without an IVR is probably looking at SAQ D and a Qualified Security Assessor visit. With IVR in place, the same merchant likely qualifies for SAQ A — a 22-question form, no QSA, no penetration test on telephony, no quarterly scans on the call recorder. The annual cost difference can run into tens of thousands.

PCI DSS v4.0.1 and IVR

The current PCI standard, v4.0.1, raised the bar on what "out of scope" actually means. Compensating controls have to be documented more rigorously, and the customised approach lets merchants design alternative controls that meet the same intent. For IVR specifically, the key clauses are around 3.3 (mask PAN when displayed), 3.5 (render PAN unreadable wherever it's stored), 8.3 (multi-factor auth on remote access to card data environments), and 12.8 (managing service provider relationships). A well-built IVR sidesteps most of these by keeping the PAN out of the merchant's environment entirely.

If you're new to the standard, our PCI DSS glossary entry walks through what changed in v4.0.1 and what the deadlines mean now that the March 2025 transition is behind us.

Hosted IVR vs. agent-assisted IVR

The two flavours solve different problems.

Hosted IVR is fire-and-forget. Customer dials a published number, the whole transaction runs without any agent. Cost per transaction is rock-bottom — there's no human labour involved at all. It's the right choice for high-volume, low-complexity payments where the customer already knows what they're paying for and the amount can be looked up automatically (utility bill, parking fine, council tax, season ticket). The downside: there's no upsell, no relationship-building, and no soft handling for confused or distressed callers.

Agent-assisted IVR keeps the human in the conversation. The agent qualifies the caller, confirms what they're paying for, then routes only the card-capture seconds through the IVR. The agent stays connected the whole time but is muted from hearing the digits. Cost per transaction is higher because you're paying for agent time, but you get the conversation — which matters for sales, retention, complex billing, or vulnerable customers. Contact centres typically run agent-assisted as their default and offer hosted IVR as a secondary self-service channel.

What about agent typing into a screen?

Some setups let the customer read out their card number while the agent types it. That isn't an IVR payment — it's an attended payment and it pulls the agent, the call recording, and the desktop into PCI scope. Modern attended-DTMF setups (where the customer keys the digits during a normal agent call and the tones are suppressed) get the same descoping benefit as IVR. We cover that pattern in our DTMF masking glossary entry.

Edge cases and failure modes

IVR payments fail in predictable ways, and a good platform handles each one without dumping the caller.

Mis-keyed card number. The Luhn check catches most of these before authorisation is even attempted. The IVR plays back the last four digits and offers a re-try. After three failed attempts, the call routes to an agent or plays a "we couldn't process that" message with a callback number.

Declined transaction. The IVR reads back the decline reason if the processor returns one, suggests trying a different card, and routes to an agent if the caller wants help. Hard declines (lost/stolen, do not honour) bounce straight to an agent — fraud-flagged calls shouldn't be looped.

3D Secure step-up. This is the awkward one. If the issuer challenges the transaction with a 3DS step-up, the customer can't complete an OTP on a phone call. Modern IVR platforms handle this by sending an SMS link to the caller's mobile to complete authentication on-device, then resuming the auth once the bank confirms. Older setups simply fail the transaction and ask for a different card. Worth checking with your provider how they handle Strong Customer Authentication post-PSD2.

Caller hangs up mid-flow. The transaction is abandoned, no card data is retained, and an abandoned-call event fires to the merchant's CRM. The IVR doesn't try to "complete" a half-entered card. If a partial PAN ever ends up in logs (it shouldn't), it has to be treated as cardholder data and the logs come into scope — which is why proper IVR providers strip everything aggressively at source.

Poor line quality. Mobile callers in patchy reception are the bane of DTMF. Tones get garbled in transit, the IVR reads back the wrong digits, the caller gives up. A decent platform supports tone-confirmation prompts ("press 1 to confirm we heard 4-4-3-3") and gracefully falls back to agent transfer.

Refunds and partial payments. IVR is bad at these. They need conversation, judgement, and often a manager. Most merchants route refund requests straight to an agent and use IVR only for the inbound "pay this bill" flow.

How an IVR payment platform compares to the alternatives

Phone payments have four broad shapes, and IVR is one of them.

Agent takes PAN verbally. Cheap to set up, expensive to run because of PCI scope. Card data is in every call recording, every agent's hearing range, every desktop screen. Most merchants doing more than a trickle of phone payments move off this within 12 months.

Pay-by-link sent during the call. Agent emails or texts a payment link, customer pays on web. Out of scope but breaks the call — caller has to find their inbox, click the link, switch to a different channel. Conversion drops sharply for older callers and during peak inbound times.

Attended DTMF / agent-assisted IVR. Agent stays on the line, customer keys digits, tones are suppressed. Same scope benefit as full IVR, keeps the conversation intact. The mainstream choice for contact centres.

Hosted IVR / self-service. No agent. Lowest cost per transaction, fully out of scope, available 24/7. The mainstream choice for utility-style bill payment.

Most merchants end up running both attended DTMF and hosted IVR side by side — attended for inbound and outbound agent calls, hosted IVR for "pay your bill" lines printed on invoices.

What to look for when choosing an IVR payment provider

A few practical things to check before signing.

True descope, not "less scope." Ask the provider to confirm in writing which SAQ you'll qualify for after implementation. If they hedge ("depends on your wider environment") without giving a clear answer, the descoping may be partial. Proper hosted IVR should put you on SAQ A for the IVR channel cleanly.

Coverage of your payment service provider. The IVR has to integrate with your existing acquirer or gateway — Stripe, Worldpay, Adyen, whoever. If you have to switch acquirers to use the IVR, factor that into the cost.

Telephony integration. If you run a contact centre on a CCaaS platform (Genesys, Five9, Amazon Connect, Talkdesk), the IVR has to plug in cleanly via SIP, the platform's marketplace, or a soft-transfer pattern. Ask for reference customers on your platform.

SMS and email receipts. Confirmation messaging is what turns a phone payment from "did that work?" into a closed transaction. Make sure the IVR can fire receipts in both channels with your branding.

Reporting and reconciliation. The merchant still needs to know which transactions came through which channel, which customers paid, and how to handle chargebacks. Decent providers expose a portal and an API. Avoid anything that only exports CSVs.

Pricing model. Per-minute, per-transaction, or flat monthly. Per-transaction is usually best aligned with the merchant's economics — you pay for the value you get. Per-minute can sting on long calls.

How Paytia handles IVR payments

Our IVR payments solution covers both hosted self-service and agent-assisted flows on the same platform, integrates with Stripe as our PSP partner, and plugs into the major CCaaS platforms via SIP. We strip DTMF tones at the network edge, so your call recording, your agent's headset, and your CRM never see the digits. Setup is a hosted line and a webhook into your billing system — most clients are taking live IVR payments within two weeks. Pricing is per-transaction, not per-minute, which keeps things predictable as call durations vary.

Frequently asked questions

What is an IVR payment in simple terms?

It's a card payment you make by phone, where you type your card number into the keypad instead of reading it out loud. An automated voice walks you through it. Nobody at the company hears or sees your card details.

Is an IVR payment secure?

Yes — usually more secure than reading your card to an agent. The DTMF tones are intercepted before they reach the merchant's systems and never appear in call recordings. Card data goes directly to the payment processor over an encrypted connection.

What's the difference between hosted IVR and agent-assisted IVR?

Hosted IVR is fully self-service — you call a payment line and the whole transaction runs without any human involved. Agent-assisted IVR is for contact centres: a live agent qualifies the call, then transfers you into the IVR only for the card-capture moment, then picks the call back up after.

Does an IVR payment take you out of PCI scope?

A properly built hosted IVR keeps the merchant's systems out of the card-data path entirely, which usually drops the merchant from SAQ D to SAQ A. That's a meaningful saving — fewer controls, no penetration testing of telephony, no quarterly scans on call recorders. Agent-assisted IVR delivers the same benefit during the card-capture seconds.

Can I take refunds through an IVR?

Technically yes, but most merchants don't. Refunds usually need a conversation — verifying who's calling, checking the original transaction, deciding how much to return. They tend to live with agents, not IVR menus.

What happens if 3D Secure challenges the payment?

Modern IVR platforms send an SMS link so the customer can complete Strong Customer Authentication on their phone, then resume the call. Older systems just fail the transaction. Worth asking your provider how they handle PSD2 step-up.

Will an IVR work with my existing payment processor?

It depends on the provider. We integrate with Stripe out of the box and connect to most major acquirers. Always confirm with your IVR vendor before signing — switching acquirers to fit the IVR isn't usually worth it.

How long does an IVR payment call take?

Two to four minutes end to end for a typical bill payment. The card-capture portion itself is usually 30 to 60 seconds depending on how many prompts the merchant has built in.

Can customers use IVR payments outside business hours?

Yes — that's one of the main reasons merchants buy them. A hosted IVR line runs 24/7 with no staffing cost. We see big spikes in late evenings and weekends for utility, parking, and council payments.

What does an IVR payment cost?

Most providers charge per transaction, typically a small flat fee plus card-scheme costs handled by your acquirer. Per-minute pricing exists too but tends to be less predictable. Setup costs vary depending on how deep the integration into your CRM and telephony needs to be.

See also

For the full picture of how IVR payments fit a contact-centre's PCI scope, integration patterns, and recording setup, see our IVR payments solution.