The Google Pay API for Passes allows you to engage with users through transit passes for buses, ferries, trains, and more. The concepts discussed in this guide should help you better understand the capabilities of transit passes.
To implement transit passes, use the JWT POST request method or "skinny" JWT links, which are methods that pre-insert the classes and objects.
TransitClasses and TransitObjects
Like other verticals in Google Pay API for Passes, data for transit passes is stored in two
data structures: TransitClass and TransitObject. This guide
explains how these data structures can be used to support your transit passes.
TransitClass
TransitClass defines the template that's used to display any object that is
associated with the class. The template defines which fields to display in different sections
of the pass. It also defines the logo and the issuer name that are shared among objects.
If two pass types require different data to be displayed in one or more sections of the pass,
you might wish to create two separate TransitClasses. For example, one
TransitClass to use for any point-to-point single-use passes and another
TransitClass to use for seasonal passes.
TransitObject
A TransitObject holds all the data that represents the journey, the transit
carrier, and the passenger(s). For example, the TransitObject contains the
journey origin, journey destination, time of departure, transit carrier number, passenger
name, seat number, and more. Some of these values are shared among multiple
TransitObjects.
The resources contained in a TransitObject are saved to a user's Google Pay app.
Supported countries
To learn which countries support the Google Pay app, see the supported country list. We suggest that you limit where you display the Save to Google Pay button based on where the user purchases the ticket from.