權杖化付款方式
總覽
權杖化付款方式 (付款方式) 是整合至付款平台的其中一種付款方式。使用者如要透過此 FOP 付款，Google 和付款整合商必須執行一次性的帳戶身分憑證交換作業。系統會接著完成建立權杖的流程，代表該使用者採用的付款方式。之後您就能使用這個權杖重新支付款項。這些 API 目前有兩種版本，第 2 版支援行動電信業者和參考號碼供應商。所有其他權杖化 FOP 供應商皆應實作第 1 版。本文件其他重點為第 1 版。
Google 會使用兩個流程來建立身分並建立這個權杖：
憑證建立完成後，Google 會在購買流程中使用這個憑證，為使用者提供快速流暢的結帳體驗。Google 會使用這個權杖代表客戶的付款方式執行個體。這又稱為樂器。Google 客戶可能會使用多種付款方式購買商品和服務。
最後，整合商的銀行與 Google 銀行之間的所有款項都是在匯款流程中完成。
|
|
|
|
|
下圖說明整個流程總覽：
權杖化付款方式總覽
整體來說，將服務新增為 Google 產品付款方式的流程如下：
下列各節將詳細說明這些流程，如需詳細說明，請參閱指南。
概念與術語
{setvar <顏色> 付款結果。付款詳情符號和會議
針對這些文件中「必須」、「不得」、「必要」、「應」、「不應」、「應該」、「建議」、「可能」和「選用」等重要字詞，均以 RFC 2119 的說明表示。
時間戳記
所有時間戳記都以毫秒表示，自世界標準時間 Unix 紀元 (1970 年 1 月 1 日) 起。
例如：
- 2019 年 4 月 23 日下午 8:23:25 (GMT = 1556051005000 毫秒)
- 2018 年 8 月 16 日下午 12:28:35 (GMT = 1534422515000 毫秒)
金額
這個 API 中的金額值會採用「微量」的格式，也就是 Google 的標準。微量是以整數為準的固定精確度格式。如要以微量單位表示金額，請將標準貨幣值乘以 1,000,000。
例如：
- $1.23 美元 = 12,30000 微秒
- $0.01 美元 = 10,000 微秒
冪等
這個 API 中的所有方法呼叫都必須具有冪等行為。Google 會定期重試要求，確保兩方的交易狀態相同。整合商不得嘗試重新處理任何已順利處理完畢的要求。請改為回報成功處理的回應。所有方法都有共用的 RequestHeader，其中包含 requestId。requestId 是所有呼叫的冪等鍵。
任何非終端機回應 (HTTP 200 失敗) 都不得以冪等方式處理。因此，如果先前收到 400 (廣告請求錯誤/失敗的先決條件) 一次，第二次呼叫時，就不能以冪等方式傳回 400，就必須重新評估。重新評估時，系統可能會傳回 400 錯誤，或已成功處理。
如要進一步瞭解冪等性，請參閱這份詳細指南。
整合商
使用 Google 付款平台為自家業務的公司。客戶可以是 YouTube 或 AdWords 等內部 (第一方)，也可以是想將服務整合到 Google 生態系統的外部 (第三方) 商家。
付款方式
付款方式。這比樂器一般。Visa、MasterCard 和 PayPal 都是 FOP。
方式
特定客戶適用的付款方式。例如使用者的信用卡或 PayPal 帳戶。針對特定客戶，代碼化 FOP 也是其中一種方式，因為其是一種客戶的付款方式，可以安全地儲存在我們的系統中。
權杖
代表特定使用者付款方式的 Google 系統代表。因為其中包含購買所需的所有資訊，而憑證也是付款方式。這可能包括使用者在整合商中所擁有的帳號。
主要流程
驗證流程
驗證是必須採取的第一個流程。驗證流程的用途是為整合商識別並驗證使用者。驗證程序可能有多種方式。權杖化付款方式支援兩種識別及驗證使用者的方式：
- SMS-MT 動態密碼驗證 (簡訊行動終止、動態密碼)
- 重新導向驗證
新手上路流程中，整合商會與 Google 合作，選擇最適合自家產品的驗證機制。
驗證流程可用於下列兩種情況：首先，找出新客戶並建立關聯，第二種方式則是要求使用者提供現有付款方式的憑證。驗證流程的結果可做為多個流程的輸入內容，例如關聯流程、重新整理權杖流程、挑戰購買流程等等。此外，驗證流程也可以在獨立模式下使用，不要與任何後續流程連結。
SMS-MT OTP 驗證
使用者在這個驗證機制中，在 Google 使用者介面中輸入電話號碼。Google 會將這組電話號碼 (透過 sendOtp 方法) 傳送給整合商。整合商將動態密碼傳送給使用者。使用者在 Google UI 中輸入密碼，並將密碼傳送給整合商。付款整合商會觸發成功回應。
如果以獨立模式使用 SMS-MT OTP 驗證方式，系統會使用 verifyOtp 方法將動態密碼值傳送給整合商。這個方法會驗證你提供的動態密碼是否為已傳送。
重新導向驗證
為了執行重新導向驗證，Google 會將使用者重新導向至整合商擁有的應用程式。應用程式可以是網頁或 Android 應用程式。
Android 和網頁重新導向的運作方式相似。Google 將使用者重新導向至整合商的應用程式。整合商會以最適合該整合商的方式，識別並驗證使用者的任何形式。整合商驗證完畢後，就會將使用者重新導回 Google 的使用者介面，完成關聯。重新導向後，Google 會提供 requestId，以便識別這個驗證工作階段。這個 ID 會在關聯期間用於驗證身分證明。
如果選擇此流程，整合商必須提供網路驗證網址，因為這是所有平台 (電腦或行動裝置) 最常見的分母。不過，我們強烈建議您透過 Android 驗證，在行動裝置上提供最佳的使用者體驗。
視裝置環境和安裝的應用程式而定，Google UI 會選擇網頁或 Android 應用程式重新導向。
這種驗證機制可提供最大自由的整合空間。驗證及識別使用者身分的方法有很多種。使用者名稱 + 密碼，或是生物特徵辨識資訊和安全性問題，都是可行的解決方案。Google 不打算說明整合商如何驗證使用者。整合商會負責驗證使用者的作業。如此一來，Google 打算利用整合商的各種使用者介面來驗證使用者，並且單純向 Google 提供驗證證明。
如要進一步瞭解驗證功能，請參閱這篇詳細指南。
關聯流程
透過上述其中一項機制進行驗證後，使用者完成關聯流程。連結流程的目的是建立 Google 付款權杖 (GPT)，以建立付款方式。這個流程會執行下列作業：
- 協商名為「權杖」的身分，以代表這位使用者。
- 提供帳戶資訊，以便 Google 的風險引擎。
- 收集建立並建立
GPT的首次設定資訊。
結果是已建立的 GPT 由 Google 和整合商議定。
整合商可與兩位 Google 使用者共用同一個使用者帳戶。在這種情況下，每位使用者會有不同的付款方式。每種樂器都有獨立的關聯流程，因此不重複的 GPT。
這張插圖將逐步說明名為 InvisiCash 的假權杖化 FOP。這展示使用者在驗證流程和連結流程中採取的步驟。
關聯流程總覽
- 有一位電子郵件地址為 sf@gmail.com 的 Google 使用者，想在 Google Play 商店中將 InvisiCash 帳戶加入 Google Play 商店，以便用於消費。
- Google Play 商店會開啟 InvisiCash 應用程式以進行驗證。
使用者以 sally@otheremail.com 電子郵件地址登入 InvisiCash 帳戶。如果她是 InvisiCash 帳戶的登入資訊，她和她的 Gmail 電子郵件地址都可能會是她。
InvisiCash 應用程式會將驗證 ID 傳回 Google Play 商店。
Google Play 商店會將驗證 ID 傳送至 Google 伺服器。
Google 伺服器會傳送訊息至 InvisiCash 伺服器，以與該帳戶建立關聯。這項關聯包含驗證 ID、
GPT(Google Payments 權杖) 及關聯 ID。InvisiCash 伺服器會儲存 Google 付款權杖 (
GPT) 和關聯 ID。目前兩者皆與 Sally 的 InvisiCash 帳戶相關聯。InvisiCash 核准了這項關聯。接著，Google 的伺服器會建立可用於日後交易的付款方式。