Call center payment processing is how contact centres take card payments on live calls without card numbers reaching agents, recordings or systems. This guide covers the PCI-compliant approaches, what to evaluate, and how it works across 30 contact centre platforms.
Call Center Payment Processing: The Short Answer
Call center payment processing lets your agents, IVR, or AI voice agents take card payments during a live call without the card number ever entering your environment. The customer enters their card details on the phone keypad inside a PCI DSS Level 1 certified payment environment, so the digits never reach the agent, the screen, or the recording, and the payment is routed to your own gateway. That limits the contact centre's PCI scope, and many operations can then validate under a shorter self-assessment (commonly SAQ A) rather than the full SAQ D.
There are four call centre payment processing options, and most contact centres use more than one: agent-assisted keypad capture (agent stays on the line), fully automated IVR payments (no agent), AI voice agent capture (autonomous), and SMS or email payment links sent mid-call as a fallback. The right call center payment solution supports every channel, fits your telephony setup, and routes across multiple payment gateways from one integration. The rest of this guide covers how each option works, what PCI requires, and what to evaluate.
If you're running a contact centre, for an insurance brokerage, a debt-recovery agency, a utility, a healthcare revenue-cycle team, a hotel chain, or a multi-tenant BPO, you've already met the payment gap. Customers want to pay on the call. Many contact centre platforms have no native, PCI-compliant way to capture their card.
Agents reading numbers into recordings drag your environment into PCI scope. Single-PSP partnerships lock you to one acquirer and break when you expand to a new geography. External pay-by-link tools fragment the customer experience and hurt conversion. The right answer depends on your platform, your volume, and whether you're a merchant taking the calls or a solution provider implementing contact centres for clients.
This guide is for merchants taking payments through their contact centre, and for solution providers and system integrators deploying CCaaS platforms (Talkdesk, Genesys, Five9, NICE CXone, RingCentral, Amazon Connect, Avaya, Cisco, Vonage, 8x8, Dialpad, Aircall, Zendesk, Intercom and more) for their clients. It covers what PCI compliance actually requires, the three architectural approaches to secure card capture, what to evaluate in a payment solution, and platform-specific guides for 30 contact centre platforms.
The Contact Centre Payment Problem
Contact centres (call centers) handle an enormous number of card payments every day. Insurance premiums. Utility bills. Debt collections. Subscription renewals. Travel bookings. Order payments.
Every one of these transactions creates a PCI compliance problem.
The moment a customer reads a card number to an agent, that data has entered your environment. It's in the audio stream. It may be in a call recording. It's been heard by a human. And depending on your infrastructure, it may have passed through systems that aren't PCI certified.
Most contact centres deal with this in one of three ways:
Accept the risk. Agents take card details verbally, processes are "tightened," and the business hopes nothing goes wrong. This is still common. It's also a breach waiting to happen.
Avoid phone payments entirely. Agents direct customers to a website or send a payment link after the call. This works but breaks the conversation, increases drop-off, and frustrates customers who called specifically to pay.
Deploy a secure payment capture solution. Card data is captured within a PCI-compliant environment during the call, and the card digits never reach the agent, the screen or the recording.
Option 3 is the only one that scales.
What PCI Compliance Actually Requires
PCI DSS (Payment Card Industry Data Security Standard) applies to every organisation that stores, processes, or transmits cardholder data. If your contact centre handles card payments in any form, you're in scope.
The Scope Problem
Traditional contact centre payment flows put almost everything in PCI scope:
Telephony systems — because card data passes through them
Call recording platforms — because recordings contain card numbers
Agent workstations — because agents see or hear card data
Network infrastructure — because card data traverses it
CRM systems — if agents type card details into them
This is PCI SAQ-D territory, the most demanding self-assessment questionnaire, with several hundred requirements covering network segmentation, encryption, access controls, monitoring, vulnerability management, and more.
Maintaining PCI DSS Level 1 compliance for this kind of environment is a significant, recurring cost.
The De-Scoping Approach
The alternative is to remove card data from your environment entirely. If card data never touches your telephony, recordings, agents, or network, your PCI scope can drop to SAQ-A, the lightest level.
This means:
Card data is captured within an external PCI-certified environment at the point of payment
The card digits never reach your systems, the agent, or the recordings
Agents can stay on the call while the secure capture handles the payment step
Your CRM receives only a transaction result (approved/declined) and a token, not card numbers
The payment provider carries most of the PCI burden. You still validate your own compliance, but against a far shorter questionnaire.
Three Approaches to Secure Contact Centre / Call Center Payments
1. Pause-and-Resume
The agent pauses call recording, asks the customer for card details, processes the payment, and resumes recording.
How it works: The agent manually (or via a button) pauses the recording system, takes card details verbally, enters them into a payment terminal or software, and then resumes recording.
The problem: This reduces recording exposure but doesn't solve the fundamental issue. The agent still hears the card number. The telephony system still carries the data. The agent's workstation is still in scope. And "pausing" recording depends on human compliance — agents forgetting to pause, pausing late, or resuming early all create gaps.
PCI impact: Still SAQ-D. Most of your environment remains in scope.
Verdict: It reduces recording exposure but leaves the agent, desktop and telephony in scope, and it depends on a manual step being done correctly every time.
2. DTMF Capture in a Certified Environment
The customer enters card details via keypad. The card is captured inside a PCI-certified payment environment at the point of payment, so the digits never reach your systems and never reach the agent.
How it works: When payment capture begins, a secure, PCI-certified card capture takes over the payment step. The customer enters their card on the keypad inside that environment. The agent can remain on the call and talk to the customer, but the card digits never reach them or their screen. Only a masked confirmation (for example, the last four digits) is returned.
The advantage: Card data never enters your environment. The agent stays connected for conversation and reassurance. Recordings are clean. Your PCI scope can drop to SAQ-A.
PCI impact: SAQ-A, minimal scope. Most of the PCI burden sits with the payment provider.
Verdict: The most mature and widely adopted approach for agent-assisted contact centre (call center) payments.
3. AI Agent Payment Capture
An AI voice agent handles the conversation and triggers payment capture autonomously, via DTMF or an SMS payment link.
How it works: The AI agent determines when a payment should be captured, triggers the payment layer, and the customer enters card details via keypad or receives a payment link. The AI model never processes card data. The payment layer handles capture, tokenisation with the gateway, and routing to your gateway.
The advantage: Fully automated. No human involvement. Scales without adding agents. Works for inbound payments (renewals, bills) and outbound (collections, sales).
PCI impact: Same as DTMF — SAQ-A if the architecture is right.
Verdict: The emerging approach for AI-first contact centres and call centers. In production today with providers processing payments across regulated industries.
For a deep dive on the AI agent architecture, see How AI Voice Agents Take PCI-Compliant Payments.
What to Evaluate in a Contact Centre / Call Center Payment Solution
PCI Certification
Is the provider PCI DSS Level 1 certified as a Service Provider? This is the highest level — required for providers handling large transaction volumes. Don't accept Level 2 or self-assessed certifications for production deployments.
Card Capture Quality
Is the card captured inside the provider's own PCI-certified environment (reliable), or does it lean on stripping or post-processing card data inside your systems (less reliable, and tends to reintroduce scope)? Does any card data reach agents, screens or recordings? What does the customer experience during the payment step?
Gateway Support
How many payment gateways does the solution support? This matters if:
You serve clients with different PSP relationships
You operate across regions with different acquirers
Your enterprise clients mandate specific gateways
You want to move a payment type to a different processor later without re-integrating
A single-gateway solution works until it doesn't. Multi-PSP support through a single integration prevents gateway lock-in. For BPOs handling payments across multiple clients, this is especially critical — see Payment Collection for BPOs.
Channel Coverage
Does the solution support:
IVR (automated payments without an agent)?
Agent-assisted (DTMF with the agent on the line)?
AI agents (autonomous payment capture)?
SMS payment links (fallback when phone capture isn't practical)?
Your needs will evolve. A solution that handles one channel today should support others without re-integration.
Carrier Requirements
Which telephony provider does the solution require today, and is a carrier-agnostic option on the roadmap? Voice capture is often tied to a specific carrier. Shuttle's voice capture, for example, runs on Twilio Pay today, so using it for voice means being a Twilio customer; for Twilio-based contact centres, Pay Connectors connect your gateway. Shuttle works with Twilio today, and any carrier coming soon, so plan around the current requirement rather than assuming any carrier works today.
Agent Experience
What does the agent see during payment capture? A good solution provides:
Real-time status (waiting for input, validating, processing)
Masked confirmation (last four digits)
Transaction result (approved/declined)
Ability to send an SMS payment link if DTMF fails
Reporting and Reconciliation
Can you track payment activity, apply refunds, and reconcile transactions from a single dashboard? Can merchants (if you're a platform) self-serve reporting through a white-label portal?
Pricing Model
Ask how the provider charges (per transaction, per seat, or a platform fee) and whether telephony usage is billed separately by your carrier. Per-transaction pricing aligns cost with payments taken; per-seat fees scale with headcount. Shuttle charges per transaction rather than per seat; see current pricing for the full model.
Payments by CCaaS Platform
Each platform has its own quirks: telephony architecture, agent desktop, AI capabilities, and partner ecosystem. The pattern is similar (multi-PSP routing, secure card capture, an agent-side interface you build, payment links) but the specifics differ. Choose your platform below for a guide written for merchants and implementation partners:
Talkdesk Payments: PCI-compliant payments for merchants and implementation partners on Talkdesk.
Genesys Cloud Payments: PCI-compliant payments for merchants and implementation partners on Genesys Cloud.
Five9 Payments: PCI-compliant payments for merchants and implementation partners on Five9.
NICE CXone Payments: PCI-compliant payments for merchants and implementation partners on NICE CXone.
RingCentral Payments: PCI-compliant payments for merchants and implementation partners on RingCentral.
RingCX Payments: PCI-compliant payments for merchants and implementation partners on RingCX.
Amazon Connect Payments: PCI-compliant payments for merchants and implementation partners on Amazon Connect.
Avaya Payments: PCI-compliant payments for merchants and implementation partners on Avaya.
Cisco Webex Contact Centre Payments: PCI-compliant payments for merchants and implementation partners on Cisco Webex Contact Centre.
Vonage Contact Centre Payments: PCI-compliant payments for merchants and implementation partners on Vonage Contact Centre.
8x8 Payments: PCI-compliant payments for merchants and implementation partners on 8x8.
Dialpad Payments: PCI-compliant payments for merchants and implementation partners on Dialpad.
Aircall Payments: PCI-compliant payments for merchants and implementation partners on Aircall.
Zoom Contact Center Payments: PCI-compliant payments for merchants and implementation partners on Zoom Contact Center.
Sprinklr Payments: PCI-compliant payments for merchants and implementation partners on Sprinklr.
Zendesk Payments: payment links and voice payments for teams working in Zendesk.
Intercom Payments: payment links and voice payments for teams working in Intercom.
Cresta Payments: taking payments while keeping Cresta recording and analytics out of card data.
Observe.AI Payments: taking payments while keeping Observe.AI recording and analytics out of card data.
Verint Payments: taking payments while keeping Verint recording and analytics out of card data.
UJET Payments: payment links and voice payments for teams working in UJET.
Gladly Payments: payment links and voice payments for teams working in Gladly.
Freshdesk Contact Center Payments: payment links and voice payments for teams working in Freshdesk Contact Center.
Salesforce Service Cloud Payments: payment links and voice payments for teams working in Salesforce Service Cloud.
Nextiva Payments: PCI-compliant payments for merchants and implementation partners on Nextiva.
LivePerson Payments: payment links and voice payments for teams working in LivePerson.
GoTo Payments: PCI-compliant payments for merchants and implementation partners on GoTo.
Content Guru storm Payments: PCI-compliant payments for merchants and implementation partners on Content Guru storm.
3CX Payments: PCI-compliant payments for merchants and implementation partners on 3CX.
Mitel Payments: PCI-compliant payments for merchants and implementation partners on Mitel.
For Solution Providers and System Integrators
If you're a CCaaS implementation partner, a Talkdesk AppConnect partner, a Genesys AppFoundry developer, a NICE partner, a Cisco Solution Partner, an AWS Partner Network member, or an SI deploying any of the platforms above for clients, Shuttle is the payment layer that sits alongside your build. It supports white-label deployment and multi-PSP routing across your client portfolio, so each client keeps their preferred acquirer. Shuttle is Twilio's chosen provider to enable Twilio Pay for many payment gateways, and the same pattern applies across the 30 platforms covered in this guide. For partnership conversations, book a discovery call. For the full implementation-partner delivery model (discovery, design, integration, pilot, go-live) see Payments for CCaaS Implementation Partners.
The BPO and Outsourcer Angle
If you're a BPO, call answering service, or outsourced contact centre, the payment problem compounds: you're handling payments for multiple clients, each with their own PSP, their own branding, and their own compliance requirements.
Many DTMF solutions are designed around a single merchant account and do not route per client out of the box, so Client A on Worldpay and Client B on Stripe means two deployments.
This is where a multi-PSP payment layer designed for platforms and outsourcers becomes essential. A single integration routes each client to their own PSP and limits the BPO's PCI scope.
For the full breakdown, see Payment Collection for BPOs: Multiple Clients, Multiple PSPs, Limited PCI Scope.
Common Objections
"Our current process works fine." It works until an audit, a breach, or a client security review exposes the gap. PCI non-compliance can mean fines from the card schemes, higher processing costs, and in a serious breach the loss of the ability to take card payments at all. The operational cost of staying compliant with a full-scope environment is ongoing, not one-off.
"Customers won't use the keypad." Most customers are familiar with keypad entry from phone banking and automated lines, and completion rates for keypad payments in live calls are typically high. For customers who struggle, the agent can send an SMS payment link during the same call as a fallback.
"Adding another system increases complexity." A secure payment layer replaces complexity. Without it, you're managing PCI compliance across your entire telephony and recording stack. With it, you manage a single integration and most of the PCI burden sits with the provider.
"We'll handle it when we scale." PCI compliance isn't a scale problem — it's a binary. You either handle card data securely or you don't. The risk exists from the first transaction.
FAQ
What is PCI DSS and does it apply to contact centres? PCI DSS is the Payment Card Industry Data Security Standard. It applies to any organisation that stores, processes, or transmits cardholder data. If your contact centre takes card payments over the phone, you're in scope.
What's the difference between SAQ-A and SAQ-D? SAQ-A is a short self-assessment (a few dozen requirements) for businesses that fully outsource card data handling. SAQ-D is the full assessment (several hundred requirements) for businesses that process card data in their own environment. Using a secure payment capture solution can move you from SAQ-D to SAQ-A.
Is a call center PCI compliant if it takes card payments over the phone? Any call center that takes card payments has PCI DSS obligations and must validate its own compliance, usually through a self-assessment questionnaire. What changes is the scope. If agents hear card numbers or type them into your systems, the desktops, recordings and network fall into scope. If the card is captured inside a PCI DSS Level 1 certified provider's environment so the digits never reach your agents, screens or recordings, your scope is limited and you can usually validate under a shorter questionnaire. For what Level 1 means and how to check a provider, see PCI compliance for service providers.
Can agents still talk to customers during payment capture? Yes. The voice channel stays open during capture. The agent can guide the customer ("please enter your card number now") while the digits go straight to the payment environment and never reach the agent, the screen or the recording. The conversation continues naturally.
How long does implementation take? It depends on the path. Payment links are the quickest because they need no telephony work. Voice capture involves building your own agent-side interface against the provider's capture, IVR, and APIs, and integrating a given contact centre platform may require technical work on your side or from an implementation partner. Treat fixed "go live in X" promises with caution and ask for a scoped estimate for your stack.
What if a customer doesn't have a phone with a keypad? Send an SMS payment link during the call. The customer completes payment on their device — supporting cards, digital wallets (Apple Pay, Google Pay), and bank transfers — while the conversation continues.
How do debt collection agencies handle secure payments? Debt collection has specific requirements, multiple creditor PSPs, payment plans, and strict regulatory oversight. See our dedicated guide: Secure Payment Collection for Debt Agencies.
Related Reading
PCI Compliant Phone Payments: How to Take Card Payments Over the Phone: the US-focused guide to compliant phone payment patterns
Take Payments on Behalf of Your Clients: for outsourcers and servicers routing payments to each client's own merchant account
Payment Solutions for Medical Billing Companies and RCM Firms: phone-heavy patient collections routed to each practice's own merchant account
Payment Collection for BPOs: Multiple Clients, Multiple PSPs, Limited PCI Scope: the multi-client payment problem for outsourcers
Why Most Call Answering Services Can't Take Payments: the gap in the call answering market
Secure Payment Collection for Debt Agencies: PCI-compliant payment collection for the collections vertical
How AI Voice Agents Take PCI-Compliant Payments: the technical architecture for AI agent payment capture
Embedded Payments for CCaaS: if you're a CCaaS platform operator embedding payments for your customers
Enterprise PSP Mandates: why enterprise clients demand their own PSP
Payments for Insurance Core Platforms: embedded payment execution for insurance
What Are Voice Payments?: the complete guide to voice payment channels
AI Voice Payments for Hotels & Travel: voice payment architecture for hotel chains and OTAs
Payment Links for Hotels & Holiday Accommodation: SMS payment links for hotel deposits, no-shows, and upsells
Prommt Alternatives for Platforms: comparing payment link providers for multi-merchant use cases
Twilio Pay Connectors: How to Connect Any Payment Gateway to Twilio: connecting Twilio to any PSP for contact centre payments
Twilio PCI Compliance: PCI scope and compliance for Twilio-based payment capture
How to Connect Stripe to Twilio: Stripe + Twilio voice payment integration
Twilio Pay: Connect Any Payment Gateway to Twilio: install the Shuttle Pay Connector and connect 30+ gateways
Get Started
Shuttle adds PCI DSS Level 1 certified card capture and payment links to contact centres, on Twilio Pay for voice today, with routing to 30+ payment gateways from one integration. Payment links need no telephony work; voice capture involves a small integration on your side.
If you take payments in a contact centre, see how Shuttle works for merchants, check current pricing, or book a discovery call to walk through your specific platform and deployment.