# Support
source: https://developer.mastercard.com/issuer-enrollment/documentation/support/index.md

## Onboarding {#onboarding}

If you have opened a project with our Customer Implementation Services and have an assigned Project Manager, please reach out to them for assistance with your onboarding and registration queries. Otherwise, please click the **Get Help** button at the bottom of this page. If you have been denied production access, an email with the reason for rejection is provided. After completing the rejected items, you can request production access again.

## Authentication and Encryption {#authentication-and-encryption}

The APIs use [OAuth 1.0a](https://developer.mastercard.com/platform/documentation/security-and-authentication/using-oauth-1a-to-access-mastercard-apis/) for authenticating client applications. POST requests (with a body) must be signed using the Google Request Body Hash extension for OAuth. **Note** : the API Signing Key (OAuth Key) can be downloaded from Mastercard Connect, as detailed in [Adding Keys](https://developer.mastercard.com/issuer-enrollment/tutorial/key-management-click2pay/index.md). You should refer to [How can I validate my OAuth implementation?](https://developer.mastercard.com/platform/documentation/security-and-authentication/using-oauth-1a-to-access-mastercard-apis/#how-can-i-validate-my-oauth-implementation) to check that your OAuth implementation is working correctly.

Also, Mastercard provides a plugin for Insomnia which you may use to test your own API Signing Key [Using Insomnia REST Client with Mastercard APIs](https://developer.mastercard.com/platform/tutorial/use-insomnia-rest-client-for-mastercard-apis/).
The [Perform Encryption](https://developer.mastercard.com/issuer-enrollment/tutorial/perform-encryption/index.md) tutorial contains details on how to obtain Mastercard public keys and encrypt an object, such as a PAN/card.

## Push Provisioning {#push-provisioning}

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 the [use cases](https://developer.mastercard.com/issuer-enrollment/documentation/use-cases/push-provisioning/mdes-token-connect/index.md).
MDES Token Connect is the MDES framework supporting issuer-initiated digitization.

It connects MDES Issuers with open-loop MDES Token Requesters. For more information about issuer-initiated digitization with MDES Token Connect, please refer to [MDES Token Connect](https://developer.mastercard.com/mdes-token-connect/documentation/#overview) page.
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](https://developer.mastercard.com/issuer-enrollment/documentation/support/index.md#get-help).
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. The MDES Token Connect framework has been designed to connect Issuers and Token Requesters for push provisioning, when Issuers and Token Requestors are different entities.

If your Issuer wallet application accepts only cards (or accounts) 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.

For more information about how to implement the Token Requester "side" of MDES Token Connect, please refer to [MDES Token Connect -- Token Requestor Implementation Guide and Specification](https://www.mastercardconnect.com/-/sign-in?MCCRedirectTo=https://w204.mastercardconnect.com%2FFIMIDP%2Fsps%2Fauth) in a new tab (requires access to Mastercard Connect).
Most MDES Token Requesters (Open Wallets, Merchants, Commerce Platforms) are eligible to participate in the MDES Token Connect framework. However, Token Requestors must fulfill specific requirements before being admitted to the framework.

However, Token Requesters 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 Requesters supporting the 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 accepted by Mastercard in the MDES Token Connect framework.
Enroll through the Issuer's website or app when prompted. 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. 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.
The MDES Token Connect framework supports up to four connection types. The following connections are supported:

* Issuer website to token requester website.
* Issuer website to token requester app (Android and iOS).
* Issuer app (Android and iOS) to token requester app (Android and iOS).
* Issuer app (Android and iOS) to token requester website.
Most MDES Token Requesters (Open Wallets, Merchants, Commerce Platforms) are eligible to participate in the MDES Token Connect framework. However, Token Requestors must fulfill specific requirements before being admitted to the framework.

However, Token Requesters 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 Requesters supporting the 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 accepted by Mastercard in the MDES Token Connect framework.
Token Requester 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 completed 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 receive the Push Receipt NOT FOUND error.

If a token requester 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.

## Auto Enrollment {#auto-enrollment}

Issuer must:

* Follow the legal procedures for collecting consumers' personal information (PII data), and using the information for data processing.  
* Take responsibility for managing and updating the consumer data in the directory.  
* Ensure to make required updates to the Terms and Conditions between Issuer and Consumer.
Enroll API-Asynchronous can enable multiple cards associated with a single profile, or multiple profiles in one batch. However, the maximum number of cards in each batch must not exceed 250. In a single batch, this number can either be the total number of cards for an individual profile, or the total number of cards belonging to different consumer profiles. Mastercard will tokenize the cards received from the bank in the enablement request. In fact, all the cards passed by Issuers must be successfully tokenized and enabled, for the profiles to be created or saved in the Issuer Segregated Directory. It is called Enroll API-Asynchronous because it is an asynchronous enablement process that does not occur at the same time or within the same phase. It follows internal due diligence for card provisioning, tokenization, enablement, and profile creation. Hence, after successful auto-enablement, it takes some time to show the linked cards to the cardholder on the Issuer banking app. Cards can also be managed by the existing [MDES Customer Service APIs](https://developer.mastercard.com/mdes-customer-service/documentation/api-reference/), and [Automatic Billing Updater (ABU)](https://developer.mastercard.com/automatic-billing-updater/documentation/) process. Currently, cards can exist in both the Click to Pay and the Issuer Segregated directory following auto-enablement. Mastercard will identify duplicate cards within Click to Pay and not show repeated cards in the card list during checkout.  

## Get Help {#get-help}

There are several ways you can request help:

* For any issues regarding your API or SDK Integrations contact: [APISupport@mastercard.com](mailto:APISupport@mastercard.com).   
  Please provide the following transaction details to facilitate investigation:
  * Correlation ID for the particular transaction.
  * Video or screenshot showing as much detail of the issue as possible.
  * HAR file (if possible).

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