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.