MOTO Payments — Secure card-not-present orders without the PCI scope

What a MOTO payment actually is

MOTO stands for Mail Order / Telephone Order. It's a card-not-present transaction where the customer gives you their card details over the phone, by email, or through a social-channel chat — neither the card nor the cardholder is anywhere near you. The term's a hangover from the catalog-sales era, but Visa, Mastercard, Amex, and Discover still use it and so do your processor, your acquirer, and your QSA.

It's different from in-person and online in a couple of ways that matter. There's no chip, no contactless tap, no swipe — none of the friction that protects a card-present sale. And unlike online, there's no clean way to slot 3DS2 into the flow, because the customer is on a phone call rather than a checkout page. The card network sees the transaction as higher risk than either alternative, prices it accordingly, and pushes the chargeback liability onto you.

Plenty of US businesses still rely on it. Mail-order pharmacy. Catalog and direct-response shopping channels. Healthcare billing — copays, deductibles, treatment plan installments. B2B trade desks closing wholesale orders. Insurance premium collection. Florists, gift sellers, ticketing call centers. Property management taking rent and security deposits over the phone. Any business with a customer base that prefers calling in to clicking through — which, in 2026, is still a long list — runs a MOTO channel whether they call it that or not.

We've been building PCI-compliant phone payment systems since 2016 and MOTO is the workflow we know best. The rest of this page covers what makes it the riskiest card channel you can run, what compliance actually demands in the US, and how to handle the call so your agent stays on the line and the card data doesn't reach your systems. If you'd rather skip to a demo, we'll show you the flow on a real call.

What PCI DSS, state wiretap laws, and HIPAA actually require for MOTO

Every MOTO transaction is in PCI DSSscope. There's no minimum-volume carve-out, no exemption for low-risk merchants, no allowance for "we only do a handful of phone payments." If you take card details by phone, the standard applies to you, and which Self-Assessment Questionnaire you have to complete depends entirely on how the card data is handled.

If your agents key the card number themselves into a virtual terminal — the traditional MOTO setup — you're on SAQ D. Around 329 controls, annual evidence, the heaviest reporting tier short of a full Report on Compliance. Your agent workstation, your call recordings, your CRM, your network, and any paper forms all sit inside the cardholder data environment, and every one of those becomes something you have to document and audit. If you route the capture through a PCI-certified provider so card data never reaches you — DTMF masking, channel separation, agent-assisted — you drop to SAQ A, which is around 22 controls. PCI DSS v4.0.1 sharpened the language on this further: any system component that can affect the security of cardholder data is in scope, so a recording system that captures DTMF tones counts even if it never stores the digits as text.

PSD2 and Strong Customer Authentication are EU/UK rules, not US ones, so SCA isn't a compliance lever here the way it is in Europe. Where US MOTO does get tangled is in state wiretap and recording-consent law. Eleven states — California, Florida, Illinois, Maryland, Massachusetts, Michigan, Montana, Nevada, New Hampshire, Pennsylvania, Washington — require all-party consent before you can record a call. The rest are one-party. Recording itself is generally fine if you announce it and get the consent your state requires. The bigger problem is what's inside the recording: a captured PAN is cardholder data, and a captured PAN sitting in a recording that's been pulled into a dispute file or shared with a TCPA defense counsel is cardholder data that's spread further than you'd like.

Where 3DS2can be brought in for a US MOTO transaction — typically when the customer has a mobile to hand during the call and can approve a step-up on their banking app — using it gives you the liability shift you'd otherwise be missing. We apply 3DS2 wherever it's available and fall back to fraud-screening rules where it isn't, so the transactions most likely to dispute later get extra scrutiny up front.

For healthcare merchants, HIPAA sits over the top of PCI. When a patient calls to settle a copay, the call audio contains both payment data and protected health information — diagnosis codes, plan IDs, treatment references — and your recording becomes a combined PCI + HIPAA artifact. The cleanest answer is to keep the card capture off the recording entirely and to operate the payment leg under a Business Associate Agreement with whoever processes the card. We sign BAAs for the healthcare merchants we work with, and DTMF masking pulls the PAN out of the audio before it ever reaches your recording, so the recording stays HIPAA-compliant on the PHI side without leaking PCI on the payment side.

How to take MOTO payments without absorbing the risk

The principle is simple: if the card number never reaches your environment, almost none of the risk reaches it either. Your agents can't leak data they never had, your recordings can't capture tones they never received, your CRM can't store digits nobody typed into it, and your QSA has 22 controls to look at instead of 329. The whole modern MOTO stack is built around getting card capture out of the parts of your business where it doesn't belong.

On the phone leg, the right answer for almost every contact center is DTMF masking. The customer types their card on their own phone keypad. Each tone is intercepted and replaced with a flat sound before it reaches your agent or your recording system. The agent stays on the call the whole time, talks the customer through it, and confirms the result when authorization comes back. From the customer's side it feels like any normal phone payment. From your auditor's side, the audio has no card data in it.

Channel separation takes the same idea a step further on calls where the agent shouldn't be in the room with the digits at all. The card capture happens on a separate audio path that bypasses the agent's line entirely. Useful for higher-value transactions, regulated industries, and anywhere the threat model includes the agent themselves. Agent-assisted sits between the two — the agent keeps the call going, the customer keys the card, and the agent sees only a masked progress indicator on screen.

For mail-order and email-order workflows, the answer is to stop accepting card details in writing at all. We send the customer a secure payment link by SMS or email; they tap through to a hosted payment page in our PCI environment, type the card themselves, and the confirmation lands back in your system as a token plus an authorization code. The order form on your end never sees a card number. The same flow handles refunds, top-ups, and ad-hoc payment requests without you ever opening an email that contains a PAN.

Where the card goes once we've captured it depends on what you already have. We pass the authorization request straight to your existing processor — Stripe, Chase Payment Solutions, Braintree, Authorize.Net, Adyen, Worldpay (US), whichever — so your pricing, your settlement, and your reporting don't move. What does move is what gets stored where. We tokenizethe card inside our vault and return a token your systems can use for refunds, repeat charges, or anything else you need to do with that customer later. The real PAN never leaves our environment. The agent never sees it. The recording never hears it. The CRM never stores it. That's what good looks like for a 2026 MOTO operation.