# Overview

## Push provisioning overview

Push provisioning lets the issuer application add a payment card directly into an xPay Wallet (for example Apple Pay, Google Pay, or Samsung Pay) using secure, standardized protocols. This removes the need for the end user to manually enter card details and improves both security and user experience.

### How push provisioning works

Instead of entering or passing card details manually to a token requestor, the issuer application exchanges card data through secure protocols that prevent card details from being exposed outside the device that will use the credentials.

The push provisioning flow typically triggers Tokenization through the relevant TSP.

There are two main types of protocols:

* **Wallet provider proprietary protocols**: APIs exposed by each wallet provider to simplify integration and data exchange between the wallet and the issuer application.
* **Payment network TSP protocols**: APIs exposed by each payment network's TSP that allow issuers to push cards to certified token requestors.

With proprietary protocols, every wallet provider defines its own:

* integration model and how to interface with the wallet (for example, dedicated mobile SDKs)
* encryption mechanisms and keys required to protect the card details

The D1 push provisioning service removes this complexity. The D1 SDK wraps these different APIs and provides a single, wallet- and scheme-agnostic integration model.

Similarly, for payment network TSP protocols, the issuer can join the individual payment network programs to push cards into eligible token requestors certified by the payment network. The D1 SDK and D1 backend handle the payment network–specific logic for you.

### Supported protocols and devices

The D1 platform supports the following:

* **Proprietary wallet protocols**
  * Apple Pay, Google Pay, and Samsung Pay. See [Implement push to digital wallets](/push-provisioning/implement-push-provisioning/implement-push-to-digital-wallets.md).
* **Payment network protocols**
  * [Mastercard token connect](/push-provisioning/implement-push-provisioning/implement-push-to-scheme/push-to-token-requestors-token-connect.md).
* **Devices**
  * Android OS
  * Apple iOS

{% hint style="warning" %}
***Google Unified Android Push Provisioning** – Thales will support the new API and the Google-OPC model by October 2026.*

*Thales will send a communication by June 2026 to allow issuers to properly plan the migration activities.*
{% endhint %}

### View and control feature

The D1 SDK also provides a **View and control** feature that lets the issuer application display and manage the digital cards created from each physical or funding card.

This is useful when the issuer wants to:

* offer digital card life cycle management directly in the issuer application
* control digital card activation, especially when ID\&V or step-up authentication is performed through the issuer application

For implementation details, see [View and control](/push-provisioning/implement-push-provisioning/implement-view-and-control/view-and-control-digital-cards.md).

### Example push provisioning experience

Use the following wallet provider guidelines to design the **Add to wallet** experience in your issuer application:

* [Apple Pay](https://developer.apple.com/documentation/passkit/pkaddpassbutton)
* [Google Pay](https://developers.google.com/pay/api/android/guides/brand-guidelines)
* [Samsung Pay](https://pay.samsung.com/developers/resource/brand)

#### Apple Pay

1. The end user opens the issuer application and authenticates.
2. The end user selects a card.
3. The end user taps **Add to Apple Wallet**.

If the end user has both an iPhone and an Apple Watch, the issuer application does not need any additional information to link the payment card. The Apple PassKit SDK handles the device selection UI, for example prompting the end user to choose between iPhone and Apple Watch.

<figure><img src="/files/NyBfF8TkzONFPbkP16jU" alt="Apple Pay push provisioning example screen in the issuer application"><figcaption><p>Example of an Add to Apple Wallet flow in the issuer application.</p></figcaption></figure>

#### Google Pay

1. The end user opens the issuer application and authenticates.
2. The end user selects a card.
3. The end user taps **Add to Google Pay**.

<figure><img src="/files/xA8wxPwDIFHSzEyJ5zXZ" alt="Google Pay push provisioning example screen in the issuer application"><figcaption><p>Example of an Add to Google Pay flow in the issuer application.</p></figcaption></figure>

#### Samsung Pay

1. The end user opens the issuer application and authenticates.
2. The end user selects a card.
3. The end user taps **Add to Samsung Pay**.

<figure><img src="/files/VoEntLenSIXWIXYAeL3h" alt="Samsung Pay push provisioning example screen in the issuer application"><figcaption><p>Example of an Add to Samsung Pay flow in the issuer application.</p></figcaption></figure>

### Example view and control experience

In the issuer application, the end user can see the list of digital cards associated with each of their cards.

The issuer application can display:

* the last four digits of each digital card
* the wallet name and logo
* the state of each digital card (for example, active, suspended, or deleted)

<figure><img src="/files/00C4m0dF1tnpDFIndzI9" alt="View and control example screen listing multiple digital cards for a single card"><figcaption><p>Example of the View and control screen showing multiple digital cards.</p></figcaption></figure>

### Example of payment network push provisioning

<figure><img src="/files/df1NCeDMULuzTSyQdk1t" alt="High-level example of payment network push provisioning"><figcaption><p>High-level example of a payment network push provisioning flow.</p></figcaption></figure>


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.payments.thalescloud.io/push-provisioning/get-started/push-provisioning-overview.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.