MOTO Payments: What They Are, What They Cost, and PCI Scope

A MOTO payment — short for Mail Order / Telephone Order — is a card transaction placed by phone, email, or post rather than in person or on a website. The card networks have treated it as a separate category since the catalogue era, with its own merchant category code, interchange rate, and chargeback rules. Because the card is never present and there's no 3D Secure step on a phone call, the merchant carries the fraud liability.

If you've ever read a card number to a person on the phone, you've made a MOTO payment. The category covers everything from a one-off invoice paid by phone to a 500-seat contact centre taking ticket bookings all day. What unites them is the absence of the card at the moment of the transaction — and the absence of any cryptographic check between the cardholder and the merchant.

Most explanations treat MOTO like an artefact — something businesses used before the web took over. That misses what's actually happening. Phone-taken payments still account for a meaningful chunk of contact-centre revenue across insurance, healthcare, B2B, charity, and travel, and the PCI DSS v4.0.1 changes that went live in March 2025 made the compliance burden tighter, not looser. If your operation takes card details over the phone — even occasionally — this page explains what MOTO actually is, how the rules apply to it, and how to run the channel without dragging your whole business into PCI scope.

What Counts as a MOTO Transaction

MOTO covers any card payment where the cardholder gives you their details remotely and you — not they — put the transaction through. The classic cases: a customer reads their card number to an agent over the phone, writes it on a mail-order form, or (still, occasionally) sends it by fax. It's a recognised category under Visa, Mastercard, American Express, and Discover scheme rules, with its own transaction coding and its own interchange treatment.

The card networks split transactions into three broad presentment categories. Card-present is anything with a chip, contactless tap, or magstripe swipe at a physical terminal. E-commerce is anything the customer enters into a web checkout themselves. MOTO is the third: the cardholder is on the phone or has posted an order form, and the merchant keys or accepts the details remotely. MOTO and e-commerce both fall under card-not-present for PCI DSS scoping purposes, but the schemes still distinguish between them because the fraud patterns and the available authentication tools are different.

The dividing line worth remembering is who completes the checkout. If your customer types their own card number into a payment page — even one you sent them by SMS mid-call — that's an e-commerce transaction. The moment your staff hear, see, or key the number, it's MOTO, and everything that touched the number becomes your compliance problem.

How a MOTO Transaction Works, Step by Step

A typical MOTO call goes like this. The customer rings, the agent identifies them and confirms the order, then asks for card details. The customer reads out the long number, the expiry, the CVV. The agent types the digits into a virtual terminal — usually a web page on their workstation connected to the payment gateway. The gateway sends the authorisation request to the card scheme, which routes it to the issuing bank. The issuer approves or declines, the agent reads the result back, and the call ends.

Every step of that flow is a risk point. The agent hears the card number and the CVV. The workstation displays them. The call recording — almost always running for quality and dispute purposes — captures the audio. The phone system carries the data. If a fax or paper form is involved, there's now a physical copy sitting somewhere. None of this is hypothetical: PCI assessors flag every one of those touchpoints as in scope.

The mechanics of MOTO are simple. The compliance fallout from running the mechanics naively is what makes it expensive — and that's the part most explanations skip.

Why MOTO Is the Most Scope-Intensive Payment Channel

In e-commerce you can hand the whole checkout to a hosted payment page and keep card data out of your systems entirely. A MOTO call offers no such shortcut. Unless you engineer one, the card number passes through human ears, telephony, call recordings, and agent workstations before it ever reaches a processor — which makes MOTO the most scope-intensive payment channel a business can run.

For a typical contact centre taking phone payments verbally, the scope list is bleak. The card number is spoken into the agent's headset, so the IP telephony system carries it. The agent types it into a virtual terminal or CRM, so the workstation, the screen, the keyboard, and the network all see it. The call is recorded, so the recording platform stores it. Sometimes the recording lands in a quality-monitoring tool, a coaching platform, or an analytics pipeline. Every one of those systems sits inside the cardholder data environment and has to be assessed against PCI DSS.

That's what drives most contact centres to SAQ D — the 329-control questionnaire — instead of the much shorter SAQ A, which runs to 22 controls. We've broken down what sits in each in our guide to SAQ A and the SAQ glossary entry, and the free Paytia Comply app walks you through the same eligibility questions one at a time. The 12 requirements of PCI DSS don't get easier just because you've got 500 agents and a CRM. If anything, they get harder, because every additional system multiplies the audit work.

What PCI DSS v4.0.1 Changed for MOTO

Version 4.0.1 has been the live version of the standard since 31 March 2025. It didn't add new requirements over v4.0 — it sharpened the language — but for phone-payment operations, three of those clarifications bite.

The first is what counts as in scope. The v4.0.1 wording is explicit: any system component that can affect the security of cardholder data is in scope. That includes a call-recording platform that captures DTMF tones, even if it never stores the digits as readable text. v4.0 already implied this. v4.0.1 leaves no room to argue.

The second is Requirement 3 on stored data. Sensitive authentication data — the CVV, full magnetic-stripe data, PIN data — must not be retained after authorisation. Not in plaintext, not encrypted, not in a temporary buffer, not in a backup. For MOTO, that means call recordings which captured a CVV have to be redacted or deleted. The old "we'll encrypt the recording" workaround doesn't hold.

The third is the set of requirements that became mandatory with v4.0.1, including multi-factor authentication on every access path into the cardholder data environment. None of it is MOTO-specific, but contact centres running payments from agent workstations on mixed corporate networks find that MFA requirement eats budget faster than expected. Our founder, Curtis Nash, puts it bluntly: "The fastest way to handle v4.0.1 in a phone-led operation is to make sure the phone leg never touches the agent in the first place. Everything else is a workaround." There's a fuller breakdown on our PCI DSS v4.0.1 page.

Why MOTO Carries More Fraud Risk Than E-Commerce

The single biggest difference between MOTO and online card-not-present is authentication. An online checkout can route the cardholder through 3D Secure, which sends a passcode to the customer's phone or asks them to confirm in their banking app. If the customer authenticates, fraud liability shifts to the card issuer. The merchant is protected.

There's no equivalent for a phone call. The card networks have talked about MOTO 3DS for years; in practice, the issuing banks haven't built it. So when your agent takes a card number on a call, no authentication happens. If the caller turns out to be a fraudster reading stolen details, the chargeback lands on the merchant. Every time.

The numbers back this up. UK Finance counted 1.98 million card-not-present fraud incidents in the first half of 2025 — a 19% rise on the same period in 2024 — while the loss figure for the half, £372 million, was actually slightly lower. More cases, smaller amounts. Fraudsters are spreading smaller charges across more stolen cards, which makes value-threshold fraud rules less useful than they were. FICO's European Fraud Map put card-not-present at around 70% of total UK card fraud losses in 2024, and the categories driving it aren't all e-commerce.

What actually works for MOTO fraud is layered and mostly unglamorous: address verification (AVS), CVV checks without ever storing the CVV, velocity checks across customer accounts, and agent training that covers social-engineering scripts. We've written more on the wider picture in card-not-present transactions explained and on our CNP fraud page.

The SCA Exemption Cuts Both Ways

UK and EU Strong Customer Authentication rules under PSD2 carved out an explicit exemption for MOTO. Phone and mail-order payments are exempt from SCA because there's no realistic way to apply biometric or device-based authentication to a phone call. That sounds helpful, and operationally it is — your agents aren't forced through an impossible challenge flow.

But the exemption cuts both ways. Because there's no SCA, there's no liability shift: the merchant still owns every fraudulent chargeback. And the same exemption that keeps MOTO workable is exactly what makes the channel attractive to fraudsters — it's the one card-not-present route where stolen details never face a real-time challenge. The exemption is a description of reality, not a protection. We've covered the regulatory backdrop in UK regulations for taking card payments by phone.

MOTO in the UK and the US

The compliance story barely changes when you cross the Atlantic. PCI DSS is enforced by contract through your acquiring bank, not by legislation, and the card schemes are global — so the scoping rules, the SAQ types, and the DTMF question are identical in London and in Denver. What differs is the regulation layered on top. The UK has the PSD2-derived SCA regime with its MOTO exemption; the US has no SCA equivalent at all, so there's no exemption to think about — just the same PCI obligations and the same merchant-side chargeback liability.

The channel itself is alive in both markets. Insurance renewals, healthcare payments, charity donations, B2B invoice settlements, and travel bookings all still run heavily through the phone, because older customers prefer to talk to a person and complex B2B orders resolve faster by voice than by checkout. Anyone telling you MOTO is a relic hasn't sat in a contact centre lately.

What a MOTO Payment Costs

MOTO transactions usually carry higher interchange fees than equivalent card-present transactions. The difference can be 0.3-0.8 percentage points depending on the card type, the acquirer, and the market. That's the card schemes pricing in the higher fraud risk — they expect more chargebacks, so they charge more per transaction. For a business processing £1m a year on the phone, that's anywhere from £3,000 to £8,000 in extra interchange compared to taking the same payments in person.

The Four Ways Businesses Take MOTO Payments Today

Most businesses that take phone payments don't really want to — they have to. A service call turns into a sale. A customer is elderly, doesn't want to go online, and has rung the office instead. A B2B finance team wants to pay an invoice by card rather than wait for a bank transfer to settle. Whatever the reason, there are four operational patterns for taking the payment, and choosing between them is really a choice about scope and conversion.

Manual keying into a virtual terminal is the default. The agent stays on the call, the customer reads out the card details, the agent types them into a payment-gateway web form. It's the simplest pattern to set up and the worst possible PCI outcome — agent, workstation, telephony, recording, and network are all in scope.

IVR self-service routes the customer off the live call to an automated menu where they key their card digits alone. Scope drops dramatically because no agent is on the line — but so do conversion rates on complex calls, and older customers find it alienating.

Agent-assisted DTMF masking keeps the agent on the call throughout. At the payment step the customer keys their card on the handset, and the tones are masked before they reach the agent, the workstation, or the recording. High conversion, low scope. This is the pattern we built Paytia around, and we think it's the only one that doesn't force a trade-off.

Pay-by-link abandons the call: the agent sends an SMS or email link and the customer completes an online checkout later. Excellent for scope — it turns the payment into e-commerce, with the customer's own device doing the work — but it kills the thing that makes MOTO valuable, which is closing the sale while the customer is on the phone. Some of them never click the link.

Do You Need a MOTO Payment Gateway?

Not a separate gateway — what you need is a gateway and merchant account with the MOTO channel switched on. Acquirers approve merchant accounts channel by channel, and MOTO transactions carry their own indicator when they're submitted for authorisation, so if your account was set up for e-commerce only, keyed phone transactions can be declined or, worse, miscoded. If you're planning to take card payments by phone, say so when you apply.

On the gateway side, the MOTO feature you'll usually be offered is a virtual terminal — the web form your staff key cards into. It works, but as covered above, it drags the workstation and everything around it into PCI scope. The better question than "which MOTO gateway do I need" is "how do I get the card number to the gateway without my people or systems touching it." That's what agent-assisted capture answers: Paytia connects to the major UK and US gateways and passes the customer's keypad digits straight through, so your existing gateway relationship stays put. Our guides to taking card payments over the phone and telephone payments cover the set-up choices in detail.

How DTMF Masking Takes MOTO Out of Scope

The technique that breaks MOTO out of full PCI scope is DTMF masking, sometimes called DTMF capture or DTMF suppression. The customer enters their card number on their phone keypad instead of reading it aloud. A service like Paytia sits in the call audio path, detects the tones, and routes the digits straight to the payment gateway. The tones are stripped or replaced with flat noise before the audio reaches the agent's headset or the call recording.

Done properly, this means:

• The agent never hears the card number. They stay on the call, can coach the customer through the process, and see only the last four digits and authorisation status on their screen.
• The call recording never captures the card number. Compliance teams can keep full-duration recordings for quality and dispute purposes without those recordings being card data.
• The contact centre infrastructure — telephony, CRM, agent desktops, network — drops out of PCI DSS scope. You move from SAQ D to SAQ A.

PCI DSS 4.0.1 called this out explicitly. If your telephony system captures DTMF tones containing card data and stores them in any log or recording, those logs become card data and the system stays in scope. So suppression has to be done before capture, not after — redacting recordings afterwards leaves the recording platform inside the cardholder data environment and doesn't help you at assessment time.