ユーザーがチェックアウトできるようにするには、ネイティブ チェックアウト統合を実装する必要があります。これには、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}呼び出しを使用して、お支払い方法、配送の詳細を更新したり、割引を適用したりできます。 - ユーザーが [GPay で支払う] ボタンをクリックすると、
POST /checkout-sessions/{id}/complete呼び出しが行われます。
認証
API キーや OAuth 2.0 などのサポートされている認証方法を含め、Native Checkout API エンドポイントを保護する方法について詳しくは、認証とセキュリティ ガイドをご覧ください。
デベロッパー ツール
Native Checkout 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 ペイロードと技術的な実装の詳細を表示します。