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
UK businesses can take card payments over the phone legally and routinely — the trick is keeping the card number out of the agent's ear, the call recording, and the CRM, which drops you from PCI DSS SAQ D (329 controls) to SAQ A (22 controls). Paytia's PCI DSS Level 1 platform plugs into the phone system and acquirer you already have, with most UK deployments live in 4–8 weeks. This page covers the three call flows that work, what they cost, the hidden risks, and how to choose between them.
Taking card payments over the phone, honestly
Last updated: 27 May 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.
The hidden risks of doing it 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 actually costs
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.
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.
Can I take card payments over the phone in the UK?
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.
Is it legal for me to write down a customer's card number?
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.
Do call recordings count as storing card data?
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.
What's the difference between agent-assisted and IVR phone payments?
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.
How much does it cost to take card payments over the phone?
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.
What happens if a customer disputes a phone payment?
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.
Do I need a special phone system?
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. Most deployments go live within a week on small setups — the telephony side barely changes, because we drop into what you already have.
Can I keep my call recording?
Yes, and most customers do. DTMF masking suppresses the card-entry tones before they reach the recording, so the rest of the call — agent's voice, customer's voice, everything before and after the payment — records normally. You keep your QA process, your dispute evidence, your regulatory archive. The only thing missing from the recording is the digits, and that's the whole point. You don't need to change your recording platform, your retention policy, or your access controls.
How long do typical deployments take?
Most UK contact centres go live in 4–8 weeks from signed contract. Smaller operations on a single cloud phone system can be live in 2–3 weeks. The technical work itself is usually 5–10 days inside that window — most of the time is spent on internal sign-off cycles, data processing agreements, security reviews, and pilot testing rather than wiring things up. We've written the day-by-day breakdown above. 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 if my acquirer doesn't support MOTO?
Every UK acquirer of any size supports MOTO transactions — Barclaycard, Worldpay, Tyl by NatWest, Elavon, and others — though it usually needs to be enabled on your merchant account separately from card-present. If you've only ever taken in-person payments, you'll need to ask your acquirer to add MOTO to your existing MID or set up a new one. The conversation usually takes a week or two and might involve a slightly higher interchange rate because card-not-present carries more fraud risk. We work with all the major UK acquirers and the main gateways — Stripe, Worldpay, Adyen, Braintree, Barclaycard, Tyl by NatWest, Ryft, Elavon, Authorize.Net, Cybersource — so the integration on our side stays the same regardless of who you're with.
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 the 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 a 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.
Does this work for outbound calls?
Yes. The same DTMF masking layer handles outbound collections, renewals, and proactive sales calls — the call direction doesn't matter to the technology, it works on the audio path either way. Outbound has its own compliance considerations (consent, recording disclosure, regulatory restrictions on call timing) but the payment-capture piece is identical. We cover this in detail on our outbound payments page. Quite a few of our collections-focused customers run outbound exclusively.
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.
