1. What is tokenisation?

1.1. Definition


Tokenisation is the practice of encrypting a card number and returning a token representing the payment card to the merchant. The token can be used to process the initial transaction as well as any subsequent recurring or stored-card payments. The partially masked card number and expiry date are returned to the merchant alongside the token. This enables the merchant to identify a card without viewing its full number. As no raw card data is stored by the merchant, less stringent PCI compliance requirements (SAQ-A or SAQ-A-E) apply. 


In other words, tokenisation is the ability to save card data without having to save card data. Merchants typically don’t want to maintain high-levels of PCI compliance, and without doing so, they cannot store the full cardholder data even if they are storing it encrypted. This means that merchants without the right level of PCI compliance would only be able to store the masked card data, which is composed of the first 6 digits of the card, the last 4, the expiry month and year, and the card scheme. However they would not be able to store the full 16 digits of the PAN. 


This is when tokenisation comes into play, as it allows merchants to save card data without having to maintain high levels of PCI compliance and to save card tokens against a customer’s profile for future uses.




1.2. General uses of tokenisation

Tokenisation is a widely-used tool - such as in the below examples;

  • No-show fees are a very common use for tokenisation, especially in the hospitality industry. For example, when a reservation is made, certain restaurants may request your card number to be entered when booking. Your card is then tokenised to be used for the penalty fees in the event of a no-show.  

  • Another example includes hotel incidentals such as room service; the hotel may use the customer’s card token to pay for the extras if they are not paid for at checkout.  

  • Tokens can be used for various types of transactional flagging such as MIT (Merchant-Initiated Transactions) or recurring transactions. 

  • A token can essentially be used for a transaction where the customer is not actively present to process the card payment (e.g. e-commerce transactions) and where the customer is present but the merchant does not want them to re-enter their card details. If the customer is present, we usually refer to this type of transactions as CIT (Customer Initiated Transaction).


In the case of a CIT where the token has already been created, the merchant would send an APEXX payment request using the token, but the transaction would have to go through the 3DS flow if the merchant is in Europe.


 NOTE 

The difference between MIT / recurring transactions and CIT is that in any 3DS-mandated markets (e.g. Europe), the merchant should always try to authenticate CIT transactions , even if the card is stored. For MIT / recurring, only the first transaction needs to be authenticated. 





2. How does tokenisation work at APEXX?


2.1.  Creating APEXX tokens



APEXX tokens are composed of 32-character unique identifier which represent the card. A token is returned to the merchant when it is requested in the request via a specific flag - create_token=true - which indicates that the merchant has requested the creation of a token for the card used by the customer. In the response, APEXX would then send a value called “token” which is 32-character long. 


To use the token, the merchant sends a server-to-server request with the token only (i.e. there is no need for any other card data). APEXX will be then able to identify the actual card details in our token store, decrypt the data, and use that data for the downstream authorisation request, as if we had been sent the actual card data in the first place. 




2.2. Token creation methods


There are 3 methods in which a token can be created:

  • a payment request

  • Virtual terminal tokenisation

  • standalone token creation



  • Token creation in the payment request

A token can be created in the payment request,  regardless of whether it is done via a Hosted Payment Page (HPP) request, direct request, or Client-Side Encryption (CSE) request. 


 NOTE 

You can request a token from APEXX in the initial payment message. This applies to both the direct (createCardTransaction), and hosted payment page (hostedPaymentPage) methods. 

As long as the dedicated flag of create_token = true, a token will be created by APEXX for merchants to store. This method is highly recommended as the primary method for token creation as it takes place during an actual transaction thus allowing the merchant to check that the card is real and that it can have payments taken against it. This method can be used to create tokens with zero value or nominal authorisations.



  • Standalone token creation

Merchants have the option to create tokens outside of a transaction, however contrary to the token created during the payment request, the only information that can be verified is that the card has a valid BIN, and a valid format. However, the merchant would not be able to know whether the card is real. This method is not encouraged, as we always recommend the tokens to be created as part of the payment flow. 


To generate a token using a standalone API request, merchants may send the card details in a createCardToken request. APEXX will return a token for the merchant to store.



  • Virtual Terminal tokenisation

In the APEXX Virtual Terminal (see dedicated article here), merchants have the ability to tokenise the card when a transaction is created via Pay to be used for future transactions. This avoids having the customer on the phone dictating their card number for each purchase.


2.3. Can tokens be deleted?

Merchants can use the deleteToken request to delete a previously generated token. After the previous token has been deleted for a given card number, APEXX will return a new token for the card. 


2.4. Can tokens be shared within the merchant’s organisation?

Yes - the scope of a token extends across the entire organisation in APEXX to which a merchant belongs, up to parent level. Merchants that are not part of the same organisation as the merchant that generated a token will not be able to share it. 


Tokens that were generated through the APEXX tokenisation can be used across multiple acquirers and channels. 

2.5. Are tokens sent in the webhook notifications? 

Tokens are not included in webhook notification responses for security reasons. Tokens are only transmitted in API responses. However, you can use the getTransactionDetails request to retrieve the token for an existing transaction from APEXX. 


3. Using tokens in MIT or recurring transactions

 

In an APEXX context, the token can only be requested at the authorisation point - whether the transaction is captured immediately or not does not matter. A token cannot be requested at the point of capture, it can only requested at authorisation. 

Tokens as explained above can be used in various transactional types like MIT or recurring. However there are a few rules to follow when using a token in conjunction with these transactional flagging.


To use a token in a MIT or a recurring transaction: 

  • the merchant should have previously done an initial CIT at the point of token creation. where the transaction has been authenticated. For token creation that happens at the authorisation stage, it is necessary to go through 3DS in 3DS-mandated markets (e.g. Europe). 
  • to use the token in an MIT / recurring transaction, the merchant should send the correct flag (either MIT or recurring) as well as the token.


If the token is sent without the correct flag, the transaction would most likely be declined with the SCA required by issuer message. 


When a token is created as part of the authorisation, APEXX then gets an authorisation response back from the scheme or the acquirer, which contains a reference called the Scheme Transaction ID or the Network Transaction ID. That reference is a link to the authenticated transaction and it is stored by APEXX against the token. When a merchant sends the token and an MIT or recurring flag, APEXX will send the card data as well as the original transaction ID (i.e. the network transaction ID) in an authorisation request for the MIT or recurring transaction. As such, there will be no need to go through the 3DS flow again for the new MIT / recurring transaction. 


 NOTE 

if the card expires, the token could become redundant as APEXX does not currently use account updater services. Card details can be sent to the account updater service of Visa or Mastercard, for example, and they will provide the updated credentials so that the token can be updated.


4. Enabling token creation with APEXX


Tokenisation can be enabled for all your organisation or for parts of it -  this depends on your business requirement.


If you would like to enable tokenisation or Virtual Terminal tokenisation, please talk to your Relationship Manager (relationshipmanagement@apexx.global) if you are a live merchant or to your Implementations Manager if you are an onboarding merchant.