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 post, or by fax — 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.