帳戶 ID
在連結流程期間，帳戶 ID 會從整合商的伺服器傳回，可協助 Google 透過兩種方式識別基礎帳戶。首先，找出使用相同基礎使用者帳戶的多種工具，以評估風險和詐欺。其次，Google 客戶服務服務專員會使用這項資訊 識別這個帳戶。這個值必須用於識別關聯要求中的使用者帳戶，且必須在特定帳戶中無法變更，且必須可由使用者識別。
舉例來說，如果整合商使用電子郵件地址來驗證身分，可以是電子郵件地址。然而，如果整合商使用電子郵件地址登入，但該地址可以變更，那麼電子郵件地址就不是帳戶 ID 的選擇。無論選擇哪種方式，如果多次連結嘗試與相同的付款整合商使用者身分，其值都必須相同。
Android 應用程式套件 (APK)
Android 作業系統用於發布及安裝行動應用程式的套件檔案格式。
API 版本管理
此規格支援版本管理。支援的版本會在 Google 伺服器上設定。從版本 N 移至 M (其中 M 是大於 N 的主要版本) 時，整合商必須同時支援 N 和 M，直到所有流量都遷移至 M。系統會根據情境區分不同的版本。Android API 和 WebRedirect API 會將 API 版本做為參數傳遞至要求。伺服器對伺服器呼叫會將版本做為網址路徑的一部分傳遞。
版本並非依照流程修正。因此，在從 N 遷移至 M 期間，整合商可能會看到針對同版本 N 的擷取內容，以及針對同版本 N 的退款。在關聯期間，整合商可能會收到版本 M 的驗證要求和版本 N 的關聯要求。
關聯 ID
associationID 可識別客戶帳戶和 Google 付款方式之間的關聯。associationId 與 GPT 非常類似。實際上，它的生命週期與 GPT 相同，而且 GPT 採用 1:1 基數。associationId 與 GPT 的機密性不同。GPT 是一種用於付款的機密權杖associationId 是公開 ID，代表相同關係，但在性質上並不會敏感。
associationId 會在 associateAccount 期間傳遞至付款整合商。這個值會在重新驗證時傳遞給整合商。如此一來，整合商就能取得需要驗證帳戶的背景資訊。如果傳入關聯 ID，則在原始關聯期間識別到的帳戶必須預先填入並通過驗證。
在整合商與 Google 之間簽訂合約的效期內，付款整合商應儲存所有關聯 ID，並將這些 ID 與特定整合商帳戶建立關聯。
驗證要求 ID
refreshToken、associateAccount 和 (選用) 方法會擷取驗證的參照。這個參照格式為 Google 參照的特定驗證 requestId。付款整合商會使用此欄位，確認付款方式確實已成功完成驗證。
擷取方法可以填入驗證 requestId。這在兩種情況下都會發生。如果 Google 在擷取前就對使用者進行驗證，Google 會填入驗證 requestId 欄位。此外，Google 通常會在設定自動付款時段時在設定時間驗證使用者。Google 會在該時間表下寫入驗證 requestId，並傳送 requestId 以及與該特定排程相關的所有擷取。
付款整合商應將所有驗證 requestIds 保存 30 天。如果付款整合商想稽核擷取要求中可以顯示的驗證 requestIds (包括付款排程)，那麼整合商必須在整合商與 Google 之間的合約生命週期內儲存所有驗證 requestId。
公司
公司是 Google 設定與合約中定義的概念。公司則定義整合商和 Google 之間的關係。PGP 金鑰和 (選用) SSL 根 CA 會與公司建立關聯。最重要的是，一家公司會與一或多個付款整合商帳戶 ID 相關聯。大多是在公司內建立的 GPT 來處理公司內部的所有付款整合商帳戶 ID。但部分例外狀況可能不適用。舉例來說，如果 GPT 與一個以一種貨幣指定的帳戶相關聯 (且不支援外匯費用)，並正嘗試以其他幣別購買付款整合商帳戶 ID。
付款方式 (FOP)
所有交易都包含一種或多種付款方式 (FOP)，例如信用卡或電子金融轉帳，當使用者向 Google 支付產品或服務費用時，就會使用這些付款方式；如果是 AdSense 使用者和 Google Play 開發人員，Google 就會付款給使用者。付款方式通常也稱為「付款方式」、「付款方式」和「付款方式」。
Google Payment Token (GPT)
GPT 是 Google 伺服器在關聯時產生的隨機網路安全 Base64 編碼值，並傳遞至整合商的伺服器。GPT 是一個私人 ID，代表使用者的帳戶與 Google 工具之間的關聯。GPT 是一種權杖 可取代使用者憑證或帳戶 ID這組權杖會在購買流程中使用，用於識別信用卡或簽帳金融卡，且雙方都保密。GPT 一律不得以明文傳送，且必須加密以保障隱私。
GPT 與 associationId 不同，因為 associationId 不受保護，並且會透過公開方式 (網址、不安全的連線) 自由傳遞。GPT 僅供 Google 和整合商使用。
在整合商與 Google 之間簽訂合約的效期內，付款整合商應儲存所有 GPTS，並將其與特定整合商帳戶建立關聯。
冪等
冪等作業可以多次套用，且不會變更結果，也不會影響作業初始套用以外的新的副作用。一般來說，冪等性會使用「鍵」來識別相同的要求。在兩個伺服器之間定義的所有要求都會使用要求標頭中定義的冪等鍵。要求標頭有一個要求 ID，可做為冪等鍵。要求 ID 是全域唯一的。冪等要求必須與 JSON 主體完全相同，但有一個例外狀況。每項要求的 requestTimestamp 都不同。這是一項重要的差異。requestTimestamp 是伺服器傳送這項要求的時間。每次嘗試則不會重複。這有助於降低重送攻擊的能力。同樣地，冪等回應必須與 JSON 主體完全相同，但每個回應的 responseTimestamp 都不同。
除了 Echo 方法之外，所有伺服器對伺服器方法都必須具備冪等性。對整合商的 UI (即 Android 或網頁) 發出的驗證要求並非冪等的。
如需冪等行為的範例，請參閱參考文件。
識別項 (ID)
ID 代表付款整合商與 Google 之間的交易或通訊。
方式
付款方式代表與單一 Google 客戶相關聯的已儲存付款方式。樂器包括：
- 登錄的信用卡號碼
- 銀行帳戶和銀行識別碼
使用者可以將自己的 Google 身分連結至多種付款方式。
百萬分之一
這個 API 中的金額是以「微型」格式表示，這是 Google 的標準格式。微量是以整數為準的固定精確度格式。如要以微量單位表示金額，請將標準貨幣值乘以 1,000,000。
例如：
- $1.23 美元 = 12,30000 微秒
- $0.01 美元 = 10,000 微秒
付款整合商
處理使用者交易付款的外部整合商。
付款整合商帳戶 ID
這個 ID 代表 Google 和整合商之間合約的限制。整合商帳戶 ID 是由 Google 產生，並於設定期間指派給整合商。通常稱為「MID」。所有要求和回應都必須包含此 ID。這個 ID 不透明，且不得剖析。所有核發的 ID 格式可能不一致。
此 ID 在交易的生命週期內不會變更。如果是擷取和退款，則使用相同的 ID。
整合商帳戶 ID 的限制是由合約本身定義。 一般而言，這類限制與應付憑據有關。例如，整合商會將 CAD 和 MXN 開立為美元的應付憑據，但需要以歐元開立 EUR 交易的應付憑據。在這種情況下，我們會使用兩個不同的付款整合商帳戶 ID，一個用於月結，另一個則用於歐元月結單。
系統可能會逐步停用這個 ID，改用新的 ID。如果 ID 已淘汰，Google 將停止擷取該 ID。不過，整合商必須接受從上次擷取開始起算一年內 (擷取定義定義為 requestHeader 中位於 requestTimestamp) 的交易退款。
PII
個人識別資訊 (PII) 是指個人識別資訊，以及可讓 Google 合理連結至此類資訊的任何其他資料，例如使用者名稱、電子郵件地址、郵寄地址或電話號碼 (無論是單獨還是組合使用)。
請求編號
requestId 可識別 Google 和付款整合商之間的所有通訊內容。
SPII
機密個人識別資訊 (SPII) 是個人識別資訊 (PII) 的子集，可能會在使用者遭駭或濫用時造成高風險。SPII 通常有法律、監管或法規遵循實體設下的限制處理和儲存要求。
權杖
當 Google 和整合商交換 PII 或 SPII 等機密憑證時，權杖會增添一層安全保障。
使用者地址
在建立付款方式時，Google 會確認使用者是否為 Google Payments 客戶。這與 Google 客戶無關。我們需要使用者的帳單地址，才能成為 Google Payments 客戶。有些監管機關會要求我們知道使用者的完整地址，但有些監管機構則需要其一部分地址。
如果付款整合商已登錄了這位使用者的地址，Google 會在連結流程中取得該地址，以便為使用者預先填入地址表單。使用者可以選擇變更預先填入的地址。預先填入使用者地址可減少新增付款方式的麻煩，並提高新增這些付款方式的使用者轉換率。
如果該地址已共用，Google 也會使用該地址在風險模型中進行計算。這可讓 Google 的風險引擎瞭解使用者表示要付費的位址，並比較使用者目前所在的 IP 位置。
「共用地址」這純粹只是將地址最佳化，有些整合商不會知道使用者的帳單地址，或者無法共用這個地址。
Web-Safe Base64 編碼
依 RFC 4648 第 5 節指定的編碼標準，含網址和檔案名稱 Safe Alphabet 的 Base 64 編碼，有時也稱為「web-safe Base64」或「base64url」編碼。(與 RFC 3548 第 4 節中，有網址和檔案名稱安全字母的 Base64 編碼相同)。所有加密和已簽署的值都必須採用上述標準編碼。