Mail Order / Telephone Order (MOTO)

When to use MOTO

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

Do not use MOTO for:

• a customer entering card details on a website or mobile application;
• a face-to-face transaction in which the cardholder is present; or
• an e-commerce transaction relabelled as MOTO to avoid authentication requirements.

MOTO availability depends on the merchant, store, terminal, card brand, currency, and acquiring agreement. A message that is valid against the nexo schema can still be rejected when MOTO or manual card entry is not enabled.

Supported nexo messages

MOTO purchase, preauthorisation, and card-verification transactions use the normal Acceptor Authorisation flow.

The MOTO fields do not replace the standard header, environment, protected card data, transaction type, amount, currency, or message-security fields required by the selected operation.

Choose the correct MOTO profile

Use the exact channel value agreed during onboarding. Do not send MOTO, PHONE, or another descriptive value in TxChanl; the nexo values are MAIL and TLPH.

Common payment-context fields

Both profiles use the following fields in the Acceptor Authorisation Request:

Example payment contexts:

<!-- Mail Order -->
<Cntxt>
  <PmtCntxt>
    <CardPres>false</CardPres>
    <CrdhldrPres>false</CrdhldrPres>
    <TxChanl>MAIL</TxChanl>
    <CardDataNtryMd>PHYS</CardDataNtryMd>
  </PmtCntxt>
</Cntxt>

<!-- Telephone Order -->
<Cntxt>
  <PmtCntxt>
    <CardPres>false</CardPres>
    <CrdhldrPres>false</CrdhldrPres>
    <TxChanl>TLPH</TxChanl>
    <CardDataNtryMd>PHYS</CardDataNtryMd>
  </PmtCntxt>
</Cntxt>

Element order matters in nexo XML. In PmtCntxt, place TxChanl before CardDataNtryMd, as shown.

Mail Order request

A Mail Order request identifies the channel as MAIL, includes the cardholder billing address, and does not include a CVD authentication block.

Mail Order-specific fields

Mail Order fragment

Add the following blocks to the normal caaa.001.001.06 request. Existing acquirer, merchant, POI, protected-card-data, transaction, and security elements are omitted here for clarity.

<AuthstnReq>
  <Envt>
    <!-- Acquirer, merchant, POI, and protected card data go here. -->
    <Crdhldr>
      <BllgAdr>
        <AdrLine>Example Street 10</AdrLine>
        <PstCd>12345</PstCd>
        <TwnNm>Example City</TwnNm>
        <Ctry>DE</Ctry>
      </BllgAdr>
    </Crdhldr>
  </Envt>
  <Cntxt>
    <PmtCntxt>
      <CardPres>false</CardPres>
      <CrdhldrPres>false</CrdhldrPres>
      <TxChanl>MAIL</TxChanl>
      <CardDataNtryMd>PHYS</CardDataNtryMd>
    </PmtCntxt>
  </Cntxt>
  <Tx>
    <!-- Standard purchase, preauthorisation, or card-verification fields go here. -->
  </Tx>
</AuthstnReq>

The address above is fictional. Replace it with the actual billing address and follow the field requirements agreed for the merchant. When BllgAdr is present in nexo 6, TwnNm and the two-letter Ctry code are required by the schema.

Telephone Order request

A Telephone Order request identifies the channel as TLPH. Billing address data can be included, and CVD can be supplied when it is collected and permitted.

Telephone Order-specific fields

Do not send an empty CSCV authentication block. If CVD is not collected and the merchant profile permits its omission, omit that Authntcn occurrence entirely.

Preparing the protected CVD

1. Convert the CVD to binary-coded decimal (BCD).
2. For an odd number of digits, add trailing hexadecimal F padding. For example, CVD 123 becomes the bytes 0x12 0x3F before encryption.
3. Encrypt the result using the same key, algorithm, and padding profile agreed for protected card data.
4. Place the encrypted value and its key metadata in PrtctdAuthntcnVal with CnttTp set to EVLP.

Telephone Order fragment

The following is a structural example. Replace the protected-value placeholders with a complete envelope generated by the integration's existing card-data encryption implementation.

<AuthstnReq>
  <Envt>
    <!-- Acquirer, merchant, POI, and protected card data go here. -->
    <Crdhldr>
      <BllgAdr>
        <AdrLine>Example Street 10</AdrLine>
        <PstCd>12345</PstCd>
        <TwnNm>Example City</TwnNm>
        <Ctry>DE</Ctry>
      </BllgAdr>
      <Authntcn>
        <AuthntcnMtd>CSCV</AuthntcnMtd>
        <PrtctdAuthntcnVal>
          <CnttTp>EVLP</CnttTp>
          <EnvlpdData>
            <!-- Rcpt/KEK: use the agreed protected-card-data key profile. -->
            <!-- NcrptdCntt/NcrptdData: use the encrypted BCD CVD. -->
          </EnvlpdData>
        </PrtctdAuthntcnVal>
      </Authntcn>
    </Crdhldr>
  </Envt>
  <Cntxt>
    <PmtCntxt>
      <CardPres>false</CardPres>
      <CrdhldrPres>false</CrdhldrPres>
      <TxChanl>TLPH</TxChanl>
      <CardDataNtryMd>PHYS</CardDataNtryMd>
    </PmtCntxt>
  </Cntxt>
  <Tx>
    <!-- Standard purchase, preauthorisation, or card-verification fields go here. -->
  </Tx>
</AuthstnReq>

If no billing address is sent and the merchant profile allows that, omit the complete BllgAdr element rather than sending empty address fields.

Response handling

Always evaluate the authorisation result independently from the address and CVD verification results.

Authorisation result

Read the payment decision from:

Document/AccptrAuthstnRspn/AuthstnRspn/TxRspn/AuthstnRslt/RspnToAuthstn/Rspn

Typical values include APPR, PART, and DECL. Do not treat a successful address or CVD check as payment approval.

Address and CVD verification results

The response can contain multiple TxVrfctnRslt occurrences:

Document/AccptrAuthstnRspn/AuthstnRspn/TxRspn/TxVrfctnRslt

Match each occurrence by Mtd; do not depend on its position in the response.

Rslt can contain SUCC, FAIL, MISS, NOVF, PART, or ERRR. The exact result and whether it affects authorisation depend on the acquiring route and merchant configuration.

Illustrative response fragment:

<TxRspn>
  <AuthstnRslt>
    <RspnToAuthstn>
      <Rspn>APPR</Rspn>
    </RspnToAuthstn>
  </AuthstnRslt>
  <TxVrfctnRslt>
    <Mtd>CSCV</Mtd>
    <Rslt>SUCC</Rslt>
  </TxVrfctnRslt>
  <TxVrfctnRslt>
    <Mtd>ADDB</Mtd>
    <Rslt>SUCC</Rslt>
  </TxVrfctnRslt>
</TxRspn>

Only expect verification entries for checks that were performed and returned by the acquiring route.

MOTO is not the same as a card-present manual-entry transaction

Both flows can use CardDataNtryMd=PHYS, but the presence and channel fields are different.

Classify the transaction according to the real interaction with the cardholder. Do not change these values merely to pass validation or authentication rules.