Mail Order / Telephone Order (MOTO)

This guide explains how to submit card-not-present Mail Order and Telephone Order transactions through the Payments REST API.

When to use MOTO

Use a MOTO origin only when a merchant employee receives payment details remotely, for example by telephone or from a mail-order form, and enters the payment on the customer's behalf.

Do not classify the following as MOTO:

a customer entering card details on a website or mobile application; use ECOM;
a face-to-face payment made with a physical terminal; use the relevant card-present flow;
a transaction relabeled as MOTO only to avoid customer authentication requirements.

MOTO is a card-not-present transaction. Its availability, accepted card brands, currencies, limits, and card-verification requirements depend on the merchant's onboarding and acquiring agreement.

Supported transaction origins

Set transactionOrigin explicitly on every MOTO primary transaction.

Value	Use
`MOTO`	Combined Mail Order or Telephone Order classification. Use this when the merchant setup does not distinguish the two channels.
`MAIL`	The order was received by mail.
`PHONE`	The order was received by telephone.

If transactionOrigin is omitted, the request is treated as e-commerce rather than MOTO.

Endpoint

POST {baseUrl}/payments

Use the base URL supplied for the target certification or production environment.

Card sale request

Use PaymentCardSaleTransaction for a sale with card details. The request must contain an explicit MOTO origin.

Do not use PaymentTerminalSaleTransaction for MOTO. That request type is for card-present terminal transactions and accepts RETAIL origin only.

{
  "requestType": "PaymentCardSaleTransaction",
  "transactionAmount": {
    "total": 49.90,
    "currency": "EUR"
  },
  "transactionOrigin": "MOTO",
  "merchantTransactionId": "MOTO-20260826-0001",
  "order": {
    "orderId": "ORDER-20260826-0001",
    "billing": {
      "name": "Example Cardholder",
      "address": {
        "address1": "1 Example Street",
        "city": "Frankfurt",
        "postalCode": "60311",
        "country": "DE"
      }
    }
  },
  "paymentMethod": {
    "paymentCard": {
      "number": "<card-number>",
      "expiryDate": {
        "month": "12",
        "year": "28"
      },
      "securityCode": "<card-security-code>"
    }
  }
}

To distinguish the order channel, replace MOTO with MAIL or PHONE as agreed during onboarding. Do not change the request type.

Request fields

JSON path	Presence	Description
`requestType`	Mandatory	Use `PaymentCardSaleTransaction` for a card sale.
`transactionAmount.total`	Mandatory	Total transaction amount as a JSON number.
`transactionAmount.currency`	Mandatory	Three-character alphabetic or numeric ISO 4217 currency code.
`transactionOrigin`	Mandatory for MOTO	Use `MOTO`, `MAIL`, or `PHONE`. Omitting it causes the request to be treated as e-commerce.
`paymentMethod.paymentCard.number`	Mandatory for a plain-card request	Payment card number. Handle and transmit it only in accordance with PCI DSS requirements.
`paymentMethod.paymentCard.expiryDate.month`	Mandatory for a normal card payment	Two-digit month from `01` to `12`.
`paymentMethod.paymentCard.expiryDate.year`	Mandatory for a normal card payment	Two-digit year.
`paymentMethod.paymentCard.securityCode`	Conditional	Three- or four-character card security code. Send it only when collected and permitted for the transaction. Never store it after authorization.
`merchantTransactionId`	Optional, recommended	Merchant reference of up to 40 characters for reconciliation.
`order.orderId`	Optional, recommended	Merchant order reference. The gateway generates one when it is omitted.
`order.billing.address.address1`	Conditional, recommended for AVS	Cardholder billing street supplied for Address Verification Service (AVS). AVS availability depends on the acquirer, issuer, card scheme, and merchant setup.
`order.billing.address.postalCode`	Conditional, recommended for AVS	Cardholder billing postal code supplied for AVS.
`order.billing.address.country`	Conditional	Billing country in an accepted ISO 3166-1 format. Supply it when required by the route or onboarding rules.
`storeId`	Conditional	Outlet identifier for applications authorized to submit transactions for multiple stores.

If encrypted-card submission is enabled for the integration, send paymentMethod.paymentCardEncrypted instead of paymentMethod.paymentCard. Do not send both representations.

Token-based MOTO sale

When the merchant is authorized to reuse a previously created payment token, use PaymentTokenSaleTransaction and keep the MOTO origin explicit.

{
  "requestType": "PaymentTokenSaleTransaction",
  "transactionAmount": {
    "total": 49.90,
    "currency": "EUR"
  },
  "transactionOrigin": "PHONE",
  "merchantTransactionId": "MOTO-20260826-0002",
  "order": {
    "orderId": "ORDER-20260826-0002"
  },
  "paymentMethod": {
    "paymentToken": {
      "value": "<payment-token>"
    }
  }
}

The token must be valid for the submitting store or an authorized related store. Supply tokenOriginStoreId, an updated expiry date, card function, or security code only when required for the token type and merchant setup.

Preauthorization

For a preauthorisation, use PaymentCardPreAuthTransaction or PaymentTokenPreAuthTransaction with the same explicit transactionOrigin.

{
  "requestType": "PaymentCardPreAuthTransaction",
  "transactionAmount": {
    "total": 49.90,
    "currency": "EUR"
  },
  "transactionOrigin": "MAIL",
  "merchantTransactionId": "MOTO-20260826-0003",
  "order": {
    "orderId": "ORDER-20260826-0003"
  },
  "paymentMethod": {
    "paymentCard": {
      "number": "<card-number>",
      "expiryDate": {
        "month": "12",
        "year": "28"
      },
      "securityCode": "<card-security-code>"
    }
  }
}

A successful preauthorization reserves funds; it does not complete the purchase. Submit a linked PostAuthTransaction to capture it, or a linked void when the authorization should be released. Preauthorization and completion must be enabled for the merchant.

Transaction response

The fields returned depend on the request type, payment method, acquiring route, and data supplied by the issuer. Fields that are not available can be omitted. The following approved card-sale response is illustrative.

{
  "type": "transactionResponse",
  "clientRequestId": "b58ab2d7-a421-4d37-a4c0-8c93f024bb2a",
  "apiTraceId": "<api-trace-id>",
  "ipgTransactionId": "<ipg-transaction-id>",
  "orderId": "ORDER-20260826-0001",
  "merchantTransactionId": "MOTO-20260826-0001",
  "transactionType": "SALE",
  "transactionOrigin": "MOTO",
  "transactionTime": 1787731200,
  "transactionAmount": {
    "total": 49.90,
    "currency": "EUR"
  },
  "transactionResult": "APPROVED",
  "transactionState": "CAPTURED",
  "approvedAmount": {
    "total": 49.90,
    "currency": "EUR"
  },
  "approvalCode": "<gateway-approval-code>",
  "schemeTransactionId": "<scheme-transaction-id>",
  "processor": {
    "referenceNumber": "<processor-reference-number>",
    "responseCode": "00",
    "responseMessage": "APPROVED",
    "authorizationCode": "<authorization-code>",
    "network": "<card-network>",
    "associationResponseCode": "<issuer-response-code>",
    "avsResponse": {
      "streetMatch": "Y",
      "postalCodeMatch": "N"
    },
    "securityCodeResponse": "MATCHED"
  }
}

Fields to retain and evaluate

JSON path	Meaning and merchant handling
`transactionResult`	Primary operation result. Use this for programmatic decision-making; HTTP `200` alone does not mean that the payment was approved.
`transactionState`	Gateway lifecycle state when returned. An approved sale normally reaches `CAPTURED`; an approved preauthorization normally reaches `AUTHORIZED`. Do not treat a non-final state as completed fulfilment.
`transactionAmount`	Amount submitted for the transaction.
`approvedAmount`	Amount actually approved. Compare its amount and currency with the requested values, especially when partial approval is enabled. It can be absent when no amount was approved.
`clientRequestId`	Echo of the request header. Retain it for idempotency checks and support investigations.
`apiTraceId`	API trace identifier used by support to locate request processing logs.
`ipgTransactionId`	Gateway transaction identifier. Store it for inquiry and linked post-authorization, void, or return operations.
`orderId` / `merchantTransactionId`	Merchant-facing reconciliation identifiers. The gateway can generate `orderId` when it was not supplied.
`transactionTime`	Transaction time expressed as Unix epoch seconds.
`approvalCode`	Gateway-level approval information. Do not parse message-like content as a stable decision interface.
`schemeTransactionId` / `transactionLinkIdentifier`	Conditional scheme identifiers used for eligible card-on-file or linked transaction flows. Preserve them when returned.
`paymentMethodDetails` / `paymentToken`	Conditional masked payment-method or token information. Never expect the response to return a full card number or security code.
`processor.referenceNumber`	Processor reference useful for reconciliation and support.
`processor.authorizationCode`	Authorization code returned for an approved authorization when supplied by the processor. This is distinct from the top-level `approvalCode`.
`processor.responseCode` / `processor.responseMessage`	Processor result details. Codes are route-specific and message text can change; do not use the message as the sole decision field.
`processor.associationResponseCode` / `processor.associationResponseMessage`	Raw issuer or card-scheme response details when provided. Interpret them using the response-code reference for the configured acquiring route.
`processor.avsResponse`	Conditional Address Verification Service result. See the AVS section below.
`processor.securityCodeResponse`	Conditional normalized result of the card security-code check. See the security-code section below.
`processor.cardholderInfoResponse`	Conditional enhanced cardholder-information checks, including postal code, address, name, telephone, and email results. The raw association value is specific to the supporting scheme and route.
`schemeResponseCode`, `merchantAdviceCode`, and processor merchant-advice fields	Conditional scheme response and retry/advice information. Interpret them using the configured route's response-code documentation rather than message text.

transactionStatus can appear in older responses, but it is deprecated in the current contract. New integrations should use transactionResult.

Transaction result values

Value	Meaning	Merchant action
`APPROVED`	The requested operation was approved.	For a sale, verify the expected `approvedAmount` and, when returned, a final `transactionState` such as `CAPTURED` before fulfilment.
`PARTIAL`	Only part of the requested amount was approved.	Continue only if partial approval was explicitly enabled and the merchant flow can collect the remaining amount; otherwise do not fulfil as fully paid.
`WAITING`	Processing has not reached a final result.	Keep the order pending and use transaction inquiry rather than assuming success or failure.
`CREATED`	A transaction record was created but the financial outcome is not final.	Keep the order pending and continue the required flow or inquiry.
`DECLINED`	The transaction was declined.	Do not fulfil. Present a neutral customer message and retain the response identifiers.
`FAILED`	Processing failed.	Do not fulfil. Record the error and trace identifiers and investigate or retry only according to the integration policy.
`FRAUD`	The transaction was rejected by fraud controls.	Do not fulfil and follow the merchant's fraud-handling policy.

Address Verification Service response

For eligible card transaction responses, processor.avsResponse compares the supplied billing street and postal code with issuer-held data. Include order.billing.address.address1 and order.billing.address.postalCode when AVS is required. Sending the address does not guarantee that AVS will be performed: support and behavior depend on the issuer, scheme, processor, region, and merchant configuration.

Field or value	Meaning
`streetMatch: Y`	The street matched.
`streetMatch: N`	The street did not match.
`postalCodeMatch: Y`	The postal code matched.
`postalCodeMatch: N`	The postal code did not match.
`NO_INPUT_DATA`	The corresponding value was not available as input for the check.
`NOT_CHECKED`	The corresponding value was not checked. This is not a successful match.
`associationAvsResponse`	Raw issuer or scheme AVS code. Its values are route-specific; use the developer portal or acquirer response-code reference for the configured route.

The whole avsResponse object, an individual normalized field, or the raw association code can be absent when no value is returned. Treat absence as unknown, not as a match. AVS is a risk signal rather than the payment decision: an APPROVED payment can contain a mismatch, and a match does not by itself mean that the payment was approved. Apply the merchant's agreed fraud policy separately from transactionResult.

Card security-code response

processor.securityCodeResponse is also conditional. The API never returns the submitted security code itself.

Value	Meaning
`MATCHED`	The security code matched.
`NOT_MATCHED`	The security code did not match.
`NOT_PROCESSED`	A result was not processed.
`NOT_PRESENT`	No security code was present for the check.
`NOT_CERTIFIED`	The issuer or route was not certified for the check.
`NOT_CHECKED`	The security code was not checked.

An omitted securityCodeResponse means that no normalized result was returned. Do not interpret omission, NOT_PROCESSED, NOT_PRESENT, NOT_CERTIFIED, or NOT_CHECKED as MATCHED. As with AVS, the security-code response is a verification signal and does not replace transactionResult.

3-D Secure and MOTO

Setting transactionOrigin to MOTO, MAIL, or PHONE identifies the transaction channel. It does not initiate 3-D Secure.

Genuine MOTO transactions are normally treated differently from customer-initiated e-commerce transactions under authentication rules.
The exact regulatory and acquiring treatment depends on the market and merchant agreement. Do not classify an e-commerce payment as MOTO to bypass 3-D Secure or Strong Customer Authentication.