Park from Transit Issuer

The issuer-initiated parking workflow can be triggered through one of the following 2 methods:

1. User uses his mobile application.
2. Directly from Transit Issuer system following business rules.

In both cases, D1 Transit solution receives a request from Transit Issuer system.

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 issuer initiated parking workflow:

1. Card Removal: Transit issuer initiates the removal of the card from user's device.
2. Park Card: In CBT ecosystem, there is a need to read the content of the applet instance within the device. To do so, Apple intiates a park redirect session with device.

Sequence diagram

Card removal

Transit Issuer initiates a "park" session with device using the manageDigitalCard (unlink) request to D1 Transit.

D1 Transit sends the unlink request to Apple, so device can be woken up in order to fetch the commands to be executed for parking the card.

Park card

Once device is online, it will connect to D1 Transit server with a get pending commands request. D1 Transit sends getDigitalCardBundleCommands to Transit Issuer to fetch the commands that shall be returned and executed on device side.

Several round trips may occur to complete the park session.

At the end of the park session, D1 Transit sends a lifecycle notification to Transit Issuer.

Error Scenarios

Device Offline

As the request is not device-initiated, there is no certainty that the device will be online. In such cases, the request may never reach the device.