購入フロー

概要

アカウントを関連付けると、新しく作成したお支払い方法を購入に使用できるようになります。Google 内での購入は、次の 1 つまたは 2 つのモードで行われます。

• ユーザー起動型。
• システム開始

一般的に、選択したモードに関係なく、インテグレータ UI は購入に関与しません。

フローの仕組み

以下の図は、ユーザーが開始する購入を示しています。

購入フロー - ユーザーに提示

この図のオブジェクトには次のものが含まれます。

• ユーザー: Google での購入を希望しているユーザーです。
• Google UI: ユーザーが購入を開始するインターフェース。
• Google サーバー: キャプチャ コマンドを決済インテグレーター サーバーに送信する Google のバックエンド サーバー。
• 決済インテグレータ サーバー: 資金回収のリクエストを受け入れるインテグレータのバックエンド サーバー。

この購入フローでは、ユーザーがセッションを行います。ユーザーは商品の購入からフローを開始します。

1. ユーザーが Google UI でアイテムの購入を開始します。
2. 購入情報は Google サーバーに送信されます。
3. Google のサーバーが、Capture リクエスト（GPT、amount）を決済インテグレーター サーバーに送信します。
4. 決済インテグレータ サーバーは、成功レスポンスを Google サーバーに送り返します。
5. Google サーバーが Google UI に成功レスポンスを返します。
6. アイテムがお客様に配送されます。

システムによって開始されるフローを以下に示します。この場合は、Google のシステムがお客様に代わって支払いを開始します。これは、月単位の定期購入など、さまざまな理由で発生する可能性があります。

この場合、ユーザーはセッション中ではありません。

購入フロー - ユーザーがいない

図中のオブジェクトは次のとおりです。

• Google サーバー: 購入を開始する Google のバックエンド サーバー。
• 決済インテグレータ サーバー: 資金回収のリクエストを受け入れるインテグレータのバックエンド サーバー。

この購入フローではユーザーは存在しません。Google サーバーが購入を開始します。

1. Google サーバーが、セッション中ではないユーザーの購入フローをトリガーします。
2. Google サーバーが、購入の GPT と amount を含む Capture コマンドを送信します。
3. 決済インテグレータ サーバーは、成功のメッセージを返します。

ベスト プラクティスとその他の考慮事項

さまざまな理由により、インテグレーターや Google が購入前にユーザーに再認証フローをご案内することがあります。次のような理由が考えられます。

1. Google のリスクエンジンが、不審なお支払いと判断します。
2. 規制要件により、購入のたびに OTP が必要となります。

そのような場合、Google はユーザーの再認証を行い、ユーザーが購入フローを完了できるようにします。再認証フローの結果が、ユーザー ID と認証の証明となります。購入フロー中に、再認証結果が購入情報とともに決済インテグレータに送信されます。