HomeProduct DocsAPI ReferenceChangelog
RecurlyAPI GuidesRecurly.jsWebhooksAPI ReferenceSupportBook demo
Product Docs
RecurlyAPI GuidesRecurly.jsWebhooksAPI ReferenceSupportBook demo

MOTO transactions

An overview of Mail Order / Telephone Order (MOTO) transactions in Recurly, including supported gateways, compliance considerations, and configuration steps.

MOTO (Mail Order / Telephone Order) transactions let you or your agents accept and process payments on behalf of customers — without the customer being present at a digital checkout. This page covers what MOTO is, when to use it, how to configure it, and the compliance boundaries you need to stay inside.
Available on all Recurly plans
1Definition 2Key benefits 3Key details 4Configure MOTO transactions 5FAQs

Definition

MOTO (Mail Order / Telephone Order) transactions allow businesses or agents to accept billing information and process payments on behalf of customers in a card-not-present scenario. MOTO applies when you or your agents are entering billing details directly — for example, through the Recurly Admin UI, or via the API for transactions processed through a custom-built internal checkout page — once the feature is enabled on your account.

Key benefits

Better experience for more customers Support customers who prefer to place orders by phone or mail, meeting them where they are and reducing friction in the payment process.
Broader payment channel coverage Expand beyond standard digital checkouts to reach customer segments who aren't transacting online, without adding a separate payment stack.
Wide gateway support MOTO is supported by a broad range of prominent gateways, making it straightforward to enable within your existing payment setup.

Key details

MOTO indicators are reserved for specific use cases: one-time, customer-initiated transactions using fresh billing details entered by the merchant into a system the customer typically doesn't access — such as a back-office system or virtual terminal.

PSD2 and SCA complianceMOTO indicators must not be used improperly in regions where PSD2 and Strong Customer Authentication (SCA) are compliance requirements. Recurring transactions are never classified as MOTO — they follow their regular processing course.

Supported gateways

Many gateways support MOTO transactions, including Adyen, Braintree, Chase Orbital, Cybersource, Stripe, and WorldPay. Before enabling MOTO, confirm your gateway supports it for your specific use case.

Adyen noteAdyen supports MOTO transactions, but may require you to complete additional documentation before enabling the feature. Check with your Adyen account contact to confirm any requirements before proceeding.

Configure MOTO transactions

Gateway configuration

Before enabling MOTO in Recurly, confirm that your gateway has MOTO transactions enabled on your account.

1

Contact your gateway

Reach out to your gateway provider and confirm that MOTO transactions are enabled for your account.

2

Complete any required documentation

Some gateways require additional paperwork before MOTO can be activated. Complete this step before proceeding to avoid processing errors.

Recurly configuration

Once your gateway is configured, enable MOTO in Recurly from the Payment Gateways settings. This step applies to supported gateways only.

1

Navigate to Payment Gateways

In the Recurly Admin UI, go to Configuration → Payment Gateways.

2

Open the gateway settings

Select Options → Edit for the appropriate gateway instance.

3

Enable MOTO transactions

Select Enable MOTO transaction and save your changes.

Gateway RoutingIf you're using Gateway Routing, make sure you're routing to the correct MOTO-enabled gateways to avoid processing errors.

FAQs

Can I use MOTO transactions when a customer is active on my website?

No. When a customer is in session on your website, that transaction is considered customer-initiated and is subject to PSD2 and SCA compliance mandates where applicable. Classifying these transactions as MOTO could result in regulatory fines from the card brands.
How do I process a MOTO transaction through Recurly?

If you're integrating with Recurly via API from your back office, classify your transactions through the /purchase endpoint using the transaction_type parameter set to MOTO.

You can also add billing information and create invoices directly in the Recurly Admin UI. When doing this, create an invoice and charge it immediately — do not create subscriptions or invoices that are collected at a later date. Transactions processed directly by customers on your website, and recurring subscriptions, should never be classified as MOTO.
What's the difference between MOTO and Unscheduled Card on File MIT transactions?

MIT (Merchant Initiated Transactions) occur without direct customer interaction — for example, processing a transaction on a pre-approved schedule outside a subscription environment, such as a top-up or resubmission scenario.

MOTO, by contrast, is driven by direct customer interaction (such as a phone call or email), but the actual transaction is entered and processed by the business on the customer's behalf.