Mail/Telephone Order Transactions

Overview

MOTO (Mail Order/Telephone Order) transactions are widely used by our clients, where merchants typically collect card details over the phone. Since the card holder is not physically present, these transactions are treated as Card Not Present (CNP).

MOTO transactions can be keyed into an ID TECH SRED device, PayConex™ virtual terminal, or the hosted payment forms.

The devices offer an enhanced level of security by encrypting card data at the point of entry on the hardware level, ensuring that sensitive information is protected throughout the transaction process. This is particularly important for merchants looking to comply with PCI DSS requirements, to minimize the risk of data breaches, and to reduce PCI scope. There is no need to worry about security configurations for the firewalls, anti-viruses and all of the infrastructure that plays a role in reducing PCI scope.

Overall, MOTO transactions provide a flexible and secure way for merchants to accept payments in situations where customers are not physically present. They are a vital tool in a variety of business contexts.

IDTECH SREDKey devices support both swiped and keyed payloads but when it comes to MOTO transactions, keyed payloads are the main focus.

In the context of PayConex™, this is how we refer to these two types of MOTOs:

• P2PE MOTO via SRED devices implementing Decryptx® for encryption/decryption. Swiped page and PayConex™ V4 API fall into the P2PE type of MOTO. This workflow follows PayConex™ and Decryptx® where the POS systems are treated as the SREDKey device.
• MOTO via the keyed page where ShieldConex® takes care of tokenization/detokenization, following the ShieldConex® workflow. This is usually a scenario where a call center is using a digital capture mechanism.

📘

Note

P2PE MOTO is well suited to merchants who prefer to keep the card off the network or the PC completely, as the payload is encrypted on hardware-level before reaching either. These merchants include call centers and back-office applications.

P2PE MOTO

The SRED devices are very basic terminals into which you key a card number, emulating USB keyboard input. A device is plugged in via USB, the merchant is prompted with a keyboard and after the data is inputted, the device encrypts the card data and prints it out in a text editor or a text field that is currently focused.

Swiped Page

In the case of a swiped page, the device populates the card tracks field on the swiped page that is focused and waiting for the card reader input.

PayConex™ V4 API

P2PE MOTO can also be processed via the V4 API with the following request payload. This scenario is intended to be used in a back-office application or similar.

POST /api/v4/accounts/{accountId}/payments/device-sale

{
  "amounts": {
    "currency": "USD",
    "total": "10.00"
  },
  "card": {
    "p2pe": {
      "cardTracks": "redacted"
    }
  },
  "device": {
    "app": "IDTECH",
    "appVersion": "0-22-4-dev-debug",
    "mode": "standalone",
    "osVersion": "22:5.1.1",
    "serial": "T140900006",
    "type": "A920"
  },
  "deviceProfile": "IDTECH",
  "entryMode": "KEYED",
  "posProfile": "P2PE_MOTO",
  "tenderType": "CREDIT"
}

*Required Scopes: pcx:payments:*, pcx:payments:device:*, pcx:payments:device:sale

📘

Note

*redacted: where cardTracks is printed out by the device as explained above.

P2PE MOTO can also be set to a recurring payment schedule via the PayConex™ Portal UI or via the PayConex v3.8 API SLAPI. Alternatively, the merchant, as a large ISV, can reuse the vaulted reissuing token returned in the response of the CIT.

For details on the body parameters, see Card Present Request Parameters and Entry Modes.

Note that Card Present transactions can be KEYED. In these situations, the card is not physically read in any way.

Keyed Page

A regular MOTO transaction can be processed digitally via a virtual terminal. This can be achieved on the keyed page in the PayConex™ Portal as shown below. This process uses ShieldConex® instead of Decryptx® to securely handle the data.

PayConex™ Hosted Payment Forms

This feature is turned on by Bluefin, providing merchants with the ability to create customizable hosted forms for payment collection. These forms basically function as the keyed or swiped page components and are used externally without a log-in.

Once this feature is activated, merchants can easily generate a secure link to share with their customers, directing them to the hosted form to complete their payment. This is particularly useful for businesses that need a simple, secure and efficient way to collect payments remotely, whether through email, text message or other digital communication channels.

📘

Reusability

The payment forms can be reused by the customer as many times as desired, unless the merchant removes them.

Creating a form

Creating a form involves a wide range of settings from general payments options to appearance layout.

For example, the merchant can specify the posProfile and the type of payment.

Payment Collection

The merchant clicks on the Preview button to get the link to the form.

After completing the form, the customer is redirected to the page with the payment status, the user-defined logo, the success message, and the total amount processed.