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 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.


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.