1. AI‑commerce là gì
Nếu e‑commerce cổ điển là câu chuyện “vào website — mở catalog — thêm vào giỏ — lướt qua ba biểu mẫu”, thì AI‑commerce là khi giao diện chính trở thành cuộc đối thoại với ChatGPT. Người dùng nêu yêu cầu bằng ngôn ngữ tự nhiên, còn agent bên trong ChatGPT đảm nhiệm vai trò tư vấn, merchandiser và phần nào là product manager.
Các truy vấn trông không giống “category=tất&price_max=20”, mà giống như “hãy gợi ý một món quà hài hước nhưng không quá ‘cringe’ cho đồng nghiệp dưới 20 đô, có thể gửi qua email”. Agent diễn giải yêu cầu, hỏi làm rõ, tra cứu catalog hàng hóa, giải thích ưu/nhược điểm của các phương án, rồi dẫn người dùng đến bước mua — và tất cả diễn ra mà người dùng không cần thấy “giỏ hàng” như một trang riêng.
Về mặt kiến trúc, ChatGPT App ở thời điểm này chuyển từ “catalog quà tặng thông minh” thành ứng dụng commerce có khả năng:
- Hiểu ý định và các ràng buộc của người dùng (ngân sách, loại quà, quốc gia, hàng số/vật lý).
- Chọn các SKU cụ thể từ product feed và giải thích lý do chọn.
- Khởi tạo việc mua qua giao thức tiêu chuẩn ACP (Agentic Commerce Protocol).
Ý tưởng của AI‑commerce là “catalog + checkout” không còn là một website riêng, mà là sự tiếp nối hợp lý của cuộc hội thoại mà người dùng vốn đang có với GPT.
2. E‑commerce cổ điển và AI‑commerce
Để cảm nhận rõ khác biệt, tiện nhất là đặt hai cách tiếp cận cạnh nhau. Dưới đây là bảng rút gọn, không nhằm bao quát hoàn hảo, nhưng làm nổi bật sự thay đổi mô hình.
| Đặc trưng | E‑commerce cổ điển | AI‑commerce trong ChatGPT |
|---|---|---|
| Điểm vào | URL website, quảng cáo, tìm kiếm trên trình duyệt | Tin nhắn trong chat (“gợi ý…”, “mua…”) |
| Giao diện | Trang, biểu mẫu, bộ lọc | Hội thoại + widget bên trong ChatGPT |
| Điều hướng | Danh mục, breadcrumb, bộ lọc | Câu hỏi làm rõ từ agent, các nút follow‑up |
| Tìm kiếm | Từ khóa, lọc thủ công | Tìm kiếm ngữ nghĩa trên product feed |
| Ra quyết định | Người dùng tự so sánh thẻ sản phẩm | Agent giải thích, so sánh, lập luận |
| Checkout | Biểu mẫu nhiều trang, chuyển hướng | Instant Checkout trong chat hoặc link‑out thông minh |
| Tích hợp AI | Chat “gợi ý” đặt đâu đó bên cạnh | Chat là giao diện chính, website có thể chỉ là hỗ trợ |
Hệ quả thực tiễn: trong AI‑commerce, trọng tâm chuyển từ thiết kế trực quan của “catalog và giỏ hàng” sang cấu trúc và chất lượng dữ liệu, cũng như giao thức chính quy cho tương tác giữa ChatGPT, backend của bạn và nhà cung cấp dịch vụ thanh toán. Product feed và các endpoint ACP trở thành “UI” quan trọng không kém chính widget.
Nếu trong cửa hàng cổ điển bạn có thể chỉnh một phần UX trên trình duyệt, thì trong AI‑commerce, mô hình gần như hoàn toàn dựa vào dữ liệu và schema mà bạn cung cấp: từ mô tả sản phẩm đến trạng thái của phiên checkout.
3. Các khối xây dựng của OpenAI Commerce
OpenAI không cung cấp “hệ thống thanh toán thần kỳ GPTPay” làm hết mọi thứ. Thay vào đó là tập hợp các đặc tả và hướng dẫn mô tả cách kết nối đúng các merchant và nhà cung cấp thanh toán hiện có vào thế giới ChatGPT. Trong đó, với chúng ta đặc biệt quan trọng là bốn khối sau.
Thứ nhất, Product Feed Specification. Đây là định dạng chính thức mà người bán mô tả catalog sản phẩm của mình: id, title, description, giá, đơn vị tiền tệ, tồn kho, hình ảnh, v.v. Feed đóng vai trò “nguồn sự thật có cấu trúc”, được OpenAI kiểm tra, lập chỉ mục và dùng cho tìm kiếm, xếp hạng và checkout bên trong ChatGPT.
Thứ hai, Agentic Checkout Specification. Đây là hợp đồng REST cho thực thể checkout_session: API mô tả cách tạo phiên thanh toán, cập nhật (ví dụ khi đổi địa chỉ hoặc phương thức giao hàng) và hoàn tất, cũng như các trường backend của bạn phải trả về (tổng tiền, thuế, các tùy chọn fulfillment, liên kết đến chính sách hoàn trả, v.v.).
Thứ ba, Delegated Payment Specification. Đây là giao thức theo đó nền tảng agent (ChatGPT) nhận token thanh toán được ủy quyền từ PSP (ví dụ Stripe Shared Payment Token) và chuyển cho backend của bạn, mà không tiết lộ thông tin thẻ. Token được giới hạn theo số tiền, thời hạn và các tham số khác, và được backend của bạn dùng để tạo khoản thanh toán thực sự tại PSP.
Cuối cùng, Instant Checkout trong ChatGPT — lớp UX nằm trên các đặc tả này. Bên trong chat xuất hiện giao diện checkout gọn: sản phẩm đã chọn, giá, địa chỉ, phương thức thanh toán. Bên dưới, nó dựa vào Product Feed, gọi các /checkout_sessions của bạn theo Agentic Checkout Spec và dùng Delegated Payment để thực hiện giao dịch tại PSP.
Tin tốt là tất cả những thứ này không phải “API bí mật của ChatGPT”, mà là các đặc tả mở ACP (Agentic Commerce Protocol). Nghĩa là cùng một backend về lý thuyết có thể hoạt động với các nền tảng AI khác nếu họ cũng hỗ trợ ACP.
4. Vai trò và ranh giới trách nhiệm
Phần thú vị nhất bắt đầu khi có tiền đi qua hệ thống: lúc đó các nhà quản lý và luật sư bỗng trở thành bạn tốt nhất của bạn. Để không rối, điều quan trọng là phân định rõ vai trò.
Vai trò quan trọng nhất là nền tảng agent, ở đây là ChatGPT. Họ sở hữu trải nghiệm người dùng: chat, widget, Instant Checkout UI. Nền tảng khởi tạo luồng commerce, chọn sản phẩm từ Product Feed, gọi các endpoint ACP của bạn và hiển thị kết quả cho người dùng. Nhưng ChatGPT không trở thành chủ sở hữu hàng hóa, cũng không là nhà cung cấp thanh toán và không lưu trữ dữ liệu product của bạn như “catalog của riêng họ” — họ dùng đúng feed mà bạn cung cấp.
Vai trò thứ hai — merchant (seller, merchant‑of‑record). Đây là chủ sở hữu hàng hóa hoặc dịch vụ. Merchant chịu trách nhiệm về chính product feed (cấu trúc, chất lượng, tính cập nhật của giá và tồn kho), về việc triển khai đúng các endpoint ACP (/checkout_sessions, webhook), về tạo và lưu trữ đơn hàng, giao hàng, hỗ trợ và hoàn trả. Tài liệu ACP nhấn mạnh rằng merchant vẫn là bên bán trong nghĩa pháp lý, chứ không phải nền tảng agent.
Vai trò thứ ba — nhà cung cấp dịch vụ thanh toán (PSP), ví dụ Stripe. PSP chịu trách nhiệm xử lý thanh toán, tuân thủ PCI DSS và các yêu cầu khác, lưu trữ thông tin thẻ, chống gian lận và chargeback. Trong bối cảnh Delegated Payment, PSP cấp cho nền tảng agent một token đặc biệt (SPT), sau đó token này được server của bạn dùng để tạo khoản thanh toán thực (ví dụ PaymentIntent trong Stripe).
Vai trò thứ tư và quan trọng nhất — người dùng. Họ nêu yêu cầu, đưa ra quyết định mua cuối cùng, đồng ý thanh toán và, lý tưởng nhất, đọc Terms / Privacy Policy mà bạn minh bạch hiển thị trong checkout‑UI. Product feed có thể chứa liên kết đến các tài liệu này và chính sách hoàn trả để tăng tin cậy và minh bạch.
Để tiện tham chiếu, có thể tóm tắt trong một bảng nhỏ:
| Vai trò | Chịu trách nhiệm | Không chịu trách nhiệm |
|---|---|---|
| ChatGPT / nền tảng | UX hội thoại, chọn sản phẩm từ feed, gọi ACP | Lưu trữ catalog như “của riêng”, tính thuế |
| Merchant | Feed, giá, tồn kho, đơn hàng, hoàn trả | Xử lý thẻ trực tiếp, UI của chat |
| PSP (Stripe, v.v.) | Thanh toán, lưu trữ thẻ, chống gian lận, compliance | Chọn sản phẩm, UX hội thoại |
| Người dùng | Ý định, chọn sản phẩm, đồng ý thanh toán | Tính chính xác của dữ liệu trong feed của bạn :) |
Phân chia vùng trách nhiệm quan trọng không chỉ với pháp lý mà còn với kiến trúc. Ví dụ, nếu ngày mai bạn kết nối thêm một PSP thứ hai, bạn không cần viết lại ChatGPT App: chỉ cần điều chỉnh lớp Delegated Payment trên backend của mình. Và nếu xuất hiện một nền tảng AI thứ hai cũng hiểu ACP, bạn có thể tái sử dụng cả product feed lẫn các endpoint checkout.
5. Kịch bản mua hàng “tất cả trong hội thoại” trông thế nào
Giờ hãy gom tất cả và xem kịch bản end‑to‑end mua một món quà số trong ChatGPT trông ra sao dưới góc độ kiến trúc. Đây là phiên bản rút gọn nhưng nêu rõ bản chất.
sequenceDiagram
participant U as Người dùng
participant C as ChatGPT
participant G as GiftGenius App
participant B as Merchant Backend
participant P as PSP (Stripe)
U->>C: "Mua món quà số dưới $50"
C->>G: callTool(find_gifts, budget<=50)
G->>B: GET /catalog?budget_lte=50
B-->>G: Danh sách SKU phù hợp
G-->>C: Các lựa chọn quà + metadata
C-->>U: Giải thích lựa chọn, đề xuất tùy chọn
U->>C: "Tôi chọn cái này"
C->>B: POST /checkout_sessions (sku, price...)
C->>P: Yêu cầu token thanh toán (SPT)
C->>B: POST /checkout_sessions/{id}/complete (token)
B->>P: Xử lý thanh toán
B-->>C: Webhook về việc tạo đơn hàng
C-->>U: Xác nhận mua hàng
Diễn giải theo ngôn ngữ ACP:
- Agent dùng Product Feed (thông qua backend của bạn) để chọn các SKU phù hợp.
- Khi quyết định “mua”, ChatGPT tạo checkout_session qua /checkout_sessions của bạn theo Agentic Checkout Spec.
- Trong Instant Checkout, ChatGPT yêu cầu PSP cấp token thanh toán ủy quyền cho số tiền và merchant cụ thể.
- Token này được gửi trong POST /checkout_sessions/{id}/complete, backend của bạn tạo thanh toán ở PSP và hình thành đơn hàng.
- Khi đơn hàng sẵn sàng, server của bạn thông báo OpenAI qua webhook, sau đó người dùng thấy xác nhận cuối cùng.
Điều quan trọng trong bài này không phải ghi nhớ tên endpoint, mà là nhìn thấy cấu trúc: feed → chọn SKU → checkout_session → thanh toán → đơn hàng → webhook. Ở các bài sau chúng ta sẽ lần lượt phân tích từng phần, bao gồm các trường của feed, trường của phiên checkout và định dạng thanh toán ủy quyền.
6. GiftGenius: App của chúng ta hòa vào AI‑commerce như thế nào
Đến thời điểm này, GiftGenius đóng vai “trợ lý chọn quà”. Nó có thể:
- hỏi người dùng tặng cho ai và nhân dịp gì;
- dùng công cụ MCP để tìm trong catalog của chính nó;
- hiển thị các thẻ lựa chọn trong widget và gửi các nút follow‑up vào chat.
Về mặt commerce, đây là “discovery thông minh” chưa có mua thật. Trong thế giới OpenAI commerce, chế độ này tương ứng với feed mà các SKU có enable_search = true, nhưng enable_checkout = false: có thể tìm và thảo luận sản phẩm, nhưng Instant Checkout bị tắt cho chúng.
Trong mô‑đun AI‑commerce, chúng ta sẽ dần biến GiftGenius thành một merchant tích hợp đầy đủ:
- thêm Product Feed có cấu trúc theo đặc tả OpenAI;
- thiết kế ACP backend có thể làm việc với checkout_sessions;
- kết nối Delegated Payment qua Stripe Shared Payment Token;
- dạy App cho người dùng biết họ không chỉ có thể chọn mà còn mua quà ngay trong chat.
Để mọi thứ không giống “ma thuật đen”, hãy thêm vào code một lớp kỹ thuật nhỏ mô hình hóa rõ ràng vai trò và các bước trong luồng commerce. Điều này hữu ích cho log và cả các bài test nội bộ.
// app/commerce/types.ts
export type CommerceRole = "user" | "chatgpt" | "merchant" | "psp";
export interface CommerceStep {
id: string;
role: CommerceRole;
description: string;
}
Các kiểu dữ liệu này giúp tách bạch “ai làm gì” ngay ở cấp TypeScript. Ta có thể dùng chúng, ví dụ, trong test hoặc UI gỡ lỗi bên trong widget.
Ví dụ nhỏ về mảng bước cho kịch bản “quà số dưới $50”:
// app/commerce/exampleFlow.ts
import type { CommerceStep } from "./types";
export const digitalGiftFlow: CommerceStep[] = [
{ id: "intent", role: "user", description: "Diễn đạt yêu cầu và ngân sách" },
{ id: "search", role: "chatgpt", description: "Chọn SKU từ Product Feed" },
{ id: "checkout", role: "merchant", description: "Tạo checkout_session" },
{ id: "payment", role: "psp", description: "Thực hiện thanh toán bằng token" }
];
Đoạn mã này chưa gọi mạng với ai, nhưng đã tạo một “trục tọa độ” hữu ích, quanh đó chúng ta sẽ bồi đắp code ACP thực thụ ở các bài tiếp theo.
7. Bài tập nhỏ: phân rã luồng “Mua cho tôi một món quà số dưới $50”
Cuối bài, hãy tự tay phân rã những gì vừa nói. Lấy yêu cầu của người dùng:
“Mua cho tôi một món quà số dưới $50”.
Nhiệm vụ — mô tả trong 3–5 bước logic những gì xảy ra tiếp theo, và với mỗi bước hãy chỉ ra ai thực hiện: ChatGPT, backend merchant của bạn, nhà cung cấp thanh toán hay chính người dùng. Bạn có thể dựa vào sơ đồ bên trên và mảng digitalGiftFlow, nhưng không nhất thiết phải giống y hệt.
Ví dụ, bạn có thể bắt đầu từ bước ChatGPT diễn giải yêu cầu và hỏi rõ người dùng (voucher số, khu vực người nhận, tặng ai). Tiếp theo là bước backend của bạn tìm SKU phù hợp qua Product Feed, rồi tạo checkout_session, nhận token thanh toán từ PSP và hoàn tất mua hàng.
Nếu muốn, bạn có thể hiện thực nó ngay trong code, thêm vài bước vào digitalGiftFlow và render chúng trong một component gỡ lỗi nhỏ ở widget. Bài tập như vậy giúp rèn thói quen không chỉ “nghĩ về code” mà còn nghĩ về vai trò trong giao thức.
Ví dụ về một API endpoint đơn giản có thể nhận “kế hoạch luồng” như vậy và ghi log (chưa có commerce thật):
// app/api/commerce/flow/route.ts
import { NextRequest, NextResponse } from "next/server";
import type { CommerceStep } from "@/app/commerce/types";
export async function POST(req: NextRequest) {
const steps = (await req.json()) as CommerceStep[];
console.log("Planned AI-commerce flow:", steps);
return NextResponse.json({ ok: true, stepsCount: steps.length });
}
Trong thực tế, thay vì console.log bạn sẽ ghi log có cấu trúc và có thể lưu các kịch bản như một phần tài liệu hoặc bài test. Nhưng ngay cả ví dụ nhỏ này cũng giúp nối kết kiến trúc trừu tượng với TypeScript cụ thể trong ứng dụng Next.js của bạn.
Nếu luôn giữ trong đầu bức tranh vai trò đã phân tích ở bài này, các chi tiết kỹ thuật tiếp theo — trường của Product Feed, schema của các phiên checkout và cấu trúc thanh toán ủy quyền — sẽ trở nên dễ nắm bắt hơn, không bị lãng mạn hóa bởi hình ảnh “GPT toàn năng”.
8. Những hiểu lầm điển hình về AI‑commerce và vai trò
Lỗi số 1: nghĩ rằng “ChatGPT sẽ tự làm hết”.
Đôi khi lập trình viên nghĩ chỉ cần “kết nối Stripe” và “cho mô hình quyền gọi API” là GPT sẽ tự xử lý. Thực tế, AI‑commerce xoay quanh ChatGPT dựa trên các đặc tả chính quy: Product Feed, Agentic Checkout, Delegated Payment. Nếu bạn không mô tả hàng hóa bằng feed có cấu trúc, không triển khai /checkout_sessions và không cấu hình Delegated Payment, sẽ không có mô hình nào “bịa” ra giúp bạn.
Lỗi số 2: nhầm lẫn vai trò của ChatGPT và merchant.
Một nhầm lẫn phổ biến khác — cho rằng ChatGPT trở thành “cửa hàng”, còn bạn chỉ “kết nối catalog”. Thực tế ngược lại: bạn vẫn là merchant, lưu trữ product feed, tạo và vận hành đơn hàng, xử lý hoàn trả. ChatGPT chỉ chịu trách nhiệm UX hội thoại và gọi chính xác các endpoint ACP của bạn. Nếu thiết kế hệ thống theo hướng “GPT tự phân phối subscription và gửi hàng”, sớm muộn bạn sẽ rơi vào ngõ cụt cả pháp lý lẫn kỹ thuật.
Lỗi số 3: bỏ qua PSP như một thực thể riêng biệt.
Đôi khi ta muốn “giấu” PSP trong backend và giao tiếp với nó như bất kỳ REST API nào, quên rằng lớp thanh toán có luật chơi riêng (PCI, gian lận, chargeback, hạn mức). Trong cách tiếp cận ACP, Delegated Payment được tách riêng không phải ngẫu nhiên: nền tảng agent giao tiếp với PSP ở tầng của họ, nhận SPT token và chuyển cho bạn, còn bạn tạo thanh toán. Nếu tìm cách bỏ qua sơ đồ này và nhận trực tiếp thông tin thẻ trong App, bạn sẽ tự đẩy mình vào các yêu cầu compliance khắt khe.
Lỗi số 4: coi product feed là “thiết lập marketing” thay vì một API cho LLM.
Nhiều người đến từ bối cảnh Google Shopping và nghĩ về feed như thứ quan trọng với tài khoản quảng cáo hơn là với code. Trong AI‑commerce, feed thực chất là cơ sở tri thức về danh mục của bạn cho mô hình. Nếu có liên kết ảnh hỏng, thuộc tính thiếu nhất quán, đơn vị đo lường kỳ lạ và các phóng đại marketing thay vì dữ kiện, mô hình sẽ đề xuất sai điều bạn cần, và chuyển đổi sẽ giảm.
Lỗi số 5: cố bật Instant Checkout “chỉ một bước”.
Cám dỗ rất lớn: “hãy bật ngay enable_checkout, để người dùng mua trong chat”. Nhưng nếu thiếu discovery tốt (feed chất lượng), thiếu checkout backend vững và thiếu tích hợp thấu đáo với PSP, bạn có nguy cơ có một hệ thống mong manh, nơi nửa số đơn bị kẹt giữa chừng. Hợp lý hơn nhiều là đi theo các bậc của OpenAI: trước tiên Product Feed chất lượng, sau đó chỉnh các endpoint ACP, rồi Delegated Payment và chỉ sau đó mới bật Instant Checkout ở môi trường production.
GO TO FULL VERSION