Token verification

The token verification flow applies to tokens created for card-on-file (COF) or e-commerce use.

In this case, the token is usually created without additional verification beyond basic card validation. The token is stored by the TSP rather than provisioned to a device.

A merchant can trigger token verification to increase the trust level of a token.

Visa and Mastercard support this flow under different names:

• Visa: Cloud Token Framework (CTF)

• Mastercard: Post-Tokenization Authentication for Secure Card on File and Click to Pay

There are two token verification request types:

1. Bind a token to a device or passkey. Because the e-commerce token is cloud-based, binding lets the merchant use device capabilities to secure token transactions and limit token use to a specific device. This increases the trust level of the token.

2. Request cardholder verification. An end user logged in to a merchant app or website may perform sensitive actions, such as changing an email address or password. If the account has stored payment methods, the merchant can request cardholder verification to confirm that the end user is the cardholder.

In both cases, the issuer backend returns a decision, as it does for a tokenization request:

• green: approve

• yellow: approve with step-up authentication

• red: decline

The following table summarizes the effect of each decision for each request type:

Decision	Binding request	Cardholder verification request
green — approve	The merchant associates the payment token with the device.	The merchant treats the result as confirmation of the cardholder identity and approves the requested account change.
yellow — approve with step-up authentication	The merchant presents the supported ID&V methods to the end user. The merchant performs no association until it receives confirmation of the verification result.	The merchant presents the supported ID&V methods to the end user. The merchant performs no action until it receives confirmation of the verification result.
red — decline	The merchant performs no association.	The merchant performs no action.

If the decision is yellow, the issuer must provide the list of ID&V methods that can authenticate the cardholder.

Because ID&V is performed in real time, do not use customer service as an ID&V method. Mastercard does not support this method.

Across payment networks, the issuer should support the following ID&V methods when available:

ID&V method types	Visa	Mastercard
cell_phone	Same as tokenization	Same as tokenization
email	Same as tokenization	Same as tokenization
push	Not applicable	See details below
bank_app	Same as tokenization	Same as tokenization + push trigger mode is available

Mastercard supports two additional methods that apply only to post-tokenization authentication:

• push: The issuer sends an OTP in a push message that opens the issuer application. The issuer must add this new type in the list of ID&V methods to use in case of step-up.

• bank_app: The issuer can send a push message that opens the issuer application. No OTP is generated. To support this method, the issuer must add the type bank_app in the list of ID&V methods to use and then assign to the value = PUSH_NOTIFICATION.

These methods improve the interaction between the merchant and the end user.