使用者會員方案註冊和通行證升級

會員註冊與登入功能可讓使用者在 Google 錢包中搜尋並加入你的會員方案，或登入自己的帳戶。系統會將使用者導向至行動裝置適用的網站，以便他們完成相關程序，並隨後在 Google 錢包中新增正式卡片。

如要將使用者新增的「靜態」票證轉換為「動態」API 連結票證，就必須先導入這項功能。本指南將概略介紹相關優點，以及啟用會員方案註冊、登入和會員卡升級功能所需的實作步驟。

總覽

首先，請確認你先前已設定專案，並已取得 Google 錢包 API 的存取權。

如要實作這項功能，請按照下列四個步驟操作：

1. 設定測試類別：設定 Google 錢包，測試流程。
2. 開發網頁：使用 Google 錢包 SharedDataType 建立註冊/登入網頁。
3. 建置推送回機制：在使用者完成動作後，將會員卡傳送至 Google 錢包。
4. 要求驗證：提交審查並要求啟用升級。

為什麼要導入會員註冊功能？

如要瞭解這項整合的價值，請務必區分 Google 錢包中的兩種憑證類型：L1 (使用者新增) 和 L2 (合作夥伴核發)。

L1 和 L2 的差異

功能	L1 Pass (使用者新增)	第 2 級通行證 (合作夥伴核發)
來源	使用者手動掃描實體卡片或輸入號碼時建立。	使用者透過您的流程註冊或登入後，使用 Wallet API 建立及推送。
控制	靜態。合作夥伴無法查看或控制這張票證。	動態。合作夥伴可透過 API 進行全面控管。
功能	條碼的靜態圖片。設定完成後即無法更新。	可更新點數餘額、會員等級狀態、顯示個人化優惠，以及接收通知。

升級路徑：計畫的「橋樑」

建立會員註冊流程 (「目的地」) 後，Google 就能建構「橋樑」，將使用者從靜態 L1 票證升級為官方 L2 票證。主要有兩種升級觸發條件：

1. L1 升級至 L2 票證：如果使用者先前已手動新增你的卡片 (L1)，Google 錢包可能會提示他們前往新的登入流程，將卡片升級為正式的動態票證 (L2)。
2. Gmail 匯入的票證升級：如果 Google 錢包偵測到使用者 Gmail 中有會員卡，系統會提示使用者前往你的流程並完成驗證，以取得正式的 L2 票證。

注意： 系統不一定會自動顯示升級提示。建立註冊流程後，您必須在驗證階段 (步驟 4) 要求 Google 將官方課程對應至這些現有的使用者新增票證。

步驟 1：在 Google 錢包中設定測試課程

請決定註冊和登入網址、會員方案標誌，以及所選的使用者欄位，然後使用 loyaltyclass 中的 discoverableProgram 巢狀欄位來設定適用的值。

設定 discoverableProgram 中的值，即可建立含有註冊/登入功能的會員方案草稿版本。為確保測試人員能看到這項資訊，請確認測試人員可存取 Google Pay 和錢包主控台。如要瞭解如何與他人共用 Google Pay 和 Wallet 管理中心的存取權，請參閱「瞭解『使用者』頁面」。

如要在開發過程中完成實作功能的驗證，請使用 Google Pay 和錢包主控台中的「與支援團隊聯絡」小工具與我們聯絡。在主控台中，選取主題中的「Google 錢包 API」，然後選取子主題中的「會員方案登入/註冊」。

步驟 2：開發註冊和登入頁面

使用者選擇登入或註冊你的會員方案時，系統會將他們導向至你網站上的專屬網頁，方便他們完成註冊或登入程序。如果使用者選擇註冊，Google 錢包就會要求使用者同意與您共用他們的使用者資料。

你必須提供下列兩個網頁或其中之一，讓使用者完成上述動作：

1. 可讓使用者登入現有帳戶的登入網址。
2. 可讓使用者建立新帳戶的註冊網址。

登入網頁和註冊網頁必須符合下列規定：

• 提供適合行動裝置的使用者體驗。
• 儘可能減少註冊程序中的必填欄位數量。
• 讓使用者可在單一網頁中完成登入或註冊程序。
• 使用有效憑證並採用 HTTPS 加密，確保使用者資料在傳輸時能安全無虞。
• 確保登入網頁和註冊網頁的正常運作時間至少達 99.9%。

除了上述規定外，我們也建議你建立不須填寫任何表單即可註冊會員方案的程序，或是僅在網頁上要求使用者同意服務條款。

• 使用者提供資料後，你就能利用這些資料建立帳戶並立即推送會員卡。SharedDataType
• 你可以隨後再透過電子郵件將一次性的密碼寄送給使用者，或是提供可讓使用者設定密碼和選填帳戶資訊的連結。
• 這麼做可以降低使用者中途退出註冊程序的可能性，因為每增加一個步驟，都可能會讓使用者萌生放棄的念頭。

顯示登入或註冊網頁時，Google 錢包會建立 Android WebView，並將 POST 要求傳送至您提供的網址。系統會以 Content-Type 為 application/x-www-form-urlencoded 的 POST 要求傳送 SharedDataType 參數，並採用 UTF-8 編碼。SharedDataType 參數的值為採用 Base64 編碼的 JSON 物件。

注意： JSON 字串會先經過 UTF-8 編碼，再以 android.util.Base64 編碼，並提供 NO_WRAP 和 URL_SAFE 選項。(符合 RFC 3548 第 4 節的規定)。

視使用者選擇的動作和您指定使用者填寫的欄位而定，JSON 物件可能會包含下列欄位。

欄位	註冊
電子郵件	✓
firstName	✓
lastName	✓
addressLine [1-3]	✓
城市	✓
州	✓
郵遞區號	✓
國家/地區	✓
手機	✓

注意：以上任何欄位都不一定會有內容。如果一或多個欄位不存在，您的網站仍必須允許使用者繼續操作。

注意：如果你要求使用者填寫某個欄位，請確保這些詳細資料會用於預先填入表單。

如需 SharedDataType 包含的已解碼 JSON 物件範例，請參閱以下內容。

資源

{
  "firstName": "Jane",
  "lastName": "Doe",
  "addressLine1": "1600 Amphitheatre Pkwy",
  "addressLine2": "Apt 123",
  "addressLine3": "Attn:Jane",
  "city": "Mountain View",
  "state": "CA",
  "zipcode": "94043",
  "country": "US",
  "email": "[e-mail]",
  "phone": "555-555-5555"
}

步驟 3：建置可立即將會員卡推送回 Google 錢包的機制

完成驗證 (登入) 或建立帳戶 (註冊) 後，您的網頁必須立即將使用者的會員卡推送回 Google 錢包。

注意： 請勿提供 Google 錢包 API 按鈕，因為使用者應在不需任何額外互動的情況下返回 Google 錢包。

你可以重新導向至符合以下結構的連結，將會員卡推送回 Google 錢包。

https://pay.google.com/gp/v/save/{jwt_generated}

注意：請務必在網址中的 JWT 前方加上正斜線 (「/」)。

注意：JWT 並未經過加密，因此請勿在深層連結中使用不適合以純文字格式分享的資料。

網址的長度上限為 2000 個字元，連結不應超過此限制。透過編碼編入 JWT 的物件應力求精簡，只包含使用者相關資料。請試著將大部分資料存放在物件的類別中，並在產生 JWT 前先建立類別。對於超出限制的大型物件，請考慮先透過 Google 錢包 API 建立物件，且在 JWT 中只傳送物件 ID。

一般通訊流程

使用者完成註冊或登入程序的通訊流程如下圖所示。你必須負責執行你的伺服器 (下圖中的「Your Server」) 之間的所有動作。

步驟 4：要求驗證及啟用

完成開發工作並測試註冊/登入流程後，請提出申請，要求審查導入作業並全面啟用。

1. 前往 Google Pay 和錢包主控台。
2. 使用「與支援團隊聯絡」小工具。
3. 通知支援團隊您已完成會員註冊整合。

重要事項： 在要求中，請明確指出要啟用 L1 到 L2 的票證升級。系統會啟動內部驗證程序，將新的官方課程對應至現有使用者新增的票證。

我們會全面審查你建置的項目，在確認相關功能可與 Google 錢包應用程式搭配運作之後，就會公開發布你的會員方案註冊/登入功能。

為提供最優質的使用者體驗，我們每隔一段時間就會檢查您導入的註冊/登入機制，確保您持續遵守相關功能規定。如果發現不符之處，系統會傳送通知給您；在問題解決前，登入/註冊功能可能會遭到停用。

常見問題

• 會員方案中使用的圖片是否有任何規定？ 是。你的圖片託管網址必須採用 HTTPS 通訊協定，否則將無法在 Google 錢包中顯示。

• 是否有任何工具能簡化 JWT 的實作和偵錯作業？ 有。www.jwt.io 等平台可讓你在開發過程中為權杖解碼並進行偵錯，方便你驗證要提交的內容。請注意，Google 與該網站並無任何聯盟關係，也並未特別推薦你採用這類第三方服務。

• 該如何正確處理採用 Base64 編碼的 SharedDataType 資料？ 請確認你在開發時全程採用 UTF-8 編碼。JSON 字串會先以 UTF-8 編碼，再以 android.util.Base64 編碼，並提供 NO_WRAP 和 URL_SAFE。(符合 RFC 3548 第 4 節的規定)。