Token binding

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

The issuer gateway receives the request from the TSP and then sends Request Device Binding to the issuer backend.

For MDES, the deviceBindingReference in the Request Device Binding does not represent the final reference associated to the bind data.

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 sections below 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 between the token and the device (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 (NOTE: this is supported only by Mastercard).

After a 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

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 TSP verifies the OTP and notifies the relevant parties when verification succeeds.

The sequence diagram below shows the flow.

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 described already by Integrate issuer application with wallet with the difference that the TSP 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. There is no overlap with the classic tokenization verification.

Trigger with a push message

The issuer triggers the issuer application through a push message.

This option is supported only by Mastercard and it applies only to the post-tokenization authentication. Essentially, when providing the list of ID&V methods, the issuer must provide still a method of the type bank_app and assign to the value = PUSH_NOTIFICATION.

If the method is selected, the issuer can send a push message that opens the issuer application.

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 triggering method used to interact with the application, 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.

Verify by 3DS

This is supported only by Visa.

If the issuer wants support this method, a proper configuration must be set on VTS. This is not managed through API.