在 Google Standard Payments 的環境中，「電信代扣」服務是一種代碼化付款方式 (FOP)，也就是說，Google 和付款整合商會執行一次性的帳戶身分憑證交換作業，藉此建立權杖。 這個權杖稍後會傳回給付款整合商，以便識別要收費的帳戶。
其他付款方式也採用代碼化技術，因此我們歡迎參閱權杖化 FOP 的一般總覽，以上都是與電信代扣相關的功能。如要進一步瞭解「驗證」、「關聯」、「購買」和「匯款」流程，請參閱該總覽。本頁將進一步說明電信業者計費的特定內容。
電信業者必須實作建立下列流程的 API，以便開始使用 Google Standard Payments：
| 流程 | 說明 | DCB3 規格相同 |
|---|---|---|
| 驗證 | 在付款整合商的系統中識別並驗證使用者帳戶，以便使用 DCB 付款 | 使用 GoogleUserToken 的 SMS-MO |
| 關聯 | 交換長期權杖，讓 Google 和付款整合商同意，以使用者的付款整合商帳戶進行付款 | 透過 OperatorUserToken 和 GetProvisioning() 核准使用者回呼 |
| FundsTransfer | 同步將資金從使用者的付款整合商帳戶移出。將責任轉移給付款整合商 | 批次要求檔案中的 Auth() 和 CHARGE 程式碼行 |
| 退款 | 同步將先前 FundsTransfer 的部分或全部資金傳回使用者的付款整合商帳戶。 將責任轉移給 Google | 批次要求檔案中的退款行 |
| 匯款 | 以 API 為基礎的結算方式，最好每天做為每日基礎 | 月結單 PDF、每月月結單詳細資料檔案、每日回顧檔案 |
| UpdateAssociatedAccount | 通知 Google 有關使用者的付款整合商帳戶異動 (例如交易限製或佈建狀態) | GetProvisioning() 意見調查 |
| 詐欺 | 通知 Google 因使用者爭議而撤銷的交易。這有助於改善 Google 的風險引擎 但不會影響金錢責任 | 無 |
與 DCB3 規格的整體比較
Google 標準付款規格可解決 DCB3 規格的問題。但是，它採用不同的技術與 API 設計，可以改善解決方案。主要差異如下：
堆疊技術比較
所有 API 通訊都使用 HTTPS POST 搭配 PGP 加密並簽署的 JSON 檔案。這表示 Google 和付款整合商只有一個 PGP 金鑰可輪替。此外，這些技術也比 SOAP 更有效的支援。如要進一步瞭解通訊堆疊，請參閱這篇文章。
API 理念比較
DCB3 非常仰賴檔案核對付款狀態。Google Standard Payments 沒有任何檔案。API 呼叫會以冪等方式重試，直到確定最終狀態為止。
最終狀態代表特定冪等鍵的最終狀態。錯誤和未確定狀態不會模擬為拒絕，而是非 200 HTTP 回應。這讓我們可以更快找出錯誤，避免遮蓋為錯誤。
新功能
Google Standard Payments 支援以下新功能：
- 透過 Fraud API 通知 Google 的詐騙風險引擎
- 更新 Associated Account API，將佈建、交易限制和帳戶狀態變更通知 Google
- 在購物期間提供更多驗證問題支援，例如 USSD PIN 碼
- 每日匯款週期
DCB3 至 Google 標準付款詞彙表
在本說明文件和規格中，您將看到看起來新穎但實際上與現有概念不同的詞語。
- 電信業者 -> 付款整合商
警告：為了避免與 DCB 整合商的概念混淆，本文件嘗試使用「付款整合商」和「DCB 整合商」，而不是「整合商」。不過，一般的 Google 標準付款說明文件一般會使用「整合商」做為「付款整合商」的簡寫
- 帳單合約 ID -> 付款整合商帳戶 ID
- OperatorUserToken (OUT) -> GooglePaymentToken (GPT)
- correlation_id -> requestId
- 按固定比率發放 -> 費用
驗證流程
如需權杖化 FOP 驗證流程的概要總覽，請參閱這個網頁。
電信代扣相關說明
針對電信代扣作業，「驗證流程」的目標是要證明使用者擁有與其電信業者帳戶連結的 SIM 卡控制權。電信代扣使用者可以透過下列任一機制進行驗證：
- SMS-MO 驗證 (權杖化 FOP 總覽)
- 重新導向驗證 (權杖化 FOP 總覽中的定義)
- SMS-MT OTP (權杖化 FOP 中的定義)
付款整合商可與 Google 合作，選擇最適合自家產品的驗證機制。
與 DCB3 比較
驗證流程會將傳送給 Google 的 approveuser 回呼替換為非 DCB3 規格，
在 DCB3 中，驗證及關聯已合併為單一流程。在 Google Standard Payments 中，驗證與帳戶關聯無關。
關聯流程
如需權杖化 FOP 的關聯流程總覽，請參閱這個頁面。
電信代扣工具使用的關聯流程與一般權杖化 FOP 流程的主要差異，在於 associateAccount 方法中提供的驗證證明會因為付款整合商是否要求其他使用者驗證而有所不同。
如果付款整合商回應了使用者需要額外的驗證問題，則驗證結果必須是 Google 在其他驗證步驟中產生的身分證明。舉例來說，SMS-MT OTP 機制產生的驗證證明就是 sendOtp 方法和 OTP 本身的 requestId。
樂器屬性
一般權杖化 FOP 總覽的「檢測屬性」一節會討論 accountAlias、accountNickname 和 fullAccountNickname 的概念。
電信代扣相關說明
accountAlias必須是使用者的電話號碼。當使用者致電 Google 支援團隊處理其帳戶相關事宜時，此資訊將有助於識別付款方式。accountNickname和fullAccountNickname是顯示名稱，用來在 UI 中識別檢測工具。
與 DCB3 規格比較
「關聯流程」會取代以下 DCB3 規格的元件：
- 取得佈建 SOAP 呼叫
- GetSubscriptionAddress SOAP 呼叫
- 由電信業者產生的 OUT 訊息
最大的差異在於，Google 會在連結流程中產生 Google 付款權杖 (GPT)，而不是電信業者產生此權杖。
另外要注意的是，在 DCB3 的 OUT 範圍中，OUT 範圍限定在特定的 BillingBindingmentId 時，GPT 的範圍不限於任何特定 PaymentIntegratorAccountID。
重新整理權杖流程
如要大致瞭解權杖化 FOP 的更新權杖流程，請參閱這個網頁。
電信代扣相關說明
以電信代扣方式付款時，我們強烈建議不要將 Google 付款權杖過期，因為這會導致訂閱訂單遭到取消。您通常可以改用下方所述的帳戶更新流程來完成用途，不需要過期權杖並依賴更新權杖流程來修正問題。
帳戶更新流程
帳戶更新流程可讓付款整合商通知 Google 有關使用者整合商帳戶的最新資訊。這些欄位最初是在連結流程中提供給 Google。付款整合商可能會更新的帳戶資料範例包括：
- 使用者的每月、每日和個別項目交易上限
- 使用者整合商帳戶的佈建狀態
- 使用者整合商的帳戶類型 (預付、後付、企業等)
- 使用者的「accountAlias」、「accountNickname」或「fullAccountNickname」
- 使用者是否設定、移除或變更預先共用靜態 PIN 碼
- 判斷使用者是否關閉帳戶或變更電話號碼，對使用者在 Google 系統中失效的付款方式失效。
- 刪除權杖流程
與 DCB3 規格比較
帳戶更新流程會取代 DCB3 規格的下列元件：
- 輪詢 Provisioning SOAP 呼叫
- 定期權杖撤銷
購買流程
如需權杖化 FOP 的購買流程總覽，請參閱本頁面。
電信代扣相關說明
部分電信業者會使用 USSD 或其他技術，在使用者進行購買交易時收集 PIN 碼。對於這些電信業者，我們改為呼叫 capture()，而非呼叫 capture()。我們允許電信業者 30 秒提示使用者輸入 PIN 碼並完成擷取。判定付款的最終狀態時，電信業者會呼叫 captureResultNotification() 以通知 Google 結果。
與 DCB3 規格比較
有重大變更。
- 單一同步方法呼叫 -- capture()，而非 auth() + 批次檔案
- 沒有任何批次檔案
- 無 cancel() 方法 (擷取 + 退款，而不是 auth + 取消)
- 回應中沒有 user_message 欄位，拒絕代碼會對應到 Google 擁有的訊息，並本地化至使用者的帳戶語言。
- 重要詞彙異動：
- CorrelationId -> requestId
- BillingBindingmentId -> paymentsIntegratorAccountId
- OperatorUserToken -> googlePaymentToken
挑戰購買流程
開發作業會持續支援購買流程，使用者在每次購物前進行驗證驗證問題。大多數可在連結流程之前使用的驗證方法，也可以在挑戰購買流程之前使用，提供額外的使用者驗證。
退款流程
如需權杖化付款方式的退款流程概要說明，請參閱這個網頁。
權杖化 FOP 支援單一訊息退款流程。退款方式可用於退還全額交易或退回部分交易的款項。單筆交易可申請多筆部分退款。
電信代扣相關說明
「退款流程」中的「電信代扣」付款方式沒有任何特別之處。
與 DCB3 規格比較
退款是由同步 API 呼叫 (而非檔案) 觸發。此外，您可以針對單筆付款建立多筆部分退款，而非僅支援單筆全額退款。
匯款流程
如需權杖化付款方式的匯款流程總覽，請參閱這個網頁。
「匯款流程」是指 Google 和付款整合商執行和解的方式。Google 是記錄系統，負責匯款。Google 會定期向付款整合商傳送匯款對帳單。對帳單提供付款整合商應支付給 Google 的金額摘要，以及如何向 Google 付款的操作說明。為方便付款整合商進行對帳，付款整合商可以向 Google 查詢組成匯款對帳單的交易層級詳細資料。
電信代扣相關說明
電信代扣 remittanceStatementDetails 包含匯款流程 API 定義中未列出的其他欄位。這些服務包括：
- revshareCategory
- itemPrice
- tax
- 時間戳記
如果與 Google 簽訂 50/50 收益分潤拆分協議的電信業者，remittanceStatementDetails 中顯示的費用是按 revshareCategory 匯總，而非依事件顯示。
與 DCB3 規格比較
DCB3 規格中的下列概念由「匯款流程」取代：
- 每月 ChargeReport/PaymentReport PDF
- 月結單詳細資料 CSV 檔案
- 每日參考 CSV 檔案
這裡的主要差異在於移除任何檔案並支援每日匯款。而非檔案，而是透過同步 API 傳遞資料，另一個 API 支援查詢匯款陳述式的詳細資料。
詐欺回報流程
詐欺回報流程可讓付款整合商呼叫 fraudNotification 方法，向 Google 回報潛在的詐欺交易。這個流程用於更新 Google 的內部風險引擎，且不會啟動任何金錢交易。
電信代扣相關說明
在付款撤銷通知流程中，「電信代扣」付款方式沒有任何特別之處。