账号 ID
在关联流程中，系统会将帐号 ID 从集成商的服务器发回；它用于帮助 Google 通过两种方式识别底层帐号。首先，找出使用同一基础用户帐号的多个付款方式，以评估风险和欺诈。其次，Google 客户服务代理会使用此 ID 来识别此帐号。此值必须在所有关联请求中唯一标识用户帐号，并且必须在特定帐号中是不可变的，并且必须可由用户识别。
例如，如果集成商使用电子邮件地址作为身份，则该地址可以是电子邮件地址。但是，如果集成商使用电子邮件地址登录，但该地址可以更改，那么使用电子邮件地址作为帐号 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 是一个表示相同关系的公共标识符，但本质上不那么敏感。
associationId 会在 associateAccount 期间传递给付款集成商。在重新向集成商重新进行身份验证期间，系统会将同一值传递至集成商。这样，集成商就可以了解必须对哪个帐号进行身份验证。如果传入关联 ID，则必须针对原始关联期间识别的同一帐号进行预填充和身份验证。
付款集成商应存储所有关联 ID，并在集成商与 Google 之间的合同生命周期内将它们与特定集成商帐号相关联。
身份验证请求 ID
refreshToken、associateAccount 和（可选）捕获方法会获取对身份验证的引用。此引用采用 Google 所引用的特定身份验证的 requestId 格式。付款集成商将利用此字段来验证方法是否确实已通过身份验证成功。
捕获方法可以填充身份验证 requestId。这种情况发生在以下两种情况下。如果 Google 在即将拍摄前对用户进行身份验证，则会填充身份验证 requestId 字段。此外，如果设置了自动付款时间安排，Google 通常会在设置时对用户进行身份验证。Google 会根据该时间表记录身份验证 requestId，并发送 requestId 以及与该特定时间表关联的所有捕获。
付款集成商应将所有身份验证 requestIds 存储 30 天。如果付款集成商想要审核捕获请求中可出现的身份验证requestIds，包括付款时间表中包含的身份验证，集成商必须在集成商与 Google 的合约期内存储所有身份验证requestId。
公司
公司是 Google 配置和合同中定义的概念。公司定义了集成商与 Google 之间的关系。PGP 密钥和（可选）SSL 根 CA 与该公司相关联。最重要的是，一家公司与一个或多个付款集成商帐号 ID 相关联。在公司中创建的 GPT 主要适用于公司内的所有付款集成商帐号 ID。不过，也有一些例外情况。例如，如果 GPT 与以某币种计价（且不支持外汇手续费）的帐号相关联，并尝试通过付款集成商帐号 ID 使用不同币种进行购买。
付款方式 (FOP)
所有交易都包括一种或多种付款方式 (FOP)，例如信用卡或电子转账，供用户向 Google 支付产品或服务费用；Google 向用户付款（如果是 AdSense 用户和 Google Play 开发者）。付款方式通常也称为“付款方式”、“付款方式”和“付款方式”。
Google 付款令牌 (GPT)
GPT 是由 Google 服务器在关联时生成并传送给集成商服务器的随机网络安全 base64 编码值。GPT 是一种私有标识符，表示用户帐号与集成商和 Google 付款方式之间的关联。GPT 是一种用于替换用户凭据或帐号 ID 的令牌。此令牌用于在购买流程中标识要用于信用卡或借记卡的帐号，并且对双方均保密。GPT 绝不能以明文形式发送，必须经过加密处理，以确保隐私安全。
GPT 与 associationId 的不同之处在于，associationId 不受保护，并且可通过公共方式（网址、不安全的连接）自由传递。只有 Google 和集成商知道 GPT。
付款集成商应存储所有 GPTS，并在集成商与 Google 之间的合同生命周期内将它们与特定集成商帐号相关联。
幂等性
您可以多次应用幂等操作，而不会改变结果，也不会在初始应用操作之外产生新的副作用。通常，幂等性使用“键”来标识相同的请求。两个服务器之间定义的所有请求都使用请求标头中定义的幂等键。请求标头有一个请求 ID，该 ID 用作幂等键。请求 ID 具有全局唯一性。幂等请求必须是完全相同的 JSON 正文，但有一个例外。每个请求的 requestTimestamp 都不同。这是一个重要的区别。requestTimestamp 是服务器发送此请求的时间。并且每次尝试都具有唯一性。这有助于降低遭受重放攻击的能力。
同样，幂等响应必须是完全相同的 JSON 正文，但 responseTimestamp 会因每个响应而异。
除 Echo 方法外，所有服务器到服务器的方法都必须具有幂等性。对集成商界面（无论是 Android 还是 Web）的身份验证请求不具有幂等性。
如需查看幂等行为的示例，请参阅参考文档。
标识符 (ID)
标识符表示付款集成商与 Google 之间的交易或通信。
票据
该付款方式代表与单个 Google 客户相关联的已存储付款方式。乐器示例包括：
- 留存的信用卡号
- 银行账户和汇款路线号码
用户可以拥有多个与其 Google 身份相关联的付款方式。
百万分之一
此 API 中的货币值使用 Google 的一项标准“micros”表示。微单位是一种基于整数的固定精度格式。如需以微单位表示货币价值，请用标准货币价值乘以 1,000,000。
例如：
- 1.23 美元 = 1230000 微美元
- 0.01 美元 = 10000 微美元
付款集成商
处理用户交易付款的外部集成商。
付款集成商账号 ID
此标识符表示有关 Google 与集成商之间合同的限制条件。集成商帐号 ID 由 Google 生成，并在设置期间分配给集成商。通常称为“MID”。所有请求和响应都必须包含此 ID。此标识符不透明，且一律不得解析。此标识符的格式可能并非在所有签发的 ID 之间保持一致。
此标识符在交易的生命周期内保持不变。如果是拍摄和退款，则使用相同的标识符。
集成商帐号 ID 的约束条件由合同本身定义。 一般情况下，此类限制与账单结算有关。例如，集成商支持以美元开具账单，加元和墨西哥比索 (MXN)，但要求以欧元开具账单。在这种情况下，系统会使用两个不同的付款集成商帐号 ID，一个用于美元账单结算，另一个用于欧元账单结算。
此标识符可以逐步淘汰，取而代之的是新的标识符。如果标识符遭弃用，Google 将停止启动对该标识符的捕获。但是，对于针对该标识符进行的交易，集成商必须接受退款，退款期限为自上次捕获启动起的一年内（捕获启动定义为 requestHeader 中的 requestTimestamp）。
PII
个人身份信息 (PII) 是指用于识别个人身份的信息，以及 Google 可以合理关联到此类信息的任何其他数据，例如用户的姓名、电子邮件地址、邮寄地址或电话号码，这些信息可以单独使用，也可以两者结合使用
申请 ID
requestId 用于标识 Google 与付款集成商之间的所有通信。
SPII
敏感的个人身份信息 (SPII) 是个人身份信息 (PII) 的一个子集，如果被泄露或滥用，会给用户带来很高的风险。法律、监管或合规实体通常会对 SPII 施加限制性处理和存储要求。
令牌
在 Google 与集成商之间交换个人身份信息或 SPII 等敏感凭据时，令牌可增加一层额外的安全防护。
用户地址
在创建付款工具时，Google 会检查用户是否为 Google Payments 客户。这独立于 Google 客户。要成为 Google Payments 客户，我们需要用户的账单邮寄地址。一些监管机构要求我们知道用户的完整地址，而另一些监管机构则要求我们提供用户的完整地址。
如果付款集成商记录了该用户的地址，Google 希望在关联流程中获取该地址，以便预填充该用户的地址表单。用户可以选择更改预填充的地址。预填充用户地址可以减少添加付款方式的麻烦，并提高添加付款方式的用户的转化率。
如果地址已被共享，Google 还会将其用作风险模型计算。这样，Google 的风险引擎便可以了解用户声称的计费地址，同时会将该地址与用户当前所在的 IP 位置进行比较。
地址共享纯粹是一项优化。有些集成商没有用户的账单邮寄地址或无法共享此地址，这也是可以的，也最好。
网络安全的 Base64 编码
RFC 4648 第 5 节“使用网址和文件名安全字母表进行 Base 64 编码”中指定的编码标准，有时也称为“网络安全的 Base64”或“base64url”编码。（这与 RFC 3548 第 4 节中“使用网址和文件名安全字母表进行 base64 编码”相同。）所有加密和带符号的值都必须使用此标准进行编码。