Token binding

Overview

Token binding starts when the token requestor sends a request to the TSP.

The issuer gateway then sends Request Device Binding to the issuer backend.

Compared with VTS, MDES provides extra data that can help the issuer backend make a decision:

• scoringInformation

  • This field has the same meaning as in a Tokenization request.

  • Use it to refine the decision.

• recentAuthenticationInformation

  • Use this field when recent end user authentication should influence the decision.

For MDES, deviceBindingReference in Request Device Binding is not the final reference.

MDES sends the final deviceBindingReference only in the success notification after cardholder verification.

The sequence diagram below shows the end-to-end flow.

...

If the issuer returns approve with step-up authentication, use the section for the selected ID&V method.

Information

If the issuer responds to the Request Device Binding with an approve with step-up but without providing the list of ID&V methods to support, the issuer gateway will call the issuer backend with the API Get IDnV Method List to retrieve it.

To avoid this, systematically return the list of ID&V methods if the decision is to step-up.

After all interactions are complete, the issuer gateway sends a Notify Virtual Card Change notification with:

• action for the confirmation performed:

  • DEVICE_BOUND

  • DEVICE_UNBOUND

• deviceBindingReference, which is the unique binding reference (of course if the bind was successful).

• authenticatorInfo, which contains details about the method that will be used to authenticate the cardholder for the subsequent transactions. This data will be also sent in the authorization request of the payment transaction.

Verify with an OTP

The TSP generates the OTP.

The issuer gateway forwards it through Send OTP, as in the Tokenization flow.

Use otpMethodId to identify the selected method and prepare the correct message and channel.

The sequence diagram below shows the flow.

...

The TSP verifies the OTP and notifies the relevant parties when verification succeeds.

Verify in the issuer application

In this flow, the issuer verifies the end user in the issuer application.

You can trigger the issuer application in two ways.

Trigger from the token requestor application

This approach matches the Tokenization flow used for token activation.

The interaction is the same as Integrate issuer application with wallet.

The TSP also sends additional data that the issuer must parse to identify the token binding context:

• Visa

  • deviceID

  • deviceIndex

  • lifeCycleTraceID

  • reasonCode = TOKEN_DEVICE_BINDING

• Mastercard

  • authenticationCorrelationId

These fields are specific to post-Tokenization verification.

Trigger with a push message

This option is supported only by Mastercard.

The issuer triggers the issuer application through a push message.

If the end user selects this method, the issuer gateway sends the method ID through Send OTP without an OTP value.

MDES does not generate an OTP for this flow.

Use otpMethodId to identify the method and build the push message.

Report the verification result

Regardless of the trigger method, the issuer must report the result to the TSP through Update Card State.

Send these values:

• virtualCardId =

  • Visa: tokenReferenceID

  • Mastercard: tokenUniqueReference

• deviceBindingReference

  • For Visa, use deviceIndex

  • For Mastercard, use authenticationCorrelationId

• action

  • APPROVE_DEVICE_BINDING when cardholder verification succeeds

  • UNBIND_DEVICE when cardholder verification fails

The sequence diagram below shows the full flow.

...

If token binding succeeds, the issuer can later unbind the token from the device.

This option is available only for Visa tokens.

Call Update Card State with:

• virtualCardId set to the target token ID

• deviceBindingReference set to the stored binding reference

• action set to UNBIND_DEVICE