How it works

Pay encrypts cardholder's details during an initial payment for secure storage, and provides you with a non-sensitive identifier for the details known as a "token". A cardholder can save multiple tokens. Pay is responsible for PCI DSS compliant storage of the cardholder's details.

Initial payment

Make sure to enable tokenization in the configuration of your sales location. Navigate to Settings > Sales location and scroll down to the Card not present card and click on Optimize your configuration. Make sure to enable Tokenization (see screenshot below) and set the 3D secure policy settings.

Save the settings and start an initial creditcard payment with the Order:Create API. The the transaction is not directly captured, make sure to also capture the transaction.

After a captured card transaction, we call your exchange endpoint with a tokenexchange. See here for the full payload of this exchange call. Make sure to store at least the recurring_id, since this is the token that you need to use when initiating a recurring payment.

Recurring payments using the token

Create the recurring payment using the token

To actually create the recurring payment, use our Card Payment authorize API.

The following recipe gives you a step-by-step walkthrough of the payload

Type of transaction for recurring payments

Merchant Initiated Transaction

If the Merchant is initiating the transaction, we call it a Merchant Initiated Transaction (MIT). The cardholder is not involved in the process, so no 3D secure verification can be done. For example to pay the monthly subscription membership fee. But also a MOTO (mail order/telephone order) transaction is Merchant initiated and can be performed with tokenization.

Customer initiated Transaction

If the Cardholder initiates the transaction, we call it a Customer Initiated Transaction (CIT). For instance in an ecommerce purchase. In that case the tokenization payment is used for a seamless checkout, but if the issuer is declining the transaction because of signs of fraud there can be a step-up to 3D secure.

MOTO

If the transaction is a MOTO (mail order/telephone order) transaction, the cardholder is supplying his data on the phone. Therefore the cardholder is also not involved in the actual payment process, so no 3D secure verification can be done

POS

If the transaction is a POS (card present) transaction, the cardholder is present. If the issuer is declining the transaction due to signs of fraud there can be a step-up to 3d secure.

ECOM

In an ecommerce purchase the cardholder is present. In that case the tokenization payment is used for a seamless checkout, but if the issuer is declining the transaction because of signs of fraud there can be a step-up to 3D secure.