詞彙解釋

帳戶 ID

系統會在連結流程中從整合服務供應商的伺服器傳回帳戶 ID,可用來協助 Google 辨識基礎帳戶。首先,識別多項工具是否使用同一個基礎使用者帳戶,以評估風險和詐欺行為。再來,Google 客服專員會使用這個帳戶來識別這個帳戶。這個值在關聯要求中必須正確識別使用者帳戶,且在特定帳戶中不可變動,且必須可供使用者識別。

舉例來說,如果整合服務供應商使用電子郵件地址來辨識身分,這可以是電子郵件地址。然而,如果整合商使用電子郵件地址登入,但是可以變更該地址,則電子郵件地址會是帳戶 ID 的不良選擇。無論您選擇哪一個,其值必須與多個付款整合使用者使用者身分的關聯相關聯,其值必須相同。

Android 應用程式套件 (APK)

Android 作業系統用於發布及安裝行動應用程式的套件檔案格式。

API 版本管理

此規格支援版本管理。支援的版本是在 Google 伺服器上設定。從 N 版本移至 M 版本 (M 是大於 N 的主要版本) 時,整合商必須同時支援 N 和 M,直到 Google 確認所有流量均已遷移至 M 為止。系統會根據內容辨識不同的版本。Android API 和 WebRedirect API 會將 API 版本做為參數傳遞至要求。伺服器對伺服器呼叫會將該版本當做網址路徑的一部分傳送。

版本無法由流程固定。因此,在從 N 到 M 的遷移期間,整合商可能會看見擷取為 M 版本的擷取資料,而針對相同交易,則可能收到 N 版本的退款。在執行關聯時,整合服務供應商可能會收到版本 M 的驗證要求,以及版本 N 的關聯要求。

關聯 ID

associationID 可識別客戶帳戶與 Google 工具之間的關聯。associationId 和 GPT 非常類似。事實上,其生命週期與 GPT 相同,且其與 GPT 的 1:1 基數。associationId 和 GPT 的敏感度不同。GPT 是用於付款的敏感憑證。associationId 是一個公開識別碼,代表相同的關係,但本質上並不敏感。

associationIdassociateAccount 期間會傳送至付款整合商。在重新驗證期間,這個相同的值會傳送至整合服務供應商。如此一來,整合商就能知道要驗證哪些帳戶。如果傳入關聯 ID,則必須預先填入在原始關聯期間找到的相同帳戶,並經過驗證。

在整合服務供應商與 Google 之間的合約效期內,付款整合商應儲存所有關聯 ID,並將其與特定的整合服務供應商帳戶建立關聯。

驗證要求 ID

refreshTokenassociateAccount 和 (選用) 擷取方法會參照驗證。這項參照採用 Google 參照的特定驗證 requestId 格式。付款整合商會使用這個欄位來確認該方法是否已成功完成驗證。

擷取方法可填入驗證 requestId。這種情況發生在兩種情況下。如果 Google 在擷取前就驗證過使用者,則會填入驗證 requestId 欄位。此外,在設定自動付款時間表時,Google 通常會在設定期間驗證使用者。Google 會將該排程的 requestId 寫入該排程,並傳送 requestId 和與該時間表相關的每次擷取。

付款整合商應儲存所有驗證 requestIds 30 天。如果付款整合商想稽核可用於擷取要求的驗證 requestIds,包括付款時間表內的驗證,則整合商必須儲存所有驗證 requestId,直到整合商與 Google 之間的合約效期內。

公司

公司是 Google 設定和合約中定義的概念,公司定義了整合商與 Google 之間的關係。PGP 金鑰和 (選擇性) 安全資料傳輸層 (SSL) 根憑證授權單位與公司相關聯。最重要的是,公司會與一或多個付款整合商帳戶 ID 相關聯。公司內部建立的 GPT 主要適用於公司中的所有付款整合商帳戶 ID。但可能會有例外狀況。例如,如果 GPT 所連結的帳戶以一種貨幣表示 (且不支援 FX 費用),而且嘗試以其他貨幣付款整合商帳戶 ID 進行交易時,就會遇到以下情況。

付款方式 (FOP)

所有交易都會包含一或多種付款方式 (如信用卡或電子金融轉帳),由使用者支付 Google 產品或服務費用給 Google,或是在 Google 使用者和 Google Play 開發人員的情況下用於支付使用者費用。付款方式通常又稱為「付款方式」、「付款方式」和「付款方式」。

Google 付款憑證 (GPT)

GPT 是 Google 伺服器在關聯時產生的安全網路 Base64 編碼值,並且會傳送至整合服務供應商的伺服器。GPT 是一個私人 ID,代表整合了使用者帳戶與整合服務供應商與 Google 工具之間的關聯。GPT 是一個取代使用者憑證或帳戶 ID 的符記。這個代碼會在購買流程中使用,以識別信用額度或扣款。GPT 不得以明文形式傳送,並且必須經過加密以確保隱私權。

GPT 與 associationId 不同,因為 associationId 未受保護,而且會透過公開方式 (網址、不安全的連線) 免費傳遞。只有 Google 和整合服務供應商才會知道 GPT。

在整合服務中,整合服務商應儲存所有 GPTS,並將其與特定整合服務供應商帳戶建立關聯。

冪等

冪等運算可以多次套用,而不會變更結果,也不會有新的應用效果。冪等性通常會使用「key」來識別相同的要求。在兩個伺服器之間定義的所有要求,都會使用要求標頭中定義的冪等金鑰。要求標頭的要求 ID 是做為冪等鍵。要求 ID 是全域唯一的,冪等要求必須和同一個 JSON 主體完全相同,但有例外狀況。每個要求都會有不同的 requestTimestamp。這很重要,requestTimestamp 是伺服器傳送這項要求的時間。而且每次嘗試時都不得重複。藉此降低重送攻擊的能力。

除了 Echo 方法之外,所有伺服器對伺服器方法都必須是冪等的。對整合服務供應商的使用者介面 (無論是 Android 或網路) 提出的驗證要求並非冪等的。

如需冪等行為的範例,請參閱參考說明文件

識別項 (ID)

ID 代表付款整合商與 Google 之間的交易或通訊。

方式

付款方式代表與單一 Google 客戶相關聯的已儲存付款方式。樂器包括:

  • 信用卡號碼
  • 銀行帳號和銀行識別碼

使用者可以使用多個與 Google 身分相關聯的付款方式。

百萬分之一

這個 API 中的金額會以「micros」的格式呈現,這是 Google 的標準格式。微資料為整數的固定精確度格式。如要以貨幣表示金額,請將標準貨幣金額乘以 1,000,000。

例如:

  • 1.23 美元 = 1230 微米
  • 0.01 美元 = 10000 微美元

付款整合商

處理使用者交易付款的外部整合商。

付款整合商帳戶 ID

這個 ID 代表 Google 與整合服務供應商之間的合約限制。整合服務供應商帳戶 ID 是由 Google 產生,並在設定期間指派給整合服務供應商。這通常稱為「MID」。所有要求和回應都必須包含這個 ID。這個 ID 不透明,永遠無法剖析。此 ID 的格式可能與所有核發 ID 不一致。

這組 ID 在交易效期內永遠不會改變。如果是擷取與退款,則會使用相同的 ID。

整合商帳戶 ID 的限制是由合約本身定義。一般來說,月結單是有關月結單的限制。例如,整合服務供應商支援以 CAD 和 MXN 的形式開立發票,但需要以 EUR 開立發票。在這種情況下,系統會使用兩個不同的付款整合商帳戶 ID,一個用於美元月結單,另一個則用於歐元月結單。

您可以逐步淘汰 ID,改用新的 ID。如果淘汰了 ID,Google 會停止擷取該 ID。然而,整合商必須針對自上次擷取 (從 requestHeader 中找到的 requestTimestamp 擷取內容) 起一年內針對該 ID 進行的交易進行退款。

PII

個人身分資訊 (PII) 是可識別個人身分的任何其他資料,並能以合理合理的方式與 Google 以合理方式連結此類資訊,例如使用者的名稱、電子郵件地址、郵寄地址或電話號碼

請求編號

requestId 可識別 Google 與付款整合商之間的所有通訊。

SPII

敏感的個人識別資訊 (SPII) 屬於個人識別資訊 (PII),會在使用者遭駭或濫用時對使用者造成極大風險。SPII 通常對於法律、監管或法規遵循實體施加的限制與儲存要求。

權杖

權杖與 PII 或 SPII 等機密憑證在 Google 與整合服務供應商之間交換時,權杖會多添一層保護。

使用者地址

在建立付款方式時,Google 會檢查使用者是否為 Google Payments 客戶。這個做法與 Google 客戶無關。如要成為 Google Payments 客戶,請提供使用者的帳單地址。有些監管機構會要求我們知道使用者的完整地址,而有些機構則需要使用者提供該位址的子集。

如果付款整合商已有使用者登錄的地址,Google 希望在關聯流程中取得該地址,以便為使用者預先填入地址表單。使用者可選擇變更預先填入的地址。預先填入使用者地址可減少新增付款方式的麻煩,且能新增這類工具的使用者轉換率。

如果分享該位址,Google 也會使用該地址來計算其風險模型。這可以讓 Google 的風險引擎瞭解使用者所表示的帳單費用,並和使用者目前所在的 IP 位置進行比對。

分享地址只是最佳化功能,我們認為部分整合商沒有使用者的帳單地址,或是無法分享這個地址。

網路安全 Base64 編碼

RFC 4648 第 5 節 (含網址及檔案名稱安全 Alpha 版的 Base64 編碼) 中指定的編碼標準,有時也稱為「web-safe Base64」或「base64url」編碼。(這與 RFC 3548 第 4 節中網址和檔案名稱安全字母的 base64 編碼相同)。所有加密和已簽署的值都必須以此標準編碼。