Quick answer: IVR payments let callers pay through an automated keypad flow with no agent on the line. The caller keys in a reference and their card details, the digits route straight to the payment gateway, and a confirmation closes the call. Because the card number never enters your phone system, call recordings or agent screens, those systems stay out of PCI DSS scope, and when the IVR is hosted by a validated provider it typically supports the lightest self-assessment route. Confirm your exact position with your acquirer or assessor.
IVR stands for interactive voice response: the automated menu system that answers a phone line, plays prompts, and reads the caller's keypad presses. An IVR payment system puts a payment flow inside that menu. "Press 1 to pay your balance" is the version most people have heard, and it exists because a large share of phone payments don't need a conversation at all. The caller knows what they owe, has their card in hand, and wants to pay and hang up.
This guide covers how IVR payment processing works, the three flows most operations run, where IVR fits alongside agent-assisted capture, what it does to your PCI compliance, and the design choices that separate an IVR flow that completes payments from one that drives callers to zero.
What IVR payments are and how the flows work
An IVR payment is an unattended card transaction taken over the phone. No member of staff hears or sees anything. The caller interacts with prompts, enters digits on their keypad, and the payment goes to the gateway for authorization. In practice this shows up as three flows.
Inbound self-pay
The caller dials a payment number, usually the one printed on a statement, invoice or letter. The IVR asks for a reference (an account number, invoice number or statement reference), looks up or confirms the amount, then prompts for card number, expiration date and security code. The caller keys each one in, the IVR reads back the amount, the caller confirms, and the payment is authorized. A confirmation is played on the call and can be followed by an SMS or email receipt.
This is the workhorse flow. It runs 24 hours a day, handles any volume the phone line can carry, and never puts a payment in front of a person.
Mid-call transfer
The caller starts with an agent. The conversation resolves whatever needed a human (a query, a dispute, a payment plan agreement), and when it's time to pay, the agent transfers the caller into the IVR payment flow. The caller pays through the same automated prompts, and the flow can hand the caller back to the agent afterward to confirm the payment landed and finish the call.
This gives you the compliance profile of an unattended transaction with the service profile of an agented call. It's a common pattern for collections conversations and for teams that want agents to close calls personally. If the agent should stay on the line during payment instead, that's agent-assisted capture, covered below.
After-hours coverage
An IVR payment line doesn't keep office hours. Callers who ring after close, on weekends or across time zones hit the same self-pay flow and complete the same payments. For operations that print a payment number on statements or letters, this matters: people tend to deal with bills in the evening, after the office that sent the letter has gone home. An automated phone payment line collects the payment when the intent is there rather than asking the caller to try again tomorrow.
Where IVR fits, and where it doesn't
IVR is a volume tool. It absorbs the routine, high-frequency payments where the caller already knows what they're paying: bill payments, balance payments, renewals, installments on an agreed plan. Every one of those calls that completes in the IVR is a call an agent never handles, which means agents spend their time on the calls that actually need judgment: disputes, hardship conversations, complex accounts, callers who want to negotiate.
It is the wrong tool for payments that need a conversation. If the amount has to be agreed, the account has to be untangled, or the caller has objections to work through, an automated menu will frustrate them and lose the payment. Those calls belong with an agent, and the compliant way to take the card there is agent-assisted DTMF capture: the agent stays on the line while the caller types their card number on the keypad and the digits route to the gateway, not the agent.
Both patterns rest on the same mechanics. The caller's keypad presses are DTMF tones, and the payment system captures those tones directly while keeping them off the agent's line and out of recordings. How that capture, clamping and masking works is covered in our guide to DTMF payments. The practical difference is who's present: agent-assisted capture keeps a person on the call, IVR runs with nobody on it.
Most phone-heavy operations end up running both: IVR for the routine volume, agent-assisted capture for the conversations, with payment links as the recovery path when a call drops or a caller struggles.
IVR payment gateway: how the flow reaches your processor
An IVR payment system does not process the payment itself. It captures the card and passes it to a payment gateway, which is the component that actually authorises the transaction against the card networks. Three layers do the work: the telephony platform answers the call and captures the keypad entry, the payment layer passes that capture to your gateway for tokenisation without it reaching your systems, and your gateway authorises and settles.
That split matters commercially, because it means adding an IVR payment line does not mean replacing your payment setup. You keep your own gateway and your own acquiring agreement, on your existing rates. The IVR sits in front of the processor you use today rather than becoming a new one. The card is tokenised with that gateway, so the token stays with your provider.
The one thing to check before you design the flow is whether your gateway is supported for voice capture. Shuttle does not support voice capture on Square or Braintree. On Braintree that comes down to a merchant-account configuration requirement on Braintree's side, and Twilio's own Braintree connector is the route if you need keypad capture there. If your processor is one of those, the phone-adjacent option with Shuttle is a payment link sent during or after the call. Shuttle connects voice and IVR flows to 30+ gateways, listed on the payment providers page.
Two design details to settle before you build. Whether you can authorise now and capture later (useful when the goods ship after the call) depends on both your gateway and the capture layer supporting a split auth and capture, so check that path end to end rather than assuming it. And refunds against an IVR payment are issued in your gateway like any other transaction, not through the phone line.
What IVR does to your PCI compliance
An IVR payment is an unattended transaction, and that shapes the compliance picture.
Card data bypasses your environment. The caller's card number travels as keypad input from their phone to the payment platform and on to the gateway. It doesn't pass through your agents' ears, their screens, your CRM or your own telephony estate. The systems that PCI DSS would otherwise drag into scope on a spoken-card-number call (the phone system, the recordings, the desktops, the people) never touch cardholder data in this flow.
That has a direct effect on validation. Merchant PCI DSS self-assessment ranges from short questionnaires for merchants whose card data is fully handled by validated third parties, up to hundreds of controls when card data touches your own systems. When the IVR is hosted by a validated provider, the merchant typically qualifies for the lightest self-assessment route. The exact SAQ level depends on the details of your setup and your acquirer's requirements, so confirm it with your acquirer or assessor rather than assuming.
Call recording gets simpler too. On an IVR payment there is nothing to pause: card data never enters the call recording path, so recordings can run for quality and dispute purposes without ever containing a card number, and your recording practices stop being tangled up with your payment compliance.
For the wider picture across every phone payment pattern, see our guide to PCI compliant phone payments.
Who uses IVR payments
The businesses that get the most from IVR share a shape: high volumes of routine payments, often collected on behalf of someone else.
Statement printers and AR outsourcers. You already produce the statement or the letter. Printing an IVR payment number on it closes the loop: the recipient calls, keys the reference from the page, and pays. The payment completes without your client's office or yours ever picking up a phone.
Billing services. Medical and dental billing services and RCM firms field patient balance calls all day. An IVR line absorbs the routine balance payments so agents handle the queries and disputes, and it keeps agents away from patient card data entirely.
Collections servicers. Agencies running payment plans need a way for debtors to make each installment without an agent call. A self-pay line takes the scheduled payment at any hour, and mid-call transfer handles the payments agreed during a conversation.
Property managers. Rent is the definition of a routine, repeating payment. An IVR line gives tenants a way to pay by phone without the office handling a single card number.
Most of these businesses collect money that belongs to their clients, which adds a routing requirement on top of the channel: each payment has to settle to the right client's own merchant account, not a pooled one. That's a solvable problem, covered in our guide to taking payments on behalf of your clients, and it applies to IVR payments the same as any other channel: each client's payments route to that client's own merchant account.
Designing an IVR flow that completes payments
An IVR payment flow lives or dies on completion rate, and the failures are predictable. The design notes that matter:
Keep the flow shallow. Every menu layer loses callers. A payment line should go from greeting to card prompt in as few steps as the lookup allows.
Accept the reference from the statement. The caller is holding the letter or statement that told them to call. Ask for the reference printed on it, in the format it's printed in, and confirm the account back to them.
Read back the amount before capture. Confirm what's being charged before asking for the card. It prevents disputes and gives the caller a clean point to bail out if something's wrong.
Offer a payment-link fallback by SMS. Some callers struggle with keypad entry: long card numbers, mobile handsets, mistyped digits. Offering to text a payment link lets them finish on their own screen instead of abandoning.
Keep a path to an agent. A caller who can't complete in the IVR should reach a person (or a callback queue) rather than a dead end. The agent can then take the payment with agent-assisted capture.
None of this is exotic. It's the difference between an IVR that collects the routine volume and one that generates complaint calls.
How to choose an IVR payment system
Most IVR payment systems demonstrate well, because the demo is a caller keying in a card and a success message. The differences show up later, in what you had to change to get there and what happens when the flow does not fit. The questions worth asking:
Where does card data actually go? Ask for the data path in writing: which systems the digits pass through, what is retained, and what lands in your call recordings. If the card number touches your telephony platform at any point, that platform is in scope.
Which gateways does it work with? A system tied to a single processor means adding a phone channel forces a payments migration. Check that yours is supported before anything else, and check whether you can keep more than one if you collect for different entities.
Can callers move between the IVR and an agent? Mid-call transfer into the payment flow and back to the agent is the difference between an IVR that handles routine volume and one that dead-ends every caller with a question.
Does it cover your other phone patterns? Few operations run IVR alone. Agent-assisted capture for conversations, AI voice agents where those are deployed, and a link to fall back to when a card declines or a call drops all need to work off the same integration and reconcile in one place.
Can it route per client? If you collect on behalf of other businesses, each payment has to settle to that client's merchant account. Systems built for a single merchant make this a manual reconciliation problem later.
What do you have to build? Expect to build the agent-side screen for your own workflow. What you should not have to build is the capture, the compliance boundary or the gateway connections.
How is it priced? Per transaction and per agent seat behave very differently as you grow, particularly for seasonal or campaign-driven phone volume. Shuttle charges per transaction, with a monthly fee per live app, and never per agent seat. See pricing for current rates.
How Shuttle handles IVR payments
Shuttle provides IVR self-payment as part of one phone payments layer:
IVR payment flows run on Twilio voice infrastructure. Shuttle is Twilio's chosen provider to enable Twilio Pay for many payment gateways. Inbound self-pay, mid-call transfer and after-hours coverage all run on the same rails.
Card details are tokenized with the payment gateway itself. Shuttle holds no card vault of its own, so the IVR doesn't create a new place where card data accumulates.
Your gateway, not ours. Shuttle works with 30+ payment gateways, so IVR payments settle through the merchant account you already have. Voice capture works on many supported gateways; payment links cover the rest.
The fallbacks are built in. A payment link by SMS or email when keypad entry fails, agent-assisted capture when the call needs a human, and bank payment options where cards don't fit.
Multi-client routing. If you run an IVR line on behalf of many clients (statement printers, billing services, collections servicers, property managers), each client connects their own merchant account and every payment goes to the one you configured.
IVR payments FAQ
What is an IVR payment?
An IVR payment is a card payment made through an automated phone menu, with no agent on the line. The caller enters a reference and their card details on their phone keypad, the digits route to the payment gateway for authorization, and the caller gets a confirmation. It's an unattended, card-not-present transaction.
Are IVR payments PCI compliant?
The pattern supports compliance well: card data goes from the caller's keypad to the payment gateway without entering your phone system, recordings or screens, so those systems stay out of PCI DSS scope. When the IVR is hosted by a validated provider, this typically supports the lightest self-assessment route for the merchant. Your exact SAQ level depends on your setup, so confirm it with your acquirer or assessor.
Can callers pay after hours?
Yes. An IVR payment line runs around the clock, so callers who ring in the evening, on weekends or from other time zones complete payments while your office is closed. For businesses that put a payment number on printed statements or letters, after-hours coverage is often where a large share of the volume arrives.
What happens if the caller makes a mistake?
Well-designed flows read back what was entered and let the caller correct it: re-enter the card number, fix the reference, or confirm the amount before anything is charged. If keypad entry keeps failing, the flow should offer a payment link by SMS so the caller finishes on their own screen, or route them to an agent.
Can an agent transfer a caller to the IVR and get them back?
Yes. Mid-call transfer hands the caller into the automated payment flow, and the flow can return the caller to the agent once the payment completes. The agent never hears or sees card details, the transaction stays unattended for compliance purposes, and the agent still closes the call personally.
Does IVR work for payment plans?
Yes. A payment plan needs each installment collected on schedule, and a self-pay line gives the payer a way to make each one without an agent call. Collections servicers commonly pair an agent conversation (where the plan is agreed) with IVR self-pay or scheduled payment links for the installments that follow.
What does IVR payment mean?
IVR stands for interactive voice response, the automated menu that answers a phone line and reads the caller's keypad presses. An IVR payment means paying through that menu rather than to a person: the caller keys in a reference and their card details, the system authorises the payment, and a confirmation closes the call. There is no agent on the line, and the card number goes straight to the gateway without entering your systems.
What is an IVR payment gateway?
The term usually means one of two things. Strictly, the gateway is the payment processor that authorises the transaction, and the IVR is the phone flow that captures the card and passes it on. Loosely, people use it for the combination of the two: the automated phone line plus the connection to their processor. If a supplier uses the phrase, ask which they mean, and specifically whether their system works with the gateway you already use.
Is an IVR payment a MOTO transaction?
Usually yes. A payment taken over the phone is card-not-present and is commonly processed as MOTO, short for mail order and telephone order. MOTO transactions are out of scope of strong customer authentication, under PSD2 in the EEA and under the UK's onshored SCA rules, which is why a MOTO-processed IVR payment does not carry a 3-D Secure challenge. That depends on how the transaction is submitted: if the flow finishes on a hosted payment page, or the payment is submitted as e-commerce, SCA applies. Confirm the classification and the associated rates with your gateway and acquirer.
Can an IVR handle bill payments and account top-ups?
That is the flow IVR suits best. Bill payments, statement balances, account top-ups and instalment payments all share the same shape: the caller knows the amount, holds a reference, and wants to pay without a conversation. Printing a payment number on the statement or letter that prompted the call closes the loop.
How much do IVR payments cost?
Pricing models vary more than the technology does. The two common shapes are a charge per transaction and a charge per agent seat, and which is cheaper depends on how your phone volume is distributed across the year. Shuttle charges per transaction, with a monthly fee per live app, and never per agent seat. See the pricing page for current rates.
Related reading
PCI Compliant Phone Payments: How to Take Card Payments Over the Phone
DTMF Payment Processing: PCI Compliant Capture, Clamping & Masking
Want your routine phone payments handled without an agent on the line? Talk to us. If you'd rather explore the technical side first, docs.shuttleglobal.com covers the flows, with sandbox accounts available for testing.