> For the complete documentation index, see [llms.txt](https://docs.payments.thalescloud.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.payments.thalescloud.io/transit-digitization/implement-google-transit/account-based-ticketing-abt/push-provisioning.md).

# Push Provisioning

The Push Provisioning workflow allows users to provision cards from the issuer app to Google Wallet.

### Workflow <a href="#workflow" id="workflow"></a>

Below are the high level steps of the Push provisioning workflow:

1. **Provisioning**
   1. **Initiation**: Use TapAndPay APIs to initiate the push provisioning process.
   2. **Bundle delivery**: Google fetches the provisioning bundle containing the card details.
2. **Provisioning Outcome**: Google sends a notification indicating the provisioning result.

This workflow assumes that the user already has a valid transit card linked to his card account. If the user does not have a transit card, he can either purchase one through the transit operator app or, if supported, use the app to read the content of his plastic card before provisioning it to the Google Wallet.

### Sequence diagram <a href="#sequence-diagram" id="sequence-diagram"></a>

{% hint style="info" %}
It is important to note that the Transit Issuer shall start preparing the data required to issue the digital card as soon as the payment request is validated with the PSP
{% endhint %}

#### Provisioning <a href="#provisioning" id="provisioning"></a>

When the user presses the "Add to Google Wallet" button, the transit operator's mobile app must provide the card details to its backend to begin the preparation of the provisioning bundle. D1 Transit generates an encryptedData payload containing the necessary details to initiate the provisioning workflow. This encryptedData payload is then sent back to the transit operator's mobile app, which subsequently calls TapAndPay API pushTokenizeRequest to initiate the provisioning workflow with Google.

Upon receiving the encryptedData, Google initiates EMV tokenization process with D1 Transit in order to eventually obtain the encrypted provisioning bundle.

**Error Scenarios**

**No request from Google to get the provisioning bundle**

A timeout period between prepare push provisioning bundle response and provisioning request from Google is set on D1 Transit side.

If the provisioning request is not received by D1 Transit within this timeout period, the provisioning is considered as failed.

If Google requests the provisioning after the timeout, D1 Transit will notify Google that the provisioning bundle is no longer available, prompting Google to halt the provisioning workflow.

<figure><img src="/files/kJFLBjuNvEiQZNWQTqJJ" alt=""><figcaption></figcaption></figure>

#### Provisioning Outcome <a href="#provisioning-outcome" id="provisioning-outcome"></a>

Once Google receives the provisioning bundle, the keys and data are securely extracted and stored. After completing personalization, an acknowledgePaymentBundle is sent to D1 Transit to report the outcome of the provisioning workflow.

**Error Scenarios**

**Card fails to provision onto device**

If provisioning fails, Google doesn't provide any notification to D1 Transit platform. As a consequence, D1 Transit waits for the configured timeout to be reached (see below).

**No acknowledgePaymentBundle Request from Google**

D1 Transit has a timeout period after sending the provisioning bundle to Google. If no acknowledgePaymentBundle is received within the specified timeframe, D1 Transit completes the worklow considering the provisioning as failed, i.e. Transit issuer is notified so it can:

* refund the customer and notify D1 Transit that the card account is deleted.
* Allow the customer to reinitiate push provisioning provisioning

Transit Issuer may rely on **getCardAccountInfo** API to check what are cardAccount information stored within D1 Transit platform (card account state, digital cards linked to card account) in order to make a decision.

<figure><img src="/files/S18L3U6PLN5KRjJ5ws7j" alt=""><figcaption></figcaption></figure>


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## 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, and the optional `goal` query parameter:

```
GET https://docs.payments.thalescloud.io/transit-digitization/implement-google-transit/account-based-ticketing-abt/push-provisioning.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

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.