MOTO payments: processing, risk, and secure voice design

What are mail order/telephone order (MOTO) payments?

MOTO payments are card-not-present (CNP) transactions because the card is not read from a chip, contactless interface, or magnetic stripe in the merchant's physical presence. The Payment Card Industry Security Standards Council (PCI SSC) names e-commerce and MOTO as CNP transaction types in FAQ 1319. A phone call alone does not determine the transaction code. The merchant must use a MOTO-enabled flow and follow its processor's and acquirer's rules.

A traditional telephone-order payment starts when a customer calls a business, agrees to a purchase, and provides payment instructions remotely. An employee might enter the card into an approved virtual terminal, or the call might move to a dedicated payment system. A mail-order payment starts from a paper form or other accepted postal instruction and follows an approved MOTO entry path.

Both are card-not-present because the merchant cannot use the physical card's chip or contactless security features. The transaction still needs the correct channel indicators, merchant configuration, and required data for the particular processor and acquirer.

MOTO is a payment classification, while "pay by phone" describes an experience. One call can end in a MOTO transaction, an e-commerce checkout, a stored-card payment, or no card transaction at all.

MOTO vs. interactive voice response (IVR), e-commerce, card-present, and saved-card flows

These flows can look similar to the caller and still create different technical, fraud, and reporting obligations.

An IVR can be part of a MOTO implementation. The term does not prove that the payment leg is isolated or correctly coded. A hosted checkout link may move the payment into an e-commerce channel. A charge to a saved method may be a customer-initiated transaction when the customer confirms it during the call, while a later scheduled charge may be a merchant-initiated transaction. The processor and acquirer must confirm the right treatment for each flow.

How MOTO payment processing works

A reliable MOTO transaction separates order taking, credential capture, payment authorization, and fulfillment.

1. The merchant establishes the order. The system resolves the customer, items or payable balance, amount, currency, delivery terms, and refund policy from trusted records.
2. The customer gives explicit payment instructions. The merchant records consent and the order details needed for customer service or a possible dispute, without adding sensitive card data to ordinary notes.
3. The approved payment path captures credentials. A virtual terminal, supported device, or specialized telephone-payment provider receives the primary account number (PAN), expiration date, and any permitted authorization data.
4. The processor sends an authorization request. The request moves through the acquiring side and card network to the issuer. The issuer approves or declines it based on account status, available funds or credit, and risk signals.
5. The merchant records the result. The order system receives a provider status and non-sensitive reference. A decline ends the attempt or triggers an approved alternative. An unknown result triggers reconciliation before any retry.
6. Capture, clearing, and settlement follow. Depending on the integration, capture may happen with authorization or later. Clearing exchanges transaction records, and settlement moves funds between financial institutions.

Authorization is only an approval stage. It does not prove the caller's identity, guarantee settlement, or prevent a later dispute. Visa's payment lifecycle separates authentication, authorization, clearing, and settlement for this reason.

Who is responsible for what?

Outsourcing credential capture changes the data path. The merchant still retains its own responsibilities.

Merchant

The merchant owns the sale and customer relationship. Its responsibilities commonly include:

• using a merchant account and payment flow enabled for the right transaction type;
• confirming amount, currency, goods or services, fulfillment terms, and customer consent;
• protecting every system, person, and record within its actual card-data environment;
• applying the agreed fraud controls and following approval and decline responses;
• retaining non-sensitive order, consent, delivery, refund, and dispute evidence;
• monitoring service providers and completing the required Payment Card Industry Data Security Standard (PCI DSS) validation; and
• reconciling authorizations, captures, refunds, settlement, and disputes.

Processor or gateway

The processor or gateway supplies the payment interface and transaction connection. Depending on the provider, it may offer a virtual terminal, tokenization, authorization and capture APIs, fraud checks, status events, settlement reporting, and dispute tooling. The merchant should document which controls the provider operates and obtain evidence that covers the service actually used.

Acquirer

The acquirer connects the merchant to card-network acceptance, either directly or through other processing partners. It commonly sets or enforces merchant acceptance terms, pricing, risk monitoring, reserves, reporting, and dispute handling. The compliance-accepting entity, typically a payment brand or acquirer, determines the merchant's PCI DSS validation and reporting methods. A Qualified Security Assessor (QSA) validates that the assessment scope and applicable PCI DSS requirements are accurately defined and documented. PCI SSC guidance explains this division.

The issuer approves or declines the cardholder's transaction and handles the cardholder side of a dispute. Card networks carry messages and define operating rules. The merchant's processor and acquirer turn those rules into the concrete requirements for its account.

Fraud, declines, disputes, and fees

MOTO lacks the physical-card checks available through chip and contactless acceptance. A stolen card number can therefore be presented without the card. An approval confirms only that the issuer accepted the authorization request. It does not show that the sale is genuine.

Use layered controls supported by the processor and appropriate to the order:

• authenticate the customer through approved account or out-of-band controls before exposing account details;
• apply amount, velocity, customer, product, and delivery limits server-side;
• use address verification service (AVS), card verification values (CVV), or other provider-supported checks where appropriate;
• route unusual orders to review or an independently sourced callback path;
• give the customer a clear receipt and use a recognizable statement descriptor; and
• prevent fulfillment when the durable payment state is declined, cancelled, or still unknown.

No single check makes MOTO fraud-proof. A CVV response, AVS match, processor risk score, or authorization can reduce uncertainty under defined rules. None guarantees that a transaction cannot be disputed. Card verification values are sensitive authentication data and must never be stored after authorization, even when encrypted, as PCI SSC FAQ 1319 explains.

A dispute may concern unauthorized use, duplicate processing, an incorrect amount, missing goods, cancellation, refund handling, or an unrecognized merchant name. Keep the exact consent, order, fulfillment, and communication records permitted by your policies, without retaining card secrets. Send dispute evidence through the processor or acquirer within its deadlines. Visa's merchant dispute guide notes that an issuer returns a contested transaction through the acquirer and that the merchant may need timely supporting documentation.

If a cardholder sees an unfamiliar charge labeled MOTO, they should contact their card issuer promptly through a trusted channel, such as the number on the back of the card, and follow the issuer's fraud or dispute process.

MOTO fees vary by country, network, merchant category, volume, provider, and risk profile. Build the cost model from the processor and acquirer's rate schedule for the exact MOTO configuration. Include every contractual line item that applies, such as interchange, network assessments, processor or acquirer markup, gateway or terminal charges, cross-border or currency costs, dispute fees, and reserves. Do not assume that web, keyed-entry, MOTO, and point-of-sale rates are interchangeable.

PCI controls for telephone and mail orders

PCI DSS scope follows the real data path. Systems that store, process, or transmit cardholder data, along with systems that can affect the security of the card-data environment, may be in scope. For telephone orders, map the call media, telephony and Session Initiation Protocol (SIP) infrastructure, agent desktop, IVR/DTMF service, speech recognition, recordings, transcripts, prompts, tools, webhooks, customer relationship management (CRM) system, logs, analytics, exports, backups, and support access.

Use these design rules:

1. Keep raw credentials out of general conversation systems. Do not ask a caller to speak a full PAN or card verification value to a general voice agent. Keep them out of prompts, transcripts, recordings, tool payloads, traces, and CRM notes.
2. Use an isolated capture surface. New-card entry belongs in a processor-hosted checkout, a specialized telephone-payment environment, or a supported protected terminal. Confirm what transaction channel that handoff creates.
3. Prevent sensitive recording at the source. PCI SSC says every effort must be made to prevent sensitive authentication data from being recorded, with suppression or redaction enabled where the necessary technology exists. If it is recorded, delete it securely immediately after authorization. Compensating controls apply only when immediate secure deletion is not feasible for a legitimate technical or business reason. That path requires documented justification, risk analysis, protective and access controls, and validation during the PCI DSS assessment. See the current audio-recording guidance.
4. Minimize retained cardholder data. Store provider tokens and masked display values only where policy permits. Tokenization can reduce exposure. Token properties, detokenization access, network reachability, and segmentation still determine scope. The PCI SSC's 2011 tokenization information supplement explains that tokenization systems and connected components can remain in scope based on their access and role. It does not replace current PCI DSS requirements.
5. Control mail-order paper. Limit who can receive and enter forms, secure them before processing, never retain card verification values after authorization, and destroy card data under an approved retention process.
6. Manage provider responsibility. Maintain written responsibility boundaries, review relevant provider compliance evidence, and monitor its status. PCI SSC confirms that outsourcing all payment processing does not remove the merchant's duty to protect account data and validate its own compliance.

A hosted processor, encryption, a recording mute control, or a token does not by itself prove that the wider environment is out of scope. The merchant should map the complete deployment and confirm its validation path with its acquirer, payment brand, and assessor.

A secure production-voice architecture

The safest role for a production voice agent is to manage conversation and order state while an isolated payment provider manages credentials. With Dasha, we run the conversation in our managed voice runtime. The agent can retrieve an order through a narrow HTTPS tool, explain the exact charge, collect explicit confirmation, and ask the merchant backend to use an eligible provider-tokenized saved method. Our conversational path receives only a minimal status and opaque payment reference.

The boundary looks like this:

Caller
  -> Dasha voice conversation: identity step, order, amount, consent
  -> Merchant backend: authorization, policy, order lock, payment attempt
  -> Payment provider: tokenized method, authorization, capture
  -> Signed provider event: durable result
  -> Merchant order system: fulfillment, receipt, reconciliation
  -> Dasha voice conversation: confirmed non-sensitive outcome

The merchant backend is authoritative. It should load the customer, amount, currency, order version, and permitted payment method from trusted storage. The model should not choose or rewrite these values. A confirmation token should bind the caller's consent to one short-lived transaction snapshot. Any change to the amount, currency, order, or payment method invalidates that consent.

Give each logical attempt a durable internal record and a stable idempotency key. Lock the order against concurrent attempts. If the payment API times out, query the known payment object and reconcile provider events before retrying. Processor idempotency retention can be finite, so the merchant's database must prevent a later retry from becoming a second charge. Verify signed webhooks where available, handle duplicates and out-of-order delivery, and make the order database the source of truth. Our production-readiness checklist covers these retry, reconciliation, observability, and fallback controls in more detail.

Map provider states to a small vocabulary the agent can use safely: confirmed, declined, processing, additional action required, already paid, or unavailable. A tool timeout remains unavailable until reconciliation proves otherwise. The voice agent should never infer success from a conversational fallback.

For a new card, transfer the payment leg to a supported hosted page, specialized IVR/DTMF service, or protected terminal. A human handoff still needs an approved capture surface. Warm transfer controls call routing behavior; it does not establish PCI card-capture compliance.

We do not currently publish PCI DSS card-capture support or DTMF masking, and we do not present Dasha as a payment processor or PCI-validated card-capture environment. Do not route spoken card credentials through our general voice path. The actual deployment still requires review with the merchant's processor, acquirer, security team, and PCI adviser or QSA.

Production checklist

Before launch, confirm that:

• the processor and acquirer have enabled and classified every payment flow;
• customer, order, amount, currency, and payment eligibility come from trusted records;
• the caller confirms the exact transaction and masked method;
• raw PAN and card verification values cannot enter general audio, transcripts, prompts, tools, logs, analytics, or backups;
• new-card capture uses an approved isolated provider path;
• one logical payment has one locked, durable attempt record;
• unknown outcomes are reconciled before a retry;
• signed events drive durable payment and fulfillment state;
• decline, processing, cancellation, refund, dispute, and secure-handoff paths are tested;
• fraud limits and independent review or callback rules are active;
• consent and fulfillment evidence excludes sensitive card data;
• service-provider responsibilities and evidence cover the services in use; and
• the compliance-accepting entity has confirmed validation and reporting methods, and the assessor has validated scope and applicable PCI DSS requirements for the actual deployment.

MOTO payment processing is manageable when the transaction classification, credential boundary, and failure states are explicit. If you are building that conversational layer for production, explore Dasha's voice AI backend and keep payment credentials inside the provider-controlled path.