Welcome to our new developer portal! Use the "Ask" button to chat with our AI Agent.
For the complete documentation index, see llms.txt. This page is also available as Markdown.

Native Provisioning

The Native Provisioning process enables the issuance of a new, anonymous transit card directly from Google Wallet.

Workflow

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

  1. Fare Product Selection & Payment: user selects the fare product he wants to purchase. Once selected, user authorizes the purchase of the selected fare product and the payment is processed by the PSP.

  2. Provisioning: Google fetches the provisioning bundle containing the card details.

  3. Provisioning Outcome: Google sends a notification indicating the provisioning result.

Sequence diagram

Fare Product Selection & Payment

The user begins by selecting the transit card within the Google Wallet and loading it with an eligible fare product of their choice. Before proceeding to payment, Google Wallet will present the transit issuer's terms and conditions, which the user must review and accept to continue. Once accepted, the user will be directed to a payment interface displaying a payment sheet, where they can choose an eligible payment card to complete the purchase.

Error scenarios

When a payment failure or timeout occurs, Google Wallet displays an error to the user. The user can retry the payment using the same or a different payment credential.

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

Provisioning

Once the user has successfully completed payment, Google starts sending provisioning requests to obtain the encrypted provisioning bundle.

Error Scenarios

No request from Google to get the provisioning bundle

A timeout period between purchase products response and getOpaqueAuthenticationCredential request from Google is set on D1 Transit side.

If the getOpaqueAuthenticationCredential request is not received by D1 Transit within this timeout period, card account and digital card references are completely discarded. Transit issuer shall refund the customer.

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

Provisioning Outcome

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.

Last updated

Was this helpful?