權杖化付款方式
總覽
代碼化 FOP (付款方式) 是整合至付款平台中的一種付款服務。使用者如要透過這個 FOP 付款,Google 和付款整合商必須執行一次性的帳戶身分憑證交換作業。接著,您就可以建立權杖,代表該使用者的付款方式。這組權杖可用於持續付款。這些 API 目前分為 2 個版本。第 2 版支援行動電信業者和參考號碼供應商。所有其他權杖化 FOP 供應商都應實作版本 1。本文件的其餘部分只介紹第 1 版。
Google 使用兩個流程來建立身分並建立這個符記:
建立權杖後,Google 就會在購買流程中使用該權杖,為使用者提供快速又流暢的結帳體驗。Google 會使用這個憑證代表客戶的付款方式。又稱為樂器。Google 客戶可能會用多種付款方式支付商品和服務費用,
最後,整合商的銀行與 Google 銀行之間的所有金錢交易都是在匯款流程完成。
下圖為流程的廣泛總覽:
權杖化付款方式總覽
整體來說,在 Google 產品中新增服務做為付款方式時,必須滿足以下流程:
以下各節將詳細說明這些流程,詳情請參閱指南一節。
概念與術語
符號和會議
「必須」使用的重要詞彙是「必須」「絕對不要」「必要」「SHALL」、「"SHALL NOT,「應」"不應"「建議」「你好」:和「OPTIONAL」並依照 RFC 2119 中的說明解讀。
時間戳記
所有時間戳記都會以世界標準時間 (UTC) 自 Unix 紀元 (1970 年 1 月 1 日) 表示的毫秒數。
例如:
- 2019 年 4 月 23 日下午 8:23:25 (GMT = 1556051005000 毫秒)
- 2018 年 8 月 16 日中午 12:28:35 (格林威治標準時間) = 1534422515000 毫秒
金額
這個 API 中的貨幣值格式為「微量」。成為 Google 的一項標準微量是整數的固定精確度格式,如要表示金額 (以百萬分之一為單位),請將標準貨幣值乘以 1,000,000。
例如:
- $1.23 美元 = 1230,000 美元
- $0.01 美元 = 10,000 美元
冪等
這個 API 中的所有方法呼叫都必須具有冪等行為。Google 會偶爾重試要求,確保兩邊的交易狀態都相同。整合商不得嘗試重新處理已經成功處理的任何要求。請回報成功處理的回應。所有方法都有通用的 RequestHeader
,其中包含 requestId。此 requestId 是所有呼叫的冪等鍵。
任何非終端機回應 (非 HTTP 200 成功) 都不得冪等處理。因此,如果要求之前收到 400 (錯誤要求/失敗的先決條件),在第二次呼叫時,該請求不得冪等地傳回 400,所以必須重新評估。重新評估時,可能會傳回 400 或已成功處理。
如要進一步瞭解冪等性,請參閱這份詳細指南。
整合商
使用 Google 付款平台處理業務的公司。可以是 YouTube 或 AdWords 等內部 (1P) 公司,也可以是 YouTube 或 AdWords 等外部企業,且想將自家服務與 Google 生態系統整合。
付款方式
付款方式。這比樂器更為廣泛。Visa、MasterCard 和 PayPal 皆為 FOP。
樂器
特定客戶的特定付款方式實例。例如使用者的信用卡或 PayPal 帳戶。個別客戶的代碼化 FOP 也是一種付款方式,因為它對該客戶的付款方式而言會安全地儲存在我們的系統中。
權杖
代表特定使用者的付款方式,並在 Google 系統中代表。因為其中包含購物所需的一切資訊,因此權杖也是一種工具。這可能包括使用者向整合商提供的帳號等這類資訊。
重要流程
驗證流程
驗證程序是第一個必要的流程。驗證流程的目的是向整合服務供應商識別並驗證使用者。驗證方式有很多種,權杖化 FOP 支援兩種識別及驗證使用者的方式:
- SMS-MT OTP 驗證 (簡訊終止、動態密碼)
- 重新導向驗證
加入計畫時,整合商會與 Google 合作,選擇最適合其產品的驗證機制。
驗證流程可用於兩種情況:首先是識別新客戶以建立關聯,其二是要求使用者提供現有付款方式的憑證。驗證流程的結果可做為多個流程的輸入內容,例如關聯流程、更新權杖流程和驗證購買流程等。此外,驗證流程可做為獨立模式使用,不會與任何後續流程連結。
SMS-MT OTP 驗證
在這項驗證機制中,使用者是在 Google UI 中輸入電話號碼。Google 會透過 sendOtp
方法將此電話號碼傳送給整合商。整合商將動態密碼傳送給使用者。使用者在 Google UI 中輸入密碼,然後將密碼傳送給整合服務供應商。這會觸發付款整合商的成功回應。
在獨立模式下使用 SMS-MT OTP 驗證時,OTP 值會透過 verifyOtp
方法傳送給整合商。這個方法可以驗證提供的動態密碼是否確實傳送給我們的。
重新導向驗證
重新導向驗證程序是由 Google 將使用者重新導向至整合商所擁有的應用程式。應用程式可以是網路或 Android 應用程式。
Android 和網頁重新導向的運作方式相似。Google 將使用者重新導向至整合服務供應商的應用程式。整合商會以最自然的方式識別及驗證使用者,讓整合商以最自然的方式進行身分驗證。驗證完畢後,整合商會將使用者重新導向回 Google 的使用者介面,以完成建立關聯。重新導向時,Google 會提供 requestId
以識別這個驗證工作階段。並在關聯期間使用這個 ID 當做身分驗證證明。
選擇這個流程的整合商必須提供網站驗證網址,因為這是所有平台 (電腦或行動裝置) 中最常見的分母。不過,我們強烈建議您使用 Android 驗證,以提供最佳的行動裝置使用者體驗。
根據裝置環境和已安裝的應用程式,Google UI 會選擇網頁或 Android 應用程式重新導向。
這種驗證機制可提供整合商最大程度的自由。驗證及識別使用者的方法有很多種。使用者名稱 + 密碼,或生物特徵辨識資訊與安全性問題都是可行的解決方案。Google 不會指定整合商驗證使用者的方式。整合商會負責驗證使用者。因此,Google 希望透過整合商提供的各種使用者介面來驗證使用者,只要將驗證證明提供給 Google 即可。
如要進一步瞭解驗證,請參閱這份詳細指南。
關聯流程
在透過上述任一機制的驗證流程之後,使用者會經過連結流程。連結流程的目的是建立 Google 付款權杖 (GPT
) 以建立付款方式。此流程會執行下列作業:
- 協議一個用於代表這位使用者的「符記」身分。
- 提供帳戶資訊,通知 Google 的風險引擎。
- 收集第一次設定時所需的資訊,以建立並建立
GPT
。
最終結果是 Google 和整合商同意所訂定的GPT
。
兩名 Google 使用者可與整合商共用同一個使用者帳戶。在這種情況下,每位使用者將使用不同樂器。每種付款方式都有獨立的連結流程,因此不重複的 GPT
。
這張插圖將帶你逐步完成名為 InvisiCash 的虛假代碼化 FOP。這個範例說明瞭使用者在執行驗證流程和關聯流程時必須採取的步驟。
關聯流程總覽
- 一位電子郵件地址為 sf@gmail.com 的 Google 使用者,想將自己的 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 付款權杖) 和關聯 ID。InvisiCash 伺服器會儲存 Google 付款權杖 (
GPT
) 和關聯 ID。這兩個帳戶現在都與莎莎的 InvisiCash 帳戶相關聯。InvisiCash 核准此關聯。接著 Google 伺服器會建立一個可用於日後交易的付款方式。