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
- Loyalty card issuer creates a
- Your server defines the
- Your server makes a
POSTrequest to insert the
LoyaltyClassin the Google Pay API for Passes server.
- Your server has a service to generate a JWT for a
LoyaltyObjectfor a particular
LoyaltyClass. This object represents that user's loyalty card.
- Your server uses a JWT to render a Save to Google Pay (S2GP) button:
- For email, SMS, and native apps, use the JWT link with a S2GP button.
- The user is taken to a landing page to save a
LoyaltyClassobject. The object to be saved is rendered on the landing page based on the JWT. If the button is tapped from a native 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
LoyaltyObjectis inserted to the Google server, then pushed to the Google Pay app. The
LoyaltyObjectis referred to as a "Loyalty Pass."
- The loyalty card issuer does a
GETrequest of the
LoyaltyObjectwith the use of the
- The loyalty card issuer updates the
- The loyalty card issuer makes a
PATCHrequest to insert the updated
LoyaltyObjecton the Google Pay API for Passes server.
LoyaltyObjectis 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
FlightClass. Both are defined in the JSON, and the
- 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.
POSTrequest 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.
To implement the API, see 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.