商家终端可通过多种方式请求特定卡券。
终端与 Google Pay 应用之间的通信
终端使用收款方 ID 标识自身。此 ID 对应于 Google 后端的兑换发卡机构 ID（卡券开发者通过 Google Pay API for Passes 与后端互动）。
发生智能触碰时，终端会将其收款方 ID 发送到 Google Pay 应用。Google Pay 应用会检查每个卡券的兑换发卡机构，取得收款方 ID，并在此 ID 匹配时将这些特定的卡券发送到终端。
要进行此设置，请参阅设置商家终端。
流程如下例所示：
设置 1：在上图中，Issuer_id: 2018 有一个类和一个对象。此发卡机构帐号供卡券开发者使用。Class_id: abc 类具有 redemptionIssuers['1990'] 对象。根据定义，Issuer_id: '1990' 是代表商家 fooPizza 的兑换发卡机构 ID。终端有一个收款方 ID 12345678。
此 ID 对应至配置为兑换发卡机构 1990 的收款方 ID。Class_id: abc 的任何对象都通过收款方 ID 12345678 传输给读取设备。
设置 1.1：在上面的示例中，fooPizza 和 yumPie 可以兑换相同的卡券 object_id: 123。一个类可以有多个兑换发卡机构。与发卡机构对应的兑换发卡机构帐号在其终端中具有各自的唯一收款方 ID。
设置 2：上图显示了该类如何将自己的发卡机构帐号设置为兑换发卡机构。Issuer_id: 2018 有一个类和一个对象。Class_id: abc 类具有名为 Issuer_id: 2018 的兑换发卡机构对象。根据定义，Issuer_id: 2018 是代表商家 fooPizza 的兑换发卡机构 ID。终端有一个收款方 ID 12345678。此 ID 对应至配置为 Issuer_id: 2018 的收款方 ID，这也是 Class_id: abc 所在的位置。Class_id: abc 的任何对象都通过收款方 ID 12345678 传输给终端。
用户从 Google Pay 应用中进行选择
传输到 Google Pay 应用的行为取决于用户在其设备上看到的内容。
如果用户在 Google Pay 中查看卡券，然后使用智能触碰，则只要其收款方 ID 与请求此 ID 的终端匹配，系统就会传输该卡券。无论此卡券是否有效（取决于在相应类或对象上设置的属性），系统都会执行此操作。
用户可能看不到卡券，例如当他们在 Google Pay 的“首页”标签中，或者当他们从设备的未锁定屏幕视图中查看卡券时。如果用户没有看到卡券，并且只有一个基于收款方 ID 的有效可兑换卡券，则系统会传输该卡券。
如果用户有多个有效且可根据收款方 ID 兑换的卡券，Google Pay 将执行以下任务之一：
- 显示选择轮播界面，供用户从中选择并通过触碰进行传输。
- 或者，如果只有一个有效卡券，则将传输该卡卷。
卡券的有效性取决于卡券类别。请务必检查与状态和使用日期相关的属性，例如 object.state 或 object.validTimeInterval。
智能触碰收款示例
考虑下面这个与假发卡机构及其会员卡有关的配置示例：
| iLuvCoffee | Eat-foo | Bacon-R-us | |
|---|---|---|---|
| 发卡机构 ID | 123 | 456 | 789 |
| 收款方 ID | 111 | 44444444 | 77777777 |
| 会员卡类 | R-basic | My Rewards | - 无 - |
| 会员卡类 | R-gold | - 无 - | - 无 - |
iLuvCoffee 有两个不同的会员卡类，用于创建 R-basic 和 R-gold 这两个卡券。同时，Eat-foo 有自己的 My Rewards 会员卡，而 Bacon-R-us 没有任何会员卡。
现在，假设您需要以下配置：
- R-basic 可向 Eat-foo 和 Bacon-R-us 兑换。
- My Rewards 可向 Eat-foo 兑换。
- R-gold 没有任何智能触碰支持。
对于此配置，使用这些兑换发卡机构 ID 设置了会员卡类：
- R-basic 兑换发卡机构 ID：456、789。
- My Rewards 兑换发卡机构 ID：456。
- R-gold 兑换发卡机构 ID：无。
使用此配置，这些类的实例配置了以下收款方 ID：
- R-basic 收款方 ID：44444444、77777777。
- My Rewards 收款方 ID：44444444。
- R-gold 收款方 ID：无。
在智能触碰时进行收款方身份认证
每个发卡机构帐号都可能具有与之关联的任意数量的公共安全密钥。这些公钥随后会同步并存储在 Google Pay 应用中，以供用户在声称是某个相关联的收款方 ID 的终端上触碰时使用。
继续我们的示例，假设我们的发卡机构也设置了以下密钥：
| iLuvCoffee | Eat-foo | Bacon-R-us | |
|---|---|---|---|
| 发卡机构 ID | 123 | 456 | 789 |
| 收款方 ID | 11111111 | 44444444 | 77777777 |
| 会员卡类 | R-basic | My Rewards | - 无 - |
| 公钥 | aaa | bbb | - 无 - |
用户的 Google Pay 帐号中有两个会员卡：iLuvCoffee 的 R-basic 会员卡和 Eat-foo 的 My Rewards 会员卡，用户会尝试触碰不同的终端。
为这两个会员卡类设置的兑换发卡机构如下：
- R-basic 兑换发卡机构 ID：456、789。
- My Rewards 兑换发卡机构 ID：456。
以下是三种可能的结果：
iLuvCoffee 终端：Google Pay 应用可以在理论上进行身份验证并确认终端确实属于 iLuvCoffee。但是，iLuvCoffee 未设置为自己的会员卡类 R-basic 兑换发卡机构。因此，在这种情况下，系统不会传输任何内容。
Eat-foo 终端：Google Pay 应用会对使用公钥“bbb”的 Eat-foo 终端进行身份验证。如果我们假设用户无法查看 R-basic 或 My Rewards 卡券的详细屏幕（例如当他们正在查看“首页”标签时），该应用会搜索其拥有的由 Eat-foo 兑换的卡券。它会找到 R-basic 卡和 My Rewards 卡，并显示轮播界面，以便用户可以选择并触碰要传输的卡。
或者，如果用户查看 R-basic 和智能触碰，则系统仅会传输 R-basic。
Bacon-R-us 终端：在此平台中，Bacon-R-us 没有任何公钥，因此即使 R-basic 卡已列为可兑换的发卡机构，它也无法对终端进行身份验证，并且系统不会传输任何内容。
身份验证限制
当卡券同步到 Google Pay 应用时，可从 Google 后端查询该卡券的所有兑换发卡机构。对于该卡券，与每个兑换发卡机构对应的收款方 ID、公钥和密钥版本会存储在 Google Pay 应用本地。
一个收款方 ID 可以有多个公钥和密钥版本。一个卡券可以有多个兑换发卡机构 ID，这些兑换发卡机构 ID 与收款方 ID 一一对应。
如果 Google Pay 应用没有任何可由某个终端兑换的卡券，Google Pay 应用便不会对该终端进行身份验证。卡券由收款方 ID 和请求的密钥版本进行标识。 要更新卡券的公钥，设备必须连接到互联网，以便它可以从 Google 后端检索新的公钥。
一个卡券可以同时与很多公钥相关联。请参阅为商家启用智能触碰，了解如何为同一卡券设置多个公钥。
通过卡券传输的值
每个类别的对象都需要设置此字符串属性：object.smartTapRedemptionValue。
一旦为与该对象对应的类启用了智能触碰，系统就会将该值发送到终端。
根据您与销售终端 (POS) 的集成，您可以使用此值来识别用户的卡券，并在他们成功触碰了商家终端后执行以下操作：
- 在 POS 上更新用户的余额或状态。
- 根据在 POS 上的交易更新您自己的后端。
- 发布对象的更新，以使其反映在 Google Pay 卡券上。
终端和 Google Pay 应用会处理通过 NFC 传输的所有数据的加密。发生智能触碰后，终端会处理数据的解密。在这些数据中，服务对象 NDEF 记录代表传输的每个卡券。服务对象的 Service number NDEF Record 具有一个有效负载，其中包含在卡券的 object.smartTapRedemptionValue 中设置的值。这意味着卡券开发者不必加密任何内容。如果卡券开发者需要额外加密以增加一道安全防线，请设置此值以便只有 POS 系统才能对其进行解密。由卡券开发者和 POS 联系人决定如何处理该加密过程。