All three work with us. One is probably right for you.
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.
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.
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.
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 maskingpage goes into the technical detail. For a step-up in regulated industries — financial services, larger insurance operations — we also run a channel-separation variant that disconnects the agent's audio entirely during card entry, useful when the highest security standard is required.
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.
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 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.
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. We've written the longer regulatory walk-through in UK regulations for taking card payments by phone, and the GDPR-specific read in how to comply with GDPR for phone payments. Worth reading before you sign anything.
Yes. It's legal, it's common, and most UK businesses need to do it at some point. The card schemes call it MOTO (Mail Order / Telephone Order) and your acquirer — Barclaycard, Worldpay, Tyl by NatWest, Elavon, or others — can enable it on your merchant account, usually as a separate MID or as a tick-box on an existing one. What's changed in recent years is how you can do it without landing in full PCI DSS scope. The short answer is: don't let the card number reach your agents, your recording, or your systems in the first place.
Writing a card number on paper isn't illegal, but it puts you in breach of PCI DSS — the card schemes' security standard you agreed to when you signed up with your acquirer. A breach can mean fines, elevated fees, or termination of your merchant account. More practically, any paper with a card number on it immediately becomes a PCI-scope asset: it needs to be locked, tracked, shredded, and documented. The cost of doing it properly usually outweighs the cost of not writing it down at all. Use a compliant capture method and skip the paperwork.
Yes. If your call recording captures a customer reading their card number out loud, that recording is now in PCI scope. You have to treat it the same as any other place card data lives — encrypted, access-controlled, retention-limited, evidence-logged. Redacting it after the fact isn't straightforward and isn't always accepted by auditors. The cleaner answer is to stop card data reaching the recording in the first place, which is what DTMF masking does.
An agent-assisted phone payment keeps a human on the call while the customer keys their card. Useful when the call needs a conversation — sales, collections, support, complex orders. An IVR payment is fully automated: the customer calls a number, a recorded voice walks them through, no agent involved. Useful for high-volume routine payments where the customer just wants to pay a bill and move on. Most businesses end up using both: IVR for simple recurring payments, agent-assisted for anything that needs a person.
Two costs. The first is your acquirer's transaction fee — MOTO interchange is roughly 0.1–0.3% higher than card-present because card-not-present fraud risk is higher. Your acquirer sets this, not us. Some businesses pass that cost to the customer through card surcharging where local rules allow it; others absorb it. The second is the technology for keeping you compliant — which is where we come in. We charge per transaction or per seat depending on volume. Both together are almost always cheaper than running your own PCI DSS SAQ D compliance programme, which is where you land if you take the card number directly.
Card-not-present transactions carry full chargeback liability on you — there's no signature or PIN to show the issuer the customer authorised it. Dispute rates tend to be higher on phone payments than in-person. 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. Our platform layers these in so you're not flying blind.
No. Our platform works with traditional PBX, SIP trunks, cloud phone systems (3CX, Genesys, Five9, Amazon Connect, NICE CXone, 8x8, RingCentral, Talkdesk), and plain office handsets. We integrate at the API or SIP layer. Most deployments go live within a week — the telephony side barely changes, because we drop into what you already have.
“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.”
Insure and Go
Read the case study →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
£40M+
Transactions processed
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.
Trusted by law firms, insurers, healthcare providers and regulated businesses worldwide. Learn more about Paytia
Other ways to take payments in this channel.
Also called DTMF suppression. The customer types their card on their phone keypad. We mask the tones in the live audio so the agent doesn't hear them and the recording stays clean.
Learn moreTake Mail Order / Telephone Order payments without the card number reaching your agents, your recording, or your systems.
Learn moreYour agent stays on the live call while the customer keys their card. We mask the tones so no card data reaches the recording or the agent's audio.
Learn more