概要

未定: 電子ウォレットの簡単な説明を追加します(電子マネーの場合と同様)。

未定: お支払い方法を Google エンティティにオンボーディングした後、電子ウォレット フローのデモをご覧ください。

電子ウォレットの取引に関連する主な Google Standard Payments フローは次のとおりです。

関連付けの流れ

Google Standard Payments を使用すると、インテグレータは支払い方法作成フローと購入フローを作成し、高速かつシームレスな購入手続きをユーザーに提供できます。

Google のお客様は 1 つ以上の支払い方法を使用しています。支払い方法とは、Google のさまざまなエコシステムやマーケットプレイスでサービスや商品の支払いを行う方法です。支払い方法を追加するには、ユーザーは、支払い方法を外部認証情報にリンクし、その認証情報を認証する必要があります。クレジット カードがその良い例です。クレジット カードには、Google が保存するカード番号(PAN)と、認証に使用されるカード確認番号(CVN)があります。ユーザーは、Google UI で PAN と CVN を入力して、支払い方法を追加します。クレジット カード会社が PAN 番号と CVN 番号を確認した後、Google は PAN を安全に保管します。同様に、この仕様では、認証の証明を Google 側の手段にリンクします。このようなアカウントと支払い方法のリンクを、関連付けフローと呼びます。

関連付けフローの出力は、Google とインテグレータの双方が合意した Google Payment Token(GPT)の交換です。取得の際、GPT は決済インテグレータ(ユーザー アカウントを保持する)に渡され、請求対象のユーザー アカウントを識別します。

アカウントの所有権を証明するために、ユーザーを認証する方法はたくさんあります。ユーザー名とパスワードは 1 つの方法ですが、OTP、生体認証情報、セキュリティに関する質問もすべて有効な解決策です。Google は、決済インテグレータによるユーザーの確認方法を規定する意図はありません。Google では、決済インテグレータがこれを最善に処理していると考えています。そのため、この仕様の一環として、Google は決済インテグレータのさまざまなユーザー インターフェースを利用してユーザーを認証し、認証の証明のみを Google に提供したいと考えています。これを認証フローと呼びます。

認証フローの出力は認証の証明です。

関連付けフローでは、Google が決済インテグレータによる認証の証明を提示する必要があります。関連付けフローの前に、Google は証明書を取得するために認証フローを呼び出します。

下の例は、ユーザーが行う認証フローと関連付けフローを示したものです。以下の例では、InvisiCash という偽の電子ウォレットについて説明します。

関連付けフロー

この図に関する注記:

  • ステップ 1 と 3 では、ユーザーの ID(メールアドレス)が Google と InvisiCash で異なることに注意してください。sf@gmail.comsally@otheremail.com。これは想定内の問題ではありません。
  • ステップ 3 と 4 の間で、InvisiCash アプリ(ユーザーがアプリをインストールしていない場合はウェブ UI)は、InvisiCash サーバーとの会話など、ユーザー認証に必要なすべてのことを実行できます。

購入フロー

関連付けが終了して、ユーザーが新しいお支払い方法を手に入れると、その手段を使って Google を通じて商品やサービスを購入できます。購入時には、ユーザーがセッション中の場合とそうでない場合があります。いずれも購入のコンテキストによります。たとえば、定期購入ベースの購入の場合、ユーザーはセッション中ではないと考えられます。購入時に、Google は決済インテグレータに GPT を提示します。決済インテグレータはこの GPT を使用して、引き落とし先の正しい口座を識別します。これを購入フローといいます。

以下の例は、ユーザー sf@gmail.com が関連付けを行い、支払い方法が作成された後も継続します。ユーザーは商品の購入を希望している。

シンプルな購入フロー

場合によっては、決済インテグレータと Google が、購入前にユーザーの認証を求めることがあります。これにはさまざまな理由があります。次に例を示します。

  • Google のリスクエンジンが不審なお支払いと判断した
  • 規制要件により、購入ごとに OTP が必要

そのような場合、Google は認証フローを購入フローと組み合わせます。ユーザーは、認証のためにインテグレータの UI にリダイレクトされます。認証フローの結果は、ユーザー ID と認証の証明となります。この証明は、購入フローで購入情報と一緒に送信されます。

以下の例では、ユーザー sf@gmail.com が関連付けを行い、支払い方法を作成しています。Google のサーバーは、購入フローで不正行為から保護するようユーザーに求めます。

ユーザーがチャレンジした購入フロー

トークンの更新フロー

関連付けフローの際に、決済インテグレータは、この GPT が X か月後に期限切れになることを Google に通知できます。Google では有効期限のないトークンを優先しますが、常にそうなるとは限りません。したがって、トークンの有効期限をサポートします。トークンの有効期限が近づいた場合、Google は認証フローにユーザーを送信します。ユーザーは認証のためにインテグレータの UI に転送されます。認証フローの結果は、ユーザー ID と認証の証明となります。この証明はインテグレータに送信され、GPT の有効期限が延長されます。 これは refreshToken フローと呼ばれます。

以下の例は、ユーザー sf@gmail.com が関連付けを行い、支払い方法が作成された後も継続します。ユーザーのトークンがまもなく期限切れになるため、Google はユーザーに支払い方法を更新するよう求めます。

更新トークンのフロー

認証フローは 2 つの異なるモダリティで使用されます。1 つ目は、関連付けの際にユーザーを認証しようとする場合です。この時点ではユーザーの ID は不明であるため、入力はユーザーが行う必要があります。ID は、ユーザー名、メールアドレス、電話番号などです。2 つ目のモダリティは、ユーザーが既存の計測器の認証情報を知っていることを認証しようとします。この状況では、ユーザーはすでに支払い方法を追加し、決済インテグレータのアカウントと関連付けています。このモダリティでは、ユーザーが特定のユーザー ID の認証情報を持っていることを確認します。ユーザーは確認対象のアカウント ID を変更できません。これを行うために、関連付け時に決済インテグレータに関連付け ID が送信されます。認証時に、Google から同じ関連付け ID がインテグレータに送信されます。インテグレータは関連付け ID を使用して、認証が必要なアカウントを検索します。

送金フロー

Google は会計記録システムであり、送金送金の会計処理を行います。Google は毎日、支払いインテグレータに送金明細書を送信します。この明細書には、決済インテグレータが Google に支払うべき金額の概要と、Google への支払い方法が記載されています。決済インテグレータは調整するために、送金明細書を構成するトランザクション レベルの詳細を Google に照会できます。

フローの例: 送金
フロー