INTEGRATION

Getting Started

TRANSACTION ASSURANCE

Tokenization

INTEGRATION

Tokenization

The network tokenization endpoints provide a gateway into Mastercard Secure Card on File (SCOF) and Visa Token Service (VTS), giving the merchant the possibility to safely store a digital version of the card of their customer. Once stored, the endpoints also provide a way to manage tokens and receive updates to allow an uninterrupted sequence of transactions to be processed.

To make use of the Network Tokenization endpoints, a merchant first needs to be enrolled for SCOF and VTS which can be done by submitting a Create Enrollment request.

Additionally, to fully utilise the token service functionality, configure an event subscription or “tokens”. This will allow you to receive update notifications on the tokens and ensures you have the most up-to-date information for processing transactions.

The full lifecycle for Network Tokenization exists of the following steps:

  • Enroll Merchant

  • Create a Token

  • Create a Token Cryptogram

  • Token Transaction Processing

Create a Token

When the enrollment is active, you are able to create tokens by submitting the required card data to the Create Token endpoint. This is an a-synchronous process, where we allow users of the service to create network tokens in bulk. Note that it is optional to provide the CVC data, but we highly recommend to do so, as this can positively impact issuer response. Furthermore, a PAN can be tokenized once per merchant.

Get a Token

Use the Get Token endpoint to fetch the created token, the result contains mostly meta data about the token. As soon as the status is active the network token is enabled for processing transactions. From that moment, transactions can be processed with the token. Important to mention is that the version increments when lifecycle updates for the token are received, for example:

  • The status of the token has been changed by the issuer.

  • The token information changes (e.g. due to an underlying PAN update of the expiration date).

  • The card metadata changes (e.g. when the card art changes).

Get Token Data

The Get Token Data endpoint provides you with the actual network token credentials that can be used instead of the physical PAN information for processing a charge. The token data is interoperable across the card network ecosystem, meaning that acquirers and issuers should accept these network tokens as substitutes for physical PANs. The Payment Account Reference is also provided as a part of the payload on this endpoint, as this reference allows you to ‘link’ various tokens that link to a specific PAN.

When token data is updated we provide a notification through the event subscription.

Create a Token Cryptogram

In addition to the token data, the token cryptogram can be obtained by the Create Token Cryptogram to validate and authenticate the network token for processing a charge. We cache token cryptograms to make sure we limit the latency impact in a check-out flow for a charge, and automatically update the token cryptogram we cache as soon as we receive a token refresh notification. The response from the endpoint will contain the following:

Specific for the processing of transactions with the token it is important to know when you should provide a tokenCryptogram for the first transaction in a sequence. To help with this, we provide the lastTokenRefresh parameter to allow you to determine whether you need a new tokenCryptogram or not for the following subsequent MIT transaction.

The instructions for providing a cryptogram are as follows;

  • For all standard purchase charges with the network token, a new tokenCryptogram needs to be provided.

  • For all first charges that utilise the network token in a recurring sequence, the tokenCryptogram needs to be provided.

  • For all first subsequent merchant-initiated charges after a token refresh, a new tokenCryptogram needs to be provided.

Example 1. When a merchant decides to safely store the cardholder data as a network token, with the purpose of processing “one-click” charges, each of these transactions will need a new tokenCryptogram to be submitted for authorization.

Example 2. After the successful authorization of an initial charge of a sequence with the PAN, the first following subsequent MIT transaction makes use of the tokenData instead of the PAN and needs a tokenCryptogram to be submitted for authorization. When, after for example 3 years of subsequent charges, a token-refresh notification is received, the first following subsequent transaction after that notification needs a tokenCryptogram to be provided.