MOTO Payments Secure card-not-present payments without the PCI scope

What a MOTO payment actually is

MOTO stands for Mail Order / Telephone Order. It's a card-not-presenttransaction where the customer gives you their card details over the phone, by email, or through a social-channel chat — neither the card nor the cardholder is anywhere near you. The term's a hangover from the catalogue-sales era, but the card schemes still use it and so do your acquirer, your processor, and your auditor.

It's different to in-person and online in a couple of ways that matter. There's no chip-and-PIN, no contactless tap, no signature — none of the friction that protects a card-present sale. And unlike online, there's no straightforward way to slot a 3DS2 step into the flow, because the customer is on a phone call rather than a checkout page. The card scheme sees the transaction as higher risk than either of the alternatives, prices it accordingly, and pushes the chargeback liability onto you.

Plenty of businesses still rely on it. Charities taking phone donations from older supporters. Housing associations collecting rent. B2B trade desks closing wholesale orders. Insurance and pensions renewals. Mail-order pharmacies. Medical billing. Solicitors and accountants invoicing by phone. Any business with a customer base that prefers a phone call to a website checkout — which, in 2026, is still most of them — runs a MOTO channel whether they call it that or not.

We've been building PCI-compliant phone payment systems since 2016 and MOTO is the workflow we know best. The rest of this page covers what makes it the riskiest card channel you can run, what compliance actually demands, and how to handle the call so your agent stays on the line and the card data doesn't reach your systems. If you'd rather skip to a demo, we'll show you the flow on a real call.

What PCI DSS, SCA, and GDPR actually require for MOTO

Every MOTO transaction is in PCI DSS scope. There's no minimum-volume carve-out, no exemption for low-risk merchants, no allowance for "we only do a handful of phone payments." If you take card details by phone, the standard applies to you, and which Self-Assessment Questionnaire you have to complete depends entirely on how the card data is handled.

If your agents key the card number themselves into a virtual terminal — the traditional MOTO setup — you're on SAQ D. Around 329 controls, annual evidence, the heaviest reporting tier short of a full Report on Compliance. Your agent workstation, your call recordings, your CRM, your network, and any paper forms all sit inside the cardholder data environment, and every one of those becomes something you have to document and audit. If you route the capture through a PCI-certified provider so card data never reaches you — DTMF masking, channel separation, agent-assisted — you drop to SAQ A, which is around 22 controls. PCI DSS v4.0.1 sharpened the language on this further: any system component that can affect the security of cardholder data is in scope, so a recording system that captures DTMF tones counts even if it never stores the digits as text.

Strong Customer Authentication under PSD2 is the rule for online card payments in the UK and EU — two factors, every time, with a handful of exemptions. MOTO is one of the exemptions, but it's not a free pass. Acquirers expect you to flag the transaction with the correct MOTO indicator when you submit it, run additional fraud screening to compensate for the missing authentication step, and keep your PSD2documentation up to date. The exemption exists because there's no realistic way to make a customer scan a fingerprint or approve a push notification while they're mid-call. It doesn't exist because MOTO is low risk; it exists because the protocol won't fit.

Where 3DS2can be brought in — typically when the customer has a mobile to hand during the call and can approve a step-up on their banking app — using it gives you the liability shift you'd otherwise be missing. We apply 3DS2 wherever it's available and fall back to fraud-screening rules where it isn't, so the transactions most likely to dispute later get extra scrutiny up front.

GDPRsits over the top of all of this. Card details are personal data, the lawful basis for processing is contract performance, and the principles of data minimisation and storage limitation apply directly to your call recordings. The cleanest answer is to not store card numbers in the first place — no card data in your environment means no retention question, no subject access request that includes a PAN, no breach-notification trigger when a backup tape goes missing. The second cleanest answer is to pause recordings during the payment portion of the call, which most contact-centre platforms support but many haven't configured.

How to take MOTO payments without absorbing the risk

The principle is simple: if the card number never reaches your environment, almost none of the risk reaches it either. Your agents can't leak data they never had, your recordings can't capture tones they never received, your CRM can't store digits nobody typed into it, and your auditor has 22 controls to check instead of 329. The whole modern MOTO stack is built around getting card capture out of the parts of your business where it doesn't belong.

On the phone leg, the right answer for almost every contact centre is DTMF masking. The customer types their card on their own phone keypad. Each tone is intercepted and replaced with a flat sound before it reaches your agent or your recording system. The agent stays on the call the whole time, talks the customer through it, and confirms the result when authorisation comes back. From the customer's side it feels like any normal phone payment. From your auditor's side, the audio has no card data in it.

Channel separation takes the same idea a step further on calls where the agent shouldn't be in the room with the digits at all. The card capture happens on a separate audio path that bypasses the agent's line entirely. Useful for higher-value transactions, regulated industries, and anywhere the threat model includes the agent themselves. Agent-assisted sits between the two — the agent keeps the call going, the customer keys the card, and the agent sees only a masked progress indicator on screen.

For mail-order and email-order workflows, the answer is to stop accepting card details in writing at all. We send the customer a secure payment link by SMS or email; they tap through to a hosted payment page in our PCI environment, type the card themselves, and the confirmation lands back in your system as a token plus an authorisation code. The order form on your end never sees a card number. The same flow handles refunds, top-ups, and ad-hoc payment requests without you ever opening an email that contains a PAN.

Where the card goes once we've captured it depends on what you already have. We pass the authorisation request straight to your existing acquirer — Barclaycard, Worldpay, Tyl, Elavon, Adyen, whichever — so your pricing, your settlement, and your reporting don't move. What does move is what gets stored where. We tokenisethe card inside our vault and return a token your systems can use for refunds, repeat charges, or anything else you need to do with that customer later. The real PAN never leaves our environment. The agent never sees it. The recording never hears it. The CRM never stores it. That's what good looks like for a 2026 MOTO operation.

Who's actually running MOTO payments in 2026

A lot of people assume MOTO is a fading channel because online checkout exists. It isn't. The businesses we onboard every month tell the same story: the phone channel is growing, not shrinking, and it's doing so in the verticals where customer trust matters more than checkout convenience. The B2B trade desk taking a £40,000 order doesn't want a payment link bounced through three approval emails — they want to confirm the deal on the call. The 78-year-old donor giving £200 to their local hospice charity isn't opening a checkout page on their laptop; they're reading their card to a volunteer over the phone. The mail-order pharmacy serving rural pensioners gets card details on the back of an order form. All of that is MOTO, all of it is in PCI scope, and very little of it is being handled the way the card schemes expect.

The verticals where MOTO is the dominant card channel haven't really shifted in a decade. Charities and not-for-profits run phone-donation campaigns through the autumn fundraising window — Macmillan, the British Heart Foundation, smaller regional charities, all of them. Housing associations and local-authority rent collection still happens by phone for tenants who don't bank online. Insurance brokers take card payments mid-call for renewals and adjustments because the customer's already on the line about something else. B2B wholesale trade desks close orders by phone because the price and quantity are being negotiated live. Travel agents — independent ones, not the OTAs — book ferries, cruises, and group trips with card details given verbally. Mail-order pharmacies, medical billing, solicitors invoicing clients, accountants taking advance fees, utility companies handling supply-disconnect payments. Every one of these runs a MOTO channel whether they call it that or not.

Pinnacle Groupis the example we point most prospects at. They're a UK facilities-management business with a multi-site contact centre taking card payments for housing-association rent, social-care contributions, and various local-authority schemes. Before they came to us they were taking MOTO calls on a traditional setup — agents typing card numbers into a virtual terminal while the call was being recorded for QA. Every recording was effectively a PCI asset, the whole agent estate was in scope, and their PCI auditor was charging accordingly. We took the card capture off the agents using DTMF masking, dropped them from SAQ D to SAQ A, and removed 95% of their PCI scope at a stroke. The recordings became card-data-free, the agent workstations dropped out of scope, and the auditor's evidence pack shrank to a fraction of what it had been. None of their callers noticed any change to the experience.

The point isn't that Pinnacle's setup was unusually risky — it's that almost every MOTO operation we see for the first time looks like that. The auditor knows it's a problem, the compliance officer knows it's a problem, the head of contact centre knows it's a problem, and nobody's had the budget or the platform choice to fix it. The reason the SAQ A picture exists is because the card schemes designed an explicit off-ramp for businesses that route capture through a certified provider. Most MOTO merchants haven't taken it yet. We exist to make that off-ramp the obvious choice.

MOTO vs IVR: which one do you actually want?

People often use "MOTO payments" and "IVR payments" interchangeably and they shouldn't. MOTO is the umbrella; IVR is one type of MOTO. The choice between them isn't about risk — both can be made fully PCI compliant — it's about what kind of conversation you want with the customer at the moment of payment.

IVR paymentsare fully automated. The customer dials a number — typically a dedicated payment line — and a recorded voice walks them through entering their reference, their amount, and their card details. No agent is involved at any point. IVR works brilliantly for high-volume, low-touch payment flows: utility bill collection, recurring rent payments, fixed-price renewals, anywhere the conversation has nothing left to add. The customer doesn't want a chat; they want to pay and get on with their day. IVR is cheaper per transaction because the agent time disappears entirely.

Agent-assisted MOTO is what most of our customers run. The agent stays on the call from the first hello to the goodbye, the customer types their card on their own keypad with DTMF masking applied, and the agent confirms the result when authorisation lands. Agent-assisted is the right choice whenever the payment is part of a larger conversation — answering questions, handling objections, upselling, dealing with disputes, collecting card details mid-troubleshoot. The customer doesn't get hung up on, transferred, or dropped into a phone tree at the moment they've decided to pay; the agent walks them through it without ever hearing the digits.

The two aren't mutually exclusive. Plenty of our larger customers run both: agent-assisted on their main contact-centre line, IVR on a dedicated payment line for callers who already know what they want to pay. The PCI architecture is the same in both cases — capture happens in our environment, the card data never reaches your systems, your scope sits at SAQ A. The only thing that changes is whether there's a human voice on the call.

What changes for your team after you go live

We're going to be straightforward about this: from the customer's perspective, almost nothing changes. They ring the same number, talk to the same agent, hear the same hold music, and at the point of payment they're asked to type their card into their handset instead of reading it out loud. Some customers don't even notice the difference because they were already typing it (mobile callers using the keypad are common). The few who do notice tend to say something like "oh, that's clever" and the call continues.

From the agent's perspective, the change is small but useful. They no longer have to read the card number back to the customer to confirm it (because they don't see it), they no longer have to worry about background noise on the recording capturing digits, and they no longer have a virtual-terminal screen to fumble with mid-conversation. The "Take payment" button in their workflow does the rest. Agents who've worked in PCI-conscious contact centres usually appreciate not being a single point of audit failure anymore.

For the compliance officer and the auditor, the change is dramatic. Annual evidence collection shrinks from a months-long exercise covering hundreds of controls across the contact-centre estate to a focused check on the integration with us. Your CNPtransaction reporting becomes simpler because the merchant identifier and acquirer relationships don't change — only the capture layer does. Penetration tests that used to cover the agent workstation network can be scoped down. Staff PCI training, while still required, can focus on customer-facing behaviour rather than card-handling because there's no card handling left to train on. We publish a Section 12.8 service-provider responsibility matrix that drops straight into your auditor's evidence pack — the part that explains which controls Paytia owns and which controls you still need to demonstrate.

On the cost side, the maths usually works out favourably. The Paytia subscription is offset by the reduction in QSA assessment time, the smaller scope of your annual penetration test, the simpler agent estate (you don't need a hardened, isolated, secure-room environment for staff who never see card data), and — for businesses that have ever had a near-miss with a breach — the dramatic reduction in your potential exposure. We have customers who've eliminated 80%+ of their PCI compliance line items in their internal cost models. For anyone running a PCI-compliant call centreat scale, that's the kind of number that justifies the project on its own.

The MOTO mistakes we see most often

After nearly a decade of onboarding MOTO operators, a handful of mistakes show up over and over. The first is treating MOTO payments as a side channel that doesn't need the same compliance investment as the main e-commerce checkout. It does — usually more, because the controls have to compensate for the missing 3DS2 layer and the human-in-the-loop risk that online checkout doesn't have. The MOTO line is rarely the highest-volume revenue stream, so it gets less attention from product and compliance teams; that's exactly why it ends up being the unaddressed liability when an audit lands.

The second is assuming pause-and-resume on call recording is enough. It isn't. Operationally it depends on every agent remembering to trigger the pause, the pause API firing reliably across every campaign, and the recording platform actually honouring it on every leg of a transferred call. We've audited operations where the pause worked 94% of the time — which sounds high until you realise that means 6% of payment calls still have card data in the recording, and you can't tell which 6% without going through every call. The card schemes don't grade on a curve.

The third is relying on agent training as the primary control. PCI training is necessary but it's not sufficient. A trained agent who reads a card number aloud, types it into a free-text CRM field, writes it on a Post-it, or repeats it back over a recorded line has put you in breach even if they meant well. The card schemes designed the SAQ A off-ramp because they know human controls fail at the rate humans fail at — which is high enough that the standard explicitly recommends taking the human out of the data path. That's what we do, and it's why every conversation we have with a serious MOTO operator ends in the same place.