A MOTO transaction is a mail order/telephone order payment: the customer gives you their card details by phone, by mail or by another written instruction, and you key the payment in yourself instead of the customer entering it at a checkout page or tapping a card at your counter. MOTO is a form of card-not-present (CNP) payment, which means the card is not physically read and the cardholder is not authenticating on a screen. That one fact explains almost everything else about MOTO: the data-entry workflow, the higher fraud exposure, the chargeback rules and the PCI DSS obligations.
This guide covers what MOTO means in payment processing, how a transaction moves from a phone call to a settled deposit, which businesses rely on it, what you need to collect, how it can look on a customer’s statement, and how to run it without inviting disputes or expanding your compliance scope.
MOTO stands for mail order/telephone order. The category dates from the catalog era, when customers filled in an order form or called a toll-free number and the merchant charged the card by hand. The label survived because the payment mechanics did not change: a person on the merchant side enters the card number, expiration date and billing details into a terminal, a gateway or a virtual terminal.
In practice, “mail order” now covers any written instruction carrying card details, and “telephone order” covers any spoken one. Merchants often sort all of them into a single MOTO bucket in their processing setup. For a broader glossary treatment, including how decline codes behave on these payments, see our MOTO transactions and card decline codes glossary.
Two points of vocabulary prevent confusion:
The flow is short, and each step is a place where errors or fraud can enter.
If you want a virtual terminal for staff-keyed payments alongside ACH and eCheck options, our B2B and B2G payment processing page covers it.
| Factor | Card-present (POS) | Ecommerce | MOTO |
|---|---|---|---|
| Who enters card data | Cardholder taps, dips or swipes | Cardholder types it at checkout | Merchant staff keys it in |
| Card physically present | Yes | No | No |
| Cardholder authentication | Chip, PIN or signature | 3-D Secure 2 is available | Typically none beyond AVS and CVV checks |
| Where card data travels | Terminal | Customer’s browser to the gateway | Phone line or document, then the agent’s screen |
| Main compliance concern | Terminal and network security | Checkout page integrity | Agent environment, call handling and paper records |
| Typical dispute exposure | Lower | Moderate, reduced by 3DS2 | Higher, and evidence-dependent |
The authentication row matters. 3D Secure 2 is designed for a customer completing an online checkout, so a payment taken by phone usually cannot use it. The merchant carries more of the burden of proving the order was legitimate.
MOTO persists because many orders are simply easier to take by voice or paper. Common examples include:
Several of these categories are treated as higher risk by mainstream processors, either because of recurring billing, dispute history or regulated products. A merchant that was declined or frozen elsewhere for exactly this kind of volume often needs an acquirer that underwrites the model rather than rejecting it.
The standard data set is:
On the merchant side you need a merchant account that is approved for MOTO volume, a gateway or virtual terminal with a MOTO transaction type, and a documented procedure for your agents. Tell your processor up front that you accept MOTO orders and roughly what share of your volume they represent. Underwriting looks at the sales channel, and a channel that appears on your account without being disclosed can lead to a freeze or a reserve increase. Our gateway and virtual terminal options are set up with that in mind.
The customer’s statement line is controlled by your billing descriptor, not by the fact that the sale was MOTO. What a cardholder normally sees is your business name or abbreviation, sometimes a city or phone number, and a transaction date. A charge labeled with something unfamiliar is a leading trigger for disputes, because a customer who does not recognize it may call the bank before calling you.
Some shorthand on a statement can contain the letters MOTO, such as a business name or abbreviation, and that does not by itself tell you the transaction was a mail or phone order. If you are a cardholder trying to identify a line, check the date against your phone orders, look for a phone number or website in the description and contact the merchant first. If you are the merchant, these habits cut avoidable disputes:
Without a chip, PIN or customer-side authentication, a thief with stolen card numbers can place MOTO orders by voice or written form. The issuer also has fewer tools to confirm that the cardholder agreed to the charge. The result is that disputes on MOTO payments often come down to how well you documented the order.
Mastercard’s published rules reflect this. Its Chargeback Guide for merchants notes that MO/TO transactions fall under specific chargeback rules distinct from card-present payments and that merchants must provide compelling evidence when they dispute. Visa’s dispute framework works on similar principles, with deadlines and evidence requirements that vary by reason code. Our walk-through of Visa chargeback rules, evidence and deadlines explains how those windows run.
Build the file at the time of the sale, not when the dispute arrives:
If disputes are already eroding your ratios, a structured chargeback management and dispute representment program handles prevention alerts, evidence assembly and representment so your team does not rebuild each case by hand.
Because your staff hears or reads card numbers, MOTO pulls your people, phones and desks into the cardholder data environment. The most effective way to shrink that exposure is to stop card data from touching your systems at all.
The PCI Council’s Self-Assessment Questionnaire A is written for merchants whose cardholder data functions are fully outsourced to validated third parties, with no electronic storage, processing or transmission of card data on the merchant’s own systems. A hosted payment page or a processor-hosted virtual terminal accessed in the right way can move you toward that shorter questionnaire. Our guide to hosted payment pages and cutting PCI scope to SAQ A shows how the architecture works. For background on PCI DSS requirements explained and who they apply to, that page lays out the standard’s coverage. Which SAQ applies to you depends on how your payment channels are actually built, so confirm it with your acquirer or a Qualified Security Assessor.
On the telephone side, the PCI Security Standards Council’s guidance on accepting telephone payments securely states that home-based and remote workers should use multi-factor authentication when connecting to telephone-payment environments or systems that process account data, and that access should be limited to personnel with a need to know. That has direct consequences for remote call center staff.
A practical baseline for a MOTO operation:
Our PCI compliance checklist for B2B merchants turns these items into an audit-ready list.
We see MOTO as a legitimate and durable sales channel that mainstream processors often handle badly. A merchant who takes phone orders for a regulated product, a subscription or a high-ticket B2B invoice is not doing anything unusual. The trouble starts when a generic processor flags the channel as an unexpected risk, applies a reserve it never explained or freezes the account in the middle of a billing cycle.
Our approach is to underwrite the MOTO channel openly. We place merchants with sponsor-backed acquiring relationships that understand keyed volume, and we are transparent about reserve structures and quote-based pricing so you know the terms before you board. Pair that with disciplined evidence capture, AVS and CVV enforcement, a descriptor your customers recognize and a hosted or outsourced entry method, and MOTO becomes a manageable channel instead of a liability.
The merchants who struggle with MOTO are usually the ones who treat it as an afterthought. Document the process, train the agents, shrink your PCI scope and keep your dispute evidence in one place. That is how you keep ratios under card network thresholds and keep the account open.
Joshua Benedetti
If you take phone or mail orders and a processor has declined, frozen or capped your account, we can help. CARDZ3N provides high-risk merchant accounts with underwriting support for MOTO and other card-not-present channels, gateway and virtual terminal integrations, ACH and eCheck, and chargeback prevention through ChargebackZ3N. Pricing is quote-based, and we explain reserve terms during underwriting. Start from our merchant services overview to tell us about your channel mix.
MOTO means mail order/telephone order. It describes a card payment where the cardholder gives their details by phone or in writing and the merchant enters the transaction manually, so the card is not present and no one authenticates at a checkout page.
MOTO is one kind of card-not-present transaction. Ecommerce payments are also card-not-present, but the customer enters the data online. In MOTO, your staff enters it, which changes the authentication options, the risk profile and the PCI scope.
They generally carry more exposure to fraud and disputes than card-present payments because there is no chip, PIN or customer authentication. Mastercard’s chargeback rules require compelling evidence from merchants on MO/TO disputes, so collecting AVS and CVV results, written authorization and delivery proof at the time of sale is essential.
Yes. A processor-hosted virtual terminal or a hosted payment page keeps card data off your own systems as far as your setup allows. That can move you toward SAQ A, though your acquirer or assessor should confirm which questionnaire applies to your actual configuration.
You need an account that is approved for the channel. Disclose MOTO during underwriting, along with expected volume, average ticket and your fulfillment process, so the acquirer can price and risk-assess it correctly rather than discovering it later.
Every merchant's processing setup is different, so the right answer depends on your industry, sales channels, average ticket size and chargeback history. CARDZ3N's payments specialists review those details with you and match your business with the right sponsor bank, gateway and risk tools, whether you sell online, in store, by invoice or on a recurring subscription.
We work with merchants across the USA, Canada, the UK and the EU, including high-risk, B2B and fast-growing businesses that traditional processors often turn away. If you would like a second opinion on your current rates, contract terms or approval options, contact our team for a free, no-obligation processing review.
Joshua Benedetti is the CEO of CARDZ3N, a Las Vegas-based merchant services provider specializing in high-risk payment processing and B2B payment technology.
Joshua Benedetti on LinkedInCARDZ3N Inc is headquartered in Las Vegas, Nevada, and provides merchant services to businesses that traditional processors turn away. Backed by top-tier sponsor banks and processors, CARDZ3N combines institutional stability with the speed of a specialized team that understands high-risk industries. Services include high-risk account underwriting and placement, gateway solutions across the major gateway platforms, POS integrations, ACH and check processing, chargeback prevention through ChargebackZ3N, and business lending and working capital. Its AerospacePay division serves OEMs, MROs, FBOs, and repair stations with B2B and B2G payment processing. CARDZ3N serves merchants in the USA, Canada, the UK, and the EU.
Start protecting your revenue from chargebacks today — schedule your complimentary consultation with CARDZ3N’s dispute management specialists.
