# Issuer Interface Implementation Guide - Push Provisioning source: https://developer.mastercard.com/mdes-token-connect/documentation/tutorials-and-guides/issuer-implementation-guide/index.md This page explains to the developers of Issuer's User Interfaces the enhancements that must be made to support MDES Token Connect framework. The page provides developers with a detailed user experience of provisioning an account to a Token Requestor. Specific guidelines apply when pushing cards to Mastercard Click to Pay. [Learn More](https://developer.mastercard.com/product/click-to-pay#resources-issuing-partners)
## Capture User's Choice {#capture-users-choice} In this section, as an issuer, you will: 1. Present the Push Provisioning option to the user. 2. Present a list of eligible Token Requestors to choose from. 3. Request the user to select a Token Requestor. 4. Present eligible user accounts ### Present Push Provisioning {#present-push-provisioning} After successful login into the mobile banking app or web site, the user should be educated about the Push Provisioning feature and its advantages. At Issuer's discretion, this information may be inserted within the main menu, or it may be accessible when the user reviews their card or account details. Once the user has been presented with Push Provisioning, they should be invited to proceed to the next step: Token Requestor and card/account(s) selection. ### Present a list of eligible Token Requestors {#present-a-list-of-eligible-token-requestors} The Issuer must present a list of Token Requestors to which users can push their card or financial account for tokenization. For each Token Requestor, the list should feature: * An icon representing the Token Requestor * A user-friendly name for the Token Requestor. Note that in some (rare) cases, this name may be long (up to 100 characters), and the list should allow to display the name in full, if needed. * The Token Requestor type: Wallet or Merchant (optional) With the MDES Token Connect API, Issuers can retrieve information about Token Requestors that are enabled for their account ranges. This information can be used to create the list of Token Requestors for the user. Issuers will call two functions from MDES Token Connect API to build the list: * [getEligibleTokenRequestors](https://developer.mastercard.com/mdes-token-connect/documentation/api-reference/index.md): to retrieve information such as Token Requestor type, user-friendly name, available user interfaces (Android/iOS app, web) | Parameter | Description | |----------------------------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | Token Requestor Id | The numeric value that identifies the Token Requestor where the card/account must be pushed to. The string contains a 11-digit numeric value. | | Name | The legal name of the Token Requestor. | | Consumer Facing Entity Name | The name of the Token Requestor to be displayed to the account holder. | | Image Asset Id | The image of the Token Requestor (for instance a logo). Provided as an Asset ID -- use the Get Asset API to retrieve the actual asset. | | Token Requestor Type | The type of Token Requestor * **MERCHANT** - The Token Requestor is a Merchant. * **WALLET** - The Token Requestor is a Wallet or a Commerce Platform. | | Wallet Id | The identifier of the Wallet Provider | | Enabled Account Ranges | An Array of account range start numbers that are enabled for the Token Requestor. | | Supported Push Methods | An array of push methods supported by a Token Requestor. The array is not returned if a Token Requestor does not participate in the MDES Token Connect program. Possible push methods are: * **ANDROID** - The Token Requestor supports app-to-app and web-to-app communication on Android. * **IOS** - The Token Requestor supports app-to-app and web-to-app communication on iOS. * **WEB** - The Token Requestor supports web-to-web or app-to-web communication. | | Supports Multiple Pushed Cards | Flag to indicate if a Token Requestor supports multiple push account receipts in a single request. When supported, a maximum of 5 receipts may be sent to the Token Requestor in a single request. If the user selects a Token Requestor supporting multiple cards/accounts, the Issuer may optionally allow the user to select multiple cards/accounts for push - typically using checkboxes instead of radio buttons, for instance. Issuers shouldn't allow the selection of multiple cards/accounts if the Token Requestor doesn't support it. Therefore, Issuers asking for selection of the card/account before presenting the list of Token Requestors aren't allowed to offer multiple cards/accounts for selection. | | Supported Account Holder Data | A list (array) of account holder data elements that the Token Requestor accepts to receive from the Issuer with a pushed card or account. If the Token Requestor participates in MDES Token Connect but doesn't accept any account holder data then an empty array is returned. **To ensure forward-compatibility, all API client implementations must be resilient to new data element values being added to responses from MDES.** Possible values are: * **NAME:** The first name and last name of the account holder. * **ADDRESS:** The billing address for the account holder. * **EMAIL_ADDRESS:** The email address for the account holder. * **MOBILE_PHONE_NUMBER:** The mobile phone number for the account holder | | Supports Card Holder Authentication | Indicates that token holder has capability to initiate cardholder authentication through MDES authentication service. A token requestor can initiate card holder authentication only if the issuer also supports * MDES authentication service for Click to Pay and Secure Card on File Token * Provides supported authentication methods in the token authorization responses On successful authentication MDES upgrade token assurance value. **This flag is only applicable to Merchant type of Token Requestors** | | Supports Token Connect | A boolean parameter that indicates if a token requestor supports Token Connect or not. **Issuer must pass a true value to receive the Token Requestors supporting Token Connect.** | | Available Push Methods | An Array of push methods supported by the token requestor. It contains URI and method type. Issuer MUST use token requestor URI from pushMultipleAccount method only as it provides latest URI supported by the Token Requestors. | | supportIssuerInitiatedDigitizationData | A boolean parameter indicate that token requestor supports Issuer Initiated Digitization Data. or not. Must be one of: * **true** - Issuer Initiated Digitization Data is supported * **false** - Issuer Initiated Digitization Data is not supported Note: Please contact Mastercard Regional Team before presenting token requestor that have supportIssuerInitiatedDigitizationData value is true. | Note: - Issuer must not call \[getEligibleTokenRequestors\](/documentation/api-reference/) more than once in a week. - Issuer must call \[getEligibleTokenRequestors\](/documentation/api-reference/) with the Supports Token Connect parameter value as true in the request. * [getAsset](https://developer.mastercard.com/mdes-token-connect/documentation/api-reference/index.md): to retrieve the image (logo) associated with the Token Requestor. The supplied images are square with a white background. For each Token Requestor, MDES supplies the logo in two formats: .svg (rescalable) and .png (192 x 192 pixels) Note: The information returned by these two functions evolves at slow pace. It may change whenever the Issuer enables additional wallets or programs for their account ranges, or when MDES onboards new Token Requestors to digital programs, such as new Merchants. Mastercard recommends that Issuer's back-end server calls these functions regularly, typically on a bi-weekly basis. Issuer's server should cache the information returned by MDES and relay it to Issuer's user Interface (app and website) so as to build the list of Token Requestors for the user. ### Select a Token Requestor {#select-a-token-requestor} The user Interface should filter out the Token Requestors that are not applicable to this list, such as Token Requestors with an inappropriate user interface. For example, user is navigating from a browser on a desktop, and Token Requestor has implemented a mobile app, but there is no website. Note: * Mastercard certifies to have obtained Token Requestor's authorization to transfer the logo to each Issuer participating in Token Connect for the purposes of displaying eligible Token Requestors to consumers and related consumer engagement efforts. * Mastercard Click to Pay is one of the Token Requestors that may be eligible as a destination for the card credentials of your cardholders. Specific guidelines apply for presenting Mastercard Click to Pay to cardholders. Please consult the [dedicated page](https://developer.mastercard.com/product/click-to-pay#resources-issuing-partners). The user should then be requested to select one Token Requestor (wallet or merchant) from this list. The indicative figure below suggests how an Issuer app may present this list: ![alt text](https://static.developer.mastercard.com/content/mdes-token-connect/documentation/tutorials-and-guides/img/issuer-choosetr-small.png "Integration") ### Present Eligible User Accounts {#present-eligible-user-accounts} The indicative figure below suggests how the user may select a Card to be pushed: ![alt text](https://static.developer.mastercard.com/content/mdes-token-connect/documentation/tutorials-and-guides/img/issuer-choosecard-small.png "Integration") ## Send User's choice to MDES {#send-users-choice-to-mdes} When the user has selected the target Token Requestor as well as the sourcing card(s) or financial account(s), they confirm with a user gesture (for instance, a button click) to continue. The user Interface must transmit the user's choices to the Issuer back-end system. It is Issuer's responsibility to develop the secure encrypted channel to transmit this information from the user Interface to their back-end system; it is expected though that this channel already exists and can be easily leveraged. Issuer's back-end system will then call the [pushMultipleAccounts](https://developer.mastercard.com/mdes-token-connect/documentation/api-reference/index.md) function from the MDES Token Connect API to trigger the push provisioning process. The Token Requestor Identifier (TRID) as well as the card(s) and/or financial account(s) details are passed as parameter. The response from MDES will include a list of receipts (pushAccountReceipt) representing the card(s)/account(s) to be pushed. The Issuer will transmit this receipt(s) to the Token Requestor that will use it in lieu of the original card/account data to request tokenization from MDES. The pushAccountReceipt expires after 15 minutes. One or more URI(s) for the Issuer to call out the Token Requestor's user interface. ### Supply Account Holder Data to the Token Requestor {#supply-account-holder-data-to-the-token-requestor} Some Token Requestors may be interested in receiving personal account holder information from the Issuer during a Push Provisioning operation, such as the name or billing address. These data elements may typically be used by the Token Requestor to reduce friction in case the customer wishes to sign up for a new account in the Token Requestor's interface - for instance by displaying an account creation form pre-filled with the information supplied by the Issuer. For instance, supplying a billing address will greatly simplify the user experience, especially in some markets where a billing address is required with any stored payment instrument. ### Which data elements can be supplied? {#which-data-elements-can-be-supplied} At their discretion, Issuers may elect to transmit any combination of account holder data elements supported by a particular Token Requestor. All account holder data elements are optional in the pushMultipleAccount request: * Name (first name and last name) * Billing Address * E-mail Address * Mobile Phone Number The Token Requestor data returned by MDES in response to [getEligibleTokenRequestors](https://developer.mastercard.com/mdes-token-connect/documentation/api-reference/index.md) informs the Issuer about each account holder data element(s) that the Token Requestor wishes to receive from the Issuer. ### How does the Token Requestor retrieve the account holder data? {#how-does-the-token-requestor-retrieve-the-account-holder-data} If the tokenization decision is "APPROVED", the Token Requestor receives the account holder data (if any) from MDES in response to the tokenization request. To mitigate the risk of identity theft, the Token Requestor doesn't receive the account holder data if the tokenization decision is "DECLINED" or "REQUIRE_ADDITIONAL_AUTHENTICATION". Warning: If an Issuer elects to transmit account holder data to Token Requestors that request such data, the Issuer acknowledges, and agrees to comply with, the following: * Issuers should provide the most accurate information. It is advisable to withhold a data element, rather than supplying an outdated/inaccurate data element * Issuers should withhold any account holder data element that is not requested by the targeted Token Requestor to avoid the unnecessary disclosure of personal information ("Privacy-by-design" principle) * **The collection and processing of personal information may be subject to local laws and regulations. This may include, for example and at a minimum, Issuers ensuring that they have provided a privacy notice and all other appropriate disclosures and terms as well as have obtained any necessary consents in order to have a valid legal basis to collect and share any personal information with Mastercard and for Mastercard to collect, store and share such data as indicated in the use of this feature. Issuers are solely responsible for ensuring that they comply with local regulations, as well as ensuring that Mastercard may receive, store, process and share any Personal Information passed through the Token Connect Services on behalf of the Issuer.** * **Issuer acknowledges that Mastercard will not be liable to Issuer or any third party for any loss or harm resulting, directly or indirectly, from Mastercard's sharing with Token Requestors of account holder data that Issuer provided to Mastercard in connection with Token Connect. Furthermore, Issuer agrees to fully indemnify and hold Mastercard harmless for any such loss or harm.** When the Issuer provides account holder data, Mastercard stores this information temporarily for the sole purpose of transmitting this information to the intended Token Requestor. Mastercard erases the account holder data once successfully sent the Token Requestor, or upon expiry of the pushAccountReceipt. ## Redirect to the Token Requestor interface {#redirect-to-the-token-requestor-interface} MDES Token Connect framework supports multiple user experiences: | User Experience | Description | |-----------------|----------------------------------------------------------------------------------------------------------------------| | App-to-App | Communication on a mobile device (Android or iOS) between an Issuer application and the Token Requestor application. | | App-to-Web | Communication on a mobile device (Android or iOS) between an Issuer application and a Token Requestor's website. | | Web-to-App | Communication on a mobile device (Android or iOS) between an Issuer website and a Token Requestor application. | | Web-to-Web | Communication on the same device (mobile or desktop) between an Issuer website and a Token Requestor website. | This section explains how to implement these various experiences. ### Choose the right Token Requestor URI {#choose-the-right-token-requestor-uri} The [pushMultipleAccounts](https://developer.mastercard.com/mdes-token-connect/documentation/api-reference/index.md) function (see above) returns up to 3 URIs -- with a minimum of one URI: * One URI for the Token Requestor's Android app * One URI for the Token Requestor's iOS app * One URI for the Token Requestor's web browser experience Issuer must respect specific rules when selecting the URI where they will send the consumer. Because Android or iOS mobile apps provide a better mobile experience than the web browsers, Issuers should always try and direct the consumer to the Android or iOS app of the Token Requestor, when possible. If the Android or iOS app URI is supplied, the web browser should remain a backup solution only. The table below indicates when Issuers should use the various Token Requestor URIs. | Token Requestor URI | Scenario | |---------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | Android URI | When present, indicates the existence of an Android app for the Token Requestor for an app-to-app or web-to-app experience. **Format:** * If the Token Requestor wishes to send the consumer directly to their app, the URI should contain a [custom URI scheme](https://developer.android.com/training/basics/intents/), such as walletAppName://deep/link/path/to/pushcard/ * If the Token Requestor prefers to send the consumer first to their web server for filtering before redirecting them to their app (if installed) or to a download of their app (if not installed), the URI will be a traditional URL with http:// or https:// scheme. **When to use it:** On Android mobile devices, from the browser or Issuer app. If the Android URI is a custom URI scheme and doesn't resolve (app is not present on the device), Issuer should call the Web URI as a fallback (when available). Otherwise the Issuer should display an error message to indicate (such as "service not available"). | | iOS URI | When present, indicates the existence of an iOS app for the Token Requestor for an app-to-app or web-to-app experience. **Format:** URI will be a [universal link](https://developer.apple.com/documentation/uikit/core_app/allowing_apps_and_websites_to_link_to_your_content): it is formatted with http:// or https:// scheme to allow fallback to the Token Requestor web server if the Token Requestor's iOS application is not yet installed. Token Requestor should then assist the consumer for the download of their app. **When to use it** : On iOS mobile devices, from the browser or Issuer app | | Web URI | When present, indicates the existence of a web server for the Token Requestor for an app-to-web or web-to-web experience. **Format:** URI containing http:// or https:// scheme. **When to use it** : * On all desktop devices, from the browser * On iOS mobile devices, from the browser or Issuer app, if MDES hasn't supplied any iOS URI for the Token Requestor * On Android mobile devices, from the browser or Issuer app, if MDES hasn't supplied any Android URI for the Token Requestor * On Android devices, from the browser or Issuer app, if the Android URI could not resolve (Android URI is a custom scheme URI and the app isn't present on the device) * On all mobile devices that are not Android or iOS, from the browser or Issuer app | Note: Some device-based wallets may decide to support a desktop-to-mobile experience for Token Connect as follows: * On the desktop browser, the Issuer web server redirects the consumer to the Web URI of the Token Requestor. * The Token Requestor web server then drives the consumer to pair their mobile device with their desktop browser session -- for instance, via scanning or a QR code to download and open their mobile app. * Once the mobile device is paired, the consumer goes on their journey on the mobile device where the digitization is completed. * When digitization is complete, the Token Requestor web server refreshes the desktop browser: consumer is invited to return to the bank interface on the desktop browser.
Therefore, when the Token Requestor supports a desktop-to-mobile journey, the Issuer perceives this as a desktop web-to-web interaction. Token Requestor isn't allowed to call out the Issuer callback URL on the mobile device, if they obtained the URL on a desktop computer. ### Append Parameters to Token Requestor URI {#append-parameters-to-token-requestor-uri} The Issuer must append parameters to the selected Token Requestor URI. This depends on Token Requestors' support for Signature. If the **tokenRequestorSignatureSupport value is true** in the response of [pushMultipleAccounts](https://developer.mastercard.com/mdes-token-connect/documentation/api-reference/index.md), the issuer needs to append the `pushAccountData` parameter. If tokenRequestorSignatureSupport value is false in the response of [pushMultipleAccounts](https://developer.mastercard.com/mdes-token-connect/documentation/api-reference/index.md), the Issuer must provide the pushAccountReceipt(s) to the Token Requestor. The Issuer may also provide a callback URI in the request, as well as other parameters. All information is passed by a query string. The table below lists the parameters that the Issuer can append to the Token Requestor URI depending on the value of the `tokenRequestorSignatureSupport`: | tokenRequestorSignatureSupport Value | Parameter Name | Presence | Description | |--------------------------------------|-------------------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | True | pushAccountData | Conditional - If tokenRequestorSignatureSupport value is true in the response of [pushMultipleAccounts](https://developer.mastercard.com/mdes-token-connect/documentation/api-reference/index.md) | Pass signature value that received in the response of [pushMultipleAccounts](https://developer.mastercard.com/mdes-token-connect/documentation/api-reference/index.md) function if tokenRequestorSignatureSupport value is true in the response as displayed in Example 1 below | | False | pushAccountReceipts | Conditional - If tokenRequestorSignatureSupport value is false in the response of [pushMultipleAccounts](https://developer.mastercard.com/mdes-token-connect/documentation/api-reference/index.md) | The pushAccountReceipts value obtained by the Issuer from the [pushMultipleAccounts](https://developer.mastercard.com/mdes-token-connect/documentation/api-reference/index.md) API, separated by commas. **Eample1:** Issuer passes one single pushAccountReceipt: pushAccountReceipts=MCC-C307F0AE-298E-48EB-AA43-A7C40B32DDDE **Example2:** Issuer passes 3 pushAccountReceipts (for 3 different cards): pushAccountReceipts=MCC-C307F0AE-298E-48EB-AA43-A7C40B32DDDE,MSI-1E8GTJ94-9D5T-96MO-WV36-56AZN95Y8DUL,DMC-9H2T37SH-RB3O-PI14-QQ9R-321UGR5ZI07A | | False | callbackURL | Conditional - If tokenRequestorSignatureSupport value is false in the response of [pushMultipleAccounts](https://developer.mastercard.com/mdes-token-connect/documentation/api-reference/index.md) | The [URL encoded](https://www.w3schools.com/tags/ref_urlencode.asp) URL for the Token Requestor to use to pass control back to the Issuer. This needs to be an absolute URL containing the scheme. If the Issuer wishes to redirect to their banking app (iOS or Android), the URL must contain a custom URI scheme. Both iOS and Android support custom URI schemes that allow the Token Requestor's app or the browser browser to open an application. Issuer can use deeplink URL for their application as callback URL. **Example1:** Issuer "Moon Bank" expects a redirection to their web site at `http://www.moonbank.com/pushcallback`: callbackURL=https%3A%2F%2Fwww.moonbank.com%2Fpushcallback **Example2:** Issuer "Moon Bank" expects a redirection to their iOs or Android bank app at moonbank://pushcallback?sessionid=123456 (custom URI scheme) callbackURL=moonbank%3A%2F%2Fpushcallback%3Fsessionid%3D123456 It this value present then the Token Requestor must display back to bank option but it is consumer choice to go back to bank or continue with merchant system. | | False | callbackRequired (depricated) | Optional (default = ~~true~~ false ) | Boolean value. When callbackURL is supplied, indicates whether the Token Requestor must call the Issuer callback URL after the push provisioning operation. Possible values are: * **false:** The Token Requestor may keep the consumer in their interface at the end of the provisioning, or send him/her back to the Issuer interface. The consumer may be involved in this choice. * **true** The Token Requestor must return the consumer back to the Issuer interface at the end of the provisioning. **Example** callbackRequired=false | | False | completeIssuerAppActivation | Conditional (default=false) | Boolean value used to drive the behavior of the Token Requestor if a digitization request receives a decision of REQUIRE_ADDITIONAL_AUTHENTICATION and the cardholder chooses the Issuer Mobile App Authentication Method from the list of supplied methods. This field is not case sensitive. Possible values are: * **false:** [Streamlined Activation](https://developer.mastercard.com/mdes-token-connect/documentation/tutorials-and-guides/issuer-implementation-guide/index.md#streamlined-activation-via-issuer-application-web-site): The Token Requestor shouldn't execute activation. The Token Requestor should return control to the Issuer app via the callbackURL, after all tokenizations are completed, so that the Issuer can perform activation * **true:** The Token Requestor should execute activation with Issuer web site using the information supplied by MDES.
**NOTE: this parameter is applicable only for Wallet Providers supporting activation via Issuer Banking Application. Other Token Requestors can ignore it.** **Example:** completeIssuerAppActivation=false | | False | completeWebsiteActivation | Conditional (default=false) | Boolean value used to indicate if Issuer has supplied account holder information to MDES along with the funding account information. Conditional: Must be present with value true if the Issuer supplies account holder information; not present (or present with default value=false) otherwise. MDES will provide the account holder information to the Token Requestor in certain scenarios. This field is not case sensitive. Possible values are: * **false:** [Streamlined Activation](https://developer.mastercard.com/mdes-token-connect/documentation/tutorials-and-guides/issuer-implementation-guide/index.md#streamlined-activation-via-issuer-application-web-site): The Token Requestor shouldn't execute activation. The Token Requestor should return control to the Issuer app via the callbackURL, after all tokenizations are completed, so that the Issuer can perform activation * **true:** The Token Requestor should execute activation with Issuer web site using the information supplied by MDES.
**NOTE: this parameter is applicable only for Wallet Providers supporting activation via Issuer Banking Application. Other Token Requestors can ignore it.** **Example:** completeWebsiteActivation=false | | False | accountHolderDataSupplied | Conditional (default=false) | Boolean value used to indicate if Issuer has supplied account holder information to MDES along with the funding account information. Conditional: Must be present with value true if the Issuer supplies account holder information; not present (or present with default value=false) otherwise MDES will provide the account holder information to the Token Requestor in certain scenarios. This field is not case sensitive. Possible values are: * **false:** Issuer hasn't supplied any Account holder data * true: Issuer has supplied Account holder data for at least one of the pushAccountReceipts. **Example:** accountHolderDataSupplied=true | | False | locale | Optional | Consumer preferred locale (language and country). This information will be useful to the Token Requestor to offer the best consumer experience during digitization. **Format:** Two letter ISO 639-1 language in lowercase, with a underscore ("_"), followed by two letter ISO 3166-1 country code in uppercase. **Examples:** en_US - fr_CA | ### Example {#example} #### Token Requestor Supports Signature {#token-requestor-supports-signature} If the **tokenRequestorSignatureSupport value is true** in the response of [pushMultipleAccounts](https://developer.mastercard.com/mdes-token-connect/documentation/api-reference/index.md), the issuer needs to append the `pushAccountData` parameter. pushAccountData=ew0KImFsZyI6ICJSUzI1NiIsDQoNCiJraWQiOiAiYXNkZmctcXdlcnR5LXp4Y3ZiIg0KfQ.ew0KDQrCoCJwdXNoQWNjb3VudFJlY2VpcHQiOiAiTUNDLVNUTC0xMzQzMTNCRi01NTg1LTRFNzEtQUIyNC1FQ0RCQzI4RjIzRjEiLA0KImlzc3VlckNhbGxCYWNrIjogImh0dHBzOi8vaXNzdWVyY2FsbGJhY2sudXJsIiwNCiJjYWxsYmFja1JlcXVpcmVkIjogdHJ1ZSwNCiJjb21wbGV0ZVdlYnNpdGVBY3RpdmF0aW9uIjogdHJ1ZSwNCiJhY2NvdW50SG9sZGVyRGF0YVN1cHBsaWVkIjogdHJ1ZSwNCiJsb2NhbGUiOiAiZW5fVVMiDQoNCn0.dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk **Sample Redirect URL When `tokenRequestorSignatureSupport` is True** https://www.mywallet.com/pushAccount?pushAccountData=ew0KImFsZyI6ICJSUzI1NiIsDQoNCiJraWQiOiAiYXNkZmctcXdlcnR5LXp4Y3ZiIg0KfQ.ew0KDQrCoCJwdXNoQWNjb3VudFJlY2VpcHQiOiAiTUNDLVNUTC0xMzQzMTNCRi01NTg1LTRFNzEtQUIyNC1FQ0RCQzI4RjIzRjEiLA0KImlzc3VlckNhbGxCYWNrIjogImh0dHBzOi8vaXNzdWVyY2FsbGJhY2sudXJsIiwNCiJjYWxsYmFja1JlcXVpcmVkIjogdHJ1ZSwNCiJjb21wbGV0ZVdlYnNpdGVBY3RpdmF0aW9uIjogdHJ1ZSwNCiJhY2NvdW50SG9sZGVyRGF0YVN1cHBsaWVkIjogdHJ1ZSwNCiJsb2NhbGUiOiAiZW5fVVMiDQoNCn0.dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk If an issuer wants to pass additional parameter, such as sessionId = sdsdw232u34oo32o2sdoo Redirection URL: https://www.mywallet.com/pushAccount?pushAccountData=ew0KImFsZyI6ICJSUzI1NiIsDQoNCiJraWQiOiAiYXNkZmctcXdlcnR5LXp4Y3ZiIg0KfQ.ew0KDQrCoCJwdXNoQWNjb3VudFJlY2VpcHQiOiAiTUNDLVNUTC0xMzQzMTNCRi01NTg1LTRFNzEtQUIyNC1FQ0RCQzI4RjIzRjEiLA0KImlzc3VlckNhbGxCYWNrIjogImh0dHBzOi8vaXNzdWVyY2FsbGJhY2sudXJsIiwNCiJjYWxsYmFja1JlcXVpcmVkIjogdHJ1ZSwNCiJjb21wbGV0ZVdlYnNpdGVBY3RpdmF0aW9uIjogdHJ1ZSwNCiJhY2NvdW50SG9sZGVyRGF0YVN1cHBsaWVkIjogdHJ1ZSwNCiJsb2NhbGUiOiAiZW5fVVMiDQoNCn0.dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk&sessionId = sdsdw232u34oo32o2sdoo #### Token Requestor Does Not Support Signature {#token-requestor-does-not-support-signature} If the **tokenRequestorSignatureSupport value is false** in the response of [pushMultipleAccounts](https://developer.mastercard.com/mdes-token-connect/documentation/api-reference/index.md), the issuer needs to append the `pushAccountData` parameter. **Sample Redirect URL When `tokenRequestorSignatureSupport` is False** https://www.mywallet.com/pushAccount?pushAccountReceipts=MCC-C307F0AE-298E-48EB-AA43-A7C40B32DDDE,MSI-1E8GTJ94-9D5T-96MO-WV36-56AZN95Y8DUL,DMC-9H2T37SH-RB3O-PI14-QQ9R-321UGR5ZI07A&callbackURL=moonbank%3A%2F%2Fpushcallback&completeIssuerAppActivation=false&completeWebsiteActivation=false&accountHolderDataSupplied=true&locale=en_US ## Invoke Token Requestor interface {#invoke-token-requestor-interface} ### Redirection: Building the Best Consumer Experience! {#redirection-building-the-best-consumer-experience} **"What if I don't see the consumer back?"** We understand that you may be afraid of "losing" the consumer when sending them to the Token Requestor's interface. This is a legitimate concern. For an app-to-web or web-to-web experience, you may then be tempted to keep the consumer with you, within your app or web page, by embedding the Token Requestor's web page within your app or website, rather than properly redirecting the consumer to a new page in the browser, using objects such as (but not limited to): * webviews (Android), WKWebviews (iOS) - for mobile application (app-to-web) * embed an iFrame in your web page - for website (web-to-web) Such implementations are not allowed with MDES Token Connect, for the following reasons: * For the Token Requestor, this downgrades the user experience. Webviews and iFrames prevent the Token Requestor from reading or writing cookies. In the Token Requestor's webpage, the consumer can't benefit from a "recognized" experience where sign-in could be avoided, either during the Push Provisioning operation or some time later. * For some Token Requestors, this may even lead to a fatal error, by preventing the opening of their device app. Token Requestor web servers may need to execute scripts to detect device settings, download (if needed) and launch the right app. Webviews and iFrames are likely to disturb this operation. With the parameters that you transmit to the Token Requestor, you may specify that the consumer must return to the Issuer's website or app. Mastercard duly validates that Token Requestors correctly interpret these parameters, before granting them access to MDES Token Connect. If your parameters indicate that the callback to the Issuer interface is required, you will see the consumer back (unless the consumer hasn't completed their navigation in the Token Requestor's interface). In brief, the consumer is the customer of both the Issuer and the Token Requestor and deserves the best experience on both sides. This requires the cooperation of both the Issuer and the Token Requestor: * Issuer must invoke a real browser redirection (app-to-web or web-to-web), * Token Requestor must return the consumer back to the Issuer interface when required. ### From a web browser {#from-a-web-browser} If the Issuer has selected the Web URI or the iOS URI as part of the Token Requestor URI selection process, the Issuer's web server simply redirects the user to the selected Token Requestor URI, with [appended query string parameters](https://developer.mastercard.com/mdes-token-connect/documentation/tutorials-and-guides/issuer-implementation-guide/index.md#append-parameters-to-token-requestor-uri). The redirection should occur in the same window. If the Issuer has selected the **Android URI**, the Issuer's web server action depends on the type of browser: | Browser | What to do | |---------------------------------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | * Chrome * Browser compatible with Chrome intents | Create a href anchor with a **Chrome intent** . * The intent will contain the Token Requestor's **Android URI**, split between android_URI_scheme and android_URI_path. The query string parameters must be appended to the android_URI_path part. * To allow fallback if the app is not present on the device, the intent will also contain the Token Requestor's Web URI (if available) with appended query string parameters. The resulting URL must be presented in [URL encoded](https://www.w3schools.com/tags/ref_urlencode.asp) format See format and example below | | Other browser | * Upon user gesture, try to redirect the consumer to the Android URI, with appended query string * If the redirection doesn't work and if a Web URI is available for the Token Requestor, redirect the consumer to the Web URI with appended query string | **Format** Continue **Example:** * Token Requestor's Android URI is mywallet://pushAccount: the scheme is mywallet, and the path is pushAccount * Token Requestor's Web URI is * Issuer's callback URL is * Issuer supports streamlined activation
The resulting href anchor is (tokenRequestorSignatureSupport = true):
Continue The resulting href anchor is (tokenRequestorSignatureSupport = false): Continue #### Technical References {#technical-references} Redirections: * * Chrome intents: * * ### From an Android app {#from-an-android-app} The Issuer app must create an [Android implicit intent](https://developer.android.com/training/basics/intents/index.html) so as to call: * The Token Requestor's Android URI, if available, with the appended query string parameters * The Token Requestor's Web URI (with appended query string), if the Android URI is not available or can't be started safely (when the Token Requestor app is not present on the device) The implicit intent will have only 2 parameters: * Action: Intent.ACTION_VIEW * URI: Android or Web URI, as applicable **Example:** ```java // Build the App intent Uri tokenRequestorApp; if(tokenRequestorSignatureSupport) tokenRequestorApp = Uri.parse("tokenRequestor://tokenrequestor/pushToken?pushAccountData=ew0KImFsZyI6ICJSUzI1NiIsDQoNCiJraWQiOiAiYXNkZmctcXdlcnR5LXp4Y3ZiIg0KfQ.ew0KDQrCoCJwdXNoQWNjb3VudFJlY2VpcHQiOiAiTUNDLVNUTC0xMzQzMTNCRi01NTg1LTRFNzEtQUIyNC1FQ0RCQzI4RjIzRjEiLA0KImlzc3VlckNhbGxCYWNrIjogImh0dHBzOi8vaXNzdWVyY2FsbGJhY2sudXJsIiwNCiJjYWxsYmFja1JlcXVpcmVkIjogdHJ1ZSwNCiJjb21wbGV0ZVdlYnNpdGVBY3RpdmF0aW9uIjogdHJ1ZSwNCiJhY2NvdW50SG9sZGVyRGF0YVN1cHBsaWVkIjogdHJ1ZSwNCiJsb2NhbGUiOiAiZW5fVVMiDQoNCn0.dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk"); else tokenRequestorApp = Uri.parse("tokenRequestor://tokenrequestor/pushToken?pushAccountReceipts=MCC-C307F0AE-298E-48EB-AA43-A7C40B32DDDE,MSI-1E8GTJ94-9D5T-96MO-WV36-56AZN95Y8DUL,DMC-9H2T37SH-RB3O-PI14-QQ9R-321UGR5ZI07A&callbackURL=issuer%3A%2F%2FpushToken%2Fcallback"); Intent tokenRequestorAppIntent = new Intent(Intent.ACTION_VIEW, tokenRequestorApp); // Build the Browser intent Uri tokenRequestorWeb; if(tokenRequestorSignatureSupport) tokenRequestorWeb = Uri.parse("https://www.tokenrequestor.com/pushToken?pushAccountData=ew0KImFsZyI6ICJSUzI1NiIsDQoNCiJraWQiOiAiYXNkZmctcXdlcnR5LXp4Y3ZiIg0KfQ.ew0KDQrCoCJwdXNoQWNjb3VudFJlY2VpcHQiOiAiTUNDLVNUTC0xMzQzMTNCRi01NTg1LTRFNzEtQUIyNC1FQ0RCQzI4RjIzRjEiLA0KImlzc3VlckNhbGxCYWNrIjogImh0dHBzOi8vaXNzdWVyY2FsbGJhY2sudXJsIiwNCiJjYWxsYmFja1JlcXVpcmVkIjogdHJ1ZSwNCiJjb21wbGV0ZVdlYnNpdGVBY3RpdmF0aW9uIjogdHJ1ZSwNCiJhY2NvdW50SG9sZGVyRGF0YVN1cHBsaWVkIjogdHJ1ZSwNCiJsb2NhbGUiOiAiZW5fVVMiDQoNCn0.dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk"); else tokenRequestorWeb = Uri.parse("https://www.tokenrequestor.com/pushToken?pushAccountReceipts=MCC-C307F0AE-298E-48EB-AA43-A7C40B32DDDE,MSI-1E8GTJ94-9D5T-96MO-WV36-56AZN95Y8DUL,DMC-9H2T37SH-RB3O-PI14-QQ9R-321UGR5ZI07A&callbackURL=issuer%3A%2F%2FpushToken%2Fcallback"); Intent tokenRequestorBrowserIntent = new Intent(Intent.ACTION_VIEW, tokenRequestorWeb); // Verify that App intent resolves PackageManager packageManager = getPackageManager(); List activities = packageManager.queryIntentActivities(tokenRequestorIntent, 0); boolean isAppIntentSafe = activities.size() > 0; // Start the Token Requestor App activity if it's safe, else the Browser activity if (isAppIntentSafe) { startActivity(tokenRequestorAppIntent); } Else { startActivity(tokenRequestorBrowserIntent); } ``` ### From an iOS app {#from-an-ios-app} The Issuer app must call: * The iOS URI (universal link), if available, with appended query string parameters. As the iOS URI is a universal link, it is formatted with an http:// or https:// scheme, and hence it will always resolve, even if the Token Requestor's app is not installed on the device. * The Web URI, with appended query string parameters, if the iOS URI is not available More information on [inter-app communication](https://developer.apple.com/library/content/documentation/iPhone/Conceptual/iPhoneOSProgrammingGuide/Inter-AppCommunication/Inter-AppCommunication.html): ***Example:*** ```swift SURL *tokenRequestorURL; if(tokenRequestorSignatureSupport) *tokenRequestorURL = [NSURL URLWithString:@"http://www.tokenrequestor.com/pushToken?pushAccountData=ew0KImFsZyI6ICJSUzI1NiIsDQoNCiJraWQiOiAiYXNkZmctcXdlcnR5LXp4Y3ZiIg0KfQ.ew0KDQrCoCJwdXNoQWNjb3VudFJlY2VpcHQiOiAiTUNDLVNUTC0xMzQzMTNCRi01NTg1LTRFNzEtQUIyNC1FQ0RCQzI4RjIzRjEiLA0KImlzc3VlckNhbGxCYWNrIjogImh0dHBzOi8vaXNzdWVyY2FsbGJhY2sudXJsIiwNCiJjYWxsYmFja1JlcXVpcmVkIjogdHJ1ZSwNCiJjb21wbGV0ZVdlYnNpdGVBY3RpdmF0aW9uIjogdHJ1ZSwNCiJhY2NvdW50SG9sZGVyRGF0YVN1cHBsaWVkIjogdHJ1ZSwNCiJsb2NhbGUiOiAiZW5fVVMiDQoNCn0.dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk" ]; else *tokenRequestorURL = [NSURL URLWithString:@"http://www.tokenrequestor.com/pushToken?pushAccountReceipt=MCC-C307F0AE-298E-48EB-AA43-A7C40B32DDDE,MSI-1E8GTJ94-9D5T-96MO-WV36-56AZN95Y8DUL,DMC-9H2T37SH-RB3O-PI14-QQ9R-321UGR5ZI07A&callbackURL=issuer%3A%2F%2FpushToken%2Fcallback" ]; [[UIApplication sharedApplication] openURL:tokenRequestorURL]; ``` ## Receive response from Token Requestor {#receive-response-from-token-requestor} The Issuer should use the response from the Token Requestor to display relevant messaging to the user, as well as to update their Issuer's back-end information if needed. | Parameter Name | Description | |----------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | results | The map of results for the tokenization attempts. The pushAccountReceipt values should be used as the key to the map, and the tokenization decision as the value. In the case of an *APPROVED* or *REQUIRE_ADDITIONAL_AUTHENTICATION* decision, the tokenUniqueReference is appended to the decision, separated by a '\|' character. Possible values are: * **APPROVED:** any of the following: (1) The Issuer has approved the provisioning request - (2) The Issuer has requested additional cardholder authentication for the provisioning request, and the authentication has been performed successfully * **REQUIRE_ADDITIONAL_ AUTHENTICATION:** The Issuer has requested additional cardholder authentication, and the authentication hasn't been performed. In the case of wallet tokens (typically for [streamlined activation](https://developer.mastercard.com/mdes-token-connect/documentation/tutorials-and-guides/issuer-implementation-guide/index.md#streamlined-activation-via-issuer-application-web-site)), the token activation is pending successful cardholder authentication. In the case of merchant tokens, the token is active with a token assurance value of 0 (zero) * **DECLINED:** The Issuer has declined the provisioning request. * **CANCELLED:** The Cardholder or Token Requestor has cancelled the provisioning request or has deleted the freshly created token. * **ERROR:** The provisioning request has resulted in an error. * **DUPLICATE_REQUEST** This card/account is already associated with wallet/merchant | **Important notes:** 1. To ensure global acceptance, the special characters '\[', '\]' and '\|' in the results are passed by the Token Requestor in their [URL-encoded](https://www.w3schools.com/tags/ref_urlencode.asp) version, respectively **%5B** , **%5D** and **%7C**. 2. If the callbackURL supplied by the Issuer already contains string parameters introduced by a '?' character (for instance, a session identifier), the Token Requestor keeps these in the redirection URL, and further appends the tokenization results introduced by a '\&' character. **Example 1: Calling back the Android Issuer app -- single card, no issuer-proprietary parameter** * Issuer "Moon Bank" receives MDES Token Connect responses in Android app at moonbank://pushcallback * Issuer has supplied a unique pushAccountReceipt to the Token Requestor, with value MCC-C307F0AE-298E-48EB-AA43-A7C40B32DDDE. * The Token Requestor has successfully tokenized this pushAccountReceipt, creating a token whose tokenUniqueReference is DWSPMC000000000132d72d4fcb2f4136a0532d3093ff1a45 * The resulting (raw) URI is: `moonbank://pushcallback?results[MCC-C307F0AE-298E-48EB-AA43-A7C40B32DDDE]=APPROVED|DWSPMC000000000132d72d4fcb2f4136a0532d3093ff1a45` * After URL-encoding of the special characters, the resulting URI called by the Token Requestor is: `moonbank://pushcallback?results%5BMCC-C307F0AE-298E-48EB-AA43-A7C40B32DDDE%5D=APPROVED%7CDWSPMC000000000132d72d4fcb2f4136a0532d3093ff1a45` **Example 2: Calling back the Issuer web server -- multiple cards, one issuer-proprietary parameter** * To avoid an unnecessary consumer login at callback, Issuer "Moon Bank" receives MDES Token Connect responses on their web server at a dynamic address including a session identifier. "Moon Bank" has supplied this dynamic address to the Token Requestor as callbackURL. For the current session, the desired return URL is `https://www.moonbank.com/pushcallback?session_id=789456123` * Issuer has supplied 3 pushAccountReceipts to the Token Requestor. One has been tokenized successfully, one requires additional authentication, one has not been tokenized due to a manual cancellation by the consumer * The resulting (raw) URI is: `https://www.moonbank.com/pushcallback?session_id=789456123&results[MCC-C307F0AE-298E-48EB-AA43-A7C40B32DDDE]=APPROVED|DWSPMC000000000132d72d4fcb2f4136a0532d3093ff1a45&results[MSI-1E8GTJ94-9D5T-96MO-WV36-56AZN95Y8DUL]=REQUIRE_ADDITIONAL_AUTHENTICATION|DWSPMC00000000032d72d4ffcb2f4136a0532d32d72d4fcb&results[DMC-9H2T37SH-RB3O-PI14-QQ9R-321UGR5ZI07A]=CANCELLED` * After URL-encoding of the special characters, the resulting URI called by the Token Requestor is: `https://www.moonbank.com/pushcallback?session_id=789456123&results%5BMCC-C307F0AE-298E-48EB-AA43-A7C40B32DDDE%5D=APPROVED%7CDWSPMC000000000132d72d4fcb2f4136a0532d3093ff1a45&results%5BMSI-1E8GTJ94-9D5T-96MO-WV36-56AZN95Y8DUL%5D=REQUIRE_ADDITIONAL_AUTHENTICATION%7CDWSPMC00000000032d72d4ffcb2f4136a0532d32d72d4fcb&results%5BDMC-9H2T37SH-RB3O-PI14-QQ9R-321UGR5ZI07A%5D=CANCELLED` ## Streamlined activation via Issuer application / website {#streamlined-activation-via-issuer-application--website} Note: This section is applicable when Issuer supports Activation via Issuer App and/or Activation via Issuer Website as token activation methods. If this is not your case, you can ignore this section. When the Issuer triggers a token provisioning request with Token Connect, the consumer is logged in the Issuer's environment, which means they are already authenticated by the Issuer. Leveraging on this pre-authentication of the cardholder in the Issuer's interface, Token Connect is the opportunity to tokenize cards without additional step-up -- provided appropriate security controls are in place (see [MDES Issuer Implementation Guide](https://techdocs.mastercard.com/bundle/m_MIIG/page/r_SmryChngsMIIG_Apr2020.html?frontSlug=Payment%20Services), chapter Pre-Digitization, section Issuer-Initiated Digitization with MDES Token Connect). Nevertheless, there are still situations where the Issuer will take the decision that an additional Cardholder Authentication is needed before the activation of the token. This section provides recommendations for a better user experience for additional Cardholder Authentication in the case of a provisioning via Token Connect. Cardholder authentication and token activation follow the same principles as digitization initiated by the Wallet Provider. While the consumer is in the Token Requestor's interface, MDES returns the list of available authentication methods, and the consumer selects their authentication method. If the cardholder selects an activation via Issuer app or web site, in theory, the user experience may become very painful, as the cardholder would be taken from Token Requestor's environment to an Issuer's interface (for activation), then back to Token Requestor (activation complete), then again to Issuer (provision through Token Connect complete). To avoid these back-and-forth interface toggles and provide a better experience, the Issuer may decide to use streamlined activation with Issuer's app or web site. The Issuer will pass additional parameters in the URL to the Token Requestor: these will indicate that if the consumer selects activation via Issuer app (respectively web site), the Token Requestor should NOT try to activate the token using the information supplied by MDES, and should return control to the Issuer via the Token Connect callback URL after all tokenizations (in the case of multiple pushed cards) are completed. In this case, the cardholder will activate the token from the Issuer's app (or corresponding web site) when driven back there. The Issuer's app/website may either bypass additional authentication or require cardholder to complete authentication at this point. The Issuer's uses [MDES Customer Service API](https://developer.mastercard.com/mdes-customer-service/documentation) to request the activation of the token to MDES. The URL query string parameters to use so as to enable streamlined activation are: * completeIssuerAppActivation * completeIssuerWebActivation They are further described above, section [Append Parameters to Token Requestor URI](https://developer.mastercard.com/mdes-token-connect/documentation/tutorials-and-guides/issuer-implementation-guide/index.md#append-parameters-to-token-requestor-uri). The figure below illustrates the difference between a standard activation and a streamlined activation using Issuer application: ![alt text](https://static.developer.mastercard.com/content/mdes-token-connect/documentation/tutorials-and-guides/img/streamlinedactivation.png "Integration") ## Summary: User Interface Design Check-list {#summary-user-interface-design-check-list} Issuers must ensure that they respect the following check-list when creating wireframes for their website and application(s) for the push provisioning operation. During the implementation project with Mastercard, Mastercard will validate the wireframes submitted by the Issuer against the check-list below. Any deviation from this check-list must be duly justified and documented to Mastercard: 1. Token Requestors must be presented in the list of potential destinations with their logo and consumer-facing name 2. Issuer must show wallet(s) and merchant(s) option similar with other push candidates. All the candidates where user can push his/her account(s) must be at same level in issuer user experience. 3. The Issuer must remove from the list of Token Requestors those that are not available for the hosting environment (for instance, on a desktop computer, eliminate Token Requestors not supporting 'WEB' interface) 4. When redirecting to the Token Requestor's interface, the Issuer's implementation must allow the Token Requestor to launch their mobile app (when supported), as well as read and write cookies. 5. If the Token Requestor selected by the account holder only accepts a single pushAccountReceipt, the Issuer user Interface shall not allow the selection of multiple cards/accounts 6. The Issuer must respect local laws and regulations related to Personally Identifiable Information (PII) if they elect to transmit account holder data to the Token Requestor. This includes, but is not limited to, supplying a privacy notice and obtaining necessary consents. 7. When the Token Requestor app or website redirects the consumer back to the Issuer interface, the Issuer interface must indicate to the consumer the outcome of the digitization for each card/account. 8. If the Issuer supports token activation via their app or website, activation must be proposed to the consumer if the Token Requestor indicates a result of REQUIRE_ADDITIONAL_AUTHENTICATION for a wallet token. ## What's new {#whats-new} Significant changes to this page are tracked here: | Date | Description of Change | |----------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | Jan 19, 2022 | * Depricate [pushAccount](https://developer.mastercard.com/mdes-token-connect/documentation/api-reference/index.md) * Added support of [pushMultipleAccounts](https://developer.mastercard.com/mdes-token-connect/documentation/api-reference/index.md) | | Feb 24, 2021 | * Depricate [callbackRequired](https://developer.mastercard.com/mdes-token-connect/documentation/tutorials-and-guides/issuer-implementation-guide/index.md#append-parameters-to-token-requestor-uri) * Changes for Jan'21 and Feb'21 releases | | March 25, 2020 | * New optional query string parameter [callbackRequired](https://developer.mastercard.com/mdes-token-connect/documentation/tutorials-and-guides/issuer-implementation-guide/index.md#append-parameters-to-token-requestor-uri) introduced * New optional query string parameter [locale](https://developer.mastercard.com/mdes-token-connect/documentation/tutorials-and-guides/issuer-implementation-guide/index.md#append-parameters-to-token-requestor-uri) introduced New [requirements](https://developer.mastercard.com/mdes-token-connect/documentation/tutorials-and-guides/issuer-implementation-guide/index.md#redirection-building-the-best-consumer-experience) to invoke Token Requestor's web URI | | March 30, 2020 | * Added references to [Provisioning Cards to Mastercard Click to Pay](https://developer.mastercard.com/product/click-to-pay#resources-issuing-partners) |