Transit イシュアからの復元

The restore process is initiated directly by the user from his transit mobile application. The primary goal is to re-enable a previously parked transit card, which is securely linked to the user's Google account, and provision it onto the device.

This section provides an overview of the workflow, including detailed steps, sequence diagrams, and potential error scenarios.

Workflow

Below are the high level steps of the restore workflow:

1. Card Account Selection: The user selects a previously parked transit card via the transit mobile application.
2. Provisioning: The selected card undergoes the standard provisioning workflow to be reactivated on the device.
3. Restore Outcome: Google sends a notification to D1 Transit with the outcome of the restore workflow.

Sequence diagram

Card Account Selection

The user begins the restore workflow from the transit mobile application.

Transit mobile application interacts with Transit mobile application server in order to retrieve available cards for restoration.

Then, the restoration process begins with a preparePushProvisioningBundle (similarly to the push provisioning flow).

Error Scenarios

Card account not eligible for restore

In case, the card account selected for restore, and specified within preparePushProvisioningBundle request, is not eligible, D1 Transit returns an error to Transit Issuer.

Provisioning

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.

Restore 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, D1 Transit notifies Transit issuer about the failure.

The digital card is deleted from D1 Transit system and the card account can be provisioned to another device using the same Google account.