Google Pay のサポートを追加する作業は標準のプロセスと変わらないように見えますが、Google Pay 統合プロジェクトを成功させるには、多くのことを判断しなければなりません。技術的な選択を安易に行うと、ユーザーに負担をかける可能性があります。統合を計画する場合は、ユーザー エクスペリエンスを常に意識することが重要です。ユーザーのウォレットにカードを追加して管理する方法を改善することで、トークン化の成功率を上げ、顧客エンゲージメントを深めることができます。また、カスタマー サービスへの問い合わせを大幅に減らし、Google Pay を通じてブランドを強化できます。
Google Pay API との統合
Google Pay には API が用意されているため、顧客と Google ウォレットのやり取りをより厳密に管理できます。Push Provisioning API を使用すると、Google ウォレットの機能を独自のバンキング アプリやウェブサイトに追加できます。世界中の多くのカード発行会社が、運用の複雑さを解消し、独自の HCE ウォレットで発生するコストを削減するために、Push Provisioning API との統合を選択しています。
Push Provisioning API のベスト プラクティス
Push Provisioning API との統合を最適に行うためには、次のベスト プラクティスを取り入れることをおすすめします。
承認なしの認証: 承認なしの認証によるプッシュ プロビジョニングのトークン化が可能な場合は、この操作を行います。
即時発行: 実際にカードが届くのを待っている間に Google ウォレットにカードを追加するようユーザーに促します。
プッシュ プロビジョニング機能の視認性強化: アプリ内でバナーを公開してプッシュ プロビジョニングを促進し、プロビジョニング ボタンにアクセスできるようにします。
詳しくは、プッシュ プロビジョニングのベスト プラクティスをご覧ください。
ID&V のベスト プラクティス
Google では、さまざまな ID&V の方法をサポートしています。ID&V プロセスを入念に計画し、効率的に実施することで、Google Pay でのトークンのアクティベーション率は 90% 以上 になります。ID&V の方法の一覧（アクティベーション率が高い順）をご覧ください。ID&V はデバイスの不正操作防止を目的としたものですが、実際には、多くの正規ユーザーがこの段階で失敗しています。ID&V に失敗した正規ユーザーは、Google Pay で自分のカードを使用できないため、Google Pay で別の発行元のカードを使用するか、Google Pay ではなく実際のカードを使用しなければなりません。さまざまな ID&V オプションをサポートするために多少の追加投資を事前に行うことで、採用率を大幅に向上させ、セキュリティを強化し、サポートへの問い合わせを減らすことができます。
1. リスクシグナルを最大限に活用する
Google では、各 TSP を通じて、アカウントとデバイスのリスクスコアなど、さまざまなリスクシグナルと推奨事項を提供しています。特定のシグナルは、TSP と TSP が提供するデータによって異なります。これらのシグナルにより、顧客と追加のやり取りを行うことなく、不正行為のリスクを大幅に低減できます。このデータとカード発行会社のリスクエンジンを活用して、カード発行会は、ユーザーに提供すべき適切な ID&V アプローチをプロビジョニング リクエストごとに判断できます。例:
ほとんどのカード発行会社は、許容できないリスクという評価のために不承認にする権利を有していますが、通常は試行のごく一部でしか生じません。
ほとんどのカード発行会社は、手動プロビジョニングを要認証にします。ただし、信頼できるデバイスである場合を除きます。たとえば、古いスマートフォンにデバイス トークンがある場合に新しいスマートフォンをセットアップする場合です。
リスク評価の改善に役立つフィールドの詳細については、TSP にお問い合わせください。
2. リスクレベルに応じて ID&V オプションを選択する
カード発行会社は、アカウントとデバイスのリスクスコアに基づいて、適切な ID&V の方法をユーザーに指定できます。たとえば、リスクの高い試行には、安全性が非常に高いと思われる方法を指定できます。一方、リスクの低い試行には、すべての ID&V 方法を提供しても問題ないでしょう。
3. SMS OTP に RCS を使用する
カード発行会社は Rich Communication Services（RCS）を使用して OTP を確実に送信することができます。RCS チャットでは、質が高く、情報量の多いメッセージをより安全に提供できます（例: 送信者とユーザーの間で送信されるメッセージの暗号化、送信者 ID と認証バッジをアプリのヘッダーに表示など）。また RCS は、Wi-Fi とモバイルデータの両方で利用できます。
4. SMS OTP を使用してユーザーをバンキング アプリにリダイレクトする
アプリ間の検証を利用すればスムーズに処理できますが、カード発行会社は別の方法として、ユーザーがバンキング アプリにログインできるリンクを SMS OTP に含めることもできます。ログインしたユーザーは、バンキング アプリで登録を完了できます。また、実際の OTP（通知やメッセージ）も表示されます。この OTP を使用して、Google ウォレットのプロビジョニングを完了します。
5. SMS OTP およびメール OTP のための一般的なメッセージのベスト プラクティス
- SMS OTP を使用する場合は、RCS を採用して情報量の多いメッセージを提供できます。
- Google ウォレットへのカードの追加を試行している旨を明記し、
- 記述されている番号は誰にも教えないようにユーザーに徹底してください。
- カードが Google ウォレットに追加されたら、SMS、メール、またはアプリの通知で、追加の確認メッセージをユーザーに送信します。迅速な報告とエスカレーションの方法に関する詳細も記載します（ユーザーが自分でカードのプロビジョニングを行わなかった場合などの対応）。
6. カード発行会社が SCA コンプライアンスを実現できる、代替の ID&V 方法
SCA コンプライアンスを実現するための選択肢として、アプリ間の検証や TSP がホストするウェブベースの安全な認証（以下の図を参照）もあります。
FPAN が変更されたときにトークンを更新する
FPAN が変更されたときに、そのカードのデバイス トークンを更新して、新しい FPAN にリンクできます。トークンを更新すると、Google Pay UI に表示される FPAN の末尾 4 桁が更新されます。この更新では、カードアートなどのその他のメタデータ属性も更新できます。この機能は、顧客にとって大きなメリットがあるにもかかわらず、見過ごされています。
たとえば、顧客のカードが期限切れになり、カードが再発行されたときに、古いカードで作成されたトークンを更新して、新しい FPAN にリンクできます。これにより、ユーザーがカードを再度トークン化し、要認証 ID&V プロセスで検証を行う必要がなくなります。
同様に、アカウントで不正行為が検出されても、通常はデバイスのトークンに影響はありません。不正行為による影響は、物理的なカードまたは 1 トークンに限定される場合がほとんどです。物理的なカードに対して不正行為が行われた場合は、古いアカウントを取り消して、新しいアカウントに置き換えます。また、トークンを新しい FPAN に更新して、顧客がメールで交換カードを待っている間もトークンを使用できるようにすることで、優れたカスタマー エクスペリエンスを提供できます。
トークンの更新を実装する方法ついては、TSP にお問い合わせください。