下圖說明用來插入類別、儲存物件及更新物件的一般通訊流程。您必須負責建置伺服器、網路瀏覽器和 Google Pay API for Passes 之間的所有動作。下圖使用「會員」票證做為範例,但所有其他「票證」多半都會使用類似的流程。
JS 按鈕和 JWT 網頁連結適用的一般 API 流程
以下大綱將詳細說明與圖 1 相同的程序,其中涵蓋 JavaScript (JS) 按鈕和 JSON Web Token (JWT) 適用的一般 API 流程:
- 會員卡核發機構建立
LoyaltyClass
。 - 您的伺服器定義
LoyaltyClass
。 - 您的伺服器發出
POST
要求,藉此在 Google Pay API for Passes 伺服器中插入LoyaltyClass
。 - 您的伺服器有項服務,能針對特定
LoyaltyClass
產生LoyaltyObject
的 JWT。這個物件代表使用者的會員卡。 - 您的伺服器使用 JWT 呈現 [儲存至 Google Pay] (S2GP) 按鈕:
- 如為網站,請使用我們的 JavaScript 按鈕。
- 如為電子郵件、簡訊和應用程式,請使用含有「儲存至 Google Pay」按鈕的 JWT 連結。
- 在會員卡核發機構的網站、電子郵件、應用程式或簡訊中,使用者按一下或輕觸 [儲存至 Google Pay]。
- 系統將使用者帶往到達網頁,以便儲存
LoyaltyClass
物件。到達網頁中會依據 JWT 顯示要儲存的物件。如果使用者是在應用程式中輕觸按鈕,系統會提示將物件儲存至 Google Pay 應用程式。 - 使用者按一下核發機構資源中的 [儲存至 Google Pay],即可儲存
LoyaltyObject
。 - 系統將
LoyaltyObject
插入 Google 伺服器,然後推送至 Google Pay 應用程式。LoyaltyObject
稱為「會員票證」。 - 發卡機構更新卡片資料:
- 會員卡核發機構使用
Object.id
執行LoyaltyObject
的GET
要求。 - 會員卡核發機構更新
LoyaltyObject
。 - 會員卡核發機構發出
PUT
或PATCH
要求,藉此在 Google Pay API for Passes 伺服器中插入更新的LoyaltyObject
。 - 系統將
LoyaltyObject
推送至 Google Pay 應用程式。
「精簡版」JWT 變化版本
因為會遭到瀏覽器截斷,網頁連結中使用的 JWT 長度不得超過 1800 個半形字元。如果這會造成作業困難,建議您事先插入類別和物件。這樣一來,JWT 就只需要包含「object id」欄位。
下圖顯示將 [儲存至 Google Pay] 按鈕新增至電子郵件或簡訊的 API 流程。
JWT POST 要求 API 流程
在儲存物件之前要實作建立及插入類別所需的後端工作,通常相當困難;但為了避免 JWT 長度超過上限 1800 個半形字元,也只能勉為其難。對於活動票券和登機證這類會隨著時間建立許多類別的票證,這種方式最為適用。
以下用航班類別為例顯示此流程:
- 您的伺服器針對
FlightObject
和FlightClass
產生 JWT。這兩個項目都是在 JSON 中定義,而且FlightObject
會參照FlightClass
。 - 您的伺服器會將這個 JWT,傳送到顯示 [儲存至 Google Pay] 按鈕的用戶端應用程式。請務必使用符合「儲存至 Google Pay」品牌規範的按鈕。
- 使用者在用戶端應用程式中按一下 [儲存至 Google Pay] 按鈕。
- 系統向 JWT 端點發出
POST
要求,此動作會插入類別 ID 和物件 ID。如果 JWT 中的類別 ID 或物件 ID 已存在於系統中,則不會再次插入這些項目。請參閱我們的 API 參考資料說明文件,瞭解如何更新現有類別和物件。如已插入這些項目,則不會顯示任何錯誤。 - 系統開啟傳回的 URI 回應,以便使用者儲存票證。這個 URI 在傳回後具有一週的效期。
- 系統向 JWT 端點發出
如要實作 API,請參閱使用 JWT POST 要求方法的說明。
在圖 3 的儲存流程中,「Your Server」(您的伺服器) 和「Google Server」(Google 伺服器) 之間沒有任何箭頭。這就是 JWT POST 和 JWT 連結與意圖方法之間的主要差異。不過,我們仍建議你實作伺服器間的通訊以更新票證。