ChatGPT Merchants và hành trình của merchant: từ đăng ký đến trách nhiệm

1. ChatGPT‑merchant là ai và khác gì so với “cửa hàng bình thường”

Từ góc nhìn của lập trình viên, rất dễ lẫn lộn các tầng: ta có ứng dụng Next.js, máy chủ MCP, một commerce‑backend nào đó, và đâu đó còn có OpenAI, ChatGPT, Stripe và các dịch vụ “người lớn” khác. Dễ buột miệng: “Tất cả chỉ là một hệ thống lớn, miễn là test đều xanh là được”.

Nhưng trong thế giới AI‑commerce, ranh giới pháp lý và kỹ thuật được phân định rất chặt. ChatGPT không trở thành cửa hàng của bạn và cũng không biến thành bộ xử lý thanh toán. Nó chỉ cung cấp giao diện thông minh và gọi API của bạn theo các đặc tả mở. Merchant vẫn là một công ty cụ thể với catalog cụ thể và trách nhiệm đối với người dùng.

Việc hiểu vai trò của merchant không chỉ dành cho pháp chế. Nó quyết định các lựa chọn kiến trúc: dữ liệu feed lưu ở đâu, bạn xác thực đơn hàng thế nào, log những gì, và cách bạn gỡ lỗi các sai lệch giữa thứ hiển thị trong chat và điều thực sự xảy ra trong hệ thống của bạn.

Ví dụ

Hãy hình dung e‑commerce cổ điển: bạn có website, giỏ hàng, checkout, tích hợp với nhà cung cấp thanh toán. Người dùng mở trình duyệt, click chuột, nhập dữ liệu thẻ — mọi thứ rõ ràng.

ChatGPT‑merchant vẫn là cửa hàng đó, chỉ là biết bán qua hội thoại AI với mức tự động hóa cao. Khác biệt không nằm ở cái gì bạn bán, mà ở cách người dùng đi từ yêu cầu đến thanh toán.

Từ góc nhìn OpenAI, merchant là tổ chức (hoặc cá nhân kinh doanh) mà:

• cung cấp Product Feed theo đặc tả OpenAI (CSV/TSV/XML/JSON với dữ liệu có cấu trúc về SKU);
• đăng ký trong cổng ChatGPT Merchants và vượt qua kiểm duyệt danh mục cùng các yêu cầu pháp lý;
• ở mức nâng cao, triển khai Agentic Checkout và Delegated Payment để Instant Checkout trong ChatGPT có thể xử lý thanh toán mà không cần đưa người dùng về website của bạn.

Nói cách khác, merchant không phải là “người viết widget”, mà là chủ sở hữu danh mục và nghĩa vụ tài chính. Trong khóa học này, chúng ta đóng cùng lúc hai vai: đội viết GiftGenius như một ChatGPT App, và đội làm backend của merchant phục vụ App đó.

2. Cổng ChatGPT Merchants: hành trình từ đăng ký đến merchant chạy thực

OpenAI có một website riêng cho người bán — cổng ChatGPT Merchants. Qua đó, người bán tham gia chương trình Instant Checkout và kết nối feed cùng backend của mình. Hãy đi qua các bước, chưa đào sâu vào chi tiết kỹ thuật (sẽ có ở bài sau).

Chuẩn bị trước

Trước khi ai đó trong đội của bạn bấm nút “Apply”, bạn cần sẵn vài “viên gạch”:

Thực thể pháp lý và website. Merchant có tên miền và một storefront dễ hiểu với người dùng — ngay cả khi sau đó mọi thứ sẽ bán qua ChatGPT, OpenAI kỳ vọng có một trang trưng bày công khai.

Danh mục trong phạm vi chính sách. Ở bài trước, chúng ta đã nói về Prohibited Products Policy: không được, ví dụ, bán vũ khí hoặc một số mặt hàng y tế. Bất kỳ sản phẩm nào bạn muốn bán qua ChatGPT phải nằm trong danh sách danh mục cho phép.

Hạ tầng thanh toán cơ bản. Dù Delegated Payment giúp bạn không phải làm việc trực tiếp với thẻ, bạn vẫn phải có tích hợp với PSP (chính là Stripe chẳng hạn) và hiểu rõ cách bạn tạo đơn hàng và hoàn tiền trong hệ thống của mình.

Nộp đơn trong cổng Merchants

Về mặt kỹ thuật đây là bước khá nhàm chán nhưng quan trọng: bạn vào trang và nộp đơn tham gia chương trình Instant Checkout. Thường sẽ hỏi:

• bạn là ai (pháp nhân, website, liên hệ);
• bạn bán gì (danh mục, khoảng giá, khu vực);
• bạn sẵn sàng cung cấp Product Feed như thế nào (định dạng, URL, tần suất cập nhật).

Phần này ít liên quan tới TypeScript, nhưng ảnh hưởng mạnh tới lộ trình: khi merchant chưa qua kiểm tra cơ bản, sẽ không có Instant Checkout được bật, cho dù mã của bạn hoàn hảo.

Kết nối Product Feed

Sau khi đơn của bạn được xem và về tổng thể đã đồng ý, trọng tâm kỹ thuật chuyển sang Product Feed. Theo tài liệu, feed là bắt buộc cho tích hợp: không có nó, ChatGPT đơn giản là không biết bạn bán gì.

Ở bước này bạn:

1. Chọn định dạng feed (thường là CSV hoặc JSON).
2. Thống nhất cách phân phối: có thể là pre‑signed URL trên S3 hoặc HTTPS‑endpoint nơi bạn định kỳ POST bản cập nhật.
3. Chuẩn bị tối thiểu các trường cho mỗi SKU: id, title, description, price, currency, availability, link, hình ảnh và các cờ enable_search / enable_checkout.

Khi bạn đặt enable_checkout = false, merchant có thể chạy ở chế độ chỉ khám phá: ChatGPT tìm và gợi ý sản phẩm, nhưng khi cố gắng mua sẽ đưa người dùng đến website của bạn.

Tích hợp ACP (chi tiết ở bài sau)

Khi Product Feed ổn định và bạn sẵn sàng tiến thêm, bắt đầu tích hợp Agentic Checkout và Delegated Payment. Ở góc độ cổng Merchants, đây là một khối yêu cầu riêng: cần hiện thực các endpoint /checkout_sessions, biết cách nhận token thanh toán được ủy quyền (Shared Payment Token) và kết thúc phiên với các trạng thái phù hợp (not_ready_for_payment, ready_for_payment, completed, canceled).

Trong bài này chúng ta chỉ nói về nó như “cấp độ khó tiếp theo”. Tất cả chi tiết của giao thức và schema request sẽ được phân tích trong bài giảng kế tiếp.

3.5. Chứng nhận và bật Instant Checkout

Giai đoạn cuối — kiểm tra cách backend của bạn ứng xử trong các kịch bản thực:

• đơn hàng có được tạo đúng không;
• giá trong feed có trùng với giá mà bạn thực sự thu không;
• lỗi và hoàn tiền có được xử lý đúng không;
• các trang ToS/Privacy của bạn có đáp ứng kỳ vọng của OpenAI và luật địa phương không.

Sau đó merchant nhận trạng thái “sẵn sàng cho Instant Checkout” và sản phẩm với enable_checkout = true thực sự trở nên có thể mua trực tiếp trong ChatGPT.

Tất cả có thể hình dung bằng sơ đồ đơn giản:

flowchart TD
  A[Đã có sản phẩm và website] --> B[Đơn gửi tới ChatGPT Merchants]
  B --> C[Product Feed đã được kết nối]
  C --> D["Đã triển khai ACP backend
(checkout_sessions + delegated payment)"]
  D --> E[Chứng nhận
và bật Instant Checkout]

3. Các phương án cho merchant: Etsy/Shopify vs backend tùy biến

Tin vui: không phải mọi merchant đều phải tự viết toàn bộ ACP‑backend. Với một số nền tảng (Shopify, Etsy, v.v.) đã có các tích hợp đảm đương phần kỹ thuật.

Nếu bạn bán qua Shopify hoặc Etsy, sơ đồ sẽ như sau: bạn bật ở họ một tùy chọn kiểu “Show in ChatGPT”, và nền tảng tự:

• tạo và duy trì Product Feed ở định dạng cần thiết;
• hiện thực hoặc proxy các endpoint ACP;
• kết nối với Stripe hoặc PSP khác.

Bạn, với tư cách chủ cửa hàng, sẽ tập trung nhiều hơn vào danh mục và mô tả, chứ không phải các endpoint REST.

Còn nếu bạn, như trong khóa học với GiftGenius, xây dựng merchant tùy biến với backend riêng, bạn sẽ có nhiều tự do hơn nhưng cũng nhiều việc hơn: tự viết mã hiện thực feed, checkout và tích hợp với nhà cung cấp thanh toán.

Tiện so sánh dưới dạng bảng:

Trong khóa học, chúng ta cố ý chọn phương án thứ ba: chỉ như vậy ta mới có thể đi hết hành trình từ feed đến webhook và production ổn định.

4. Trách nhiệm của merchant: dữ liệu, đơn hàng, chính sách, tiền

Khi bạn trở thành ChatGPT‑merchant, bạn không chỉ có niềm vui từ các đơn hàng mới mà còn nhận một tập nghĩa vụ rất cụ thể. Hãy phân tích theo từng lớp.

Dữ liệu catalog và chất lượng Product Feed

Product Feed là nguồn sự thật cho ChatGPT. Nếu ghi rằng sản phẩm có giá 10 USD và còn hàng, thì đó chính là những gì người dùng sẽ thấy trong chat. Nếu feed sai, thì tốt nhất bạn nhận khách phàn nàn, tệ nhất — vi phạm chính sách và gặp rắc rối với OpenAI.

Kỳ vọng đối với merchant:

• tính đúng đắn của các trường bắt buộc (định dạng giá chính xác, mã tiền tệ ISO, liên kết HTTPS hợp lệ, hình ảnh hoạt động);
• cập nhật feed đủ thường xuyên để không bán “hàng ma”;
• tính nhất quán của định danh: id SKU trong feed phải trùng với ID trong cơ sở dữ liệu và hệ thống đơn hàng của bạn, để bạn có thể hiểu một cách rõ ràng là đã mua thứ gì.

So sánh với e‑commerce thông thường, Product Feed ở đây là “xuất sang marketplace”, chỉ khác là marketplace lần này là trợ lý thông minh sống trong đầu người dùng và rất dễ ghi nhớ các bất nhất.

Đơn hàng, giao hàng và hoàn trả

ChatGPT không biến thành bộ phận hỗ trợ của cửa hàng bạn. Người dùng dĩ nhiên trò chuyện với nó, nhưng về mặt pháp lý họ mua hàng của merchant, chứ không phải của OpenAI. Điều đó có nghĩa là:

• bạn chịu trách nhiệm đơn hàng được tạo trong hệ thống của bạn và đi đến kho;
• bạn chịu trách nhiệm việc bưu kiện đến đúng địa chỉ do người dùng cung cấp trong Instant Checkout;
• bạn chịu trách nhiệm xử lý hoàn trả, hủy, hoàn tiền một phần, v.v.

Trong khuôn khổ ACP, checkout_session sau khi hoàn tất thường chứa đối tượng order với các trường của nó. Nhưng đó chỉ là phản chiếu những gì xảy ra trong backend của bạn — chính bạn quyết định bản ghi trong bảng orders trông như thế nào, có những trạng thái gì, và chúng liên kết với logistics ra sao.

Chính sách và địa lý

Trong cổng Merchants, bạn nêu rõ bạn bán ở những quốc gia nào và loại sản phẩm gì. Về phía mình, OpenAI kiểm tra rằng bạn:

• không bán các danh mục bị cấm;
• tuân thủ luật địa phương (ví dụ, quy định thuế và hạn chế theo độ tuổi);
• cung cấp Terms of Service và Privacy Policy dễ hiểu.

Trong các mô‑đun tiếp theo, chúng ta sẽ còn nói về các trang pháp lý, nhưng ngay bây giờ hữu ích khi nghĩ theo hướng: “Nếu tôi không thể giải thích cho luật sư tôi bán cái gì và ở đâu, ChatGPT khó có thể bán giúp tôi.”

Tiền và nhà cung cấp thanh toán

Cuối cùng, thứ đáng sợ nhất — tiền. May mắn thay, ACP và Delegated Payment giúp cuộc sống của lập trình viên dễ hơn rất nhiều:

• ChatGPT và nhà cung cấp thanh toán (ví dụ, Stripe) thống nhất Shared Payment Token cho một số tiền và merchant cụ thể;
• backend của bạn nhận token này trong yêu cầu complete và sử dụng trong PSP của bạn, mà không thấy dữ liệu thẻ “thô”.

Tức là bạn không phải biến thành quái vật tuân thủ PCI, không lưu số thẻ và không sa vào cơn ác mộng audit. Trách nhiệm của bạn — sử dụng đúng token được ủy quyền (tạo thanh toán, thu tiền, hoàn tiền) và ghi chép cẩn thận.

5. Điều này đặt vào kiến trúc GiftGenius như thế nào

Quay lại ứng dụng học tập GiftGenius. Về mặt kiến trúc, sau mô‑đun 14, chúng ta muốn học viên có thể vẽ sơ đồ mức: “Người dùng → ChatGPT → App widget → MCP Gateway → Product Feed / Agents / ACP backend”.

Trong sơ đồ này, vai trò merchant được hiện thực trong backend của chúng ta, còn widget và App chỉ là “bộ mặt” của merchant đó trong ChatGPT.

Cấu hình merchant trong mã

Bắt đầu từ bước đơn giản: tạo trong mã một cấu trúc cấu hình merchant. Giả sử đó là module TypeScript lib/merchantConfig.ts trong dự án Next.js của chúng ta:

// lib/merchantConfig.ts
export type MerchantConfig = {
  id: string;                // ID của merchant trong ACP/Stripe
  name: string;              // Tên dễ đọc (human-readable)
  feedUrl: string;           // Nơi lưu Product Feed
  instantCheckoutEnabled: boolean;
};

export const giftGeniusMerchant: MerchantConfig = {
  id: process.env.MERCHANT_ID ?? "dev-merchant",
  name: "GiftGenius",
  feedUrl: process.env.PRODUCT_FEED_URL ?? "https://example.com/feed.json",
  instantCheckoutEnabled: false, // sẽ bật sau
};

Ở đây, thứ nhất, chúng ta cố định ranh giới rõ ràng: đây là merchant, không phải “widget”. Thứ hai, đưa các giá trị quan trọng vào biến môi trường — trong các mô‑đun về triển khai và môi trường, chúng ta sẽ còn nhắc lại vì sao không nên hard‑code những thứ như vậy.

Để tiện, có thể thêm một hàm đơn giản báo cho mã của chúng ta biết có thể dùng Instant Checkout lúc này hay không:

// lib/merchantConfig.ts
export function canUseInstantCheckout(cfg: MerchantConfig) {
  // Trên dev và staging luôn tắt Instant Checkout
  if (process.env.NODE_ENV !== "production") return false;
  return cfg.instantCheckoutEnabled;
}

Bằng cách này, chúng ta chuẩn bị trước cho kiến trúc rằng ở các môi trường khác nhau hành vi sẽ khác nhau, và không để bản thân (và GPT) vô tình đi vào checkout thật từ môi trường thử nghiệm.

MCP‑tool để lấy thông tin về merchant

Thường tiện khi cho mô hình và widget khả năng biết merchant đang chạy ở chế độ nào. Ví dụ, để GPT không đề xuất Instant Checkout nếu nó đang tắt.

Trong MCP‑server (chúng ta đã dựng ở các mô‑đun trước), có thể tạo một công cụ đơn giản:

// mcp/tools/merchant.ts
import { giftGeniusMerchant, canUseInstantCheckout } from "../lib/merchantConfig";

export const getMerchantInfoTool = {
  name: "get_merchant_info",
  description: "Trả về thông tin cơ bản về merchant GiftGenius",
  inputSchema: { type: "object", properties: {}, additionalProperties: false },
  async handler() {
    return {
      id: giftGeniusMerchant.id,
      name: giftGeniusMerchant.name,
      instantCheckout: canUseInstantCheckout(giftGeniusMerchant),
    };
  },
};

Công cụ này không làm gì ghê gớm, nhưng tạo một nơi rõ ràng để mô hình có thể hỏi: “Hiện có thể mua ngay trong chat hay chỉ chuyển qua liên kết?”.

Sử dụng thông tin merchant trong widget

Ở phía widget, dùng các hook của Apps SDK mà chúng ta đã quen, có thể gọi get_merchant_info và thay đổi UI tùy theo chế độ. Ví dụ component đơn giản:

// components/MerchantBadge.tsx
"use client";

import { useEffect, useState } from "react";
import { useCallTool } from "../lib/use-call-tool";

type MerchantInfo = { name: string; instantCheckout: boolean };

export function MerchantBadge() {
  const callTool = useCallTool();
  const [info, setInfo] = useState<MerchantInfo | null>(null);

  useEffect(() => {
    callTool("get_merchant_info", {}).then((res) => {
      setInfo(res?.result as MerchantInfo);
    });
  }, [callTool]);

  if (!info) return null;
  return (
    <span>
      {info.name} · {info.instantCheckout ? "Instant Checkout" : "Discovery only"}
    </span>
  );
}

Một component nhỏ như vậy nhấn mạnh rõ ràng cho người dùng (và cho chính bạn ở chế độ dev) trạng thái tích hợp với ChatGPT hiện tại.

6. Bài tập nhỏ thực hành

Để bài giảng không chỉ ở mức “lời nói và sơ đồ”, hãy thử thực hiện các bước sau trong dự án GiftGenius của bạn (hoặc tương tự):

Thứ nhất, thêm module cấu hình merchant giống merchantConfig.ts, và đưa MERCHANT_ID và PRODUCT_FEED_URL vào biến môi trường. Với phát triển local, có thể dùng .env.local, còn production — dùng thiết lập của Vercel hoặc nền tảng khác.

Thứ hai, hiện thực trong MCP‑server một công cụ đơn giản get_merchant_info trả về ít nhất name và instantCheckout. Nghĩ xem còn những trường nào có thể hữu ích cho mô hình: ví dụ danh sách loại tiền tệ được hỗ trợ hoặc quốc gia giao hàng.

Thứ ba, thêm vào widget một phần tử UI nhỏ (badge, dòng trạng thái, chú thích trên thẻ sản phẩm) dùng tool này và hiển thị cho người dùng biết merchant của bạn đang chạy chế độ nào: chỉ gợi ý hay đã có Instant Checkout đầy đủ. Điều này không chỉ tốt cho UX, mà còn rất hữu ích cho việc gỡ lỗi.

Cuối cùng, thử viết ra bằng chữ các bước mà dự án cụ thể của bạn sẽ đi từ “chúng ta có website và backend” đến trạng thái ChatGPT‑merchant. Bạn sẽ kết nối Product Feed ở đâu, khi nào bật enable_checkout, khi nào bắt đầu hiện thực các endpoint ACP. Bài tập như vậy rất kỷ luật và giúp không quên các thứ ít được ưa thích như chính sách hoàn trả.

7. Lỗi thường gặp trên đường trở thành ChatGPT‑merchant

Lỗi №1: “ChatGPT chính là cửa hàng của tôi”.
Đôi khi lập trình viên “chuyển” mọi thứ sang phía ChatGPT trong suy nghĩ: như thể nó lưu catalog, tính giá và thực thi đơn hàng. Thực tế, ChatGPT là giao diện và bộ điều phối, chứ không phải ERP của bạn. Nếu quên điều này, rất dễ xây một kiến trúc không có mô hình đơn hàng riêng đàng hoàng, mọi dữ liệu sống “đâu đó trong prompt”, và bất kỳ thay đổi nào trong hành vi mô hình cũng đe dọa tính nhất quán.

Lỗi №2: trông đợi Instant Checkout mà không có đăng ký riêng và ACP.
Việc bạn viết một widget tuyệt vời và cấu hình Product Feed chưa tự động bật Instant Checkout. Cần có đơn đăng ký trong cổng Merchants, kiểm duyệt danh mục, hiện thực Agentic Checkout và Delegated Payment, vượt qua bài test. Cố giả định có Instant Checkout “mặc định” thường kết thúc bằng việc GPT bắt đầu đề xuất cho người dùng những thứ thực ra chưa có, hoặc đưa link thay vì màn hình thanh toán như kỳ vọng.

Lỗi №3: hard‑code cứng định danh và URL của merchant.
Một câu chuyện kinh điển: MERCHANT_ID = "prod-123" được viết thẳng trong mã, URL feed — là chuỗi trong component widget. Ngay khi bạn có staging hoặc cần tạo merchant thứ hai, sẽ bắt đầu cuộc săn‑và‑thay thế hàng loạt. An toàn hơn nhiều là đưa các thứ như vậy vào cấu hình và biến môi trường, rồi dùng qua một lớp trừu tượng nhỏ, như ta đã làm với MerchantConfig.

Lỗi №4: Product Feed “sống đời riêng”, không liên kết với đơn hàng.
Nếu trong feed SKU GIFT_RED_MUG là 10 USD, còn trong cơ sở dữ liệu đơn hàng cho đúng định danh đó bạn vì lý do nào đó lại thu 12 USD, sớm hay muộn điều đó sẽ lộ ra. Nguồn sự thật về giá và tồn kho phải là feed được tổng hợp từ dữ liệu nội bộ của bạn, hoặc một lớp chung mà cả feed và checkout cùng tin cậy. Cố gắng duy trì “kế toán kép” (một cho ChatGPT, một cho website của mình) sẽ rất nhanh mang lại rắc rối.

Lỗi №5: bỏ qua vai trò của nhà cung cấp thanh toán và việc lưu trữ dữ liệu thanh toán.
Đôi khi có cám dỗ “nhìn trộm” vào token của nhà cung cấp thanh toán hoặc thậm chí yêu cầu thêm thông tin thanh toán từ người dùng trong UI của bạn. Điều này không chỉ vi phạm mô hình Delegated Payment, mà còn có thể kéo bạn vào thế giới PCI DSS và tuân thủ nặng nề. Thực hành đúng — coi Shared Payment Token như một chuỗi không trong suốt, chỉ dùng nó trong SDK của nhà cung cấp thanh toán và không log hay cache ở đâu cả.

Lỗi №6: đánh giá thấp tính nhiều bước của onboarding và thiếu kế hoạch.
Cuối cùng, một lỗi tổ chức phổ biến — nghĩ rằng “chúng ta chỉ cần kết nối với ChatGPT, có gì đâu khó”. Thực tế hành trình của merchant gồm nhiều bước: kỹ thuật (feed, backend, test) và phi kỹ thuật (tài liệu pháp lý, duyệt danh mục, hạn chế vùng). Nếu không viết kế hoạch từ trước, đội sẽ nhảy lung tung giữa các nhiệm vụ và deadline sẽ “tan chảy” nhanh hơn cả cảm hứng của bạn với AI‑commerce.