# Push Provisioning to Merchant with Authentication
source: https://developer.mastercard.com/mdes-token-connect/documentation/use-cases/push-to-merchant-auth/index.md

Available for Use By:

* Issuers
* Issuer Processors
* Online \& Mobile Banking Vendors
* Merchant

Regional Availability:

* Global

## Scenario {#scenario}

Susan opens her issuer's mobile banking app to check her account balance. She sees there is a new service available that lets her load her payment cards or account into leading digital wallets and merchants. Susan likes the convenience of making purchases online and with apps using her mobile phone. And she uses a merchant mobile application on her mobile phone for online purchase. So she decides to opt in to the new service and loads her card into her favorite merchant. She can now shop knowing her purchases are convenient and secure.

![alt text](https://static.developer.mastercard.com/content/mdes-token-connect/documentation/use-cases/img/CompleteFlow_new.png "Scenario")

## Pre-requisite {#pre-requisite}

* Consumer sign-in to the mobile banking app and selects the card to provision.

## User Experience {#user-experience}

1. [Issuer fetches eligible token requestors.](https://developer.mastercard.com/mdes-token-connect/documentation/use-cases/push-to-merchant-auth/index.md#fetch-eligible-token-requestors)
2. [Consumer chooses card(s) and destination in issuer interface.](https://developer.mastercard.com/mdes-token-connect/documentation/use-cases/push-to-merchant-auth/index.md#consumer-selects-cards-and-destination-in-issuer-interface)
3. [Consumer is redirected to token requestor.](https://developer.mastercard.com/mdes-token-connect/documentation/use-cases/push-to-merchant-auth/index.md#consumer-is-sent-to-merchant-or-commerce-platform-interface)
4. [Consumer returns to issuer app with provisioning confirmation.](https://developer.mastercard.com/mdes-token-connect/documentation/use-cases/push-to-merchant-auth/index.md#consumer-sees-confirmation-in-issuer-interface)

### Fetch Eligible Token Requestors {#fetch-eligible-token-requestors}

Before consumers can begin to provision their payment cards and accounts you'll need to display a consumer-friendly list of eligible Token Requestors to which consumers can push their account to.

* When enabled for Token Connect, you must retrieve from MDES the Token Connect parameters of each Token Requestor for which you have enabled your account range(s) in MDES.
* Periodic maintenance of Token Requestor information is required, and it is recommended that you perform a refresh bi-weekly.

#### Integration {#integration}

![alt text](https://static.developer.mastercard.com/content/mdes-token-connect/documentation/use-cases/img/retrieves-token-requestor-data.png "Integration")

1. Fetch the details of the Token Requestors with your enabled account range(s) by sending applicable accountRanges to the [getEligibleTokenRequestors](https://developer.mastercard.com/mdes-token-connect/documentation/api-reference/index.md) request. MDES returns information about eligible Token Requestors in the response including:
   * the user-friendly name for the Token Requestor;
   * the type of Token Requestor (wallet or merchant);
   * **the authentication information of the Token Requestor (merchant supports Consent Service)**
   * the imageAssetID - the reference of the Token Requestor logo to display to the consumer.
2. Retrieve the logo of each eligible Token Requestor by sending the *imageAssetID* in a [getAsset](https://developer.mastercard.com/mdes-token-connect/documentation/api-reference/index.md) request. MDES supplies the Token Requestor logo in two formats: .SVG (rescalable) and .PNG (192 x 192 pixels). The images are square with a white background.
3. Cache the details of the eligible Token Requestors and their logos in your back-end server.

### Consumer selects Card(s) and Destination in Issuer Interface {#consumer-selects-cards-and-destination-in-issuer-interface}

The consumer logs into your online or mobile banking app and navigates to an area where they can see information about the features and benefits of push provisioning. They are invited to select the card(s) they wish to push provision. Note that financial accounts may also be eligible for push provisioning. Next, they select from a list of available merchants, digital wallets and commerce platforms.

![alt text](https://static.developer.mastercard.com/content/mdes-token-connect/documentation/use-cases/img/MerchantSelection.png "Integration")

### User Experience Design Guidelines {#user-experience-design-guidelines}

Request the consumer to select one or more card(s) or financial account(s).

Present the list of Token Requestors to which consumers can push their card(s) or financial account(s) for tokenization.

* **Token Requestor Logo**
* **Token Requestor Name:** the user-friendly name for the Token Requestor
* **Token Requestor Type:** digital wallet or merchant

Request the consumer to select one Token Requestor (wallet or merchant) from this list.

#### Integration {#integration-1}

![alt text](https://static.developer.mastercard.com/content/mdes-token-connect/documentation/use-cases/img/user-selects-token-requestor-and-cards.png "Integration")

1. The consumer is logged in their Issuer app/web site.
2. While navigating, they select the target Token Requestor as well as the card or account to push.
3. The Issuer app or browser calls the Issuer back-end with consumer's choice.
4. Using MDES Token Connect API, the Issuer contacts MDES to request the push of the selected card(s) or account(s) to the target Token Requestor. The Issuer may append account holder data (for instance, billing address) to the request, if supported by the Token Requestor. Issuer append callbackURL, locale information to include in signature. If the request is valid, MDES generates and returns a pushAccountReceipt(s) -- a string voucher valid for the next 15 minutes to be used by the target Token Requestor for the tokenization of the card(s) or account(s). MDES returns signature. MDES also returns the URI(s) of the available interface(s) for this Token Requestor.
5. The Issuer returns the pushAccountReceipt and the URI(s) to the Issuer interface on the device.
6. The Issuer interface selects the most appropriate URI corresponding to the device environment, and appends dynamic parameters to this URI, among others:
   * the pushAccountReceipt of the card or account being pushed. If the Token Requestor supports multiple cards/accounts pushed simultaneously, multiple pushAccountReceipts may be appended
   * the callback URL: the Issuer URL that the Token Requestor must call out upon completion of tokenization to return the consumer to the Issuer's interface where they started their journey
7. The Token Requestor validates signature from the redirection URL.

The Issuer interface calls out the resulting URI, and as a result, the consumer is taken to the Token Requestor's interface (app or website).

### Consumer is sent to Merchant or Commerce Platform Interface {#consumer-is-sent-to-merchant-or-commerce-platform-interface}

The merchant or commerce platform website or app is launched. The consumer experience now mostly depends on the Token Requestor's implementation.

* **If necessary, the consumer *logs in or signs up* to the Token Requestor's app or web site. This allows the Token Requestor to associate a valid customer account with the card or account being pushed.**
* Upon successful log in, the Token Requestor proceeds with the tokenization of the payment card or account
* **If the tokenization decision is "REQUIRE_ADDITIONAL_AUTHENTICATION" and the issuer supports consent service then the token requestor must complete authentication flow.**
* The Token Requestor may display a confirmation before sending the consumer back to your Issuer interface

In the example below, the Token Requestor is a Merchant, and the consumer must accept the Merchant's Terms and Conditions if displayed. The Issuer requires additional cardholder authentication \& merchant supports cardholder authentication, and the Merchant Interface displays a confirmation before returning the consumer to the Issuer interface.

![alt text](https://static.developer.mastercard.com/content/mdes-token-connect/documentation/use-cases/img/Tokenization_Auth.png "Integration")

#### Integration {#integration-2}

![alt text](https://static.developer.mastercard.com/content/mdes-token-connect/documentation/use-cases/img/merchant-token-requestor_auth.png "Integration")

1. The Token Requestor interface asks the consumer to **sign in or sign up**.

2. The Token Requestor interface calls out the Token Requestor back-end to complete sign in/up and to pass the pushAccountReceipt.

3. The Token Requestor requests tokenization with MDES. The only difference with a 'regular' tokenization initiated from the Token Requestor's interface is that the enciphered account data is replaced by the pushAccountReceipt that was supplied by the Issuer. MDES matches the pushAccountReceipt with the account data that was supplied by the Issuer. The Issuer receives the tokenization authorization message.

4. \*\*If the issuer supports Consent Service and looking for authentication for this tokenization; the issuer must set token authorization decision as "REQUIRE_ADDITIONAL_AUTHENTICATION" and pass activation method(s) from below

   * TEXT_TO_CARDHOLDER_NUMBER (with masked mobile number as value)
   * EMAIL_TO_CARDHOLDER_ADDRESS (with masked email address as value) \*\*
5. \*\*If the token requestor and issuer both support consent service and the decision is "REQUIRE_ADDITIONAL_AUTHENTICATION" then the token requestor must display authentication screen to consumer to select a way to receive authentication code with retry option.
   Note: supportsAuthentication flag value is true in the tokenize response if an issuer supports Consent Service
   \*\*

6. **On selection of channel to receive authentication code by consumer; the token requestor initiate authentication using SRC service with "ADD_CARD" as reason code**

7. **MDES generates authentication code and notifies the issuer through Consent service (Activation Code Notification or Deliver Activation Code) with the reason code.**

8. **The issuer shares authentication code to the consumer**

9. \*\*After receiving authentication code from the consumer; the token requestor completes the authentication using SRC service.

10. **On successful authentication; MDES upgrade Token Assurance**

11. The Token Requestor appends the list of pushAccountReceipt, with their respective results, to the callback URL that the Issuer interface had provided. The Token Requestor calls out the resulting URI, and as a result the consumer is taken back to the Issuer's interface (app or website).

Note:

* "token requestors may receive FPANs", primarily so that they can fall back on the FPANs if needed to ensure good approval rates. This will help Issuers recognize that they are part of the solution of driving the industry towards tokenization, because if they have higher approval rates on tokens, then token requestors won't need to fall back on the FPAN. We are moving away from the hard line approach of providing issuers with a list of FPAN receiving TRs.

* Documentation will strongly advise that Token Requestors use the tokens for payment transactions instead of FPANs and follow token transaction best practices for transaction retries. Mastercard reserves the right to periodically monitor usage patterns.

* FPANs will only be passed until December 2023, upon which the TR will have to support full tokenization.

* \*\* The token requestor will receive an active token even if the decision is REQUIRE_ADDITIONAL_AUTHENTICATION and the token requestor and the issuer both supports Consent Service\*\*

* \*\* The token requestors must delete the token if authentication is failed \*\*

### Consumer sees Confirmation in Issuer Interface {#consumer-sees-confirmation-in-issuer-interface}

The consumer is returned to your website or banking app and sees confirmation of the provisioning.

![alt text](https://static.developer.mastercard.com/content/mdes-token-connect/documentation/use-cases/img/BackToIssuer.png "Integration")