What are MOTO Payments?

MOTO means Mail Order / Telephone Order — a card transaction placed by phone, post, or fax rather than in person or through a website. The card networks have classified MOTO separately since the catalogue era of the 1980s, and they still do: MOTO transactions carry their own merchant category code, their own interchange rate, and their own chargeback rules. Every MOTO payment is also a card-not-present transaction for PCI DSS purposes, which means the agent's headset, screen, and call recording all sit inside the cardholder data environment unless you've taken active steps to keep card data out.

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. MOTO predates the web by decades, and it's still one of the largest channels for B2B payments in the UK.

Where MOTO Fits in the Card-Scheme Picture

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 entered into a web checkout. MOTO is the third — the cardholder is on the phone (or, rarely now, posting an order form), and the merchant keys or accepts the details remotely.

Each category gets a different transaction code. Acquirers price them differently, fraud-monitor them differently, and apply different chargeback rules. 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.

Why MOTO Carries More 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, but 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 call turns out to be a fraudster reading stolen details, the chargeback lands on the merchant. Every time.

That's why MOTO chargeback rates run higher than e-commerce in most industries, and why fraud teams obsess over voice channels even though they're proportionally smaller than online traffic. We've covered the wider liability shift picture in our piece on 3D Secure authentication.

MOTO and PCI DSS Scope

The PCI DSS scope question for MOTO is the same as the question for any card-not-present channel: which systems can see, hear, store, or transmit the card data, and how do you protect them?

For a typical contact centre taking phone payments verbally, the answer 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. 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.

How DTMF Capture Descopes MOTO

The technique that breaks MOTO out of full PCI scope is DTMF capture, sometimes called DTMF masking 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.

SCA Exemptions and MOTO

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, but it has a sting in the tail: because there's no SCA, there's no liability shift. The merchant still owns every fraudulent chargeback.

The exemption is a description of reality, not a protection. It just means "we know you can't do SCA on a phone call, so we won't make you try." It does not mean "phone payments are lower-risk than online."

MOTO Interchange and the Cost of a Phone Payment

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 Operational Reality of Taking MOTO Payments

Most businesses that take phone payments don't really want to take phone payments — they have to. Customers ring up with a query, the conversation turns into a sale, and now there's a card payment to take. Or the customer is elderly, doesn't want to go online, and has called the office instead. Or it's a B2B invoice and the finance person wants to pay over the phone rather than wait for a bank transfer to settle.

Whatever the reason, the choice isn't really between "take MOTO payments" and "don't." It's between "take them with scope and fraud risk" or "take them with the data kept out of your environment." The second option is what Paytia exists for. We covered the regulatory backdrop in UK regulations for taking card payments by phone, and the comparison with the wider CNP picture in card-not-present transactions explained.

MOTO vs Virtual Terminal vs Pay-by-Link

Three things often get muddled. A virtual terminal is a web form your agent types into — the merchant captures the card number on the agent's screen. A pay-by-link sends the customer a URL or SMS so they enter the card themselves on a hosted page. A MOTO call with DTMF capture keeps the customer on the phone and lets them key the card on the handset.

From a PCI scope point of view, virtual terminals are the worst (the agent's workstation is in scope), pay-by-link is excellent (the customer's device is in scope, not yours), and DTMF capture matches pay-by-link while keeping the agent on the call. Which one fits depends on whether you need a live agent guiding the payment, and whether your customers will follow a link.