According to article 7 “Requirements of the elements categorized as possession” of the RTS on SCA & CSC “1. Payment service providers” shall adopt measures to mitigate the risk that the elements of strong customer authentication categorized as possession are used by unauthorized parties” and “2. the use by the payer of those elements shall be subject to measures designed to prevent replication of the elements”.

Tokenisation is the process of substituting sensitive data such as the card details with a value that is non-sensitive and has no exploitable meaning. This value, the token, can be used in order to process the payment without actual card details being exposed while these are held safe in a secure token vault or a device secure component based on implementation-specific methods and according to security best practices.

Tokenisation on payment processing is a security measure that has not been developed in order to provide authentication means to the payer but to mitigate risks derived from keeping actual card details from environments where data can be vulnerable and, if breached, used for illegal purposes.

Tokenisation on payment processing can be used in various use cases that may cover Card-Present (CP) and/or Card-non-Present (CnP) transactions and typically fall into the following broad categories:

A. Digital wallets that can facilitate CP transactions through close proximity at the POS and/or CnP transactions such as e-commerce or in-app transactions:

Typically, in these cases the token issuance process involves interaction of the cardholder with a token service provider and a card issuer via the digital wallet and the token resides on the payer’s device (e.g. secure element, host card emulator) in order to facilitate close proximity at POS payments.

CnP transactions such as e-commerce or in-app transactions may utilise either the token that resides on the consumer’s device or a token that resides on a shared storage that merchants can interact with by implementation-specific methods.

Consumer access to the payment token may be controlled either by the consumer device itself or a digital wallet app that will require consumer credentials.

B. Card-on-File (CoF) transactions that are used to facilitate CnP transactions such as one-click orders and in-app transactions:

Typically in these cases the cardholder maintains a relationship with a merchant (mobile or web) and the merchant is the one that triggers the token issuance process following the consent of the cardholder. The token is bound to both the cardholder and the merchant and is restricted in its usage to the specific token acceptance environment (e-commerce platform or merchant application) and may also add further restrictions based on the specific device or certain transaction types.

The token may reside on the merchant’s environment or on a shared storage that merchants can interact with by implementation-specific methods.

Consumer access to the payment token will require consumer credentials associated with the merchant’s platform.

Tokenisation on payments processing is also used widely in order to facilitate Merchant Initiated Transactions (MIT) following a mandate that has been given from the payer to the payee through an SCA process. As already clarified in a previous Q&A 2018_4031 transactions initiated on the basis of such a mandate can be qualified as payee initiated transactions, provided that those transactions do not need to be preceded by a specific action of the payer to trigger their initiation by the payee.