概要
アカウントを関連付けると、新しく作成したお支払い方法を購入に使用できるようになります。Google 内での購入は、次の 1 つまたは 2 つのモードで行われます。
- ユーザー起動型。
- システム開始
一般的に、選択したモードに関係なく、インテグレータ UI は購入に関与しません。
フローの仕組み
以下の図は、ユーザーが開始する購入を示しています。
購入フロー - ユーザーに提示
この図のオブジェクトには次のものが含まれます。
- ユーザー: Google での購入を希望しているユーザーです。
- Google UI: ユーザーが購入を開始するインターフェース。
- Google サーバー: キャプチャ コマンドを決済インテグレーター サーバーに送信する Google のバックエンド サーバー。
- 決済インテグレータ サーバー: 資金回収のリクエストを受け入れるインテグレータのバックエンド サーバー。
この購入フローでは、ユーザーがセッションを行います。ユーザーは商品の購入からフローを開始します。
- ユーザーが Google UI でアイテムの購入を開始します。
- 購入情報は Google サーバーに送信されます。
- Google のサーバーが、
Capture
リクエスト(GPT
、amount
)を決済インテグレーター サーバーに送信します。 - 決済インテグレータ サーバーは、成功レスポンスを Google サーバーに送り返します。
- Google サーバーが Google UI に成功レスポンスを返します。
- アイテムがお客様に配送されます。
システムによって開始されるフローを以下に示します。この場合は、Google のシステムがお客様に代わって支払いを開始します。これは、月単位の定期購入など、さまざまな理由で発生する可能性があります。
この場合、ユーザーはセッション中ではありません。
購入フロー - ユーザーがいない
図中のオブジェクトは次のとおりです。
- Google サーバー: 購入を開始する Google のバックエンド サーバー。
- 決済インテグレータ サーバー: 資金回収のリクエストを受け入れるインテグレータのバックエンド サーバー。
この購入フローではユーザーは存在しません。Google サーバーが購入を開始します。
- Google サーバーが、セッション中ではないユーザーの購入フローをトリガーします。
- Google サーバーが、購入の
GPT
とamount
を含むCapture
コマンドを送信します。 - 決済インテグレータ サーバーは、成功のメッセージを返します。
ベスト プラクティスとその他の考慮事項
さまざまな理由により、インテグレーターや Google が購入前にユーザーに再認証フローをご案内することがあります。次のような理由が考えられます。
- Google のリスクエンジンが、不審なお支払いと判断します。
- 規制要件により、購入のたびに OTP が必要となります。
そのような場合、Google はユーザーの再認証を行い、ユーザーが購入フローを完了できるようにします。再認証フローの結果が、ユーザー ID と認証の証明となります。購入フロー中に、再認証結果が購入情報とともに決済インテグレータに送信されます。