令牌化 FOP
概览
令牌化 FOP（付款方式）是付款平台中的一种付款集成。对于使用此付款方式进行付款的用户，Google 和付款集成商必须进行一次性的账号身份凭据交换。然后完成创建令牌的流程，该令牌代表该特定用户的付款方式。此令牌可用于重复付款。这些 API 目前有两个版本。版本 2 支持移动运营商和参考号提供商。所有其他令牌化 FOP 提供商应实现版本 1。本文档的其余部分将重点介绍版本 1。
Google 使用两个流程来建立身份并创建此令牌：
创建令牌后，Google 将在购买流程中使用该令牌，为用户提供快速顺畅的结账体验。Google 使用此令牌来表示客户的付款方式实例。也称为乐器。Google 客户可能会通过多种付款方式为商品和服务付款。
最后，集成商银行与 Google 银行之间的所有资金转移均在汇款流程中完成。
<ph type="x-smartling-placeholder">
|
<ph type="x-smartling-placeholder">
|
<ph type="x-smartling-placeholder">
|
<ph type="x-smartling-placeholder">
|
<ph type="x-smartling-placeholder">
|
下图展示了流程的大致概览：
令牌化 FOP 概览
概括来讲，将您的服务添加为 Google 产品的付款方式涉及到以下流程：
以下部分更详细地介绍了这些流程，指南部分也对此进行了更详细的说明。
概念与术语
符号和惯例
关键字“必须”“不得”“必需”“会”“不会”，“应该”“不应”“推荐”“可以”和“OPTIONAL”RFC 2119 中解释这些文档。
时间戳
所有时间戳均以自 Unix 纪元（1970 年 1 月 1 日）以来的毫秒数表示（采用世界协调时间）。
例如：
- 2019 年 4 月 23 日晚上 8:23:25（格林尼治标准时间 = 1556051005000 毫秒）
- 格林尼治标准时间 2018 年 8 月 16 日下午 12:28:35 = 1534422515000 毫秒
金额
此 API 中的货币值采用名为“微单位”的格式，是 Google 的一项标准微单位是一种基于整数的固定精度格式。要以微单位表示货币价值，请用标准货币价值乘以 1,000,000。
例如：
- 1.23 美元 = 1230000 微美元
- 0.01 美元 = 10000 微美元
幂等性
此 API 中的所有方法调用都必须具有幂等行为。Google 将不定期地重试请求，以确保双方的事务都处于相同的状态。集成商不应尝试重新处理任何已成功处理的请求。应改为报告成功处理的响应。所有方法都有一个共同的 RequestHeader，其中包含 requestId。此 requestId 是所有调用的幂等键。
任何非终端响应（非 HTTP 200 成功）不得以幂等方式进行处理。因此，之前收到 400（错误请求/失败前提条件）的请求在第二次调用时不得以幂等方式返回 400，必须重新评估该请求。在重新评估时，它可能会返回 400 或成功处理。
如需详细了解幂等性，请参阅此详细指南。
集成商
使用 Google 付款平台开展业务的公司。它可能是内部 (1P) 企业，如 YouTube 或 AdWords；也可能是希望将其服务与 Google 生态系统集成的外部 (3P) 企业。
付款方式
付款方式。这比乐器更通用。Visa、MasterCard 和 PayPal 均为付款方式。
乐器
特定客户使用的特定付款方式。例如用户的信用卡或 PayPal 账号。特定客户的令牌化 FOP 也是一种付款方式，因为它是该客户的付款方式实例，安全地存储在我们的系统中。
令牌
在 Google 系统中，表示特定用户的付款方式。令牌包含购买所需的全部信息，因此也是一种付款方式。这可能包括用户在集成商处拥有的账号等信息。
主要流程
身份验证流程
身份验证是必须执行的第一个流程。身份验证流程旨在向集成商识别和验证用户身份。可以通过多种方式进行身份验证。令牌化 FOP 支持两种识别和验证用户身份的方法：
- SMS-MT 动态密码身份验证（短信移动版终止、动态密码）
- 重定向身份验证
在初始配置过程中，集成商会与 Google 合作，选择最适合其产品的身份验证机制。
身份验证流程可用于两种情况：第一，识别新客户以建立关联；第二，验证用户以获取现有付款方式的凭据。身份验证流程的结果可用作多个流程的输入，例如关联流程、刷新令牌流程、质询购买流程等。此外，身份验证流程可在独立模式下使用，而不与任何后续流程相关联。
SMS-MT 动态密码身份验证
在此身份验证机制中，用户在 Google 界面中输入电话号码。Google 将此电话号码发送给集成商（通过 sendOtp 方法）。集成商向用户发送动态密码。用户将密码输入到 Google 界面中，然后由该界面将密码发送给集成商。这会触发支付集成商的成功响应。
在独立模式下使用 SMS-MT 动态密码身份验证时，系统会通过 verifyOtp 方法将动态密码的值发送给集成商。此方法可验证提供的动态密码是否发送。
重定向身份验证
重定向身份验证由 Google 将用户重定向到集成商拥有的应用。该应用可以是 Web 应用，也可以是 Android 应用。
Android 重定向和网页重定向的行为类似。Google 将用户重定向到集成商的应用。集成商以最适合该集成商的任何形式识别和验证用户。通过身份验证后，集成商会将用户重定向回 Google 的界面以完成关联。重定向后，Google 会提供 requestId 来识别此身份验证会话。然后，该标识符将用作关联期间的身份身份验证证明。
选择此流程的集成商必须提供网络身份验证网址，因为这是所有平台（桌面设备或移动设备）上最常见的分母。不过，我们强烈建议使用 Android 身份验证功能，以便在移动设备上提供最佳用户体验。
根据设备使用情境和安装的应用，Google 界面将选择是网页重定向还是 Android 应用重定向。
这种身份验证机制为集成商提供了最大的自由。可以通过多种方式对用户进行身份验证和标识。“用户名+密码”或“生物识别信息”和“安全问题”都是可行的解决方案。Google 不打算指定集成商验证用户的方式。集成商负责对用户进行身份验证。因此，Google 打算利用集成商的各种界面对用户进行身份验证，然后简单地向 Google 提供身份验证证明。
如需详细了解身份验证，请参阅此详细指南。
关联流程
在通过上述某种机制完成身份验证流程后，用户会经历关联流程。关联流程旨在创建 Google 付款令牌 (GPT) 以创建付款方式。此流程会执行以下操作：
- 协商一个名为令牌的身份来代表此用户。
- 提供账号信息，以告知 Google 的风险引擎。
- 收集创建和建立
GPT所需的首次设置信息。
结果是既定的 GPT 由 Google 与集成商商定。
两个 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。这两个账号现在都与 Sally 的 InvisiCash 账号相关联。InvisiCash 批准建立此关联。然后，Google 的服务器会创建付款方式，以供日后的购买交易使用。