智能触碰通信流程

终端与 Google 钱包应用之间的通信

终端使用收款方 ID 标识自身,该 ID 将映射到兑换发卡机构 ID。当发生智能触碰时,终端会将其收款器 ID 传输到用户的设备。然后,Google 钱包应用会检查每个存储的卡券的类 ID 和收款方 ID。找到一个或多个匹配项时,Google 钱包应用会将匹配的卡券传输到终端。如需了解设置详情,请参阅商家配置

示例 1:一个兑换发卡机构

以下部分介绍了此图中列出的设置。

上图中有两个不同的颁发者:

  • 发卡机构 2018 是卡券开发者(也称为集合商家)
  • 发卡机构 1990 是商家 fooPizza(也称为兑换发卡机构)

兑换发卡机构 fooPizza 想要为其卡券(由集合商家管理)启用智能触碰功能。集合商家和兑换发卡机构必须完成以下步骤,才能为商家终端启用智能触碰功能。

步骤 角色 说明
1 聚合信息网站 创建卡券类和对象(在图中分别为 abc123)。
2 集合商家 将兑换发卡机构的 ID 添加到卡券类的 redemptionIssuers 属性中。这会告知 Google 钱包,发卡机构 ID 1990 可以兑换引用此类的卡券对象。
3 兑换发卡机构 获取收款方 ID(在图中,12345678)。
4 兑换发卡机构 在要使用的每个支持智能触碰的终端上设置收款方 ID 12345678。任何类 ID 为 abc 且收集器 ID 为 12345678 的对象都将传送给读取器。

示例 2:多个兑换发卡机构

一个卡券类可以有多个兑换发卡机构。为了能够兑换特定卡券类,兑换发卡机构的 ID 必须包含在该类的 redemptionIssuers 属性中。然后,每个兑换发卡机构都有自己的收款方 ID,此 ID 会在支持智能触碰的终端上配置。

以下部分介绍了此图中列出的设置。

上图中有三个不同的颁发者:

  • 发卡机构 8088 是卡券开发者(集合商家)
  • 发卡机构 1990 是商家 fooPizza(兑换发卡机构)
  • 发卡机构 2018 是商家 yumPie(兑换发卡机构)

集合商家和兑换发卡机构必须完成以下步骤,才能为商家终端启用智能触碰功能。

步骤 角色 说明
1 聚合信息网站 创建卡券类和对象(在图中分别为 abc123)。
2 集合商家 在卡券类的 redemptionIssuers 属性中添加兑换发卡机构的 ID。这会告知 Google 钱包,发卡机构 ID 19902018 可以兑换引用此类的卡券对象。
3 兑换发卡机构 获取收集器 ID(在图中,12345678 用于 fooPizza,18802001 用于 yumPie)。
4 兑换发卡机构 在要使用的每个支持智能触碰的终端上设置相应的收款方 ID。任何具有类 ID abc 和匹配的收集器 ID 的对象都将传输给读取器。

示例 3:无集合商家

卡券类可以在同一发卡机构帐号中开发和发放。在这种情况下,没有聚合器管理多个兑换发卡机构的卡券类。为了能够兑换特定的卡券类,卡券开发者必须在该类的 redemptionIssuers 属性中包含其发卡机构 ID。然后,卡券开发者必须获取收款方 ID,并在支持智能触碰的终端上对其进行配置。

以下部分介绍了此图中列出的设置。

卡券开发者必须完成以下步骤,才能为商家终端启用智能触碰功能。

步骤 角色 说明
1 通过开发者 创建卡券类和对象(在图中分别为 abc123)。
2 通过开发者 将其发卡机构 ID 添加到卡券类的 redemptionIssuers 属性中。这会告知 Google 钱包,发卡机构 ID 2018 可以兑换引用此类的卡券对象。
3 通过开发者 获取收款方 ID(在图中,12345678)。
4 通过开发者 在要使用的每个支持智能触碰的终端上设置相应的收款方 ID。任何具有类 ID abc 和匹配的收集器 ID 的对象都将传输给读取器。

用户体验和行为

在终端和 Google 钱包应用之间传输的内容的行为取决于用户以及当时用户与 Google 钱包应用的互动方式。

场景 1:用户打开特定卡券

步骤 角色 说明
1 用户 在 Google 钱包应用中选择特定卡券。
2 用户 点按某个已启用智能触碰的终端。
3 航站楼 (收集器 ID 匹配)卡券会传输到终端。
(收款方 ID 不匹配)卡券不会传输到终端。

情形 2:Google 钱包“首页”标签页或解锁的屏幕视图

步骤 角色 说明
1 用户 在 Google 钱包应用中打开“首页”标签页,或解锁设备屏幕。
2 用户 点按某个已启用智能触碰的终端。
3 航站楼 (单个有效的收款方 ID 匹配)卡券会传输到终端。
(多个有效的收款方 ID 匹配)显示有效卡券的轮播界面,并传输用户选择一张卡券。

请注意,卡券的有效性取决于卡券对象的具体配置。请务必检查以下传递对象属性:

  • state
  • validTimeInterval

智能触碰数据收集示例

下表介绍了此示例中将使用的颁发者和卡券:

商家名称 ILuvCoffee 咖啡美食 Mocha-R-U
发卡机构 ID 123 456 789
收款方 ID 11111111 44444444 77777777
会员级别 R-基本版 我的奖励
R 级

ILuvCoffee 有两个不同的会员层级:R-BasicR-Gold。同时,Coffee-Foo 的会员卡只有一级,即 My Rewards,Mocha-R-U 没有会员卡。

在交叉宣传广告系列中,商家希望为客户提供以下选项:

  • R-Basic 层级客户可以使用智能触碰功能在 Coffee-Foo 和 Mocha-R-U 兑换会员会员资格
  • R-Gold 层级客户无需使用智能触碰兑换功能
  • My Rewards 客户可以使用智能触碰功能兑换其仅在 Coffee-Foo 的会员会员资格

为了让此广告系列能够正常运行,每个会员卡类都需要在类定义的 redemptionIssuers 属性中设置以下值。

会员卡类 兑换发卡机构 ID
R-基本版 ["456", "789"]
R 级 []
我的奖励 ["456"]

使用此配置时,引用这些类的所有传递对象都将具有以下收集器 ID:

  • R-Basic4444444477777777
  • R-Gold:不会包含收款方 ID
  • 我的奖励44444444

点按时收款方身份验证

作为发卡机构配置的一部分,发卡机构帐号可以有多个关联的公钥。这些公钥存储在 Google 钱包应用中,当用户在支持智能触碰的终端上点按其设备时,该应用会使用这些公钥进行身份验证。在应用找到发放给用户的卡券对象后,系统将执行此身份验证步骤,该对象的收款方 ID 与终端通告的值匹配。

继续上一部分中的示例,下表介绍了与每个颁发者关联的公钥。

商家名称 ILuvCoffee 咖啡美食 Mocha-R-U
发卡机构 ID 123 456 789
收款方 ID 11111111 44444444 77777777
会员级别 R-基本版 我的奖励
R 级
公钥 aaa bbb

示例客户在其 Google 钱包应用中保存了以下会员卡:

  • ILuvCoffeeR-Basic
  • Coffee-Foo我的奖励

与之前一样,您可以在每个会员卡类的 redemptionIssuers 属性中设置以下值。

  • R-基本版["456", "789"]
  • 我的奖励["456"]

如果用户在每个商家的终端上触碰设备,可能有三种结果:

商家终端 结果
ILuvCoffee 由于 ILuvCoffee(兑换发卡机构 ID 123)当前未配置为兑换自己的会员卡类 R-Basic,因此系统不会传输任何内容。
Coffee-Foo Google 钱包应用使用 bbb 公钥向 Coffee-Foo 终端进行身份验证。根据用户在其设备上查看的当前屏幕,可能会出现用户体验部分中列出的某种场景。
Mocha-R-U 在此示例中,Mocha-R-U 没有公钥。虽然可以通过商家兑换 R-Basic 程序,但它无法向终端进行身份验证,因此系统不会传输任何内容。

身份验证限制

将卡券同步到用户的 Google 钱包应用时,系统会从 Google 钱包后端查找该卡券的所有兑换发卡机构。每个兑换发卡机构的收款方 ID、公钥和密钥版本均存储在 Google 钱包应用本地。

一张卡券可以有多个兑换发卡机构 ID。然后,每个 ID 都映射到特定商家的特定收款方 ID。此外,单个收集器 ID 可能有多个公钥和密钥版本。

如果 Google 钱包应用没有任何可由某个终端兑换的卡券,则不会尝试向该终端进行身份验证。此编号基于收款方 ID 和公钥版本。如需更新卡券的公钥,终端必须连接到互联网,以便可以从 Google 钱包后端检索新的公钥。

一个卡券可同时与多个公钥关联。如需了解如何为同一卡券设置多个公钥,请参阅商家配置

在点按期间传输值

若要在点按期间发送卡券的数据,必须设置卡券对象的 smartTapRedemptionValue。一旦为与该对象对应的类启用了智能触碰,此值就会发送到终端。

根据您的集成和用例,此值将用于标识用户的卡券并执行任何所需的事务逻辑,例如:

  1. 更新用户的余额或状态
  2. 根据事务更新您自己的后端
  3. 使用 Google Wallet API 对卡券对象发布更新,以便在其设备上反映对用户状态所做的任何更改

终端和 Google 钱包应用会处理通过 NFC 传输的所有数据的加密。终端会在智能触碰发生后处理数据解密。在这些数据中,服务对象 NDEF 记录表示传输的每个卡券。服务对象的 Service number NDEF Record 有一个载荷,其中包含在传递对象的 smartTapRedemptionValue 属性中设置的值。这意味着卡券开发者不必处理传输数据的加密。

如果要增加一道安全防线,您可以设置 smartTapRedemptionValue 属性,以便只有接收所传输数据的系统(如销售终端)才能解密数据。不过,卡券开发者和 POS 管理员将负责加密/解密过程。