Suspend/Resume from Transit Issuer

Issuer-initiated suspension and resumption are actions triggered by the Transit Issuer or, in some cases, by the user via the transit operator's app.

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

Workflow

Suspension / Resumption

Below are the high level steps of the suspension/resumption workflow:

1. State change initiation: The Transit Issuer or, in some cases the user (via the transit operator's app) notifies D1 Transit that a card state change should be performed. D1 Transit platform then informs Google by sending handleTspEvent.
2. State change execution: Once event is delivered to Google, D1 Transit updates the digital card state change. Google, will later on, sends a getTokenStatus in order to fetch and apply the state change from D1 Transit.

Sequence Diagram

Suspension / Resumption

For suspension, Transit Issuer should primarily add the card to the deny list. Adding the card to the deny list is crucial if the device is offline, as the card may not be suspended immediately.

Transit Issuer sends a manageDigitalCard to D1 Transit platform, which itself, sends handleTspEvent to Google.

Upon receiving this request, Google will fetch the state change to apply and attempt to apply it to the digital card on the device, though this is on a best-effort basis since the device could be offline.

D1 Transit notifies the Transit Issuer that the state change order was submitted to Google.

Error Scenarios

Device is offline

If the device is offline, the request to change the card state is queued and will be sent to the device as soon as it reconnects.