How to Set Up IVR Payments — Implementation Guide

Last updated: 29 May 2026

If you're trying to set up IVR payments for the first time, the hardest part isn't the technology. It's working out which bits of your current setup are in scope, which vendor actually handles compliance for you, and how you sequence the cut-over so your inbound queue doesn't grind to a halt. We've walked dozens of contact centres, charities, utilities and insurers through this — Pinnacle Group cut PCI scope by 95% on the back of it — and there's a repeatable order to the work. This guide is the one we hand to operations leads who've just been told "we need to stop reading card numbers over the phone, can you make it happen by next quarter".

We'll cover what an IVR payment actually is, the pre-flight checks you need before you sign anything, integration patterns, a realistic week-by-week timeline, how to brief agents, common rollout traps, and what changes for your auditors. If you'd rather start from first principles, our pillar guide on IVR payments guide covers the basics. Already shopping vendors? See the best IVR payment platforms for 2026.

What you're actually buying when you set up IVR payments#

An IVR payment is a customer-facing menu that takes card details by DTMF tones — the beeps your phone makes when you press a key. The customer types their card number into their handset, the tones are masked or stripped before they reach your agent or your phone system, and a PCI-compliant gateway processes the transaction in the background. The agent hears progress updates ("card accepted", "declined") but never sees or hears the numbers.

That's the model. What you're actually buying depends on the flavour. There's agent-assisted IVR, where your agent stays on the line and triggers the payment step partway through a call. There's fully automated IVR, where the customer dials in or is transferred to a self-service menu and never speaks to a human. And there's outbound IVR, where you call a customer (or send them an SMS link to a callback) for arrears, renewals or scheduled charges. Most contact centres start with agent-assisted because it's the smallest behavioural change. Self-service IVR usually comes later, once you've seen what proportion of your call volume is actually just routine payment-taking.

The reason we labour this is because what you're setting up determines who owns which bit of compliance. With agent-assisted, your agents and your CRM stay in scope for everything except the card capture moment. With fully automated, you can take entire call flows out of scope. Get this wrong on day one and you'll either over-spend on infrastructure you don't need or, more painfully, under-scope the rollout and discover halfway through that your CRM screen still shows the PAN.

Pre-flight: the seven questions to answer before you sign#

Before you talk to a vendor, get clear answers to these. We've seen projects stall for months because nobody asked them up front.

How are you taking phone payments today? If it's "we read the card out and key it into the gateway terminal", you're SAQ D — the heaviest PCI questionnaire. If it's "we use pause-and-resume on the call recording", you're still SAQ D, because the cardholder data still passes through your agent, your phone system, and your carrier. Pause-and-resume only protects the recording, not the live audio path. We've written about why pause-and-resume isn't enough on its own if you want the detail.

What does your phone stack look like? Specifically: is your telephony cloud-hosted (Genesys Cloud, Five9, Amazon Connect, 8x8, NICE CXone) or on-prem? Is it SIP all the way to the carrier, or is there a TDM gateway in the building? IVR payment vendors integrate through SIP trunks or via SBC bridging. Cloud telephony is usually a 1-2 week integration; complex on-prem can stretch to 6-8.

Which gateway and acquirer do you use? Worldpay, Stripe, Adyen, Opayo, Global Payments, Barclaycard, Chase — they all have different tokenisation models, different settlement timelines, and different fees on 3DS step-up. Your IVR vendor either has a pre-built integration or builds you a custom one. Custom means longer and pricier.

What's your call volume and average ticket? Vendors price on a mix of per-transaction, per-call-minute and platform fees. Twenty thousand £40 transactions a month looks very different in pricing terms from two thousand £4,000 transactions a month, even though the revenue is the same. Bring the numbers to the table.

Do you take recurring or stored payments? If yes, you need a gateway tokenisation strategy from day one. Storing a token instead of a card means you can take repeat charges, set up recurring payments, or chase failed renewals without ever re-prompting the customer for their card. If you don't decide this early, you'll be retro-fitting it six months in.

What CRM, ticketing or case-management system do agents work in? Salesforce, Zendesk, Microsoft D365, ServiceNow, HubSpot, a bespoke build. The IVR payment vendor will need either an API call from your CRM to start the payment step, or a click-to-pay widget embedded in the agent screen. Decide which you want before the demo.

Who's your QSA, and when's your next assessment? If you're SAQ D today and you're moving to SAQ A, that needs to be documented and re-attested. If your assessment is six weeks away, you've got a sequencing decision: rush the rollout so the new architecture is in place for the QSA visit, or delay until after and re-scope for next year.

Integration patterns — which one fits your stack#

There are four broad ways IVR payment systems connect to your call flow. The right one depends on your telephony, your call volumes, and how much you want your agents to feel the change.

SIP redirect. Your telephony platform transfers the customer's call leg to the payment vendor's SIP endpoint for the payment step, then transfers back. The agent stays on the line via a conference bridge. Audio splits — the customer's DTMF tones go to the payment vendor, the agent hears tone replacement (a flat beep) and gateway responses. This is the cleanest pattern and the one we recommend for new builds. Setup is usually a SIP trunk plus DTMF configuration on your SBC.

API-triggered click-to-pay. The agent clicks a button in their CRM, which fires an API call to the payment vendor. The vendor sends the customer an SMS or in-call IVR prompt to enter their card. The agent watches the status change in real time. This is the pattern for ad-hoc payments, mid-call upgrades, and inbound queues that don't always end in a transaction. Our click-to-pay solution is built around this.

Fully automated inbound IVR. Customers dial a dedicated number (or are routed by your menu to a self-service queue) and pay without ever speaking to an agent. Best for utility bills, ticketing, recurring top-ups, and any high-volume routine payment. You'll need clear authentication — usually account number plus a postcode or date of birth — and a sensible fall-through to a live agent if anything fails.

Outbound IVR or SMS-to-pay. For arrears, renewals, scheduled charges. Your collections team or campaign tool triggers an outbound call or text with a payment link or a callback number. The customer authenticates and pays. Outbound payment campaigns are how a lot of insurers and utilities now handle missed direct debits.

Most mid-market deployments end up with two or three of these running in parallel: agent-assisted for inbound service calls, automated IVR for repeat customers, and outbound for arrears. You don't need to launch them all at once. Pick the one with the highest call volume first.

A realistic week-by-week rollout timeline#

This is the timeline we usually quote a contact centre of 40-100 seats with cloud telephony and a mainstream gateway. Larger or more complex stacks add weeks; simpler ones knock weeks off.

Week 1 — discovery and contract. Vendor walks your call flows, audits your phone stack, confirms gateway integration, and produces a statement of work. You sign. PCI documentation kicks off in parallel — your QSA (or your vendor's, if they offer one) drafts the responsibility matrix.

Week 2 — SIP and gateway integration. SIP trunk provisioned between your telephony and the payment vendor. Test calls running through to the gateway sandbox. CRM integration scoped — usually an API call from a custom button or a small embedded widget.

Week 3 — UAT. Test transactions with real cards from your test pool. Decline handling, 3DS step-up, partial captures, refunds, tokenisation for repeat customers. Whiteboard the agent script and the customer-facing IVR prompts. Record the prompts in your brand voice (or use the vendor's stock prompts if you're in a hurry).

Week 4 — pilot. Five to ten agents take live calls through the new flow. Daily stand-ups. You'll find at least three things that don't work the way the demo suggested — a DTMF tone that doesn't strip cleanly, a gateway response code your agents don't understand, a customer journey that confuses people. Fix them.

Weeks 5-6 — phased rollout. Roll out to the rest of the floor in waves. Update agent training. Switch off the legacy capture process (and this is the bit people forget — leaving the old screen accessible "just in case" keeps you in full PCI scope). Re-attest with your QSA on the new architecture.

Self-service IVR for inbound, or outbound campaigns, usually follow 4-8 weeks after agent-assisted goes live, once you've got the operational rhythm.

What changes for your agents (and how to brief them)#

The biggest cultural shift is what agents say during the payment step. They go from reading numbers back ("OK, that's 4-5-3-2... and the security code?") to handing the call over to the system ("I'm just going to pop you through to our secure payment line — you'll hear some prompts to enter your card details on your keypad, and I'll be right here when you're done"). For agents who've been doing this for years, that feels like losing control. They need to know they still own the call.

Here's the script we usually recommend. Adjust the words to fit your brand voice but keep the structure:

"Right, I've got your total at £X. I'm going to pop you through to our secure payment system now — you'll hear a prompt to enter your long card number, then expiry, then security code. I'll be on the line throughout, I just won't see or hear your card details. Ready to go?"

Then trigger the IVR. The customer enters their details, you hear tone replacement and the gateway confirmation. You pick up the conversation: "Lovely, that's gone through, reference 12345. Anything else I can help with?"

A few things to brief explicitly: agents should never offer to "key it in for you" as a fallback — that defeats the whole point. If a customer can't use their keypad (older phones, accessibility issues), the right answer is to take a payment link via SMS or email, not to revert to verbal capture. And agents should expect about 5-10% of customers to ask "why can't I just read it to you?" — train them on a one-liner. Ours is "It's to keep your card details safe — even our agents can't see them, which means they can't be stolen from us".

Tokenisation, recurring charges and stored cards#

If any portion of your business takes repeat payments — subscriptions, renewals, instalments, top-ups — you want tokenisation switched on from day one. A token is a meaningless reference that points to the real card stored at the gateway. You can charge it again later without re-prompting the customer, and because the token sits inside the gateway (not your CRM), it doesn't pull anything back into PCI scope. The dedicated page on sensitive data capture covers the mechanics.

The decision you have to make on day one is where tokens are stored and what they're scoped to. Most gateways offer two flavours: a token scoped to a single merchant ID (only usable by you), and a network token scoped to the card scheme (portable across processors, automatically updated when the card is reissued). Network tokens are better for long-running subscriptions because they survive card expiries and re-issues. Merchant tokens are fine for shorter relationships.

Either way, you need a clear policy: who's authorised to trigger a token charge, how does the customer consent to being stored, and how do they remove themselves later. Tokenisation done badly creates GDPR problems even when it doesn't create PCI problems. We've also seen rollouts get held up because nobody decided what happens to existing manually-stored cards on day one — the safest answer is to re-tokenise them on the customer's next interaction, not migrate them in bulk.

DTMF masking, channel separation and what your auditor will ask about#

Two technical concepts your QSA will quiz you on. DTMF masking is the suppression of the audible tone so it doesn't reach the agent or get into the call recording. Channel separation is the structural split of the call leg, so the customer's DTMF is routed to the payment vendor and the agent's audio is on a different bridge entirely. Both matter, and they do different jobs.

Masking alone — without channel separation — is the cheaper approach. The customer's tones still touch your phone system and your carrier, you just replace them with flat tones in the recording and in the agent's headset. This reduces your scope but doesn't eliminate it; you're still relying on the carrier and PBX vendor to behave. Channel separation routes the customer's DTMF audio away from your network entirely, before it ever reaches your phone system. This is what gets you to SAQ A. Our solution page on DTMF masking versus channel separation spells out the trade-offs.

When your QSA visits, expect questions about: the SIP path the DTMF takes, where masking is applied and by whom, what the call recording captures, who has access to live audio, how token storage is segregated, and what happens on a failover. Have the vendor's responsibility matrix ready and have a network diagram. The visit goes from a half-day to two days if you don't.

Common rollout traps and how to avoid them#

The CRM screen still shows the PAN on save. Easy one to miss. Your agent doesn't capture the card — the IVR does — but your CRM workflow still has a "card number" field that pulls back from the gateway response. Anything that has the full PAN in it is in scope. Make sure the response your CRM receives is the last four digits and the token, never the PAN.

Pause-and-resume left on as a "backup". If you keep the old verbal-capture process running in parallel for the first month, your QSA will treat your environment as if the old process is still in use. Switch it off at cut-over, not three months later.

The chatbot still has card capture. If you have a web chat with payment capability, it needs to be on the same compliant path. Web chat payments are out of scope of your IVR rollout but in scope of your overall PCI estate. Don't fix the phone channel and leave the chat channel as a back door.

Refunds go through a different path. Customer service raises refunds in the gateway portal, which is fine for compliance but a nightmare for reporting because nobody knows where to look. Make sure refunds flow through the same workflow that captured the original payment, ideally triggered from the CRM ticket.

The IVR prompts are robotic. Your customers will hate it. Pay the £400 for a proper voice artist to record the prompts in a friendly tone. It's the single highest-impact change you can make to CSAT on the payment leg.

Nobody owns post-go-live. Pick a named operations lead to own the payment system in BAU. Decline rates, gateway response codes, monthly reconciliation, vendor change notes — somebody has to read this stuff.

How Paytia handles it (and what to look for in any vendor)#

We're biased — we built Paytia exactly for the contact-centre rollout described above — but the same checklist applies to any vendor you talk to. Look for: pre-built integrations with your gateway and your CRM, channel separation as standard (not masking-only), agent-assisted and fully automated IVR in the same platform, recurring and outbound built in, a named onboarding manager, and a clear responsibility matrix with your QSA. If a vendor can't draw the SIP path on a whiteboard in their first call with you, walk away.

Pinnacle Group cut PCI scope by 95% running on our agent-assisted IVR. Warby Parker and InsureandGo run mixed agent-assisted and self-service IVR through the same platform. Contact centres, insurers and utilities have the highest call-payment volumes and tend to see ROI inside three months on agent time saved alone.

Cost — what to expect when you're costing this up#

Three components, broadly. Per-transaction fees (a few pence per successful payment, sometimes tiered by volume). Per-minute or per-call fees on the IVR leg (usually 1-3p per minute that the customer is on the secure payment line, which is short — a card capture takes 60-90 seconds). And platform fees (a monthly minimum, sometimes tied to seat count, sometimes flat). For a 50-seat contact centre running 15,000 transactions a month at £100 average ticket, you're looking at high-three-figures to low-four-figures monthly all-in. Compare that to the cost of one mis-handled card breach (six figures of fines and remediation, minimum) and the ROI maths is straightforward.

Watch for vendors that pad the price with "integration fees", "compliance fees" and "professional services". A reputable vendor builds the integration into their go-live price. Anything itemised after that should be optional add-ons, not core to making the system work.

Authentication and customer identity in self-service IVR#

Once you move past agent-assisted into fully automated IVR, you've got an authentication problem to solve. The agent isn't there to verify who's on the line, so the system needs to do it. The pattern we see working is two-factor lite: a customer-facing reference number (invoice number, account number, policy reference) plus a piece of personal data the customer would know but a fraudster probably wouldn't (postcode, date of birth, last four of a registered phone number). It's not perfect, but it's a reasonable trade-off for routine payments under, say, £500.

For higher-value or higher-risk transactions, you want to push the customer to a secure web payment link instead, where you can run 3D Secure and proper risk scoring. Don't try to bolt full identity verification onto a voice IVR — the customer experience falls apart, declines spike, and you end up with people abandoning halfway through. Voice IVR is brilliant for fast, routine payments. It's not the right channel for first-time high-value transactions.

One thing to design in early: a clean fall-through to a human. If the customer fails authentication three times, gets confused, or hits an edge case, the system should route them to a live agent — not just hang up. The handover should pass the context (caller ID, account number if known, what step they were on) so the agent doesn't start cold. The vendors who do this well treat IVR as the front door, not the whole house.

Handling declines, 3DS step-up and partial captures#

Half your support calls about the new system will be about declined cards. Brief your agents on the common gateway response codes — insufficient funds, expired card, do-not-honour, suspected fraud, 3DS authentication failed — and what to say to the customer for each. Most of the time the right answer is "your card's been declined by your bank; would you like to try a different card, or would it be easier if I sent you a payment link to use later?". Don't let agents guess at the reason. The bank doesn't tell you, and speculating makes things worse.

3D Secure 2 step-up is the modern fraud check — if the issuer wants extra authentication, the customer gets a prompt on their banking app. Inside a voice IVR, the path is usually: the gateway returns a "challenge required" code, the system sends an SMS link, the customer authenticates in their banking app, then comes back to the call. It works but it's clunky. For high-volume self-service IVR, a lot of merchants now route to a hosted payment page (SMS link) for the entire transaction rather than IVR-and-step-up. Worth weighing in your design.

Partial captures (taking £40 of a £100 balance because the customer can't pay the full amount today) are common in arrears and collections. Your IVR vendor should let agents enter the actual amount taken, not the original balance. If your gateway settles on the partial amount and your CRM still shows the full balance as paid, you've got a reconciliation problem.

Call recording, compliance and what to do with the audio#

UK FCA-regulated firms have to record calls. So do most insurance and financial services contact centres for compliance and complaint-handling. The IVR rollout doesn't remove that obligation — it changes what the recording contains. Once channel separation is in place, the customer's DTMF audio is never on the recording. What's left is the agent's voice, the customer's voice everywhere except the payment step, and a flat tone where the keypad entry happened.

That's the right outcome. But it does mean if a customer disputes a transaction, the recording can only prove that a card was entered, not which card. Make sure your gateway logs (token, last four, timestamp, amount, response code) are accessible to your QA team and tied back to the call recording by case ID or call ID. Some vendors index this automatically; others leave it to you to build.

Retention is the other one. Card data retention rules are strict (you can't hold the PAN at all, beyond the moment of transaction, unless you have a documented reason). Call recording retention is set by your sector — typically 6 years for FCA-regulated voice. The IVR vendor handles the card data side; you handle the recording side. Make sure your data capture policy covers both clearly.

Reporting, reconciliation and the operational dashboard#

What does "good" look like in week 12, once IVR payments are live across the floor? The metrics we'd want a contact-centre operations lead to be tracking weekly:

Payment completion rate — what percentage of attempted IVR payments end successfully? Anything below 85% suggests a usability problem in the prompts or an authentication issue. Above 95% is excellent.

Average time on the secure line — should be 60-90 seconds for a full card capture. If it's drifting over 2 minutes, the prompts are too long or the customer is getting confused.

Decline rate by response code — track the top five reasons and watch for spikes. A sudden jump in "do not honour" responses often points to a gateway risk-rule change at the acquirer end.

Agent handle time — should drop noticeably (typically 30-60 seconds per call) because agents aren't reading numbers back and waiting for confirmation. If it hasn't dropped, agents are over-talking around the payment step. Re-brief.

Tokenised customer percentage — for businesses with repeat customers, how many of your active customers now have a stored token? This is the lead indicator for your recurring revenue and your customer effort score on repeat purchases.

Refund and chargeback rates — should be stable. If chargebacks rise, that's usually a CSAT or fulfilment issue rather than anything to do with the payment system, but check anyway.

Your vendor should give you a dashboard for most of this out of the box. If you have to build the reporting yourself in week 13, ask why they didn't include it.

What changes for QSAs, your SAQ and the annual cycle#

Once your IVR rollout is complete and channel separation is in place, you're typically eligible to drop from SAQ D to SAQ A. SAQ A has 22 controls; SAQ D has over 300. That's the headline of the scope reduction.

What your QSA will want to see at re-attestation: an updated network diagram showing the SIP path and where DTMF is segregated, the responsibility matrix between you and the IVR vendor, the gateway's PCI Attestation of Compliance (AoC), evidence that pause-and-resume and verbal capture are decommissioned, your incident response plan updated for the new architecture, and your training materials confirming agents are briefed on the new flow.

The first re-attestation after rollout usually takes longer than subsequent ones because there's new evidence to review. Budget for a day or two more QSA time in year one, then it settles. Some QSAs will want to listen to a sample of calls to verify the audio is genuinely separated — be ready for that and prep the sample with your vendor.

Your annual cycle changes too. Quarterly external vulnerability scans (ASV scans) are still required, but they're scanning a smaller environment. Internal scans drop in scope. Penetration testing — if you were doing it on the whole call-centre estate — now focuses on the agent desktops and CRM, not the card capture path. We've seen QSA fees drop by a third in year two purely because there's less to assess.

Special cases — charities, healthcare, education, public sector#

A few sectors have wrinkles worth flagging.

Charities often take one-off donations by phone alongside regular giving. The IVR rollout needs to handle Gift Aid declarations (a verbal yes/no captured in the recording, or a DTMF press) and recurring direct-debit setup alongside card. Non-profit contact centres we work with usually run agent-assisted IVR for the conversation and self-service for repeat regular givers.

Healthcare — UK NHS or private medical — adds patient identity verification on top of card. Patient ID, postcode and date of birth typically. The conversation flow is sensitive (you're discussing health conditions), so the payment step needs to feel like a small administrative interlude, not a hard sell. Healthcare contact centres tend to favour agent-assisted IVR exclusively.

Education — universities, schools, after-school programmes — have peaks around term enrolment, exam fees and event tickets. Plan capacity for peak weeks and consider self-service IVR for the routine enrolment payments to take pressure off agents during peak.

Public sector — council tax, parking, fines, fees — usually wants automated IVR end to end because volumes are high and the transactions are routine. The integration with the council's back-office system (Capita, Civica, Northgate) is the long pole; the IVR side is usually fast.

Multi-channel — making IVR fit alongside web, chat and email#

Most contact centres taking phone payments also take payments via web checkout, web chat, and SMS link. The mistake we see is rolling out compliant IVR while leaving the other channels on legacy capture, then being surprised when the QSA scope assessment still looks heavy. PCI scope is determined by your worst channel, not your best.

The fix is to plan the full multi-channel cut-over at the start. Web chat payments need an embedded payment widget that doesn't pass cards through your agent screen. Web checkout needs a hosted payment page or iframe from your gateway, not card fields on your own domain. SMS-to-pay needs a tokenised link, not a "please reply with your card number" message. All of this can run on the same gateway as your IVR — most vendors offer the full set.

Sequence the cut-over so the high-volume channels go first. For most contact centres that's: phone (IVR), then web chat, then web checkout, then SMS. Email-to-pay (where customers send card details in an email reply) should be killed off entirely before you start anything else — it's the easiest scope wedge and the highest-risk channel.

Vendor due diligence — the questions to ask before you sign#

Beyond the basics (PCI Level 1 service provider AoC, ISO 27001, SOC 2 Type II if you're in the US or selling there), here's the list of less-obvious questions we'd recommend you put to any IVR payment vendor:

"Who owns the SIP infrastructure between us?" — Sometimes the vendor uses a third-party SBC or carrier. That's fine, but you need to know who's responsible if there's an outage.

"What's your uptime SLA, and how is it measured?" — 99.95% is industry standard for payment platforms. Anything lower is a red flag. Check whether the SLA covers the payment leg specifically or the whole platform.

"How do you handle major incidents?" — Real example: their gateway integration breaks during a Christmas peak. What's their escalation path, who calls you, how fast do they communicate?

"Show me three references in my sector at my size." — A vendor who only has enterprise references but pitches you as a mid-market customer will treat you like a mid-market customer. Be a reference customer for your sector's size.

"What happens at contract end?" — How do you exit? Can you take your tokens with you (often you can't — they're vendor-specific), or do you re-tokenise on a new platform? This matters a lot if you ever switch.

"What's your roadmap?" — Are they investing in conversational AI, mobile-first payment links, new gateway integrations? You want a vendor who's still building, not one in maintenance mode.

Next steps#

If you've worked through the pre-flight questions and you know what your stack looks like, the fastest way forward is a 30-minute call where we walk your call flows and quote an end to end timeline. Book a discovery call or see the IVR payment flow in a live demo — you'll dial in, type a test card, and watch what the agent sees (and crucially, what they don't).