# Push Provisioning to Wallet
source: https://developer.mastercard.com/mdes-token-connect/documentation/use-cases/push-to-wallet/index.md

Available for Use By:

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

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 digital wallet on her mobile phone to make contactless payments in stores. So she decides to opt in to the new service and loads her card into her favorite digital wallet. 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/CompleteFlowWallet.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-wallet/index.md#fetch-eligible-token-requestors)
2. [Consumer chooses card(s) and a token requestor.](https://developer.mastercard.com/mdes-token-connect/documentation/use-cases/push-to-wallet/index.md#consumer-selects-cards-and-destination-in-issuer-interface)
3. [Consumer is redirects to wallet.](https://developer.mastercard.com/mdes-token-connect/documentation/use-cases/push-to-wallet/index.md#consumer-is-sent-to-digital-wallet-interface)
4. [Consumer returns to issuer app with provisioning confirmation.](https://developer.mastercard.com/mdes-token-connect/documentation/use-cases/push-to-wallet/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 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/WalletSelection.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_wallet.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(s) or account(s) 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 Digital Wallet Interface {#consumer-is-sent-to-digital-wallet-interface}

The digital wallet 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(s) or account(s) being pushed.
* Upon successful log in, the Token Requestor proceeds with the tokenization of the payment card or account
* The Consumer will need to accept your Terms and Conditions to the digitization
* Depending on your configuration, the cardholder may need to authenticate before the token is activated.
* 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 Digital Wallet, and the consumer must accept the Issuer's Terms and Conditions. The Issuer doesn't require additional cardholder authentication, and the Digital Wallet 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/Tokenize_Wallet.png "Integration")

![alt text](https://static.developer.mastercard.com/content/mdes-token-connect/documentation/use-cases/img/device.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(s).
3. The Token Requestor checks card availability 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.
4. The consumer accepts the Issuer's Terms and Conditions in the Token Requestor interface.
5. The Token Requestor checks the card eligibility with MDES, exactly as in a 'regular' tokenization. The Issuer receives the tokenization authorization message.
6. Note that depending on the Issuer's configuration, cardholder authentication may be required to activate the new token.
7. When the tokenization is successfully completed, MDES notifies the Issuer and the Token Requestor. When multiple accounts are pushed, the tokenization process (steps 3 through 7) is repeated for each pushAccountReceipt.
8. The Token Requestor appends the list of pushAccountReceipts, 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).

### 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")