Take card payments over the phone without the PCI nightmare
Taking card payments over the phone — also called MOTO (Mail Order Telephone Order) payments — means accepting a card transaction where the customer reads or keys their details across a phone call. In the UK it's legal, common, and standard for any business with a phone-based sales or service channel. The compliance challenge is that the moment a card number reaches your agent's ear, your call recording, or your CRM, you're in full PCI DSS scope (SAQ D, 329 controls). Paytia routes the card capture through our PCI DSS Level 1 infrastructure so the number never reaches your agents or your systems — same call, same customer, none of the scope. Works with your existing phone system and merchant account.
All three work with us. One is probably right for you.
Agent-assisted — agent stays on the call
IVR — automated, no agent needed
Outbound — you dial the customer to collect
On this page
TL;DR
In 2026, the safe way to take card payments over the phone is to keep the digits off your agent, your call recording, and your CRM. Customer presses the card on their own keypad, DTMF masking intercepts the tones, the payment processor gets the number, and your PCI scope drops from SAQ D (329 controls) to SAQ A (22 controls). Paytia plugs into the phone system and acquirer you already have — UK deployments live in 4–8 weeks.
Last updated: 29 May 2026
How to take card payments over the phone in 2026
We've been building phone payment systems since 2016, and the call that starts a project hasn't really changed.
A customer couldn't finish the checkout on the website and rang in. An enquiry call turned into a sale and the customer wants to pay before they hang up. A renewal's due. A tradesperson's standing in a kitchen and the homeowner wants to settle the deposit there and then. A donor wants to pledge on the spot.
It's routine business — and the moment the card number leaves the customer's mouth and lands in your agent's ear, you've changed your compliance position without anyone in the room realising.
Most UK contact centres got the first decision wrong. They picked a payment method based on what was easiest for the agent on day one, not what was cheapest for the business in year three. The card number reaches the agent. The agent types it into a virtual terminal. The call recording catches the digits. The CRM holds a note. None of it's malicious — it's just what happens when nobody pushed back on the obvious-looking flow. Two or three audits later, the compliance bill arrives and the architecture doesn't bend cheaply.
The compliance gap nobody talks about until they're sat with an assessor: every place card data touches is in scope. Headset, telephony, recording, screen, CRM field, the sticky note next to the keyboard. PCI DSS doesn't care whether you stored the number deliberately. It cares whether the number was capable of reaching that surface. If it was, you're defending it.
The fix isn't to stop taking phone payments. It's to stop the card data reaching you. That's the whole point of DTMF masking: intercept the keypad tones in real time, send the digits straight to the payment processor, and leave your agent on the call talking to a customer who can hear them perfectly. If you're weighing this up, the rest of this page is the playbook we run every time a UK business asks us how to do this properly.
Three flows handle nearly every phone payment a UK business runs. They're all PCI-friendly, they all keep card data out of your environment, and they suit different kinds of calls. Most contact centres we deploy for end up using two of them in combination — one for the conversational calls, one for the high-volume routine ones.
Agent-assisted with DTMF masking
The customer stays on the call with your agent the whole way through. When it's time to pay, the agent triggers the secure payment step from inside their normal interface — a button in the CRM, an extension on the soft-phone, whichever you've wired in. The customer enters their card number, expiry, and CVV on their own keypad. The DTMF tones get intercepted before they reach the agent's headset or the recording. Your agent hears a flat replacement tone that says "customer is typing" without carrying any digit information. The card goes straight to the processor. The agent confirms the result on the same call, gives the customer a reference, and wraps up. Best for sales calls, collections, support, anything where the conversation either side of the payment is the value. We cover the mechanics in depth on the agent-assisted payments page.
IVR self-service
No agent on the call at all. The customer dials a number — usually one published on their bill or invoice — and walks through a voice menu. They enter an account or reference, then their card. Authorisation comes back, the IVR reads them a confirmation, the call ends. It's the right answer for utility bills, council tax, parking penalties, subscription top-ups, any high-volume routine payment where the customer doesn't need to talk to anyone. The cost per call drops, your contact centre stops fielding calls that didn't need a person, and customers who'd rather pay at 11pm on a Sunday actually can. The downside is the obvious one: it doesn't suit complex orders, exceptions, or situations where the customer wants reassurance. Detail on IVR payments.
Pause-and-resume — the one we don't recommend
Worth covering because it's still the most common method in UK contact centres that haven't modernised yet. The agent manually pauses the call recording before the customer reads their card number, then resumes it after. It addresses one risk — the recording — and leaves every other one in place. The agent still hears the digits. The CRM field still receives them. The screen recorder still captures them. The agent's workstation, the network it's on, and the building it sits in are all still in scope. And the pause-and-resume itself is fragile: agents forget, pause late, resume early, or run a script that masks the audio but lets the digits through to the recording metadata. Assessors are increasingly sceptical of pause-and-resume as a primary control. If you're using it as a backup alongside DTMF masking, drop the backup — running both keeps your whole recording infrastructure in scope and undoes the descope you just paid for.
If you want a side-by-side breakdown of how the agent flow compares to the fully-bypassed approach, our DTMF masking page goes into the technical detail. For a step-up in regulated industries — financial services, larger insurance operations — we also run a channel-separationvariant that disconnects the agent's audio entirely during card entry, useful when the highest security standard is required.
Methods compared, at a glance
The same call can be run four different ways. Three of them keep card data out of your environment. One of them — pause-and-resume — only looks like it does.
Which one fits depends on the call, not the technology. A high-value sales call where the agent has spent twenty minutes building rapport with the customer is the wrong place to drop into an IVR — the customer paused mid-purchase will half the time abandon. A routine monthly invoice payment from a customer who already knows the drill is the wrong place to tie up an agent — the customer doesn't want to wait on hold for one to be free. Channel separation suits the kind of regulated environment where the security policy explicitly forbids any chance of an agent overhearing a digit, even masked, even briefly. Pause-and-resume is the one that suits nothing in 2026, and we'll explain why in a second.
Nothing, anymore — assessors are sceptical and the savings vanish
SAQ A = 22 controls. SAQ D = 329. Independent assessors confirm the categorisation — Paytia provides the signed Attestation of Compliance your QSA needs.
Most UK contact centres we deploy for end up using two of the green-row methods together — DTMF masking on conversational calls, IVR on the routine high-volume ones. The full side-by-side is in our DTMF masking vs channel separation comparison, and the pause-and-resume teardown is at DTMF masking vs pause-and-resume.
The compliance gap nobody costs in until they're audited
Every system that can hear, see, store, or touch a card number is part of your cardholder data environment. That's the rule PCI DSS is built on, and it's the rule most UK contact centres get caught out by.
The card scheme doesn't care whether you stored the number on purpose — it cares whether your architecture made it possible. An agent who hears a CVV puts that agent's desktop in scope. The desktop puts the network segment in scope. The network puts the firewall, the patching policy, the AV deployment, the change-control regime in scope. By the time you've traced it through, the cardholder data environment is most of your office.
That's the difference between SAQ A and SAQ D. SAQ D — 329 controls, annual QSA-led assessment for anything past a small volume threshold, mandatory PCI training, documented evidence for every touchpoint, quarterly scans, penetration testing — is what you land on when card data reaches your agents. SAQ A — 22 controls, focused on the contractual relationship with a certified provider, signed off by your finance director in an afternoon — is what you land on when it doesn't. The mechanics aren't complicated. They're just unforgiving.
The audit-cost impact lands in three places. The QSA fees themselves: a typical UK SAQ D audit for a 30-seat contact centre runs £15,000–£30,000 a year once you account for the assessor's time, ASV scans, penetration testing, and the staff hours pulled into evidence-gathering. The infrastructure controls: hardened agent builds, segregated network zones, locked-down screen recording, retention policies on call archives, the lot. And the staff overhead: annual training, attestation records, role-based access reviews. Moving to a certified provider for the capture step typically cuts the compliance-related spend by 60–75% in the first year, with bigger swings in years two and three as you stop maintaining controls you no longer need.
DTMF masking plus tokenisation is what bridges the gap. Tones get intercepted before they reach your environment. The card never lands in any system you own. The processor returns a token your CRM stores in place of the number, which means refunds, recurring payments, and saved-card flows all work without you holding card data. The token is useless to anyone who steals it. The audit you complete the following year is a fundamentally different document.
We've written the longer compliance read at PCI compliance for telephone payments if you want the requirement-by-requirement walk through the framework. The summary version is here.
Hidden risks when you take card payments over the phone the obvious way
The audit is the visible cost. The hidden costs are the ones that show up when something goes wrong, and they're usually worse than the compliance bill.
We see the same four patterns play out in unsecured phone payment setups, and every one of them is harder to manage once it's in motion.
Agent-side fraud is the first. Most agents will never misuse a card number they overheard. But "most" isn't "all," and insider fraud in contact centres is a documented problem that the ICO and acquirers report on every year. An agent under financial pressure who's already taking three hundred card numbers a week has the means and the cover. They don't need to be sophisticated — a card number written on the back of a printed call list and walked out at the end of a shift is a breach, and you'll find out about it from the chargebacks six weeks later. Even when nothing happens, the reputational risk lives in the architecture: a customer whose card's misused after a call with you has every reason to blame you, regardless of where the data actually leaked.
Call-recording compromise is the second. Most UK contact centres record calls for quality, dispute resolution, and regulator-required evidence — and most of them retain those recordings for months. If the recording captures a customer reading a card number, every minute of stored audio becomes a protected asset. A misconfigured cloud bucket, a leaked S3 key, a forgotten admin account on the recording platform: any of those turn into a notifiable breach. Recordings don't expire when you forget about them, which is why a contact centre that did this for two years before tightening up is still defending the historic archive.
Documentation-side leakage is the one that catches everyone out. Sticky notes, paper order pads, the back of a printed delivery sheet, a CRM custom field somebody added for "notes," a Slack message between two agents trying to confirm a dropped digit. Every workaround for a fragile process creates a paper trail nobody planned, and paper PANs are the easiest possible PCI violation to find. The QSA walks into the office and asks the new starter how she handles a card number — the answer is usually honest and usually disqualifying.
Chargeback exposure is the fourth, and it's structural rather than situational. Card-not-present transactions carry full chargeback liability on the merchant. There's no PIN to wave at the issuer, no signature to compare, no card-present indicator. Phone payment dispute rates run measurably higher than card-present, and the issuer almost always sides with the customer unless you can produce 3DS2 authentication evidence or a clear audit trail. Take a payment where the agent typed the number in, and you've got neither.
Every workaround we've seen — pause-and-resume, post-call redaction, "secure rooms," headset muting, dedicated payment-only seats — solves one risk and leaves the others standing. The honest answer is to remove the card data from the path entirely, which makes the other four problems go away at the same time.
A few real scenarios contact centres deal with, so the abstract risks land properly. The first: a small UK insurance broker, twelve agents, taking renewal payments over the phone with pause-and-resume. An agent forgets to pause once during a Friday afternoon shift. The recording captures the full PAN and CVV. Nobody notices until six months later when the recording archive gets reviewed for a complaint and the QA team spots the digits. That single recording is now in scope. The retention policy says recordings are kept for two years. The broker now has eighteen months of unreviewed audio to either audit line-by-line or treat as cardholder data by default. The cost of either path runs to five figures.
The second: a mid-sized utility's contact centre runs a virtual-terminal flow where agents type the customer's card number into a browser form. A new starter on her third day asks her team leader if it's OK to write the number on a Post-it when the system's slow. The team leader says no, of course. She does it anyway when she gets a card-on-card decline and needs to retry. Her supervisor finds the Post-it under her keyboard at the end of the shift. That moment becomes a notifiable incident, a conversation with the acquirer, an explanation to the QSA at the next audit, and a re-training programme for every agent on the floor.
The third: a B2B software business takes annual renewal payments by phone. Their CRM has a free-text "notes" field on the customer record that agents use for everything from delivery instructions to follow-up reminders. One agent uses it to paste a card number while waiting for the virtual terminal to load, intending to delete the note after the payment goes through. He gets distracted, doesn't delete it. Three months later the customer's record gets exported as part of a normal data subject access request. The PAN goes out in the export. The data protection officer finds out the day after the customer's lawyer does.
The fourth: a contact centre invests in pause-and-resume because their pen-and-paper system was clearly worse. Two years later they fail their QSA assessment because the assessor pulls a random sample of fifty recordings and finds digits in three of them — pauses kicked in half a second late, scripts not always followed, one agent who'd been off the day of refresher training. The assessment gets downgraded to SAQ D. The recording archive falls back into scope. The compliance bill for the year jumps by £40,000. The technology that was supposed to be cheaper than doing it properly cost more in remediation than the proper fix would have.
None of these scenarios involve sophistication or malice. They involve normal humans doing normal work under normal pressure. The architecture is what fails. The fix isn't better training or stricter monitoring — it's removing the digits from the path so the only possible behaviour is the compliant one.
What it costs to take card payments over the phone
Two costs to think about, and they pull in different directions.
The first is your acquirer's transaction fee. MOTO transactions — what the card schemes call your phone payments — carry interchange roughly 0.1–0.3% higher than card-present, because card-not-present fraud risk is higher. Your acquirer (Barclaycard, Worldpay, Tyl by NatWest, Elavon, whoever) sets this, not us. Some businesses pass it on through card surcharging where local rules allow; most absorb it as a cost of taking phone orders at all.
The second is what you pay for the masking technology itself. Two common models, and which one suits you depends on your call shape. Per-transaction pricing charges a small amount per masked payment — scales linearly with volume, painful in a big sales month, watch the minimum monthly commitment. Per-seat pricing charges for each named user authorised to take payments — predictable, easy to budget, gets expensive fast if you have 300 agents but only 50 of them take cards regularly.
Things to watch for in the proposal: setup fees that don't include integration, pass-through telephony surcharges, "card brand fees" with margin added on top, recording-storage charges if you keep archives long-term. None of these are unreasonable on their own; together they're often the difference between the headline price and the year-one total. Get a vendor to model your real annual volume before you sign — we'll do this in the second demo call if you ask. The longer walk-through is at how to choose DTMF masking software.
The honest comparison isn't "Paytia versus running it yourself." It's the masking cost against the cost of staying in full PCI DSS SAQ D scope. A typical UK SAQ D audit for a 30-seat contact centre runs £15,000–£30,000 a year once you count the QSA assessor, ASV scans, penetration testing, and the staff hours pulled into evidence-gathering. Add the infrastructure controls — hardened agent builds, segregated network zones, locked-down recording — and the annual staff overhead — training, attestation, role-based access reviews — and the all-in compliance bill for doing it yourself is usually £40,000–£80,000 a year for a mid-sized operation.
Moving to a certified provider for the capture step typically cuts compliance-related spend by 60–75% in the first year, with bigger swings in years two and three as you stop maintaining controls you no longer need. The full breakdown is at how much does PCI compliance cost. We'll quote you a real number against your real call volume — book a 20-minute calland we'll model it.
What good looks like — operationally
A modern phone payment deployment isn't a rebuild — it's a small bit of plumbing on top of what you already have.
The telephony stays the same. The CRM stays the same. The acquirer relationship stays the same. What changes is where the card capture happens inside that stack, and it's a change measured in days rather than months.
The typical timeline runs 4–8 weeks from signed contract to full rollout for a standard UK contact centre, and most of that is waiting on internal scheduling rather than technical work. Week one is a scoping call where we map your telephony platform, your gateway, your CRM, and the calls you're actually trying to handle. Week two covers the commercial paperwork, the data processing agreement, and the PCI attestation exchange — you get our signed Attestation of Compliance, your legal team signs the DPA. Weeks three to four are the technical integration: provisioning the masking layer, wiring it into your telephony, hooking the webhooks into your CRM. Week five is a pilot — a small group of agents takes real low-value payments, QA reviews a sample of calls, anything odd gets fixed. Weeks six onwards are the rollout: a twenty-minute agent training session covering the new payment button and the edge cases, then everyone's on the new flow.
The agent's interface barely changes. Where they used to type card digits into a virtual terminal field, there's now a button — usually in the CRM, sometimes in the soft-phone, occasionally in a dedicated browser tab — that triggers the secure payment step. The agent sees a live progress display: digits entered (not the digits themselves), expiry captured, CVV captured, authorisation result. They can talk to the customer through it, answer questions, retry a decline. The only operational habit they need to break is the one where they ask the customer to read the card number aloud as a fallback, because that habit puts everything back in scope.
The customer experience is the part we measure when we're selling a deployment internally. Customers enter their own card on their own keypad, which is the same gesture they make at a chip-and-PIN terminal every week. They don't read sixteen digits to a stranger. They don't worry about who's overhearing. Average call handling time drops because the pause-resume-confirm dance disappears — Warby Parker reported a 35% drop after they deployed us, Total Tiles saw daily order throughput jump from 25–30 to 45–50 once the payment step stopped being a bottleneck. Those are the published numbers from their case studies, not aspirational targets.
Once you're live, the system runs itself. Your compliance lead reviews the integration evidence annually, your agents keep taking calls, and the masking layer handles the security and the gateway plumbing in the background. The biggest ongoing activity is usually watching the dashboard and occasionally tightening a script.
Week-by-week, who does what
The 4–8 week window above is the headline number. Inside it, the actual work breaks down like this — useful if you're planning the deployment internally and need to know who needs to be in which meeting.
Week one is discovery. Two calls of about an hour each, between our integration lead and your telephony owner (whoever runs your phone system day-to-day), your CRM owner, and your compliance or finance lead. We map your gateway, your acquirer relationship, the call types you're handling, and the systems the payment confirmation needs to land in. By the end of the week we know whether you need DTMF masking, IVR, or both, and your team has a one-page integration scope document to circulate internally.
Week two is paperwork. Your legal or DPO reviews our data processing agreement. Your finance team signs the order form. Your compliance lead receives our signed Attestation of Compliance and adds it to your PCI evidence pack. None of this is fast on the customer side because it goes through corporate sign-off queues, which is why it gets its own week. The integration work doesn't start until the paperwork closes.
Weeks three and four are the technical build. Day one: we provision your account on the masking platform, generate API credentials, and set up a test merchant against your acquirer's sandbox. Day two to three: your telephony engineer (or your telephony partner's implementation team) wires the masking layer into your phone system — SIP trunk configuration if you're on-prem, a connector install if you're on Aircall, Talkdesk, Zoom, 3CX, Genesys, Five9, NICE CXone, 8x8, RingCentral, or Amazon Connect. Day four to five: your CRM developer adds the payment button and wires up our webhooks so authorisation results land back in the right place. Days six to ten: full-path test calls with your sandbox acquirer, fixing whatever surfaces. By the end of week four, the integration is technically working — just not on live cards yet.
Week five is the pilot. A small group of agents — usually three to five people picked because they'll surface problems honestly — switches their next live phone payments to the new flow. We're both watching the dashboard in real time. Your QA team listens back to a sample of the calls and confirms the agent never hears the digits. Your compliance lead checks the audit log. Anything odd, we fix the same day. Most pilots run 50–100 real transactions before the team's confident enough to scale.
Weeks six to eight are the rollout. Your training lead runs a twenty-minute briefing for the rest of the agents covering the new payment button, the edge cases (declined card, customer mistypes a digit, customer wants to switch cards), and the new script wording for the moment of capture. Your supervisors do a buddy-shift with each agent on their first live payment under the new flow. By the end of week eight, every agent who takes payments is on the new system, and the old virtual terminal or pause-and-resume process is decommissioned.
For smaller operations — up to ten agents on a single cloud phone system — the whole thing collapses into 2–3 weeks because there's less telephony plumbing and less paperwork. For larger or more regulated operations the timeline stretches because of security reviews, penetration tests, and change-control windows on the customer side. Neither of those extremes is technically harder, just operationally bigger.
What to look for in a phone-payment provider
The market's noisy. Every gateway, every telephony vendor, every contact-centre platform claims it'll "handle" phone payments — and most of them mean "our agents type the digits into a screen." That's the architecture that puts you in SAQ D. The questions below cut through the marketing in about fifteen minutes.
Ask any provider you're evaluating: are you PCI DSS Level 1 certified, audited annually by a QSA, and will you give us a signed Attestation of Compliance our assessor can rely on? Will the card number ever reach our agent's headset, our call recording, our desktop, our CRM, or our network? Which acquirers and gateways do you sit in front of — Stripe, Worldpay, Adyen, Barclaycard, Tyl, Elavon, Braintree, Ryft, Authorize.Net, Cybersource? Which telephony platforms have you got live deployments on — 3CX, Aircall, Talkdesk, Zoom Contact Centre, Genesys, Five9, NICE CXone, 8x8, RingCentral, Amazon Connect? Do you support agent-assisted, IVR, and outbound flows on the same contract, or do you charge extra per channel? What's the per-transaction or per-seat pricing, and what's in the "extras" column (setup, integration, card-brand fees, recording-storage surcharges)? Can we keep our existing call recording and retention policy unchanged?
If a provider can't give you a one-word answer to the first two questions, walk. The rest are negotiable. Those two aren't.
Pinnacle Group is one of the UK's largest housing management companies — 3,000 staff, 30,000 homes managed across 100+ locations. Their income team needed to take card payments over the phone for service-charge collections without putting their RingCentral telephony or their CRM into full SAQ D scope. They came to us in the "sit a virtual terminal next to the agent" world, with all the documentation overhead that brings.
We slotted Paytia in front of their existing acquirer and wired it into RingCentral. Agents kept the same desk, the same script, the same dispute-resolution workflow. Customers entered card digits on their own phone keypad — the agent stayed on the line throughout and never heard a single number. The result: a 95% reduction in PCI controls, dropping Pinnacle from SAQ D (329 controls, annual QSA assessment, hardened infrastructure) to SAQ A (22 controls, signed off by their finance director). The compliance bill collapsed. The customer experience improved. The agents stopped having to explain to callers why they were being asked to read sixteen digits aloud to a stranger.
Full write-up at how Pinnacle Group cut PCI scope by 95% with Paytia — including the call shape, the integration points, and what their compliance lead said about the next audit. Adjacent options worth a look: MOTO payments for the acquirer-side framing, and SMS payment links for the hybrid flow where you send the customer a link mid-call instead of capturing digits live.
Common mistakes to avoid
We've been deploying phone payment systems for UK contact centres since 2016. The same five anti-patterns come up over and over — sometimes from contact centres we're replacing a previous solution at, sometimes from prospects who've been told one of these will do the job. They won't.
Relying on pause-and-resume as the primary control
Pause-and-resume addresses one of the four risks — the recording — and only addresses it when the agent remembers to press the button at the right moment. The agent still hears the digits. The CRM still receives them. The screen recorder still captures them. The desktop, the network, and the building are all still in scope. Assessors have been increasingly sceptical of pause-and-resume as a standalone control for years, and the move to PCI DSS v4 has hardened that position. If you're running pause-and-resume because your previous compliance assessment let you, plan for the next one to question it.
Sticky-note workarounds when the system's slow
Any process where the agent has to hold the card number in working memory while a system loads creates the pressure to write it down. Sticky notes, scratch pads, the back of a printed call list, a Notes window on the desktop. None of these are policy — every one of them is what an agent does when the alternative is asking the customer to read the digits again. The fix isn't a stricter no-paper policy. It's a flow where the agent never holds a digit in the first place.
Agent-typed digits into a virtual terminal
A web-based virtual terminal feels safer than a paper system because the data goes straight to the gateway. It isn't. The agent still hears the customer read the number out loud, which puts the agent's headset and workstation in scope. The browser session sits inside the cardholder data environment. The screen recorder catches the digits as they're typed. The customer's also paying in the worst possible way for chargeback defence — no 3DS2, no audit trail beyond "an agent typed it in." If you're currently using a gateway-provided virtual terminal as your main phone payment method, you're in SAQ D regardless of how the gateway markets it.
Paper order pads "we'll process later"
Field service businesses, trade callouts, telephone-order retailers. The pattern is the same: the agent or the engineer writes the order on a paper pad, including the card number, and somebody processes the batch at the end of the day or week. Every pad is a portable cardholder data store. Every locked drawer holding pads is in scope. Every van with an order book is a mobile breach in waiting. The right answer is to take the payment at the point of contact via a secure phone payment, an SMS payment link, or an in-person tap if the engineer's on site.
After-the-fact redaction of recordings
Some contact centres take the digits live and rely on automated redaction software to bleep the PAN and CVV out of the recording before it's stored. Two problems. First, the redaction is best-effort — if the customer says "four-five-eight-three" instead of typing it, the software may catch it or may not, and any miss is a stored PAN. Second, even when redaction works on the recording, it does nothing about the agent's ear, the screen, the CRM, or the desktop. Redaction is a recording-only control bolted onto an SAQ-D-scope architecture. Doesn't change the scope.
The pattern across all five: each one tries to fix one symptom while leaving the underlying architecture — card data reaching your environment — in place. Anything short of stopping the digits at the customer's phone is patching, not solving.
The UK regulatory frame, in one paragraph
PCI DSS is the headline rule, but it isn't the only one. UK GDPR treats card numbers as personal data, which brings in lawful basis, data minimisation, and 72-hour breach notification to the ICO.
FCA-authorised firms also have to fit phone payment handling into their consumer duty and operational resilience obligations. PSD2 strong customer authentication applies where the customer is paying online or via an app, and the 3DS2 flow is the practical implementation most acquirers expect.
How do I take card payments over the phone safely?
Stop the card number reaching your agent, your call recording, and your CRM. The customer keys their digits on their own phone keypad. DTMF masking intercepts the tones in real time and sends them straight to the payment processor — your agent stays on the call, hears a flat replacement tone during entry, and gets a pass/fail result the moment the transaction settles. That's it. No agent ever hears or sees the digits. The recording, the desktop, and the CRM all stay out of PCI scope because the cardholder data never touched them.
Is taking card payments over the phone PCI compliant?
It is when you do it through a PCI DSS Level 1 certified provider that keeps card data out of your environment entirely. Paytia is Level 1 certified — the highest tier, audited annually by a QSA. We hand you a signed Attestation of Compliance you give to your assessor, and your scope drops from SAQ D (329 controls) to SAQ A (22 controls). What's not compliant in 2026: typing the number into a virtual terminal, writing it down, pause-and-resume as the only control, or trusting after-the-fact redaction on call recordings. Assessors increasingly reject those as standalone controls under PCI DSS v4.
Can my agents hear card numbers when we take phone payments?
No — that's the whole point. With DTMF masking, the customer presses digits on their handset, the masking layer intercepts the tones before they cross the audio bridge to your agent, and your agent hears a flat replacement tone that carries no digit information. The customer hears the agent throughout. Reverse direction works too — the agent's voice keeps flowing, just without picking up the keypad tones. If the architecture lets even one agent hear a single CVV, every desktop, headset, and screen recorder in the building goes into PCI DSS scope. That's the line that has to hold.
Do I need special equipment to take phone payments?
No. Our platform works with traditional PBX, SIP trunks, cloud phone systems (3CX, Aircall, Talkdesk, Zoom Contact Centre, Genesys, Five9, NICE CXone, 8x8, RingCentral, Amazon Connect), and plain office handsets. We integrate at the API or SIP layer. There's no new hardware on the agent's desk, no replacement headsets, no separate payment phone. Most deployments go live within 4–8 weeks on small setups — the telephony side barely changes because we drop into what you already own. Your acquirer relationship and your CRM both stay where they are.
What's the difference between MOTO and taking card payments by phone?
Same thing, different audience. MOTO (Mail Order / Telephone Order) is the card-scheme term for any card-not-present transaction taken without an online checkout — the customer reads or keys their details to a merchant who keys them into a terminal. "Taking card payments over the phone" is what businesses actually call it. Your acquirer prices, settles, and reports the transaction as MOTO. Same chargeback liability, same PCI scope considerations, same interchange band — different vocabulary. We've a full breakdown on our MOTO payments page.
How fast can I start taking payments over the phone?
Most UK contact centres go live in 4–8 weeks from signed contract. Smaller setups on a single cloud phone system (up to ~10 agents) can be live in 2–3 weeks. The technical work itself is usually 5–10 days — most of the calendar time is spent on data processing agreements, security reviews, and pilot testing, not wiring. We've written the week-by-week breakdown further down this page. If you need to move faster than that for a genuine deadline, talk to us — we've done compressed deployments and we'll tell you honestly whether yours fits.
What gateways work with Paytia phone payments?
All the ones a UK business is likely to be on. Stripe, Worldpay, Adyen, Braintree, Barclaycard, Tyl by NatWest, Ryft, Elavon, Authorize.Net, Cybersource. Plus every major UK acquirer (Barclaycard, Worldpay, Tyl, Elavon and others). You keep your existing gateway and acquirer relationship — Paytia sits in front as the PCI-compliant capture layer, tokenises the card, and hands a token your CRM stores in place of the PAN. Refunds, recurring billing, and saved-card flows all work against the token. Switching gateways later doesn't require switching us.
Is there a per-call cost when I take payments over the phone?
Two pricing shapes, and which one suits you depends on call volume. Per-transaction pricing charges a small amount per masked payment — scales linearly with volume, painful in a big sales month, watch for the minimum monthly commitment. Per-seat pricing charges for each named agent authorised to take payments — predictable, easy to budget, gets expensive fast if you have 300 agents but only 50 take cards regularly. We'll model both against your actual call shape in the demo. The honest comparison isn't "Paytia vs DIY" — it's masking cost vs the £40,000–£80,000/year all-in cost of staying in SAQ D scope for a 30-seat operation.
Do call recordings count as storing card data?
Yes. If your recording captures a customer reading their card number, that recording is now a PCI-scope asset — encrypted storage, access controls, retention limits, audit logs. Redacting it after the fact is best-effort and assessors are increasingly sceptical of it as a sole control. The cleaner answer is to stop card data reaching the recording in the first place, which is what DTMF masking does. The agent's voice, the customer's voice, and everything before and after the payment record normally. The only thing missing is the digits, and that's the point. You keep your QA process, your dispute evidence, and your regulatory archive — none of it changes.
Do I need PSD2 / SCA on phone payments?
Phone-keyed MOTO transactions are out of scope for PSD2 strong customer authentication when the customer enters digits on their own keypad during a voice call — the regulation specifically carves out telephone orders. Where it gets nuanced: if you're using a hybrid flow where the customer pays via an SMS payment link you send during the call, that's online and SCA applies. 3DS2 is the practical implementation, and most modern gateways handle it automatically. Worth checking with your acquirer for your specific transaction mix — we'll help you map it during the scoping call.
What if a customer disputes a phone payment?
Card-not-present transactions carry full chargeback liability on you — there's no PIN or signature to show the issuer the customer authorised it. Phone-payment dispute rates run measurably higher than card-present. You can mitigate with 3DS2 where the customer can authenticate via their banking app, fraud screening, and clear call scripts that confirm the amount and reference verbally. Our platform layers these in so you're not flying blind. The audit trail you keep — masked PAN, timestamp, agent ID, call reference — gives you the strongest defence the issuer will accept.
Does this work for outbound calls as well as inbound?
Yes. The DTMF masking layer doesn't care about call direction — it works on the audio path either way. Collections calls, renewal calls, proactive sales calls all use the same flow. Outbound has its own compliance considerations (consent, recording disclosure, regulatory restrictions on call timing) but the payment-capture step is identical. Quite a few of our collections-focused customers run outbound exclusively. Detail on our outbound payments page.
More on taking payments over the phone
Everything across the site that goes deeper on a specific piece of this — methods, compliance, integration, industries. Read the bits relevant to where you are.
“The common capture service means our customers get the same secure payment experience whether our agent is in the office or working from home. Complete location transparency with total security.”
Used by British American Tobacco · Howard Kennedy · CITB · Clinical Partners · Trinity Hall College
Since 2016
Building secure payments
PCI DSS Level 1
Highest certification
99.99%
Platform uptime
£400M+
Transactions processed
Phone payments, without the scope and without the faff
Tell us what your calls look like and we'll show you the simplest way to take the payment without the card number reaching you. Most UK customers go live within a few weeks on the phone system they already own — same acquirer, same CRM, smaller PCI footprint.
