Not every sale happens at a checkout counter or a website button. For a lot of businesses, the biggest orders arrive the old-fashioned way — a customer calls in, an email lands with an order attached, a buyer confirms a restock over the phone. That entire category of card payment has a name: MOTO, short for Mail Order and Telephone Order. MOTO payments sit inside the broader family of card-not-present transactions, and they behave very differently from the tap-and-go payment you take across a counter. Understanding those differences is what separates a smooth phone-order process from a fraud chargeback, a leaked card number, or a payment that never gets authorized.
What Are MOTO Payments and How Do They Actually Work?
A MOTO payment is any card transaction where the card is not physically present and the payment details are entered manually by staff — over the phone, from a mailed-in order form, or from an email conversation. Because there’s no chip to read and no PIN or contactless handshake, the transaction is keyed in rather than read from the card. The customer reads out a card number, expiry date, and security code, and the business types those details into a payment system that sends an authorization request to the card issuer.
That manual entry is the source of both the convenience and the risk. On the positive side, MOTO lets a business close a deal without needing the customer in front of them, which is essential for wholesale accounts, service businesses, and any company whose customers order by phone. On the risk side, manual entry removes the cryptographic proof that the actual card was present, so the transaction sits in a category issuers treat as higher risk. That’s why keyed payments often carry different interchange treatment than swiped or tapped transactions, and why the systems used to process them build in layers of verification.
The practical tool behind most MOTO operations is a virtual terminal — a secure, browser-based payment page that functions like a card machine on a screen. Quality matters here. A well-built virtual terminal performs an address verification (AVS) check against the cardholder’s billing address and validates the CVV, then applies 3-D Secure authentication where the issuer supports it. It should tokenize card data so the raw number never sits in a spreadsheet, and it should include a customer card vault so repeat charges and recurring schedules can run from a stored token instead of a card number typed again. Look for access controls too: role permissions that decide who can key transactions, issue refunds, and void payments, plus automatic session timeouts and exportable audit logs so there’s a record of exactly who did what.
The single most important operational rule is short and absolute: card numbers get keyed directly into the terminal and never written down. Not on a paper order pad, not in a notes field, not in a CRM contact record. Stored card data in an unprotected place is the fastest route to a breach and a PCI headache. Readers regularly ask, Can I accept credit cards by phone or email securely? — and the honest answer is yes, provided the card details live only inside a PCI-compliant terminal and your staff are trained to enter them there every single time.
Where MOTO Payments Fit: Real-World Scenarios
The clearest way to understand MOTO is to see where it shows up in daily operations. Consider a B2B or wholesale supplier whose buyers used to mail cheques against net-term invoices. A virtual terminal flips that workflow: the invoice goes out, the buyer calls or emails to authorize payment by commercial card, and the order ships without waiting on the post. The buyer’s purchase order number can be captured alongside the charge, so the payment reconciles to the right job in accounting. When a partial payment comes in, it can be traced back to the same invoice rather than floating as an unidentified deposit, and receivables reporting clears invoice by invoice.
Now think about a service business — HVAC, landscaping, restoration, equipment repair — where the technician finishes a job and the homeowner isn’t home to hand over a card. A phone call with a keyed payment, or an emailed pay-by-link that the customer completes on their own device, closes the job the same day instead of waiting for a follow-up visit. Deposits and balance payments work the same way: take the deposit when the work is booked, then collect the remainder at completion, each tied to the same reference.
Retailers benefit from the hybrid case. A customer calls to reserve an item in a specific size or colour, pays by card over the phone, then picks it up in store. If a virtual terminal shares a dashboard with the retail point of sale, the phone sale, the in-store sale, and the online sale all land in one view — and a later return can be processed against the original transaction rather than as a blind refund.
Repeat and recurring revenue is the third major fit. Maintenance plans, subscription boxes, and monthly service contracts can all draw from cards saved in the customer vault, with schedules that run automatically and receipts that go out instantly. The key is that the customer authorized the stored credential, the token is protected, and every charge maps back to a documented agreement.
Reducing Fraud and Chargebacks on Keyed Transactions
Because keyed transactions lack a physical card, they attract more attempts at unauthorized use — and they also attract friendly fraud, where a legitimate cardholder disputes a charge they actually made. The defense starts at the moment of entry. AVS and CVV responses give you an immediate signal: a billing address that doesn’t match and a CVV that fails are reasons to pause, ask a follow-up question, or request an alternate payment method. Build a written policy for how staff handle mismatches so decisions aren’t improvised under pressure.
Add authentication where the issuer supports it. 3-D Secure pushes the cardholder through an extra verification step in their own banking app, and in many cases that step can shift dispute liability away from the merchant. It won’t fit every phone scenario — the customer has to complete the challenge — so the practical approach is to enable it where it works and lean on verification policy where it doesn’t.
Controls inside the terminal matter just as much as controls at the point of entry. Restrict key-entry permissions to trained staff, separate the ability to issue refunds and voids from the ability to take payments, and let session timeouts close an unattended browser automatically. Exportable audit logs turn “I think Sarah took that one” into a documented trail with timestamps and user IDs — invaluable if a customer later questions a charge.
Even with all of that in place, some disputes will happen. That’s where a structured chargeback response earns its keep: alerts that arrive early enough to act, evidence packs assembled from transaction, authorization, and delivery details, deadline tracking so nothing lapses, guidance on the reason code being argued, and reporting on outcomes over time. Combine that with immediate email receipts to the cardholder and a clear business name on the statement descriptor, and you remove most of the “I didn’t recognize that charge” disputes before they start. Not every dispute can be won, but the ones backed by clean records and fast responses are a very different fight from the ones backed by a note on a sticky pad.
Born in Sapporo and now based in Seattle, Naoko is a former aerospace software tester who pivoted to full-time writing after hiking all 100 famous Japanese mountains. She dissects everything from Kubernetes best practices to minimalist bento design, always sprinkling in a dash of haiku-level clarity. When offline, you’ll find her perfecting latte art or training for her next ultramarathon.