Google Standard Payments:

トークン化された FOP

概要

トークン化された FOP（お支払い方法）は、支払いプラットフォームへの支払い統合の一種です。ユーザーがこの FOP で支払いを行うには、Google と決済インテグレータが、アカウント ID の認証情報を 1 回だけ交換する必要があります。そして、この特定のユーザーの支払い方法を表すトークンを確立します。このトークンは、支払いに繰り返し使用できます。現在、これらの API には 2 つのバージョンがあります。バージョン 2 では、携帯通信会社と照会番号プロバイダがサポートされています。他のすべてのトークン化された FOP プロバイダは、バージョン 1 を実装する必要があります。このドキュメントの残りの部分では、バージョン 1 を中心に説明します。

Google は、次の 2 つのフローを使用して ID を確立し、このトークンを作成します。

  1. 認証フロー: ユーザーを識別して検証（認証）します。
  2. 関連付けフロー: ユーザーのトークン（新規または以前に識別および認証されたユーザー）を確立します。このトークンは、特定のユーザーによる特定の支払い方法を表します。トークンは今後の購入で使用できます。

トークンが確立されると、Google は購入フローでそのトークンを使用して、ユーザーが迅速かつシームレスな購入手続きを行えるようにします。Google はこのトークンを使用して、お客様による支払い方法のインスタンスを表します。これは楽器とも呼ばれます。Google のお客様は、商品やサービスの支払いに複数の支払い方法を持つことができます。

最後に、インテグレーターの銀行と Google の銀行間のすべての送金は送金フローで行われます。

<ph type="x-smartling-placeholder">
</ph> サービスを選択
1） ユーザーが購入する商品を選択します
 <ph type="x-smartling-placeholder">
</ph> お支払い方法を選択してください
2） 次に、お支払い方法を選択します。
 <ph type="x-smartling-placeholder">
</ph> お支払い方法を追加する
3） 新しいお支払い方法を追加しました
<ph type="x-smartling-placeholder">
</ph> リダイレクト
4） 認証のためにリダイレクトされる
 <ph type="x-smartling-placeholder">
</ph> 認証済み
5） 最後に、ユーザーは認証され、購入できるようになります

次の図は、フローの概要を示しています。

トークン化された FOP の概要

トークン化された FOP の概要図

サービスをお支払い方法として Google サービスに追加する大まかな流れは次のとおりです。

  1. 認証フロー
  2. 関連付けフロー
  3. 購入フロー
  4. 払い戻しフロー
  5. 送金フロー

これらのフローについては以下のセクションで詳しく説明し、さらにガイドのセクションで詳しく説明します。

概念と用語

記号と規則

“しなければならない”というキーワードは禁止事項:「必須」「SHALL」"できません"「すべきです」「すべきでなければ」「推奨」「も構いません」および「省略可」RFC 2119 に記載されているとおりに解釈されます。

タイムスタンプ

すべてのタイムスタンプは、UTC の Unix エポック（1970 年 1 月 1 日）からのミリ秒数で表されます。

例:

  • 2019 年 4 月 23 日午後 8:23:25 GMT = 1556051005000 ミリ秒
  • 2018 年 8 月 16 日午後 12:28:35 GMT = 1534422515000 ミリ秒

金額

この API の金銭的価値は「micros」という形式です。Google の標準となっています。micros は整数ベースの固定精度形式です。金額をマイクロ秒単位で表すには、標準の通貨値に 1,000,000 を掛けます。

例:

  • 1.23 米ドル = 1230,000 マイクロ米ドル
  • 0.01 米ドル = 10,000 マイクロ米ドル

べき等性

この API 内のすべてのメソッド呼び出しは、べき等の動作を持つ必要があります。Google は、トランザクションが両側で同じ状態になるように、リクエストを何度も再試行します。インテグレータは、すでに正常に処理されたリクエストを再処理しようとしないでください。代わりに、成功した処理のレスポンスを返す必要があります。すべてのメソッドには、requestId を含む共通の RequestHeader があります。この requestId は、すべての呼び出しのべき等性のキーです。

非ターミナル レスポンス（HTTP 200 成功以外）は、べき等に処理してはいけません。したがって、以前に 400（不正なリクエスト/失敗した前提条件）を取得したリクエストは、2 回目の呼び出されたときにべき等に 400 を返さないようにする必要があります。再評価する必要があります。再評価時に 400 が返されるか、正常に処理される可能性があります。

べき等性の詳細については、こちらの詳細ガイドをご覧ください。

インテグレータ

Google の支払いプラットフォームをビジネスで使用している会社。YouTube や AdWords などの社内（1P）企業の場合もあれば、Google のエコシステムと連携させるために自社のサービスを統合したいと考えている社外（3P）企業もあります。

FOP

お支払い方法。これは、楽器というよりも一般的なものです。Visa、MasterCard、PayPal はすべて FOP です。

楽器

特定の顧客による支払い方法の特定のインスタンス。（ユーザーのクレジット カード、PayPal アカウントなど）。特定の顧客のトークン化された FOP も支払い方法の一つになります。これは、その顧客のお支払い方法のインスタンスであり、Google のシステムに安全に保存されているからです。

トークン

Google のシステムにおける特定のユーザーの支払い方法の表現。トークンには購入に必要なすべての情報が含まれているため、トークンでもあります。これには、ユーザーがインテグレータから入手した口座番号などの情報が含まれることがあります。

主なフロー

認証フロー

認証は、最初に実行する必要があるフローです。認証フローの目的は、インテグレータに対してユーザーを識別して認証することです。認証はさまざまな方法で行われます。トークン化された FOP では、次の 2 つの方法でユーザーを識別して認証できます。

  1. SMS-MT OTP 認証（SMS モバイル終端、ワンタイム パスワード）
  2. リダイレクト認証

オンボーディング時に、インテグレータは Google と連携して、自社のプロダクトに最適な認証メカニズムを選択します。

認証フローは、2 つのコンテキストで使用できます。1 つ目は、新しい顧客を識別して関連付けるため、2 つ目は、既存の機器の認証情報をユーザーに確認することです。認証フローの結果は、関連付けフロー、更新トークン フロー、チャレンジ 購入フローなど、複数のフローへの入力として使用できます。また、認証フローは、後続のフローに関連付けられていないスタンドアロン モードで使用できます。

SMS-MT OTP 認証

この認証メカニズムでは、ユーザーが Google UI で電話番号を入力します。Google はこの電話番号をインテグレータに送信します（sendOtp メソッドを使用）。インテグレータはユーザーにワンタイム パスワードを送信します。ユーザーが Google UI に入力したパスワードはインテグレータに送信されます。これにより、決済インテグレータから成功レスポンスがトリガーされます。

SMS-MT OTP 認証がスタンドアロン モードで使用される場合、OTP の値は verifyOtp メソッドを使用してインテグレータに送信されます。このメソッドは、提供された OTP が送信されたものであることを確認します。

リダイレクト認証

リダイレクト認証は、Google がインテグレータ所有のアプリケーションにユーザーをリダイレクトすることで行われます。対象となるアプリケーションは、ウェブ アプリケーションでも Android アプリケーションでもかまいません。

Android のリダイレクトとウェブのリダイレクトは同様に動作します。Google がユーザーをインテグレータのアプリにリダイレクトします。インテグレータは、インテグレータにとって最も自然な形式で、ユーザーを識別して認証します。認証されると、インテグレータはユーザーを Google の UI にリダイレクトして関連付けを完了します。リダイレクト時に、Google はこの認証セッションを識別するために requestId を提供します。この ID は、関連付けの際に認証の ID 証明として使用されます。

このフローを選択するインテグレータは、ウェブ認証 URL を指定する必要があります。これは、すべてのサーフェス（パソコンまたはモバイル）で最も一般的なものであるためです。ただし、モバイルで最適なユーザー エクスペリエンスを実現するには、Android 認証を強くおすすめします。

デバイスのコンテキストとインストールされているアプリに応じて、Google UI はウェブまたは Android アプリのリダイレクトを選択します。

この認証メカニズムにより、インテグレータは最も自由度が高くなります。ユーザーの認証と識別にはさまざまな方法があります。ユーザー名とパスワードの入力、あるいは生体認証情報やセキュリティ保護用の質問は、どちらも有効な解決策です。Google は、インテグレータがユーザーの本人確認を行う方法を規定するものではありません。インテグレータがユーザーの認証を行います。このように、Google はインテグレータのさまざまなユーザー インターフェースを利用してユーザーを認証し、認証の証明を提供するだけです。

認証の詳細については、こちらの詳細ガイドをご覧ください。

関連付けのフロー

上記のメカニズムのいずれかを介した認証フローの後、ユーザーは関連付けフローを進めます。関連付けフローの目的は、お支払い方法を作成するための Google 支払いトークン（GPT）を確立することです。このフローは次の処理を行います。

  1. このユーザーを表すトークンと呼ばれる ID をネゴシエーションします。
  2. Google のリスクエンジンに通知するためのアカウント情報を提供します。
  3. GPT の作成と確立に必要な初回設定情報を収集します。

その結果、確立された GPT が Google とインテグレータの両方によって合意されます。

2 人の Google ユーザーが同じユーザーのアカウントをインテグレータと共有できます。この場合、ユーザーごとに異なる支払い方法が必要になります。各支払い方法には独立した関連付けフローがあるため、一意の GPT があります。

この図では、InvisiCash と呼ばれる偽のトークン化された FOP について説明します。ここでは、ユーザーが認証フローと関連付けフローを実行する手順を示しています。

関連付けフローの概要

トークン化された FOP - Invisicash

  1. 「sf@gmail.com」というメールアドレスを持つ Google ユーザーが、InvisiCash アカウントを Google Play ストアに追加して購入に使用できることを望んでいます。
  2. Google Play ストアで、認証のために InvisiCash アプリが開きます。

  3. このユーザーは、sally@otheremail.com というメールアドレスを使用して、InvisiCash アカウントにログインします。Gmail のメールアドレスが InvisiCash アカウントへのログイン用である場合、彼女は両方に Gmail のメールアドレスを使用している可能性があります。

  4. InvisiCash アプリは Google Play ストアに認証 ID を返送します。

  5. Google Play ストアから認証 ID が Google サーバーに送信されます。

  6. Google のサーバーは、アカウントを関連付けるためのメッセージを InvisiCash サーバーに送信します。この関連付けには、認証 ID、GPT（Google 支払いトークン）、関連付け ID が含まれます。

  7. InvisiCash サーバーは、Google 支払いトークン（GPT）と関連付け ID を保存します。これで両方がサリーの InvisiCash アカウントに関連付けられます。

  8. InvisiCash はこの関連付けを承認します。次に、Google のサーバーが、今後の購入に使用できる支払い方法を作成します。