Update the digital card assurance level

Use this flow to increase a digital card's assurance level after Tokenization.

It applies to tokens used for card-on-file (COF) and e-commerce use cases. Unlike proximity-payment tokens, these tokens are stored by the payment network TSP. They are not provisioned to a device.

Merchants typically request token verification before a sensitive action or before they bind a token to a device or passkey.

Supported payment network flows

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

Verification request types

There are two token verification request types:

1. Bind a token to a device or passkey. Because the token is cloud-based, binding lets the merchant use device capabilities to secure token transactions and restrict token use to a specific device. Binding increases trust because it requires cardholder verification on the target device. The same token can be bound to multiple devices, but each device usually requires cardholder verification.
2. Request cardholder verification. An end user logged in to a merchant app or website may perform a sensitive action, such as changing an email address or password. If the account stores payment methods, the merchant can request cardholder verification to confirm that the end user is the cardholder. This flow is not yet supported by Mastercard.

What D1 does

In both cases, D1 orchestrates the flow on behalf of the issuer. The issuer backend does not need an additional workflow.

The issuer backend only needs to return end user details when requested. D1 then selects the available ID&V methods on behalf of the issuer.

Issuer obligations

Regardless of the selected integration model, the issuer must provide end user details and keep them accurate.

D1 uses this data to build the list of ID&V methods.

Decision outcomes

For each request, D1 returns the decision value expected by the payment network TSP:

• green: approve
• yellow: approve with step-up authentication
• red: decline

D1 manages the decision on behalf of the issuer.

D1 does not return green for these requests.

This process increases the assurance level of an e-commerce token that usually receives initial approval because the card details are valid.

Supported ID&V methods

If the decision is yellow, step-up authentication is required. D1 adds the supported ID&V methods to the decision returned to the payment network TSP.

D1 supports these methods:

• ID&V using an OTP sent by SMS or email
• ID&V through the issuer application

Prerequisites for ID&V methods

The issuer must meet these prerequisites so D1 can manage the available ID&V methods:

1. End user contact details are available.
2. The issuer configuration set during D1 onboarding includes:

   1. the supported ID&V methods
   2. if the OBO option is enabled, the SMS and email templates
   3. if the OBO option is not enabled, an implementation of the Deliver OTP API

The OBO option must match the Tokenization configuration.

The ID&V model used for Tokenization also applies to token verification.

High-level flow

The following diagram shows the parties and the main steps in a token verification request:

Token verification flow and involved parties

Depending on the end user's selection, verification uses an OTP or the issuer application.

OTP verification by SMS or email

OTP verification flow by SMS or email.

Verification by issuer application

Verification flow through the issuer application.

Integration between the merchant application and the issuer application in step 9 is out of scope for Thales.

Use the same scheme guidance that applies to a Tokenization flow. For simplicity, see Integrate in-app ID&V. The only additional requirement is to handle the extra data that identifies the originating use case.

In particular:

• Visa adds the following data compared with a Tokenization flow:

Field	Binding request	Cardholder verification request
deviceID	ID assigned to the device	-
deviceIndex	Reference to the device	-
reasonCode	TOKEN_DEVICE_BINDING	CARDHOLDER_STEPUP
lifeCycleTraceID	Unique ID tracking the request	Unique ID tracking the request

• Mastercard adds the following data compared with a Tokenization flow:

Field	Binding request	Cardholder verification request
authenticationCorrelationId	Unique ID tracking the request	Not applicable

Next steps

• For device binding, see Token binding.
• For cardholder verification, see Cardholder verification flow.