Google Standard Payments：

令牌化 FOP

概览

令牌化 FOP（付款方式）是付款平台中的一种付款集成。对于使用此付款方式进行付款的用户，Google 和付款集成商必须进行一次性的账号身份凭据交换。然后完成创建令牌的流程，该令牌代表该特定用户的付款方式。此令牌可用于重复付款。这些 API 目前有两个版本。版本 2 支持移动运营商和参考号提供商。所有其他令牌化 FOP 提供商应实现版本 1。本文档的其余部分将重点介绍版本 1。

Google 使用两个流程来建立身份并创建此令牌：

1. 身份验证流程：识别和验证用户（对其进行身份验证）。
2. 关联流程：为用户创建令牌（新令牌或之前已识别并身份验证的用户）。此令牌表示特定用户的特定付款方式。此令牌可供日后的购买交易使用。

创建令牌后，Google 将在购买流程中使用该令牌，为用户提供快速顺畅的结账体验。Google 使用此令牌来表示客户的付款方式实例。也称为乐器。Google 客户可能会通过多种付款方式为商品和服务付款。

最后，集成商银行与 Google 银行之间的所有资金转移均在汇款流程中完成。

<ph type="x-smartling-placeholder"> </ph> 1) 用户选择要购买的产品

<ph type="x-smartling-placeholder"> </ph> 2) 然后，选择付款方式

<ph type="x-smartling-placeholder"> </ph> 3) 现在，他们添加了新的付款方式

<ph type="x-smartling-placeholder"> </ph> 4) 他们会被重定向以进行身份验证

<ph type="x-smartling-placeholder"> </ph> 5) 最后，他们通过了身份验证，可以购买

下图展示了流程的大致概览：

令牌化 FOP 概览

概括来讲，将您的服务添加为 Google 产品的付款方式涉及到以下流程：

1. 身份验证流程
2. 关联流程
3. 购买流程
4. 退款流程
5. 汇款流程

以下部分更详细地介绍了这些流程，指南部分也对此进行了更详细的说明。

概念与术语

Symbols & Conventions

The key words "MUST," "MUST NOT," "REQUIRED," "SHALL," "SHALL NOT," "SHOULD," "SHOULD NOT," "RECOMMENDED," "MAY," and "OPTIONAL" in these documents are to be interpreted as described in RFC 2119.

Timestamps

All timestamps are represented as milliseconds since the Unix epoch (Jan 1, 1970) in UTC.

For example:

• April 23, 2019 8:23:25 PM GMT = 1556051005000 milliseconds
• August 16, 2018 12:28:35 PM GMT = 1534422515000 milliseconds

Amounts

Monetary values in this API are in a format called "micros," a standard at Google. Micros are an integer based, fixed precision format. To represent a monetary value in micros, multiply the standard currency value by 1,000,000.

For example:

• USD$1.23 = 1230000 micro USD
• USD$0.01 = 10000 micro USD

Idempotency

All method calls within this API must have idempotent behavior. Google will sporadically retry requests to ensure that transactions are in the same state on both sides. Integrators should not attempt to reprocess any request already successfully processed. The response for the successful processing should be reported instead. All methods have a common RequestHeader which contains a requestId. This requestId is the idempotency key for all calls.

Any non terminal response (a non HTTP 200-success), must not be idempotently processed. So a request that previously got a 400 (bad request/failed precondition), when called a second time, must not idempotently return 400, it must be re-evaluated. At re-evaluation, it could return a 400 or be processed successfully.

For more information on idempotency see this detailed guide.

Integrator

A company who uses Google’s Payment Platform for their business. It could be internal (1P), such as Youtube or AdWords, It can also be an external (3P) business wanting to integrate their service to work with Google’s ecosystem.

FOP

Form of Payment. This is more general than an instrument. Visa, MasterCard, and PayPal are all FOPs.

Instrument

A particular instance of a form of payment by a specific customer. For instance, a user’s credit card, or their PayPal account. A tokenized FOP for a particular customer is also an instrument, because it is an instance of a form of payment for that customer, securely stored on our system.

Token

A representation, on Google’s system, of a specific user’s payment method. Since it contains all the information needed to make a purchase, a token is also an instrument. This may include such information as an account number a user has with their integrator.

主要流程

身份验证流程

身份验证是必须执行的第一个流程。身份验证流程旨在向集成商识别和验证用户身份。可以通过多种方式进行身份验证。令牌化 FOP 支持两种识别和验证用户身份的方法：

1. SMS-MT 动态密码身份验证（短信移动版终止、动态密码）
2. 重定向身份验证

在初始配置过程中，集成商会与 Google 合作，选择最适合其产品的身份验证机制。

身份验证流程可用于两种情况：第一，识别新客户以建立关联；第二，验证用户以获取现有付款方式的凭据。身份验证流程的结果可用作多个流程的输入，例如关联流程、刷新令牌流程、质询购买流程等。此外，身份验证流程可在独立模式下使用，而不与任何后续流程相关联。

SMS-MT 动态密码身份验证

在此身份验证机制中，用户在 Google 界面中输入电话号码。Google 将此电话号码发送给集成商（通过 sendOtp 方法）。集成商向用户发送动态密码。用户将密码输入到 Google 界面中，然后由该界面将密码发送给集成商。这会触发支付集成商的成功响应。

在独立模式下使用 SMS-MT 动态密码身份验证时，系统会通过 verifyOtp 方法将动态密码的值发送给集成商。此方法可验证提供的动态密码是否发送。

重定向身份验证

重定向身份验证由 Google 将用户重定向到集成商拥有的应用。该应用可以是 Web 应用，也可以是 Android 应用。

Android 重定向和网页重定向的行为类似。Google 将用户重定向到集成商的应用。集成商以最适合该集成商的任何形式识别和验证用户。通过身份验证后，集成商会将用户重定向回 Google 的界面以完成关联。重定向后，Google 会提供 requestId 来识别此身份验证会话。然后，该标识符将用作关联期间的身份身份验证证明。

选择此流程的集成商必须提供网络身份验证网址，因为这是所有平台（桌面设备或移动设备）上最常见的分母。不过，我们强烈建议使用 Android 身份验证功能，以便在移动设备上提供最佳用户体验。

根据设备使用情境和安装的应用，Google 界面将选择是网页重定向还是 Android 应用重定向。

这种身份验证机制为集成商提供了最大的自由。可以通过多种方式对用户进行身份验证和标识。“用户名+密码”或“生物识别信息”和“安全问题”都是可行的解决方案。Google 不打算指定集成商验证用户的方式。集成商负责对用户进行身份验证。因此，Google 打算利用集成商的各种界面对用户进行身份验证，然后简单地向 Google 提供身份验证证明。

注意 ：如果集成商在重定向期间要使用 SMS-MT 动态密码，Google 强烈建议您使用上述 SMS-MT 动态密码身份验证。用户在使用 Google 产品和服务时，可以获享更顺畅的体验。

如需详细了解身份验证，请参阅此详细指南。

关联流程

在通过上述某种机制完成身份验证流程后，用户会经历关联流程。关联流程旨在创建 Google 付款令牌 (GPT) 以创建付款方式。此流程会执行以下操作：

1. 协商一个名为令牌的身份来代表此用户。
2. 提供账号信息，以告知 Google 的风险引擎。
3. 收集创建和建立 GPT 所需的首次设置信息。

结果是既定的 GPT 由 Google 与集成商商定。

两个 Google 用户可以与集成商共享同一个用户账号。在这种情况下，每位用户都有不同的付款方式。每种付款方式都有独立的关联流程，因此具有唯一的 GPT。

此插图展示了一个名为 InvisiCash 的虚假令牌化 FOP。这演示了用户在身份验证流程和关联流程中要经历的步骤。

关联流程概览

1. 一位电子邮件地址为 [e-mail] 的 Google 用户希望将自己的 InvisiCash 账号添加到 Google Play 商店，以便使用该账号购物。
2. 为了进行身份验证，Google Play 商店会打开 InvisiCash 应用。

3. 用户使用电子邮件地址 [e-mail] 登录其 InvisiCash 账号。如果她的 InvisiCash 登录信息是她的 Gmail 电子邮件地址，则她可能会将这两个电子邮件地址用于这两个账号。

   注意 ：还有其他身份验证方法。这只是一个示例。您甚至可能在网页上完成，而不是通过应用。

4. InvisiCash 应用将身份验证 ID 发送回 Google Play 商店。

5. Google Play 商店将身份验证 ID 发送到 Google 服务器。

6. Google 服务器向 InvisiCash 服务器发送消息，以关联该账户。此关联包括身份验证 ID、GPT（Google 付款令牌）和关联 ID。

7. InvisiCash 服务器会存储 Google 付款令牌 (GPT) 和关联 ID。这两个账号现在都与 Sally 的 InvisiCash 账号相关联。

8. InvisiCash 批准建立此关联。然后，Google 的服务器会创建付款方式，以供日后的购买交易使用。