Mail Order Telephone Order (MOTO) Payments Explained
Mail Order Telephone Order (MOTO) is a card payment taken without the card being present — the cardholder reads or writes their details and the merchant keys them into a virtual terminal or gateway.
Mail Order Telephone Order — almost always shortened to MOTO — is one of the oldest forms of card-not-present payment. The customer isn't standing at a till. They're on the phone, or they've posted an order form, or sometimes (still, in 2026) they've emailed or faxed their card details to the merchant. The merchant then keys those details into a virtual terminal, a payment gateway page, or a card machine that supports a manual entry mode.
It sounds dated, and the "mail order" half almost is. But the "telephone order" half is still huge. Hotels take card details over the phone to guarantee bookings. Tradespeople take deposits. Charities take donations. B2B suppliers take invoice payments. Anyone who sells to customers who'd rather speak to a human than fill in a checkout form is, technically, running MOTO transactions.
How a MOTO payment actually works
The mechanics are simpler than card-present. There's no chip read, no contactless tap, no PIN. The merchant collects the card number (PAN), expiry, CVV, and the cardholder's name and billing address. Those details go into a virtual terminal — usually a web page provided by the merchant's acquirer or payment gateway — and the gateway routes the transaction to the card schemes for authorisation.
Address Verification Service (AVS) and CVV checks run in the background. If the billing address numerics and postcode match what the issuer has on file, and the CVV matches, the issuer is much more likely to approve. If they don't, the issuer may decline, or approve but flag the transaction as higher risk.
3D Secure (the SCA flow most people know as Verified by Visa or Mastercard Identity Check) is a wrinkle. In a normal e-commerce flow, the cardholder gets pushed to their banking app to approve the payment. In MOTO, that's not happening — the cardholder isn't at a screen. In the UK and EU, MOTO is exempt from Strong Customer Authentication under PSD2, which is partly why it's still such a popular fallback channel for businesses whose customers struggle with online checkouts.
Why MOTO is a PCI DSS problem
Here's where it gets uncomfortable. The moment a merchant hears, sees or writes down a card number, they're in scope for PCI DSS. Every system, every person, every recording. A call centre that takes card payments over the phone is sitting on what the standard calls the cardholder data environment (CDE), and that environment has to meet the same controls as a high-volume e-commerce site.
The specific risks with MOTO are well known:
- Agents hear the full PAN. Anyone listening — colleagues, supervisors, anyone passing the desk — also hears it.
- Call recordings capture card data. If you record calls (and most contact centres do, for quality and compliance), you're now storing cardholder data on whatever system holds those recordings. That brings the recording platform, the storage, the backups, and anyone with access to them all into PCI scope.
- Agents can write it down. Even with a clean-desk policy, paper Post-its happen. So do screen captures.
- Screens display the PAN. Whatever CRM or virtual terminal the agent's typing into now has the card number on screen, often visible to anyone walking past.
PCI DSS v4.0.1 — the current version of the standard — doesn't say "you can't take MOTO payments." It says you have to protect cardholder data wherever it lives, and that protection has to be testable. For a manual phone-order setup, that's a long list of requirements: access controls, encryption, training, audit logs, segregation of the call recording platform, pause-and-resume on the recorder, and an annual SAQ (Self-Assessment Questionnaire) or — at higher volumes — a full ROC by a QSA.
The alternative: descope the call
The standard way around all of this is to keep the card details out of the agent's environment entirely. The customer enters their card number on their own phone keypad using the DTMF tones during the call. The tones are masked (or captured by a separate, isolated system) so the agent never hears the digits, the call recording never captures them, and the merchant's CRM screens never display them.
This is what DTMF-masked payment services do. The agent stays on the line, talks the customer through the process, sees confirmation that the payment went through — but the actual card data goes straight from the customer's keypad to the payment gateway, bypassing everything in between. The result: the agent, the CRM, the call recording, and most of the contact-centre infrastructure drop out of PCI scope. The merchant typically files a SAQ A (the lightest version) rather than the much heavier SAQ D for full MOTO.
MOTO vs e-commerce vs card-present
For interchange and chargeback purposes, MOTO sits in its own category. It's card-not-present (CNP), but it's not e-commerce. The transaction is flagged differently to the schemes, and acquirers usually charge a different rate for it. Chargeback liability rules are also different — for MOTO without 3DS, the merchant is on the hook if the cardholder disputes the transaction as fraudulent. That's a real cost line for hotels, travel agents, and anyone taking deposits.
Compared to card-present (chip and PIN, contactless, mobile wallets), MOTO has higher fraud rates, higher acquirer fees, and weaker liability protection. Compared to a properly built e-commerce checkout with 3DS, MOTO has none of the SCA friction but also none of the SCA fraud shielding. It's a trade-off, and for many businesses the trade is worth making because the customer experience — "just call us, we'll take your card" — converts better than asking someone to navigate a checkout flow.
Who still uses MOTO in 2026
Quite a lot of people, actually. Hotels and B&Bs taking booking deposits. Restaurants taking large-party booking guarantees. Tradespeople, locksmiths, plumbers, electricians taking emergency call-out payments. Charities taking phone donations. Veterinary practices. Care homes taking top-up fees. B2B suppliers letting buyers pay an invoice without setting up a portal account. Subscription-based businesses where customers want to renew by phone. Anyone selling to an older customer base that's wary of online checkouts.
The common thread: the merchant's customers prefer a person over a form, and the merchant's average order value is high enough that a few minutes on a phone call is profitable.
What good MOTO compliance looks like
If you're taking MOTO payments at any scale, the realistic options are:
- Full SAQ D MOTO compliance. Keep the call but build out the controls — agent training, secure rooms, screen privacy, call recording with pause-and-resume properly configured, segmented networks, encrypted storage, regular vulnerability scans. This is expensive and audit-heavy, but it's what large contact centres without DTMF masking are doing.
- DTMF masking on every phone payment. The agent stays in the conversation, the customer keys the card on their own phone, the digits never reach anywhere that's in scope. Typically reduces the SAQ to SAQ A and slashes the scope of the rest of the environment. This is what Paytia does.
- Send a pay-by-link. Instead of taking the card on the call, text or email the customer a hosted payment page. Works well for some customers, but adds drop-off — and a chunk of the customers who phoned in did so precisely because they didn't want to fill in a form.
The first option is workable but heavy. The second is the path most contact centres handling regular phone payments end up on. The third works as a top-up for the customers willing to do it themselves.
A practical compliance checklist
If you're still running unprotected MOTO calls and want to know where you stand, the questions to ask are:
- Do agents hear card numbers? (If yes, you're in full PCI scope.)
- Are calls recorded? (If yes, the recording platform is in scope and needs reliable pause-and-resume.)
- Where do card numbers get typed? (Whatever screen and system — virtual terminal, CRM field — is in scope.)
- Who has access to the recording archive? (Anyone with access is in scope.)
- What SAQ does your acquirer expect from you? (Find out — most merchants discover they've been signing the wrong one.)
If any of these answers worry you, the fastest route to a quieter audit is taking card data out of the call. We've written more about how PCI scope works for contact centres if you want the longer version.
Frequently Asked Questions
Is taking a card payment by phone legal?
Yes, MOTO is a legitimate payment channel and falls under MOTO interchange categories with the card schemes. But it's in scope for PCI DSS, so you can't take phone payments without meeting the relevant security controls — or descoping the call with DTMF masking.
What's the difference between MOTO and e-commerce?
Both are card-not-present, but e-commerce means the customer enters the card details themselves on a website. MOTO means the merchant captures the details from the customer over the phone or via mail. They sit in different interchange categories and have different SCA rules — MOTO is exempt from PSD2 SCA in the UK and EU.
Do I need PCI compliance for occasional phone payments?
Yes. PCI DSS scope is binary — either you handle cardholder data or you don't. Even one phone payment a month puts you in scope, though your SAQ obligations scale with volume. Talk to your acquirer about which SAQ applies.
Can I just pause call recording when the customer reads their card number?
You can, and many contact centres do, but it relies on agents remembering every time, and the pause logic has to be auditable. Most QSAs treat manual pause-and-resume as a weak control unless it's automated and tested. DTMF masking removes the question entirely.
What's a virtual terminal?
A virtual terminal is a web-based form provided by your acquirer or payment gateway where you key in the customer's card details to take a MOTO payment. It's effectively a card machine that runs in a browser. The risk is that the agent typing into it sees and hears the card data.
Is MOTO going away?
No. Voice commerce is growing in some sectors (hotels, B2B, charity, healthcare, trades), and customer preference for talking to a human is stubborn. What's changing is how merchants take the payment — fewer are willing to wear the PCI DSS overhead of unprotected MOTO, so DTMF masking and pay-by-link are taking over.
See how Paytia handles mail order telephone order (moto)
Book a personalised demo and we'll show you how our platform works with your setup.
Trusted by law firms, insurers, healthcare providers and regulated businesses worldwide. Learn more about Paytia