販売店の端末が特定のパスをリクエストする方法はいくつかあります。
端末と Google Pay アプリの間の通信
端末はコレクタ ID で識別されます。これは、パスのデベロッパーが Google Pay API for Passes 経由でアクセスする Google バックエンドでクーポン発行者 ID にマッピングされます。
スマートタップを利用する際に、端末がコレクタ ID を Google Pay アプリに送信します。Google Pay アプリはパスのクーポン発行者を調べ、コレクタ ID を取得します。ID が一致すると、そのパスを端末に送信します。
この設定を行う方法については、販売店の端末を設定するをご覧ください。
以下に、このプロセスの例を示します。
設定 1: 上の図で、Issuer_id: 2018 には 1 つのクラスと 1 つのオブジェクトがあります。この発行者アカウントは、パスのデベロッパーによって使用されます。Class_id: abc クラスには redemptionIssuers['1990'] オブジェクトがあります。Issuer_id: '1990' は、販売店 fooPizza を表すクーポン発行者 ID です。端末のコレクタ ID は 12345678 です。
これは、クーポン発行者 1990 に構成されているコレクタ ID にマッピングされます。Class_id: abc のオブジェクトは、コレクタ ID 12345678 でリーダーに送信されます。
設定 1.1: 上の例で、fooPizza と yumPie は同じパス object_id: 123 を利用できます。クラスには、複数のクーポン発行者を定義できます。端末では、発行者に対応するクーポン発行者アカウントそれぞれのコレクタ ID が表示されます。
設定 2: 上の図では、クラスの発行者アカウント自身をクーポン発行者に設定しています。Issuer_id: 2018 には 1 つのクラスと 1 つのオブジェクトがあります。Class_id: abc クラスには、Issuer_id: 2018 というクーポン発行者オブジェクトがあります。Issuer_id: 2018 は、販売店 fooPizza を表すクーポン発行者 ID です。端末のコレクタ ID は 12345678 です。これは、Issuer_id: 2018 に構成されているコレクタ ID にマッピングされます。ここには Class_id: abc も含まれています。Class_id: abc のオブジェクトは、コレクタ ID 12345678 で端末に送信されます。
Google Pay アプリでのユーザーの選択
ユーザーがデバイスに表示する内容によって Google Pay アプリに送信される情報が異なります。
ユーザーが Google Pay でパスを表示してからスマートタップを行った場合、リクエストを送信した端末とコレクタ ID が一致するとパスが送信されます。この処理は、有効性に関係なく、クラスまたはオブジェクトに設定されたプロパティに基づいて行われます。
ユーザーが Google Pay のホームタブを表示している場合や、デバイスでロックされていない画面から表示している場合など、ユーザーにパスが表示されないことがあります。ユーザーにパスが表示されない場合でも、コレクタ ID で検証した結果、利用可能なパスが 1 つしかなければ、パスが送信されます。
コレクタ ID で検証した結果、利用可能なパスが複数存在する場合、Google Pay は次のいずれかの処理を行います。
- ユーザーが選択してタップする選択カルーセルを表示します。
- 有効なパスが 1 つしかない場合は、そのパスを送信します。
パスの有効性は、パスのカテゴリによって異なります。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 には、パスの作成に使用される 2 つのポイントクラス（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 ポイントカードを管理し、複数の端末で利用したとします。
この 2 つのポイントカード クラスには、次のクーポン発行者が設定されています。
- R-basic のクーポン発行者 ID: 456、789
- My Rewards のクーポン発行者 ID: 456
次の 3 つの結果が考えられます。
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 アプリのローカルに保存されます。
1 つのコレクタ ID に多くの公開鍵と鍵バージョンがある場合があります。パスは複数のクーポン発行者 ID を持つことができ、クーポン発行者 ID はコレクタ ID と 1 対 1 のマッピングを持ちます。
端末で利用できるパスがない場合、Google Pay アプリはその端末を認証しません。これは、コレクタ ID とリクエストされた鍵バージョンによって識別されます。 パスの公開鍵を更新するには、Google バックエンドから新しい公開鍵を取得できるように、デバイスがインターネットに接続している必要があります。
1 つのパスに複数の公開鍵を関連付けることもできます。同じパスに複数の公開鍵を設定する方法については、販売店でスマートタップを有効にするをご覧ください。
パスから送信される値
文字列プロパティ object.smartTapRedemptionValue は、オブジェクトのカテゴリを問わず、設定する必要があります。
オブジェクトに対応するクラスでスマートタップが有効になると、この値が端末に送信されます。
POS との統合により、この値はユーザーのパスの特定に使用されます。ユーザーが販売店の端末でタップに成功すると、次の処理を行います。
- POS でユーザーの残高またはステータスを更新します。
- POS での取引に基づいて、独自のバックエンドを更新します。
- オブジェクトを更新して、Google Pay Pass に反映させます。
端末と Google Pay アプリは、NFC 経由で送信されるデータの暗号化を処理します。スマートタップの発生後、端末でデータが復号されます。データには、送信されたパスを表す Service Object NDEF レコードが含まれます。サービス オブジェクトの Service number NDEF Record のペイロードには、パスの object.smartTapRedemptionValue に設定されている値が含まれています。つまり、パスのデベロッパーが暗号化を行う必要はありません。パスのデベロッパーがセキュリティ強化のために別の暗号化を追加する場合は、POS システムだけが復号できる値を設定します。この暗号化プロセスを行うかどうかは、デベロッパーと POS の担当者が判断します。