This document discusses the steps a Public Transit Operator (PTO) and their system integrator, hereafter referred to as issuer, need to take to provide a Motics implementation in Google Wallet.
1. Complete Prerequisites
- Sign a non-disclosure agreement (NDA) with Google. This click-to-accept online form is shared by Google's business development (BD) team.
- Integrate with the standard Google Wallet API for QR codes:
- The issuer uses the Google Wallet API to provision passes and add them to a user's Google Wallet app. Review the Transit QR Codes documentation and complete the necessary prerequisites to integrate with the API.
- Register with the VDV eTicket Service to obtain an ownerId (orgId) and the relevant PKI details required for Motics.
2. Technical Implementation
Step 2 contains the main technical implementation details, which should be developed in parallel.
Upgrade your Google Wallet API Implementation
The Technical Details page outlines the methods and parameters the issuer needs to use and update for the Motics integration. Specifically, the issuer needs to call the following Google Wallet API methods with additional Motics related parameters:
Implement activation endpoint
The Google server calls the issuer-hosted activation endpoint. This triggers the generation of the static entitlement data (sigSTB) on the issuer server. Review the activation endpoint section for details.
Implement the Move & Unlink Flow
To provide a good user experience, a user should be able to move their Motics ticket from one device to another, within certain limits defined by the issuer. For this, the issuer has to implement the Move and Unlink Flow.
Send confirmation email on ticket save
Google requires that the issuer sends a confirmation email to users when they save a Motics ticket to Google Wallet. The confirmation email should (at a minimum) contain:
- Useful links for users to manage their ticket (subscription).
- Instructions how to contact the issuer's customer support.
3. Perform end to end integration testing in STAGING
Create a Google Wallet test transitClass for development use and once the
integration work is complete, the solution needs to be validated and tested
end to end using this development transitClass. In the transitObject:Insert,
set the cert_environment to STAGING. All use cases should be fully tested
and all test cases must have a successful outcome.
4. Perform end to end testing in PRODUCTION
Once the solution has been successfully tested using the STAGING environment,
create a new production transitClass. This time set the cert_environment to
PRODUCTIONwhen inserting the transitObject. Follow and complete all test
cases and instructions in the Testing section.
5. Follow the launch process & obtain approvals
Before launching or commencing a public pilot, full launch approval must have been granted by Google. Approval depends on the outcome of the various testing phases as well as other factors such as (but not limited to) the following that must be reviewed and approved by Google:
- Overall launch scope & plan
- In case of a pilot, the launch plan must include clear exit criteria and timelines to proceed to a full launch.
- Planned Marketing Activities
- Launch Communications
- Launch Date
- Launch day timelines and escalation process & contacts
- End user support processes