ユーザーがチェックアウトできるようにするには、ネイティブ チェックアウト統合を実装する必要があります。これには、Google がサーバーで決済フローをプログラムで管理できるようにする標準の REST API を作成することが含まれます。この方法では、ユーザーに最もシームレスなエクスペリエンスを提供できます。当初は、Google が購入者のユーザー インターフェースをレンダリングしますが、今後、よりエージェント的なエクスペリエンスをサポートする予定です。
購入手続きのフロー
ネイティブ統合では、Google が呼び出して購入手続きセッションを作成および管理できる RESTful API を構築する必要があります。
全体的なフローは次のとおりです。
- Build checkout session（購入手続きセッションを構築）: ユーザーとエージェント（任意）が、セッションにアイテムを追加するループに入ります。
- Google UI へのハンドオフ: ユーザーがエージェントの購入手続きを決定すると（エージェントが関与している場合）、制御が Google UI に渡されます（購入手続きセッション データが渡されます）。
- 手動の購入手続き: ユーザーは Google UI のみを使用して、配送と支払いに関する機密情報を入力し、注文を送信します。エージェントはこの部分に関与しないため、決定論が保証されます。
- 完了と返品: Google UI に [ありがとうございました] ページが表示され、注文が確定します。必要に応じて、ユーザーはエージェントにリダイレクトされます。エージェントには、購入完了の通知がすでに届いている可能性があります。
Checkout セッションのステータスのライフサイクル
ユーザーが購入手続きフローを進めるにつれて、購入手続きセッション status を更新して現在の状態を反映する必要があります。セッションは次のライフサイクルをたどります。
incomplete: セッションが作成されたときの初期ステータス。これは、必須情報（配送方法、税金、ユーザーの詳細など）がないか、計算されていないことを示します。ready_for_payment: ユーザーが配送先住所を更新し、配送オプションと合計を計算した後、支払い方法が確定する前に使用するステータス。ready_for_complete: 支払い方法が選択され、すべての注文の詳細が検証された後、完全な購入手続きオブジェクトのハイドレーション中に使用するステータス。completed: 支払いの処理と注文の完了後に返される最終ステータス。canceled: チェックアウト セッションが中止された場合に返されるステータス。error: 回復不能なビジネス ロジック エラーにより購入手続きができない場合に返されるステータス。このステータスは、UCP バージョン2026-04-08以降で使用できます。
複数アイテムの購入手続きフロー:
Google は、1 回の購入手続きセッションで複数の異なる広告申込情報をサポートするようになりました。一般的なフローは次のとおりです。
- ユーザーが UCP 対応のインターフェースから購入手続きを開始します（例: 商品の [今すぐ購入] をクリックする）。
line_items配列内のすべての個別のアイテムを含むPOST /checkout-sessions呼び出しが行われます。line_items配列には、チェックアウトされる個別のアイテムごとに個別のオブジェクトが含まれます。- ユーザーは、
PUT /checkout-sessions/{id}呼び出しを使用して、支払い方法や配送の詳細を更新したり、割引を適用したりできます。 - ユーザーが [Pay with GPay] ボタンをクリックすると、
POST /checkout-sessions/{id}/complete呼び出しが行われます。
認証
API キーや OAuth 2.0 などのサポートされている認証方法を含め、Native Checkout API エンドポイントの保護について詳しくは、認証とセキュリティ ガイドをご覧ください。
デベロッパー ツール
ネイティブ チェックアウト API の実装を支援するため、Universal Commerce Protocol の GitHub リポジトリで次のリソースをご利用いただけます。
- UCP GitHub リポジトリ: 包括的なドキュメント、仕様、コミュニティ リソースについては、メイン リポジトリをご覧ください。
- SDK: ソフトウェア開発キットを使用して、統合を加速します。言語固有の SDK が利用可能です。以下が含まれます。
準拠テスト: 準拠テストスイートを使用して、UCP 仕様に対して API エンドポイントを検証します。
これにより、実装が必須の標準と動作を満たしていることを確認できます。
これらのツールを使用して、開発とテストのプロセスを効率化することを強くおすすめします。
サービスレベル目標
次のサービスレベル目標（SLO）は、ネイティブ チェックアウト REST API エンドポイントに適用されます。Google と統合する企業は、API のパフォーマンスと可用性に関するこれらの目標を達成することが求められます。
| エンドポイント | 対象 | レイテンシ（50 パーセンタイル） | レイテンシ（95 パーセンタイル） |
|---|---|---|---|
POST /checkout-sessions（作成） |
>= 95% | 1 秒以下 | 4 秒以下 |
PUT /checkout-sessions/{id}（更新） |
>= 95% | 1 秒以下 | 5 秒以下 |
POST /checkout-sessions/{id}/complete（完了） |
>= 95% | 6 秒以下 | 10 秒以下 |
50 パーセンタイルのレイテンシは、リクエストの少なくとも 50% がこの時間内に完了すると予想されることを示します。95 パーセンタイルのレイテンシは、リクエストの 95% 以上がこの時間内に完了すると予想されることを示します。
次のステップ
UCP バージョンの購入手続き API ペイロードと技術的な実装の詳細を確認します。
サードパーティのサービス提供者として統合する場合は、UCP Checkout サービスのセットアップに進んで、販売者プロフィールをホストし、アカウント関係のハンドシェイクを構成します。