# Support
source: https://developer.mastercard.com/mdes-token-connect/documentation/support/index.md

## FAQ {#faq}

MDES Token Connect is the MDES framework supporting issuer-initiated digitization. It connects MDES Issuers with open-loop MDES Token Requestors. For more information about issuer-initiated digitization with MDES Token Connect, please refer to our [Push Provisioning](https://developer.mastercard.com/mdes-token-connect/documentation/use-cases/index.md) use case. Push Provisioning is the ability for a consumer to provision their payment credentials from an issuer mobile application or website to a token requestor. Push Provisioning may also be referred to as "issuer-initiated digitization". For more information about Push Provisioning with MDES Token Connect, please refer to our [Push Provisioning](https://developer.mastercard.com/mdes-token-connect/documentation/use-cases/index.md) use case. MDES Token Connect is compatible with account ranges that Issuers have enabled for MDES including:

* Mastercard card account ranges
* Maestro card account ranges
* 'Pay with Bank Account' financial account ranges

For inquiries about Private Label account ranges, please contact your Mastercard Representative.
Yes. Depending on how your wallet is configured, MDES Token Connect may ease the technical work for token provisioning, as well as enhance the experience for the cardholder.
As an Issuer, you may supply an Issuer wallet to your cardholders, for instance a cloud-based wallet (MCBP) supporting contactless or online payments. In this case, you are both a card Issuer, as well as a Token Requestor.

### Should you implement MDES Token Connect as an Issuer? {#should-you-implement-mdes-token-connect-as-an-issuer}

If your Issuer wallet application is also the mobile banking app for your cardholders, you can implement the Issuer "side" of MDES Token Connect. By doing so, your cardholders will have the possibility to push their card credentials to MDES merchants, commerce platforms (such as Secure Remote Commerce - SRC), wearables and other device wallets.

For more information for Issuers, please consult [Push Provisioning with MDES Token Connect](https://developer.mastercard.com/mdes-token-connect/documentation/use-cases/index.md).

### Should you implement MDES Token Connect as a Token Requestor? {#should-you-implement-mdes-token-connect-as-a-token-requestor}

MDES Token Connect framework has been designed to connect Issuers and Token Requestors for push provisioning, when Issuers and Token Requestors are different entities.

If your Issuer wallet application accepts only cards (or account) issued by yourself, your Issuer wallet is a closed wallet, that is, the Token Requestor and the Issuer are a single unique entity. In this case, implementing the Token Requestor "side" of MDES Token Connect is not a necessary step.

On the contrary, if your Issuer wallet application can host cards from other Issuers, your wallet is an open wallet -- where the Token Requestor and the Issuer may be different entities. In this case, implementing the Token Requestor "side" of MDES Token Connect will benefit your wallet application, as it will appear in the mobile payment application of other (eligible) Issuers, as a possible destination where cards can be pushed to.

For more information about how to implement the Token Requestor "side" of MDES Token Connect, please refer to [MDES Token Connect -- Token Requestor Implementation Guide and Specification](https://techdocs.mastercard.com/bundle/p_MDESRQ) (requires access to Mastercard Connect).
Yes, if the target Token Requestor supports multiple credentials, you can transmit up to five payment credentials at once when you send your consumer to the Token Requestor's environment.
Some Token Requestors accept to receive up to five payment credentials when the consumer is redirected by the Issuer into their mobile app or website.

In this case, the `supportsMultiplePushedCards` flag is set to `true` for this Token Requestor in the response to `getEligibleTokenRequestors`. Otherwise, when the flag is set to false, the Token Requestor can accept only one payment credential per redirection.

If the Token Requestor supports it, you can pass multiple payment credentials to the Token Requestor by appending multiple pushAccountReceipts in the query string parameters of the first redirection URL. Refer to [Issuer Interface Implementation Guide](https://developer.mastercard.com/mdes-token-connect/documentation/tutorials-and-guides/issuer-implementation-guide/index.md) for more details on the formatting of the query string parameters.

Note that when a Token Requestor supports multiple push cards and if an issuer has passed more than five pushAccountReceipts in the query string then the Token Requestor can use only five pushAccountReceipts for tokenizing and drop additional pushAccountReceipts and will not share any results to the Issuer for dropped pushAccountReceipts.
Digitization initiated with MDES Token Connect can be identified in the Tokenization Authorization Request (TAR) or Authorize Service API message, with a specific value for the "source" field/parameter value that indicates the card was added via an application.
Depending on Issuer configuration for tokenization authorization messages, Issuer-initiated digitizations can be identified as follows:

In Tokenization Authorization Request (TAR) ISO message, Subfield "Primary Account Number Source" in [DE 124](https://techdocs.mastercard.com/bundle/m_MIIG/page/r_DE124SubfieldsAuthReq0100TokenAuth.html) has value 3 ("Card added via application")

In the Authorize Service API request, the parameter `source` has a value of `ACCOUNT_ADDED_VIA_APPLICATION`
Note:   

* This information is not available to the Issuer if they have selected to receive tokenization authorizations via Account Status Inquiry (ASI) ISO message.
* These values identify all issuer-initiated digitizations. This includes MDES Token Connect framework and potentially other proprietary wallet push provisioning frameworks. To distinguish between MDES Token Connect and other frameworks, Issuers can log the activity of their banking app or website prior to reaching out to the Token Requestor for digitization.
* Once successfully digitized, there is no specific data element or value in transaction authorization requests to indicate that the token was created using MDES Token Connect.
Absolutely. You are eligible to MDES Token Connect, whatever connection you are using for Pre-digitization messages.

* ISO Token Authorization Request (TAR) message
* ISO Account Status Inquiry (ASI) message
* [MDES Pre-Digitization API](https://developer.mastercard.com/mdes-pre-digitization/documentation)
The Card Verification Code is not required for provisioning with MDES Token Connect.
MDES Token Connect has been designed to simplify the digitization experience for consumers by avoiding manual entry of card details.

Therefore, when initiating a digitization request through MDES Token Connect, consumers do not enter their CVC2 security code, neither in the Issuer app or website, nor later in the Token Requestor interface, even if a CVC2 is applicable for the card being digitized. Issuer systems should not expect the presence of the CVC2 information for digitizations initiated with MDES Token Connect.
You may want to prevent cardholders from tokenizing the same card twice to the same Token Requestor. To achieve this, you'll need to know if a token already exists for a given {Card, Token Requestor} combination. MDES offers several possibilities to inform Issuer systems about tokens that exist for a given card or account.
Note: Having multiple tokens for the same {Card, Token Requestor} combination may be a viable use case. Typically, for device-based wallets, the same card may legitimately be tokenized on multiple devices.

### Real-time notifications {#real-time-notifications}

Issuer systems get systematically informed in real-time for any life cycle event for tokens associated with their cards/accounts: creation, activation, suspension, deletion.

Depending on the configuration selected by the Issuer, these notifications may be sent via ISO messages or via [MDES Pre-Digitization](https://developer.mastercard.com/mdes-pre-digitization/documentation) API calls. Refer to [MDES Issuer Implementation Guide](https://techdocs.mastercard.com/bundle/m_MIIG/page/c_MIIG_LifecycleEvents.html) for further details about life cycle events notifications (note: requires access to Mastercard Connect).

Based on these token life cycle notifications, Issuer systems can keep their own database of tokens associated to cards and Token Requestors. This database can then be used to eliminate Token Requestors from the list of possible destinations for push provisioning, if a token already exists.

### Customer Service API {#customer-service-api}

Alternatively, Issuer systems can query MDES using the [search](https://developer.mastercard.com/mdes-customer-service/documentation/api-reference/) function from [MDES Customer Service API](https://developer.mastercard.com/mdes-customer-service/documentation/) to retrieve the list of tokens associated with a particular card.
Note:
* The usage of Customer Service API is subject to traffic restrictions. Find out more in the [MDES Customer Service API guide](https://developer.mastercard.com/mdes-customer-service/documentation/). To avoid technical limitations to processing capacity, Issuers should design their mobile apps and websites so as to call the search function only when needed, rather than on a systematic basis.
* Similarily, Token Requestors are also likely to verify that a card/account being pushed by the Issuer doesn't duplicate an existing token for the same user account (and same user device, if applicable). If the Token Requestor detects that the new token duplicates an existing token, they will delete the new token and returns the consumer back to the issuer with a result of CANCELLED for the pushAccountReceipt.
* It may be difficult in all cases to definitively determine whether a token already exists in the device wallet on the current device. The following data (when provided by Wallet Provider) is present in real-time notifications and Customer Service API for already existing token(s) and can be useful in the investigation:
  * Device ID: Serial number of the device provisioned with the token. Using mobile OS developer tools this could be compared with the serial number of the current device.
  * Device Name: Nickname of the device provisioned with the token. Using mobile OS developer tools this could be compared with the device name of current device.
  * Device type: e.g. '21' - Phone Mobile phone, '23' - Watch/Wristband Watch
As an Issuer you have flexibility in the presentation of eligible provisioning destinations within your mobile app(s) and web sites, however it is recommended that you respect a few presentation guidelines.

* Please read [MDES Token Connect -- Issuer Interface Implementation Guide](https://developer.mastercard.com/mdes-token-connect/documentation/tutorials-and-guides/issuer-implementation-guide/index.md)) for generic guidelines

<!-- -->

* Make sure that there is a clear distinction between Merchants and Wallets. This will make it easier for the consumer to find what they are looking for.
* For each Token Requestor, display both the logo and the consumer-facing name
* As the number of eligible Token Requestors grows, consider including a search bar for a quicker access to a particular merchant or wallet.
* If you have special offers for your consumers due to bilateral agreements with specific merchants or wallets, you may want to give these a privileged place in your mobile app or website. However, make sure that this doesn't prevent consumers from pushing payment information to other Token Requestors.
* To determine if consumer's mobile device already has the target wallet or merchant app installed before presenting Token Requestor you can use the following method:
  * From the getEligibleTokenRequestors response see if ANDROID and/or IOS are provided as supportedPushMethods and then find the availablePushMethods URI for the application
  * Use the mobile OS developer tools to determine if the application ID (app name) in the URI is available on the device
  * Mobile device OS developer tools also enable finding out e.g. the specific model or brand of the mobile device. For mobile OS developer tools refer to Android and iOS developer sites.
This can happen if you are using account ranges that are not onboarded to MDES and/or enabled on any eligible Token Requestors in your request. MDES Token Connect framework supports up to four connection types.
The following connections are supported:

* Issuer website to token requestor website,
* Issuer website to token requestor app (Android and iOS),
* Issuer app (Android and iOS) to token requestor app (Android and iOS),
* Issuer app (Android and iOS) to token requestor website
You can choose whether you provide a callback URL or not. If you do not provide one, the consumer will not be directed back to your environment and you will not receive the push provisioning Results from the Token Requestor.
If you do provide callback URL, you can additionally indicate:

1. If the Token Requestor is required to call the callback URL to redirect the consumer to your environment and provide the results.
2. If the Token Requestor may either keep the consumer in their interface at the end of provisioning or redirect the consumer back to the issuer interface (consumer choice) Considerations for different Token Requestors:
   * When pushing to merchant website, consider Option B, since the merchant may wish to propose to the consumer to make a purchase after push provisioning a card (e.g. subscription merchants).

   <!-- -->

   * When pushing to Click to Pay, consider Option B for flexibility (refer to the Click to Pay push provisioning use case documentation).
   * When pushing to a wallet or device, consider Option A to complete the user journey from app to app.

Note: If you choose Option B, you may not receive the Results of the provisioning. Even in Option A, you may not always receive the results in error scenarios (app crash, etc)

**Callback Considerations**

|                                                               Behavior                                                               | Callback URL | callbackRequired |                  Are the Results sent to issuer?                  |
|--------------------------------------------------------------------------------------------------------------------------------------|--------------|------------------|-------------------------------------------------------------------|
| Consumer must return to the issuer interface                                                                                         | present      | true             | Sent - Not sent in some unexpected error scenarios like app crash |
| Consumer must stay in the token requestor interface                                                                                  | absent       | n/a              | n/a                                                               |
| Consumer may either stay in the token Requestor interface or return to the Issuer interface (consumer and/or token requestor choice) | present      | false            | Not sent - Results are not sent if TR does not use callback URL   |

Most MDES Token Requestors (Open Wallets, Merchants, Commerce Platforms) are eligible to participate in MDES Token Connect framework. However, Token Requestors must fulfill specific requirements before being admitted to the framework.

However, Token Requestors must fulfill specific requirements before being admitted to the framework. For instance, they must enhance their app or web site to support push provisioning requests from Issuers.

The list of Token Requestors supporting MDES Token Connect framework evolves dynamically. By calling the `getEligibleTokenRequestors` API, Issuers can obtain an up-to-date list of Token Requestors that have effectively been admitted by Mastercard in the MDES Token Connect framework.
Token Requestor provides the redirect URIs to MDES and the URIs will be provided to issuer in real-time via MDES. Issuer should not whitelist any Token Requestor URIs, as they could be updated by the Token Requestor. MDES strongly recommends provisioning is initiated after a consumer has finished the sign-in/sign up process. The existing experience is based on the assumption that a cardholder will sign-in/sign-up first, and then, the token requestor will initiate provisioning through push account receipt. This will also ensure that the consumer does not received the Push Receipt NOT FOUND error.

If a token requestor would like to initiate provisioning before the consumer has completed sign-in/sign-up, then the merchant must do the following to ensure that the token is not associated with a consumer profile:

* Remove any Cardholder PII data received in the Tokenize Response from your system as soon as possible.
* Delete token using the Delete API as soon as possible once you receive Notify Token Updated for a provisioning request.

## Get Help {#get-help}

### Contact us for technical support. {#contact-us-for-technical-support}