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 relabelled 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.

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

Endpoint

POST .../payments

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"
  },
  "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

If encrypted-card submission is enabled for the integration, send paymentMethod.paymentCardEncrypted instead of paymentMethod.paymentCard. In order to use paymentMethod.paymentCardEncrypted, you will need to get a RSA public key from our gateway.
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.

Example response

The fields returned depend on the acquiring route. The following response is illustrative.

{
  "type": "transactionResponse",
  "clientRequestId": "b58ab2d7-a421-4d37-a4c0-8c93f024bb2a",
  "apiTraceId": "<api-trace-id>",
  "ipgTransactionId": "<ipg-transaction-id>",
  "orderId": "ORDER-20260826-0001",
  "transactionType": "SALE",
  "transactionOrigin": "MOTO",
  "transactionResult": "APPROVED",
  "approvedAmount": {
    "total": 49.90,
    "currency": "EUR"
  },
  "processor": {
    "responseCode": "00",
    "responseMessage": "APPROVED",
    "authorizationCode": "<authorization-code>"
  }
}

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.