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.

• Payment network protocols

  • Mastercard token connect.

• Devices

  • Android OS

  • Apple iOS

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.

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.

Example push provisioning experience

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

• Apple Pay

• Google Pay

• Samsung Pay

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.

Example of an Add to Apple Wallet flow in the issuer application.

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.

Example of an Add to Google Pay flow in the issuer application.

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.

Example of an Add to Samsung Pay flow in the issuer application.

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)

Example of the View and control screen showing multiple digital cards.

Example of payment network push provisioning

High-level example of a payment network push provisioning flow.