The following diagram illustrates a typical communication flow used to insert a class, save an object, and update an object. All actions between your server, the web browser, and Google Pay API for Passes are your responsibility to implement. The following diagram uses Loyalty as an example, but all other Passes could use a similar flow.

Typical API flow for JS buttons and JWT web links
The following outline explains the same process as figure 1 in more detail. It covers the typical API flow for JavaScript (JS) buttons and JSON Web Tokens (JWTs):
- Loyalty card issuer creates a
LoyaltyClass
. - Your server defines the
LoyaltyClass
. - Your server makes a
POST
request to insert theLoyaltyClass
in the Google Pay API for Passes server. - Your server has a service to generate a JWT for a
LoyaltyObject
for a particularLoyaltyClass
. This object represents that user's loyalty card. - Your server uses a JWT to render a Save to Google Pay (S2GP) button:
- For websites, use our JavaScript button.
- For email, SMS, and apps, use the JWT link with a S2GP button.
- The user clicks or taps Save to Google Pay on the loyalty card issuer's website, email, app, or SMS.
- The user is taken to a landing page to save a
LoyaltyClass
object. The object to be saved is rendered on the landing page based on the JWT. If the button is tapped from an app, the user is prompted to save the object in the Google Pay app. - The user clicks Save to Google Pay on the issuer's property to save the
LoyaltyObject
. - The
LoyaltyObject
is inserted to the Google server, then pushed to the Google Pay app. TheLoyaltyObject
is referred to as a "Loyalty Pass." - Card issuer updates card data:
- The loyalty card issuer does a
GET
request of theLoyaltyObject
with the use of theObject.id
. - The loyalty card issuer updates the
LoyaltyObject
. - The loyalty card issuer makes a
PUT
orPATCH
request to insert the updatedLoyaltyObject
on the Google Pay API for Passes server. - The
LoyaltyObject
is pushed to the Google Pay app.
"Skinny" JWT variation
Due to truncation by browsers, JWTs used in web links must not exceed 1800 characters. If this becomes a challenge, it might be best for you to insert both the class and object beforehand. Then, the JWT only needs to contain the object id field.
The following diagram shows an API flow to Add the Save to Google Pay button to your email or SMS.

JWT POST request API flow
It's often difficult to implement the backend work required to create and insert a class before an object is saved, but the JWTs are likely to exceed the 1800-character limit. This is most useful for event tickets and boarding passes, where many classes are created over time.
The flow, with a flight class as an example, is as follows:
- Your server generates a JWT for both
FlightObject
andFlightClass
. Both are defined in the JSON, and theFlightObject
references theFlightClass
. - This JWT is sent from your server to your client application, which displays a Save to Google Pay button. Be sure to use a button that follows the S2GP brand guidelines.
- The user clicks the S2GP button in your client application.
- A
POST
request is made to the JWT endpoint. This inserts the class ID(s) and object ID(s). If the class ID(s) or object ID(s) in the JWT already exist in the system, they aren't inserted again. Review our API reference documentation on how to update existing classes and objects. If they've already been inserted, no error is thrown. - The returned URI response is opened for the user so that they can save the pass. This URI is valid for a week after it's returned.
- A
To implement the API, read
Use the JWT POST request method.
In figure 3, there aren't arrows between "Your server" and "Google server" in the save flow. This is the fundamental difference between the JWT POST and the JWT link and intent method. However, we recommend that you implement server-to-server communication to update Passes.