レッスン
開始
勉強を始める
CodeGym /コース /ChatGPT Apps /1 つのプロジェクトでの Product Feed、Merchant、ACP の統合

1 つのプロジェクトでの Product Feed、Merchant、ACP の統合

ChatGPT Apps
レベル 14 , レッスン 4
使用可能

1. それぞれ単体ではすでに動いている…

この時点で、ChatGPT を中心にコマースのフローがどう回るかをすでにイメージできているはずです。マーチャントには商品フィードがあり、/checkout_sessions などの ACP エンドポイントが実装され、Instant Checkout が決済を実行し、バックエンドは webhook を受け取って注文を作成します。これらはあなたの ChatGPT App がなくても動きます。必要なのは Product Feed と ACP バックエンドだけです。

個別には次のことができるはずです:

  • OpenAI の仕様に沿って Product Feed を組み立てる;
  • Agentic Checkout / Delegated Payment を設計・実装する;
  • ギフト検索のためのウィジェットと MCP ツールを備えた ChatGPT App を書く。

個別に見ると完璧でも、まとめると簡単に「サービスが乱立した状態」になります。ウィジェットはウィジェットの都合、MCP サーバーは MCP の都合、ACP バックエンドは別の都合、注文と webhook のロジックはさらに別の都合で動きます。実際の購入をデバッグしたり奇妙なバグを直したりしようとした途端、誰も全体像を見えていないことに気づきます。

この講義の目的は、その状態から抜け出し、実装可能で一貫したアーキテクチャを提示することです。Product Feed が ACP バックエンドとどう結び付くのか、両者が ChatGPT App とウィジェットとどう関係するのか、決済プロバイダがどこに登場するのか、そしてそれらをチームが理解しやすいコンポーネント（サービス、DB、API）にどう落とし込むのかを説明します。

あわせて強調します。何がSPEC という厳密な標準で、何が GiftGenius のための私たちのアーキテクチャ上の選択にすぎないのかを。

Insight: ChatGPT は「無料の Google」

ChatGPT は Google とほぼ同じようにユーザーと向き合います。ChatGPT は別のところ、すなわちユーザー自身から収益を得るため、あなたに関連するトラフィックを無料で連れてきてくれるのです。

ビジネスの観点ではこれはシンプルな意味を持ちます。ChatGPT はあなたの商品の「無料の広告チャネル」になるのです。もちろん、Product Feed と ACP バックエンドを接続していることが前提です。モデルは、ユーザーのリクエストにうまく合致するならあなたの商品を提案し、あなたは表示やクリックに個別の支払いをする必要がありません。

ここから 2 つの実践的な示唆が得られます:

  1. チャンスの窓は「今だけ」非常に安い。 現在、ACP エコシステムの競争は激しくありません。従来の広告予算なしで、高価格帯に到達できる可能性があります。高額商品の高コンバージョンなトラフィック（航空、住宅、プレミアム品、保険など）が実質的に無料になり得る、稀有な局面です。
  2. 最も粗利の高いバーティカルから始めるのが合理的。 高い客単価のカテゴリにアクセスできるなら、まずそこから接続するのが賢明です:
    • 飛行機、ヨット、別荘の販売 / 賃貸;
    • 住宅およびプレミアム不動産の販売 / 賃貸;
    • ジュエリー、高級時計、保険商品・サービス。

これは「すぐに億万長者」という保証ではありませんが、非対称性を生みます。高価格帯で高品質の Product Feed と信頼できる ACP バックエンドを最初に投入した人は、チャネルが過小評価され事実上無料であるあいだに、不釣り合いに大きなリターンを得られます。

2. GiftGenius のリファレンスアーキテクチャ: 大づかみの構図

まずは俯瞰から始めましょう。前のモジュールの全体像を思い出してください。ユーザーが ChatGPT に書き込み、モデルがあなたのツールを呼び出し、コマース層は別のバックエンドとして存在します。

GiftGenius の主要ブロックを整理します。

第一に、ChatGPT の UI と GPT モデルです。これがユーザーと対話し、必要に応じて GiftGenius App を呼び出します（あるいは App を使わず、Product Feed のみで動くこともあります）。

第二に、GiftGenius のウィジェット（Next.js + Apps SDK）。ギフトのカードや必要に応じてチェックアウトの進行状況を表示します。これは window.openai のサンドボックス内で動作し、実際の決済情報は一切知りません。

第三に、MCP 層です。これはカタログ（Product Feed）に対するギフト検索のツールをモデルに提供し、場合によっては注文履歴の参照も行います。

第四に、コマース / ACP バックエンドです。これは次を担います:

  • Product Feed を商品と SKU のソース・オブ・トゥルースとして読み取る;
  • Agentic Checkout Spec（/checkout_sessions、webhook、ステータス）を実装する;
  • Delegated Payment Spec に従い（例: Stripe）決済プロバイダと通信する。

第五に、（フィードを DB から生成するなら）カタログの DB、注文 DB、補助的な構造（ユーザー、設定など）です。

そして最後に、決済プロバイダです。これは決済データを保管・処理し、決済結果の webhook を送信します。

概略図にすると次のようになります:

graph LR
  U[ChatGPT のユーザー] --> GPT[GPT モデル]
  GPT -->|レンダリング| W[GiftGenius Widget
Next.js + Apps SDK]
  GPT -->|MCP tools| MCP[MCP サーバー
ギフト検索]
  MCP --> PF["Product Feed
(DB/JSON)"]
  GPT -->|ACP HTTP| ACP[GiftGenius Commerce Backend
Agentic Checkout]
  ACP --> ORDERS[注文データベース]
  ACP --> PSP["決済プロバイダ
(Stripe など)"]
  PSP --> ACP
  ACP -->|webhooks/イベント| GPT

この図は GiftGenius のアーキテクチャを実装例として示しています。Product Feed の形式、/checkout_sessions のコントラクト、Delegated Payment のプロトコルは ACP 標準の一部であり、サービスの配置、DB スキーマ、プロセス分割はあなたのアーキテクチャ上の選択です。

3. Product Feed、ACP、ウィジェットの論理的な結び付き

Kotlin

矢印の海に溺れないよう、シンプルだが重要な前提を固定します。あなたには厳密に1 つのソース・オブ・トゥルース（商品に関する真実の出所）しかありません。

GiftGenius の世界では、PostgreSQL の products + skus テーブルだとしましょう。そこから次を行います:

  1. OpenAI の仕様に沿って Product Feed を生成する（直接またはエクスポート経由）。
  2. MCP ツール用の検索インデックスを構築する（例: search_gifts）。
  3. ACP バックエンドからのリクエストを検証する—到着した sku_id が存在し、価格と通貨が正しいことを確認する。

こうして MCP の検索と ACP のチェックアウトは同じデータを見ます。ウィジェットは、MCP ツールから来る結果、あるいは ACP 経由（例: 注文情報）で間接的に来る結果を表示するだけです。

これは同じカタログに対する 2 つの「窓」と捉えられます。1 つは検索とレコメンド用、もう 1 つは購入手続き用です。もしこの 2 つの窓が別々のデータベースを見ていたら、同期ずれという楽しい世界が待っています。

4. データのモデリング: Product Feed から注文まで

まずはシンプルな TypeScript の型から。この型はあなたの GiftGenius リポジトリ内（例えば src/domain/commerce.ts）に置きます。これは仕様の逐語的なコピーではありませんが、アプリで扱いやすい形で主要なアイデアを反映します。 

// src/domain/commerce.ts

export interface ProductSku {
  id: string;          // 安定した SKU ID（Product Feed と一致）
  title: string;       // 人間が読めるタイトル
  priceCents: number;  // セント（または最小通貨単位）での価格
  currency: string;    // ISO コード（例: "usd"）
}

export type CheckoutStatus = "pending" | "succeeded" | "failed";

export interface CheckoutSession {
  id: string;
  skuId: string;
  totalCents: number;
  currency: string;
  status: CheckoutStatus;
}

ここでは CheckoutSession に skuId と固定の通貨/金額への参照を明示的に持たせています。これは内部モデルです。実際の Agentic Checkout Spec はより豊富ですが、基本的な考え方は同じです。すなわち「いくらで、何に対して、どのステータスか」ということです。

次に注文の型が必要です:

export interface Order {
  id: string;
  userId: string;
  skuId: string;
  totalCents: number;
  currency: string;
  checkoutSessionId: string;
  status: "awaiting_payment" | "paid" | "canceled" | "refunded";
}

ここには前モジュールの共通エンティティ intent、checkout_session、order の影響が感じられます。本講義の学習用プロジェクトでは、エンティティを増やしすぎないために intent と order をやや統合しつつ、checkoutSessionId との関連は保持します。

5. GiftGenius ウィジェットが commerce の世界を「のぞき見る」方法

重要なポイント: ウィジェット自体は決済に直接アクセスしませんし、ACP の詳細を知る必要もありません。ウィジェットの役割は、バックエンドで計算・確定された状態をユーザーに表示することです。

最もシンプルで有用なシナリオとして、購入が成功した後にユーザーがチャットへ戻って「GiftGenius の最近の注文を見せて」と尋ねるケースを考えます。GPT は get_user_orders のような MCP ツールを呼び出してあなたのバックエンドへアクセスし、ウィジェットがその一覧を表示します。

最近の注文を返す Next.js の API ルート（簡略化）を想定します:

// app/api/orders/recent/route.ts

import { NextRequest, NextResponse } from "next/server";
import { getRecentOrdersForUser } from "@/lib/orders";

export async function GET(req: NextRequest) {
  const userId = req.headers.get("x-giftgenius-user-id")!;
  const orders = await getRecentOrdersForUser(userId);
  return NextResponse.json({ orders });
}

getRecentOrdersForUser 関数はあなたのコマース層にあり、DB とやり取りし注文の構造を把握しています。ウィジェット側は、前モジュールで行ったように window.fetch でこのルートを呼び出し、購入カードを表示します。

「MCP ツール → あなたの API → 注文 DB → ウィジェット」という組み合わせによって、App に購入の「記憶」があるように感じられますが、実際にはウィジェットがバックエンドの状態を描画しているだけです。

6. Next.js スタイルでの簡易 ACP エンドポイント実装

ここで、主要な ACP エンドポイントの 1 つ、checkout_session の作成を学習用にざっくり実装してみます。仕様上はかなりリッチなコントラクトですが、講義では本質だけに絞ります。すなわち skuId が届き、それをフィード/DB で検証し、セッションを作成して ID と金額を返す、という流れです。

ルートは POST /api/checkout-sessions とします: 

// app/api/checkout-sessions/route.ts

import { NextRequest, NextResponse } from "next/server";
import { findSkuById, createCheckoutSession } from "@/lib/checkout";

export async function POST(req: NextRequest) {
  const body = await req.json();          // { skuId: string }
  const sku = await findSkuById(body.skuId);

  if (!sku) {
    return NextResponse.json(
      { error: "SKU not found" },
      { status: 400 },
    );
  }

  const session = await createCheckoutSession(sku);
  return NextResponse.json({ session });
}

ここにはいくつか重要な点があります。

第一に、まさにこの箇所でコマース層が Product Feed / DB と照合します。findSkuById はフィードを生成しているのと同じソースを見なければなりません。「空から降ってきた」値—GPT からであれウィジェットからであれ—は信用しません。

第二に、ChatGPT / ACP クライアントに必要なものだけを返します。セッション ID、金額、通貨、ステータス（デフォルトは用語に応じて pending または not_ready_for_payment）。実際の ACP には、利用可能な支払い方法やフルフィルメント情報など、より多くのフィールドがありますが、学習用の例はセッションの一次作成にフォーカスします。

第三に、このようなルートは契約テストで保護しやすいのが利点です。明日 Product Feed の構造が変わったとしても、findSkuById と createCheckoutSession のテストが、ChatGPT がユーザーに奇妙なエラーを出すより先に検知してくれるはずです。

7. ACP セッションと決済プロバイダの関係

ここまでで決済プロバイダには触れていません。実際の統合では概ね次のように進みます（簡略版）。

まず ChatGPT（ACP 経由）があなたの POST /checkout_sessions を呼びます。あなたのバックエンドは自前の DB にローカルセッションを作成します。ユーザーが Instant Checkout の UI で支払いを確定すると、プラットフォームは特定マーチャントと金額向けの委任済み決済トークン（Shared Payment Token）を PSP に要求します。このトークンは complete リクエスト（または Delegated Payment Spec の類似呼び出し）であなたのもとへ届きます。

その後、あなたは実際の決済データに触れずに、このトークンを用いて PSP 側で決済を作成します。PSP は結果の webhook を送信し、あなたは注文やチェックアウトセッションのステータスを更新します。

学習用コードではこの手順を模擬で済ませても構いません。例えば completeCheckoutSession は次のように書けます: 

// src/lib/checkout.ts

export async function completeCheckoutSession(sessionId: string, spt: string) {
  // 実際には PSP API を委任トークン（SPT）で呼び出す
  const paymentOk = await mockChargeWithToken(spt);

  return paymentOk
    ? { status: "succeeded" as const }
    : { status: "failed" as const };
}

PSP への呼び出しと Shared Payment Token の利用は Delegated Payment 標準の一部であり、mockChargeWithToken はそれを模擬する学習用のアーキテクチャ層です。

8. GiftGenius のエンドツーエンド・フロー: リクエストから支払い完了したギフトまで

ここまでの内容を手順の連なりとしてまとめます。これが、すべての層を組み合わせる GiftGenius の「実戦」ストーリーです。異なる 2 つの世界を混同しないよう、それぞれ別々に見ていきます。

スキーム A: App なし、Product Feed + ACP のみ

このシナリオでは、Product Feed と ACP バックエンドはあるものの、ChatGPT App とウィジェットはないという構成です。これは古典的な Instant Checkout マーチャントです。

ユーザーは ChatGPT に「50 ドル以内のデジタルギフトを選んで」のように書き込みます。GPT はあなたの Product Feed を使って該当する SKU を探し、ChatGPT のネイティブ UI でショッピングカードとして表示します。ここにはあなたの React コードは一切ありません—カードは完全に ChatGPT が描画します。

ユーザーがそのカードの「Buy」ボタンをクリックします。このクリックはChatGPT 自身が処理します。プラットフォームは:

  1. Product Feed に基づいて line_items を組み立てる。
  2. Agentic Checkout Spec に従ってあなたの POST /checkout_sessions を呼び出す。
  3. ユーザーに Instant Checkout の UI（支払い方法、住所など）を表示する。
  4. 確定後に PSP から Shared Payment Token を受け取り、あなたの .../complete を呼び出す。
  5. あなたから checkout_session の最終状態を受け取り、必要に応じて注文の webhook を待つ。

あなたのコードの観点では、ここで動いているのは ACP エンドポイントと Product Feed だけです。Apps SDK、window.openai、ウィジェットは存在しません。これは完全に妥当な「純粋な」 ACP マーチャントのシナリオです。

スキーム B: ChatGPT App と GiftGenius ウィジェットを使う場合

ここに ChatGPT App と GiftGenius ウィジェットを追加します。Product Feed と ACP バックエンドはそのままです。依然として検索と決済を支えます。違いは、App 内に専用の UI とステップのロジックが現れることです。

会話を想定しましょう。ユーザーが ChatGPT に「お母さん向けの 50 ドル以内のギフトを選んで」と書き込みます。GPT はこれがコマースリクエストだと理解し、GiftGenius App の利用を提案します。ウィジェットはいくつかの補足質問（年齢、興味、国）を行います。その後、GPT は search_gifts のような MCP ツールをフィルタ付きで呼び出し、MCP サーバーはカタログ（DB または事前構築インデックス）にアクセスして複数の SKU を見つけ、構造化して返します。

GPT はこれらのデータをウィジェットに渡し、ウィジェットは独自のギフトカード（React コンポーネント、カルーセルなど）を表示します。これはすでに あなたのデザインと UX であり、ChatGPT の標準ショッピング UI ではありません。

ユーザーがウィジェットの「購入」ボタンをクリックしたら、スキーム A とは異なることが起きます。このクリックはウィジェットが処理します:

  1. ウィジェットはユーザーが選んだ SKU を把握する。
  2. 独自の API（例えば POST /api/checkout-sessions）を通じてあなたのバックエンドにアクセスし、 checkout_session を作成する（または準備済みのセッション ID を取得する）。
  3. 続いてウィジェットは Apps SDK のランタイムメソッドを次のように呼び出します: 
    // 最新のシグネチャは Apps SDK のドキュメントを参照
await window.openai.requestCheckout({
  checkoutSessionId: session.id, ...
});

    この呼び出しはウィジェットのイニシアチブです。ChatGPT にとっては「この checkout_session のために Instant Checkout を開くときだ」というシグナルになります。

あとはプラットフォーム側で、スキーム A と非常によく似た処理が舞台裏で進みます:

  • ユーザーにネイティブな Instant Checkout UI を表示;
  • PSP から Shared Payment Token を取得;
  • あなたの ACP エンドポイント（.../complete）を呼び出してセッションを完了;
  • あなたのバックエンドからの webhook の受信と処理に関与。

つまりスキーム B では、ウィジェットが Apps SDK を通じてチェックアウトを起動し、ACP（checkout_session の作成/完了）に関する呼び出しは、その前（あなたがバックエンドでセッションを作成する場合）か、requestCheckout の後に発生しますが、いずれもサーバーサイドで行われます。

その間ウィジェットは、あなたの API（/api/orders/...）や MCP ツールを基に「購入手続き」やステータス、注文プレビューを並行して表示できます。

スキーム B を図示すると次のようになります:

sequenceDiagram
  participant User as ユーザー
  participant GPT as ChatGPT / GPT
  participant W as GiftGenius Widget
  participant MCP as MCP サーバー
  participant ACP as Commerce Backend
  participant PSP as 決済プロバイダ

  User->>GPT: "50 ドル以内のギフトを選んで"
  GPT->>MCP: search_gifts(...)
  MCP-->>GPT: SKU の一覧
  GPT->>W: カード描画用のデータ
  User->>W: クリック「購入」
  W->>ACP: POST /api/checkout-sessions (skuId)
  ACP-->>W: checkout_session (id, 合計, 通貨)
  W->>GPT: window.openai.requestCheckout({ checkoutSessionId })
  GPT->>User: UI Instant Checkout
  User->>GPT: 支払いの確定
  GPT->>PSP: Shared Payment Token の要求
  PSP-->>GPT: SPT
  GPT->>ACP: complete(sessionId, SPT)
  ACP->>PSP: charge(SPT)
  PSP-->>ACP: 決済結果
  ACP->>GPT: 注文ステータス
  GPT->>User: 支払い成功/失敗のメッセージ

スキーム A との主な違い:

  • A ではカードと「Buy」ボタンをChatGPT 自身が描画し、ACP への呼び出しも ChatGPT が直接行います。
  • B ではカードと「購入」ボタンをあなたのウィジェットが描画し、window.openai.requestCheckout(...) を呼び出すのもウィジェットです。その後で ChatGPT が舞台裏であなたの ACP バックエンドや PSP と対話します。

Insight

ChatGPT の SDK には、まもなくアプリ内にマネタイズが登場すると書かれています。実際そのとおりです。ウィジェットには、まだアナウンスされていないメソッドがすでにいくつか使えます。その中でも最も興味深いのが requestCheckout() です。

呼び出しは次のようになります:

window.openai.requestCheckout({
  id: "checkout_session_123",

  payment_provider: {
    merchant_id: "stripe",
    supported_payment_methods: ["card"]
  },
   ...
}

これにより、ユーザーが支払いを完了できるダイアログが表示されます。したがって、マネタイズがすでに有効になっている前提でアプリを設計してください。作業が完了する頃には、本当にそのとおりになっているはずです。

9. コース用ミニ実装: モノリシックなバックエンド

アーキテクチャのモジュールでも議論しましたが、すべてを 1 つのサービスでやるべきか、MCP サーバー・コマースバックエンド・決済統合の専用サービスに分けるべきかは悩ましいところです。教育目的では、たいてい「ほぼモノリス」で十分です。1 リポジトリ、1 デプロイですが、ロジックはレイヤごとに丁寧に分離します。

学習用の GiftGenius は次のようにできます。Next.js アプリで:

  • ウィジェットは app/widget/page.tsx に配置;
  • ACP エンドポイントは app/api/checkout-sessions とその近辺のルートに配置;
  • MCP ツールは app/api/mcp/route.ts または別ディレクトリに配置;
  • 注文の処理は src/lib/orders.ts、src/lib/checkout.ts などのモジュールで管理。

物理的には 1 台のサーバー（特に dev/staging では）ですが、頭の中ではすでに 3 つの役割—UI（ウィジェット）、MCP（GPT 向けのツール/リソース）、ACP（コマースバックエンド）—として考えます。

のちほどプロダクションのモジュールでは、この「モノリス」を複数のサービスと環境に分割し、その前に MCP Gateway を置く方法を見ます。しかしモジュール 14 の段階でも、「正しいレイヤ分離をしたモノリス」は十分に実在的なアーキテクチャを提供します。

10. 実践課題: あなたの ACP 周辺アーキテクチャ

ここまでの内容を机上の空論で終わらせないよう、自分のドメインに当てはめてみましょう。講義内では 2 つのミニ演習ができます。

第一に、あなた自身のシナリオを選びます。SaaS サブスクリプション、予約、フードデリバリー、オンライン講座など、商品/サービス・価格・妥当なチェックアウトがあるケースなら何でも構いません。フェーズモデル（discovery → decision → checkout → post-payment）を思い出してください。

第二に、GiftGenius のアーキテクチャを土台に、自由形式で次を記述してください。Product Feed をどう構築するか（SKU と価格はどこにあり、誰が更新するか）、ACP のコントラクトはどこで実装するか（独立サービスか既存バックエンドの一部か）、決済プロバイダをどう接続するか、そしてウィジェット（ある場合）が MCP と Apps SDK を通じてそれらとどう連携するか、です。

プロジェクトがスキーム A（App なしの Instant Checkout）のみか、スキーム B（App + ウィジェット）のみか、両方に対応するのかを明確にしておくのも有益です。テキストによるラフなアーキテクチャ草案でも、実際の統合段階での不測のリスクを大きく下げられます。

11. Product Feed、ACP、ウィジェット統合のよくあるミス

エラー 1: 検索用とチェックアウト用で別々のカタログを持つ。
チームがまず GPT 用の「検索用」フィード（小さな JSON など）を急造し、その後で注文向けのコマース DB を別に作ることがあります。両者を共通の ID と共通の更新ロジックで結び付けないと、GPT はすでに買えない商品や古い価格の商品を提案してしまい得ます。正しいアプローチは、Product Feed と ACP エンドポイント用の内部テーブルが同じソース・オブ・トゥルースから形成されることです。

エラー 2: GPT やウィジェットから来たデータを信用してしまう。
checkout_session に skuId と価格が届いたとき、「GPT が嘘をつくはずがない」と信じてしまいがちです。しかしモデルは簡単に創作したり SKU を取り違えたりしますし、ユーザーがリクエストを改ざんしようとすることもあります。入力を Product Feed / DB で照合しないと、別物を別価格で売るリスクがあります。あらゆる ACP エンドポイントは、カタログの一次ストアに対するバリデーションから始めるべきです。

エラー 3: ウィジェットとコマースバックエンドの役割を混同する。
フロントエンドから決済 SDK を直接叩き、Stripe のセッションを作り、通常サイトのノリで進めてしまうことがあります。ChatGPT Apps の文脈ではこれはセキュリティモデルを壊し、ACP に反します。決済フローは ChatGPT とあなたのコマースバックエンドを通るべきで、ウィジェットは状態表示とイベント送出（requestCheckout など）に専念すべきです。ウィジェットが決済周りを知りすぎると、複雑性とリスクが増大します。

エラー 4: ACP コントラクトを単純化しすぎる。
学習用の例では、意図的に skuId、金額、ステータスだけに絞っています。問題は、この「デモ用コントラクト」がいつの間にかプロダクションに流入することです。住所、税金、配送方法、プロモコードなどのフィールドが足りないことに気付き、場当たり的な追加に追われます。最初から現実のシナリオを見据え、内部モデルに余裕を持たせて設計するのがよいでしょう。初期は使わないフィールドがあっても構いません。

エラー 5: 注文とユーザーの関連付けがない。
デモでは orderId と skuId だけで済ませがちで、「1 週間後にユーザーが『購入履歴を見せて』と言ったらどうするか」を考えません。最初から userId（または耐久性のある別の識別子）を注文とチェックアウトセッションに入れておかないと、後で移行やブリッジが大変になります。ChatGPT を中心としたコマースアーキテクチャは、多くの場合 GPT が現在の対話とユーザーの注文履歴を紐づけられることを前提にしています–それを早い段階で織り込んでおきましょう。

エラー 6: webhook と冪等性の重要性を甘く見る。
本講義では webhook に触れただけで、深掘りは次のモジュールで行います。「webhook は 1 度来るから、注文を更新すれば終わり」と考えがちですが、現実には決済システムはイベントをリトライしますし、ネットワークは応答を失います。checkoutSessionId や paymentId をキーに、注文やチェックアウトセッションを冪等な構造として設計しないと、二重請求、重複注文、PSP と自前 DB の不整合に繋がります。

エラー 7: Product Feed における制限・ポリシーを無視する。
デモ用フィードを急ぐあまり、年齢制限、国別の提供可否、禁止カテゴリなどの「小さなこと」を忘れがちです。その結果、GPT がユーザーの居住地域や年齢では売れない商品を提案してしまうことがあります。ポリシーと制限に関するフィールドは、最初から設計・入力すべきです。たとえ今扱っているのが無害なデジタルギフトだけだとしても、です。

1
アンケート/クイズ
決済: ACP と Instant Checkout、レベル 14、レッスン 4
使用不可
決済: ACP と Instant Checkout
コマース: Product Feed、ACP と Instant Checkout
オープン
コメント
TO VIEW ALL COMMENTS OR TO MAKE A COMMENT,
GO TO FULL VERSION