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

## General {#general}

Push Provisioning is the ability for a consumer to provision their payment credentials from an issuer mobile application or website to a token requestor. It is also referred to as issuer-initiated digitization.

For more information, see [MDES Token Connect APIs](https://developer.mastercard.com/issuer-enrollment/documentation/use-cases/push-provisioning/mdes-token-connect/index.md).
MDES Token Connect is the framework that supports issuer-initiated digitization. It connects MDES Issuers with open-loop MDES Token Requesters so they can push eligible cards into a token requestor experience.

For more information, refer to [MDES Token Connect](https://developer.mastercard.com/mdes-token-connect/documentation/#overview).
Consumers typically enroll through the Issuer's website or app when prompted to complete registration or provisioning. See the [Push Provisioning use cases](https://developer.mastercard.com/issuer-enrollment/documentation/use-cases/push-provisioning/index.md) for the supported enrollment approaches.

## Enrollment {#enrollment}

### Onboarding {#onboarding}

Yes. Review the rejection email, address the listed items, and submit a new production access request. See the [Production onboarding tutorial](https://developer.mastercard.com/issuer-enrollment/documentation/tutorials-and-guides/issuer-onboarding-click2pay-production-tutorial/index.md) for the production enrollment process. Follow these steps to prepare a Sandbox integration:

1. Confirm that issuer is enrolled in MDES and can access Mastercard Connect.
2. Request access to the "Mastercard Checkout Solutions - Sandbox" application and have your Security Administrator approve it.
3. Enroll in the Click to Pay program, then create a Sandbox project.
4. Use the project's Sandbox keys and `srcClientId` to configure and test your integration.

See the [Issuer Onboarding tutorial](https://developer.mastercard.com/issuer-enrollment/documentation/tutorials-and-guides/issuer-onboarding-click2pay-tutorial/index.md) for the full process and [Key Management](https://developer.mastercard.com/issuer-enrollment/documentation/tutorials-and-guides/key-management-click2pay-tutorial/index.md) for key details.
1. Complete Sandbox testing and the required certification with your Mastercard representative.
2. Follow the [Production onboarding tutorial](https://developer.mastercard.com/issuer-enrollment/documentation/tutorials-and-guides/issuer-onboarding-click2pay-production-tutorial/index.md) to request and complete Production enrollment.

### Auto Enablement {#auto-enablement}

For the auto-enablement workflow, see [Auto Enablement](https://developer.mastercard.com/issuer-enrollment/documentation/use-cases/auto-enrollment/index.md).
Issuer must:

* Follow the legal procedures for collecting consumers' personal information (PII data) and using it for data processing.  
* Take responsibility for managing and updating the consumer data in the directory.  
* Ensure required updates to the Terms and Conditions between the 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. This limit applies whether the batch contains all cards associated with one profile or cards belonging to multiple consumer profiles. Yes. Mastercard tokenizes cards received from the bank in the enablement request, and 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 the enablement process happens asynchronously, following card provisioning, tokenization, enablement, and profile creation. After successful auto-enablement, it takes time before the linked cards appear in the Issuer banking app. Yes. Cards can also be managed using 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. Mastercard identifies duplicate cards within Click to Pay and avoids showing repeated entries in the card list during checkout.

## Integration {#integration}

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.

Download the API Signing Key and Consumer Key for your project from Mastercard Connect; see [Key Management](https://developer.mastercard.com/issuer-enrollment/documentation/tutorials-and-guides/key-management-click2pay-tutorial/index.md). For protocol details, follow the [OAuth guide](https://developer.mastercard.com/platform/documentation/security-and-authentication/using-oauth-1a-to-access-mastercard-apis/).
Use this checklist to prepare and test OAuth authentication:

1. Confirm that you have the project's API Signing Key and Consumer Key; see [Key Management](https://developer.mastercard.com/issuer-enrollment/documentation/tutorials-and-guides/key-management-click2pay-tutorial/index.md).
2. Configure the client to sign requests with OAuth 1.0a, following [Mastercard's OAuth validation guidance](https://developer.mastercard.com/platform/documentation/security-and-authentication/using-oauth-1a-to-access-mastercard-apis/#how-can-i-validate-my-oauth-implementation).
3. Send a test request with your client or the [Mastercard Insomnia plugin](https://developer.mastercard.com/platform/tutorial/use-insomnia-rest-client-for-mastercard-apis/).
4. If the request fails, check the response details and consult [Code and Formats](https://developer.mastercard.com/issuer-enrollment/documentation/code-and-formats/index.md); the page documents, for example, gateway 401 responses caused by OAuth signature problems.
Use the [Perform Encryption](https://developer.mastercard.com/issuer-enrollment/documentation/tutorials-and-guides/perform-encryption-tutorial/index.md) tutorial to obtain the required public keys and encrypt sensitive data, including card-related objects. The MDES Token Connect framework supports four main connection types:

* 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.

See the [MDES Token Connect use case](https://developer.mastercard.com/issuer-enrollment/documentation/use-cases/push-provisioning/mdes-token-connect/index.md) for the documented issuer flow.
MDES Token Connect is designed to connect Issuers and Token Requestors for push provisioning when they are different entities.

If your Issuer wallet accepts only cards (or accounts) issued by your organization, your wallet is considered a closed wallet. In this model, the Issuer and Token Requestor are the same entity, so implementing the Token Requestor side of MDES Token Connect is not required.

If your Issuer wallet can host cards issued by other Issuers, your wallet is considered an open wallet. In this model, the Token Requestor and Issuer may be different entities. Implementing the Token Requestor side of MDES Token Connect enables your wallet to appear as an eligible destination in the mobile payment applications of participating Issuers, allowing cardholders to push their cards to your wallet.

For the Token Requestor implementation guide, see [MDES Token Connect -- Token Requestor Implementation Guide and Specification](https://www.mastercardconnect.com/-/sign-in?MCCRedirectTo=https://w204.mastercardconnect.com%2FFIMIDP%2Fsps%2Fauth) (requires Mastercard Connect access).
MDES strongly recommends starting provisioning only after the consumer has completed sign-in or sign-up. This avoids mis-association of the provisioning flow and reduces the risk of a Push Receipt NOT FOUND error.

If you need to initiate provisioning before the consumer completes the sign-in or sign-up process, you must ensure that the token is not associated with a consumer profile. To do this:

* Remove any cardholder PII received in the Tokenize Response from your systems as soon as possible.
* Delete the token using the Delete API as soon as possible after receiving the Notify Token Updated notification for the provisioning request.

## Policy {#policy}

MDES Token Connect supports account ranges that Issuers have enabled for MDES, including Mastercard card account ranges, Maestro card account ranges, and "Pay with Bank Account" financial account ranges. For Private Label account ranges, contact your Mastercard representative. The [MDES Token Connect use case](https://developer.mastercard.com/issuer-enrollment/documentation/use-cases/push-provisioning/mdes-token-connect/index.md) describes the related issuer flow. Yes. MDES Token Connect can make token provisioning easier to implement and provide a smoother experience for your cardholders, depending on how your wallet is configured. If you offer an Issuer wallet, such as a cloud-based wallet (MCBP) that supports contactless or online payments, you are acting as both the card Issuer and the Token Requestor. MDES Token Connect is designed to support this type of setup. No. You do not need to enter your Card Verification Code (CVC2) when adding your card using MDES Token Connect.

MDES Token Connect is designed to make it easier to add your card to a digital wallet without requiring you to manually enter your card details. When you use MDES Token Connect, you will not be asked to enter your CVC2 in your Issuer's app or website, or later in the wallet app.

## Performance {#performance}

Most open wallets, merchants, and commerce platforms may participate in MDES Token Connect, provided they meet Mastercard's admission requirements. Token Requesters must support push-provisioning requests from Issuers in their app or website.

The supported Token Requester list changes over time. Issuers can call [`getEligibleTokenRequestors`](https://developer.mastercard.com/issuer-enrollment/documentation/api-reference/index.md#available-apis) to retrieve the requestors enabled for one or more of the Issuer's account ranges.
An empty array is expected when there are no eligible Token Requestors available for the card being provisioned.

* If you are an Issuer providing an Issuer wallet to your cardholders, such as a cloud-based wallet (MCBP) supporting contactless or online payments, you may also act as the Token Requestor. In this case, your wallet is associated with the same entity as the Issuer, and the Token Requestor may not need to be returned as an eligible Token Requestor for push provisioning.
* If your wallet is a closed wallet, meaning it accepts only cards issued by your organization, you generally do not need to implement the Token Requestor side of MDES Token Connect. Consequently, getEligibleTokenRequestors may return an empty array.
* If you are expecting Token Requestors to be returned, verify that the card and wallet configuration supports push provisioning to eligible Token Requestors.

For the related API flows, see the [MDES Token Connect use cases](https://developer.mastercard.com/issuer-enrollment/documentation/use-cases/push-provisioning/mdes-token-connect/index.md).
Token Requesters provide redirect URIs to MDES, and those URIs can be updated by the Token Requestor at runtime. Issuers should not whitelist Token Requestor URIs as a hard-coded static list because those values may change. For the redirect flow, see the [MDES Token Connect use case](https://developer.mastercard.com/issuer-enrollment/documentation/use-cases/push-provisioning/mdes-token-connect/index.md).

## Support {#support}

If you have an assigned Project Manager through Customer Implementation Services, contact them directly with your onboarding and registration queries. If you do not have an assigned Project Manager, use the **Get Help** button at the bottom of this page to submit your request. When raising a technical issue, include:

* The environment (Sandbox or Production) and affected API or operation.
* Steps to reproduce the issue and the expected and actual results.
* The Correlation ID and, for API errors, the error response details.
* A screenshot or video showing the issue and a HAR file, if available.

Before sharing screenshots, response data, or HAR files, remove or redact credentials, access tokens, session cookies, and cardholder data. For help interpreting API errors, see [Code and Formats](https://developer.mastercard.com/issuer-enrollment/documentation/code-and-formats/index.md).

### Get Help {#get-help}

For API or SDK integration issues, email [APISupport@mastercard.com](mailto:APISupport@mastercard.com) and include the diagnostic details listed in [What information should I include when I request assistance?](https://developer.mastercard.com/issuer-enrollment/documentation/support/index.md#what-information-should-i-include-when-i-request-assistance). For onboarding and registration questions, contact your assigned Project Manager through Customer Implementation Services. If you do not have one, use the **Get Help** button.

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