Hướng dẫn Agentic Checkout

Tóm tắt — Agentic checkout là phần “hãy mua giúp tôi” của mua sắm bằng AI. Khi trợ lý AI tìm sản phẩm và hoàn tất giao dịch thay bạn, bước giao dịch cuối cùng đó chính là agentic checkout. Trong luồng thanh toán ủy quyền của OpenAI, agent dùng token thanh toán có phạm vi thay cho số thẻ thô; gặp thao tác rủi ro như đăng nhập hay xác minh bổ sung, nó dừng và trao quyền lại cho con người. Đây là một phần của các giao thức lớn hơn (ACP và UCP), không phải sản phẩm độc lập.

Agentic checkout là gì

Phần lớn “mua sắm bằng AI” là khám phá: bạn yêu cầu trợ lý tìm một thứ, nó đọc nguồn cấp sản phẩm của merchant và đề xuất lựa chọn. Agentic checkout là bước tiếp theo — lúc agent thật sự tạo đơn hàng: chọn phương thức giao, tính thuế và phí vận chuyển, chuyển thanh toán rồi hoàn tất giao dịch.

Từ khóa là bước. Agentic checkout không phải sản phẩm hay công ty riêng. Đây là khả năng hoàn tất giao dịch được tích hợp trong hai tiêu chuẩn agentic commerce lớn: Agentic Commerce Protocol (ACP) của OpenAI và Stripe, cùng Universal Commerce Protocol (UCP) của Google và Shopify. Các bài viết liên quan trình bày tổng quan từng giao thức; bài này tập trung hoàn toàn vào cơ chế checkout.

Ba điều mọi người thường hiểu sai

• “AI mua hàng mà không có con người tham gia.” Không hẳn. Cả hai giao thức đều có bước “dừng và hỏi con người” cho đăng nhập, xác minh thẻ bổ sung hoặc xác nhận. Đặc tả không được xây dựng cho checkout hoàn toàn tự vận hành.
• “AI nhìn thấy thẻ tín dụng của tôi.” Không. Thanh toán được chuyển qua token có phạm vi — đại diện chỉ dùng cho một merchant, một số tiền, một cửa sổ thời gian và một lần. Số thẻ thô không bao giờ đến agent.
• “Điều này đã phổ biến; hầu hết cửa hàng đều có.” Cũng không. Giữa năm 2026, thị trường vẫn rất sớm: chỉ khoảng một tá cửa hàng Shopify từng chạy ChatGPT checkout trước khi OpenAI thu hẹp phiên bản hoàn toàn trong chat vào tháng 3 năm 2026.

Ai chịu trách nhiệm nếu có sự cố?

Cửa hàng bạn mua vẫn là cửa hàng — tức merchant of record. Họ xử lý đơn, hoàn tiền và tranh chấp như giao dịch trực tuyến thông thường. Phần thật sự phức tạp và chưa ai giải quyết đầy đủ là điều xảy ra với khoản chargeback khi “người mua” là agent AI. Phần Nâng cao đi sâu vào vấn đề này.

Muốn xem state machine thực tế, phạm vi token thanh toán, lúc con người phải can thiệp và những gì merchant cần kiểm thử trước khi bật? Hãy chuyển sang Nâng cao.

Tóm tắt — Agentic checkout là khả năng hoàn tất giao dịch của agentic commerce: tạo, cập nhật, hoàn tất/hủy checkout session, ủy quyền thanh toán và xác nhận đơn. Đây là một khối của ACP và một khả năng trong UCP, không phải giao thức độc lập. Trục kỹ thuật là state machine: ACP đưa session qua not_ready_for_payment → ready_for_payment → (requires_escalation / authentication_required khi cần) → completed, tương ứng với incomplete → requires_escalation → ready_for_complete của UCP. Trạng thái escalation là điểm nối có chủ đích cho con người. Ủy quyền thanh toán dùng token có phạm vi — khóa theo merchant, giới hạn số tiền, thời gian và một lần dùng — để agent không giữ thẻ thô. Xác nhận đơn là push: merchant POST webhook toàn object, ký HMAC. Merchant vẫn là merchant-of-record, nên settlement/refund/chargeback thuộc merchant và PSP; nhưng khuôn khổ bằng chứng chargeback vẫn chưa được giải quyết giữa năm 2026. Trước khi bật, hãy kiểm thử retry an toàn về idempotency, xác minh chữ ký webhook và mọi đường escalation.

Phạm vi: đây là bước giao dịch, không phải toàn bộ giao thức

Agentic checkout là một khả năng. Trong ACP, nó đúng nghĩa là khối Agentic Checkout — một trong năm khối cùng Product Feed, Delegate Payment, Delegate Authentication và Orders/Webhooks. Trong UCP, nó là khả năng checkout bên trong đặc tả rộng hơn có cơ chế thương lượng capability. Các bài về ACP và UCP trình bày giao thức và bối cảnh kinh doanh xung quanh như chất lượng nguồn cấp, profile /.well-known/ucp và tác động khám phá từ bước chuyển tháng 3 năm 2026. Bài này chỉ bàn cơ chế hoàn tất giao dịch: vòng đời session, ủy quyền thanh toán, điểm con người can thiệp, xác nhận đơn và trách nhiệm.

Một cách nhìn cần mang sang từ bài ACP mà không tranh luận lại: agent giao dịch với nguồn cấp và API, không phải HTML được crawl. Vì thế thứ cần tối ưu ở đây là độ tin cậy của checkout, không phải nội dung trang.

State machine của checkout session

Điểm khác biệt quan trọng nhất — và nhiều bài bỏ qua — là checkout là session có trạng thái, rồi trạng thái di chuyển qua một cỗ máy được xác định.

Tài liệu Checkout của ACP liệt kê đầy đủ enum: incomplete, not_ready_for_payment, requires_escalation, authentication_required, ready_for_payment, pending_approval, complete_in_progress, completed, canceled, in_progress, expired. Happy path ngắn: not_ready_for_payment → ready_for_payment → in_progress → completed, với canceled là trạng thái kết thúc còn lại. Theo khái niệm vòng đời ACP, việc cung cấp lựa chọn fulfillment bắt buộc chuyển session từ not_ready_for_payment sang ready_for_payment; thanh toán thất bại có thể đưa nó trở lại ready_for_payment để thử lại.

Những trạng thái thú vị nằm ngoài happy path:

• requires_escalation / authentication_required — agent không thể tự tiếp tục; cần con người hoặc bước xác minh bổ sung.
• pending_approval — chờ phê duyệt, chẳng hạn ký duyệt purchase order B2B.
• expired — session hết thời gian; CheckoutSession có trường expires_at.

Đây cũng là thiết kế nền tảng của checkout UCP: incomplete → requires_escalation → ready_for_complete, trong đó requires_escalation trao quyền lại cho con người qua continue_url. Hai giao thức riêng biệt cùng hội tụ một mẫu: checkout không phải lúc nào cũng hoàn tất nếu không dừng để hỏi con người. Đây không phải hạn chế gắn thêm mà là hình dạng cốt lõi của thiết kế.

Lưu ý thực tế cho người tích hợp ACP: yêu cầu sai định dạng trả object lỗi cấp HTTP với type là invalid_request, request_not_idempotent, processing_error hoặc service_unavailable. Nhưng vấn đề logic nghiệp vụ trong một session hợp lệ được trả dưới dạng MessageError trong mảng messages[], không phải lỗi HTTP. Bạn phải xử lý cả hai; chúng rất dễ bị nhầm trong giai đoạn tích hợp đầu.

Ủy quyền thanh toán hoạt động thế nào

Mục đích của tầng ủy quyền thanh toán là dữ liệu thẻ thô không bao giờ đến agent. Thay vì đưa số thẻ cho agent, thông tin thanh toán của người mua được chuyển thành token có phạm vi.

Theo đặc tả Delegated Payment của OpenAI, payload thanh toán ủy quyền được gửi thẳng đến PSP hoặc vault của merchant; PSP/vault trả một token thanh toán nằm ngoài phạm vi PCI và chỉ dành cho khoản thanh toán được ủy quyền. Token bị giới hạn trên bốn trục:

• reason — hiện là "one_time": chỉ dùng một lần.
• max_amount — giới hạn khoản thu ở tổng checkout; token không thể dùng để thu quá mức.
• expires_at (RFC 3339) — token có thời điểm hết hạn cứng.
• merchant_id + checkout_session_id — gắn với một merchant và một session.

Vì vậy token ủy quyền được khóa theo merchant, giới hạn số tiền, thời gian và một lần dùng. Cơ chế này cho phép agent “chi tiền” mà không được tin cậy với thông tin thẻ có thể tái sử dụng. Ở ACP, Shared Payment Token của Stripe được mô tả là triển khai đầu tiên tương thích Delegated Payment Spec; các PSP khác sẽ theo sau. UCP dùng mô hình tách rời tương tự, phân biệt payment instrument và handler.

Phạm vi PCI là quyết định thật. Đặc tả OpenAI nói rõ tích hợp trực tiếp với Delegated Payment Spec đồng nghĩa xử lý trực tiếp dữ liệu chủ thẻ, có thể ảnh hưởng phạm vi PCI và đòi hỏi PCI DSS Level 1. Với phần lớn merchant, đường token hóa — network token hoặc PSP xử lý ủy quyền — giúp dữ liệu chủ thẻ ở ngoài môi trường của họ. Lựa chọn “tự xử lý CHD” hay “để PSP token hóa” là quyết định kiến trúc đầu tiên; thẻ Quyết định hướng dẫn chi tiết.

Những lúc con người vẫn phải can thiệp

“Người mua vẫn phê duyệt” là đúng nhưng mơ hồ. Các trigger cấp giao thức rất cụ thể; gọi đúng tên giúp bạn thiết kế bàn giao thay vì gặp ngõ cụt im lặng:

• 3-D Secure / step-up. ACP mô hình hóa bằng InterventionCapabilities với loại hỗ trợ gồm 3ds, address_verification; mức enforcement là always / conditional / optional; và display_context là native / webview / modal / redirect. Kết quả step-up trở lại dưới dạng AuthenticationResult với giá trị như authenticated, denied, rejected, abandoned, canceled, not_supported.
• Trạng thái requires_escalation / authentication_required. Chúng nói rằng cần con người hoặc kiểm tra bổ sung trước khi session tiếp tục.
• approval_required cho B2B. Object PaymentData có các trường B2B purchase_order_number, payment_terms, due_date, approval_required; agentic checkout không chỉ dành cho DTC.
• Bàn giao continue_url của UCP. requires_escalation trong UCP đưa ra continue_url để người mua tự hoàn tất đăng nhập, xác nhận hoặc kiểm tra tuổi. Cùng điểm nối, khác giao thức.

Kết luận: giao dịch escalate rõ ràng tốt hơn nhiều giao dịch âm thầm đi vào ngõ cụt. Hãy thiết kế đường escalation như luồng hạng nhất, không phải trường hợp lỗi.

Xác nhận đơn là push, không phải pull

Một chi tiết nhiều bài đối thủ bỏ qua: sau mua hàng, nền tảng agent không ngồi poll API để hỏi trạng thái đơn. Merchant push webhook đã ký.

Theo tài liệu webhook ACP, merchant POST sự kiện đơn để nền tảng agent đồng bộ với sự thật cấp fulfillment. Hai loại sự kiện là order_create cho đơn mới và order_update cho thay đổi trạng thái. Trạng thái đơn được nêu gồm created, manual_review, confirmed, canceled, shipped, fulfilled. Ba chi tiết triển khai quan trọng:

• Yêu cầu phải được ký bằng chữ ký HMAC trong header Merchant-Signature. Yêu cầu thiếu hoặc sai chữ ký nhận 401.
• Trường data phải chứa toàn bộ object Order, không phải delta tăng dần. Mỗi lần gửi toàn trạng thái.
• Mã phản hồi cần xử lý: 200 thành công, 401 chữ ký không hợp lệ, 429 bị giới hạn tốc độ.

Vì vậy câu hỏi “nền tảng biết đơn hoàn tất thế nào?” có câu trả lời cụ thể: bạn báo cho nó bằng POST toàn object đã ký và xử lý back-pressure 429 từ nền tảng.

Gian lận, chargeback và trách nhiệm — phần nào đã rõ, phần nào chưa

Đây là phần cần trung thực và khác biệt nhất, nên tôi sẽ nêu thẳng ranh giới giữa điều “đã rõ” và “còn mở”.

Điều đã rõ: merchant of record. Đặc tả thanh toán của OpenAI nói OpenAI không phải merchant of record; trong ACP, merchant dùng PSP riêng, còn settlement, refund, chargeback và compliance vẫn thuộc merchant cùng PSP. Arjun Bhargava của Rye xác nhận độc lập rằng cả hai giao thức giữ merchant làm merchant of record, chịu trách nhiệm fulfillment, chargeback và dispute. Điều này nhất quán với cách trình bày ở hai bài giao thức liên quan; hãy kế thừa thay vì suy luận lại.

Điều chưa rõ: khuôn khổ bằng chứng chargeback. Merchant-of-record cho biết mặc định ai chịu tranh chấp, nhưng không cho biết cách thắng khi “khách hàng” được agent AI trung gian. Phòng vệ chargeback truyền thống dựa vào dấu vết do con người tạo: IP, thiết bị, hành vi duyệt, cú nhấp “mua”. Log ủy quyền do agent tạo là loại bằng chứng khác, trong khi quy tắc tranh chấp của mạng thẻ không được viết cho chúng. Chuyên gia gian lận Ben Herut của Chargeflow nói agentic commerce đem đến tầng gian lận và nhầm lẫn mới mà hệ thống cũ không thể diễn giải. Phân tích của Chargeflow nói thẳng hơn: chưa có câu trả lời rõ ràng; mạng thẻ, issuer và nền tảng đều đang xử lý câu hỏi này.

Các khuôn khổ mới chỉ đang hình thành, chưa hoàn tất. Trusted Agent Protocol của Visa được mô tả là khuôn khổ dựa trên tiêu chuẩn để merchant xác minh danh tính và ý định agent theo thời gian thực, ngăn giả mạo mà không làm giảm trải nghiệm. Agent Pay của Mastercard, công bố tháng 4 năm 2025, dùng “Agentic Tokens”, phần mở rộng của Digital Enablement Service. Theo nguồn thứ ba Fintech Wrap Up / Finextra, trách nhiệm của Mastercard được nói là theo quy tắc giao dịch token hóa chuẩn: issuer chịu trách nhiệm gian lận khi token được phát hành hợp lệ và được chấp nhận lúc authorization. Hãy xem phân bổ này là được thuật lại, chưa xác nhận cho đến khi có tài liệu chính thức Mastercard. Đồng thời, bảo đảm zero-liability cho người dùng của Visa bảo vệ chủ thẻ khỏi giao dịch trái phép; nó không giải quyết câu hỏi tranh chấp phía merchant. Đừng đánh đồng hai việc.

Merchant cần triển khai và kiểm thử gì

Nội dung hiện có đưa ra lời khuyên chiến lược như làm sạch nguồn cấp và chương trình loyalty. Đây là tầng vận hành — những gì thật sự phải xây và xác minh trước khi bật:

• Quyết định tư thế PCI. Đường token hóa/network token hay xử lý CHD trực tiếp (Level 1). Phần lớn merchant muốn PSP giữ phần ủy quyền.
• Làm retry an toàn về idempotency. ACP có loại lỗi request_not_idempotent vì agent hoặc mạng chập chờn sẽ thử lại lời gọi create/complete. Gửi idempotency key và làm lời gọi lặp cùng key an toàn để không thu tiền hay tạo đơn hai lần.
• Xác minh chữ ký webhook. Kiểm tra HMAC Merchant-Signature trên mọi webhook đơn đến, từ chối khi không khớp và xác nhận trả 200/429 đúng dưới tải.
• Mô phỏng đường escalation trong sandbox. Ép requires_escalation / authentication_required, chạy 3DS step-up và bảo đảm xử lý AuthenticationResult bao phủ denied/rejected/abandoned, không chỉ authenticated.
• Đối chiếu giá nguồn cấp/checkout. Agent thấy một giá trong feed nhưng checkout trả giá khác sẽ phá niềm tin rất nhanh.
• Thiết lập attribution cho đơn từ agent. Checkout hoàn tất có thể không kèm GA4 session. Theo dõi ở cấp đơn/OMS, đừng chờ lượt truy cập website.

Thẻ SOP Kiểm thử và Bảng tra nhanh biến danh sách này thành một lượt kiểm tra cụ thể.

Tình hình giữa năm 2026

Hãy bám vào thực tế áp dụng, không phải slide quảng bá. Chủ tịch Shopify Harley Finkelstein cho biết chỉ khoảng một tá merchant Shopify đang dùng công cụ AI checkout — không đáng kể so với tổng số merchant — và chính OpenAI thu hẹp Instant Checkout hoàn toàn trong chat thành khám phá rồi chuyển hướng vào tháng 3 năm 2026 sau khó khăn về onboarding, độ chính xác và giỏ nhiều sản phẩm. Leigh McKenzie của Semrush mô tả ma sát rất đúng: chuẩn hóa catalog thời gian thực cho hàng chục triệu SKU là bài toán quy mô thập kỷ mà Google đã giải bằng Merchant Center; người dùng vẫn mặc định chọn checkout họ tin như Apple Pay, Google Wallet và Amazon one-click.

Điều đó không có nghĩa agentic checkout chỉ là hứa hẹn. Khả năng giao thức — tạo/cập nhật/hoàn tất session bằng chương trình, thanh toán ủy quyền và webhook đơn đã ký — là thật, có đặc tả và đáng xây dựng. Chỉ là nó chưa “phổ biến”, và bước cuối hoàn tất trong chat hay trên website là chi tiết triển khai đã thay đổi một lần và có thể thay đổi tiếp.

Tóm tắt cho AI

Bản cô đọng của phần Nâng cao:

• Agentic checkout = bước hoàn tất giao dịch của agentic commerce: agent tạo, cập nhật, hoàn tất hoặc hủy checkout session thay người mua. Đây là một khối của ACP và một khả năng trong UCP, không phải giao thức độc lập.
• Đây là state machine. ACP: not_ready_for_payment → ready_for_payment → (requires_escalation/authentication_required) → completed, với canceled, expired, pending_approval ngoài happy path. Tương ứng UCP: incomplete → requires_escalation → ready_for_complete.
• Trạng thái escalation là điểm nối cho con người — đăng nhập, 3DS step-up, kiểm tra địa chỉ, approval_required B2B, continue_url UCP. Đặc tả không được xây dựng cho checkout hoàn toàn tự động, không con người.
• Thanh toán = token có phạm vi: khóa theo merchant (merchant_id + checkout_session_id), giới hạn số tiền (max_amount), thời gian (expires_at), một lần dùng (reason: one_time). Agent không giữ thẻ thô. Xử lý CHD trực tiếp ảnh hưởng phạm vi PCI (Level 1); đa số merchant dùng PSP/đường token hóa.
• Xác nhận đơn là push: merchant POST webhook toàn object đã ký HMAC (Merchant-Signature), dùng order_create/order_update, xử lý 200/401/429.
• Trách nhiệm: merchant vẫn là merchant-of-record; settlement/refund/chargeback thuộc merchant + PSP theo đặc tả OpenAI. Nhưng câu hỏi bằng chứng chargeback khi agent AI mua vẫn chưa được giải quyết giữa năm 2026. Visa TAP / Mastercard Agent Pay là khuôn khổ mới hình thành, chưa hoàn tất.
• Kiểm thử: retry an toàn về idempotency (request_not_idempotent), xác minh chữ ký webhook, đường escalation/3DS mô phỏng, giá feed/checkout nhất quán, attribution đơn từ agent không có GA4 session.
• Áp dụng còn sớm: khoảng một tá merchant Shopify từng hoạt động trước bước chuyển tháng 3 năm 2026 của OpenAI sang khám phá rồi chuyển hướng.

Tài liệu chính thức

Tài liệu nguồn sơ cấp về cơ chế checkout.

ACP — checkout, vòng đời, webhook

• Tài liệu tham chiếu ACP Checkout API — endpoint checkout session, đầy đủ enum trạng thái, trường CheckoutSession, object lỗi/MessageError, RiskSignals, AuthenticationResult, InterventionCapabilities.
• Vòng đời / khái niệm ACP Checkout — chuyển trạng thái: lựa chọn fulfillment → ready_for_payment; retry thanh toán thất bại.
• Webhook đơn ACP — order_create/order_update, yêu cầu HMAC Merchant-Signature, payload toàn object, mã phản hồi.
• Đặc tả ACP trên GitHub — OpenAPI/JSON Schema và phiên bản theo ngày.

OpenAI / Stripe — ủy quyền thanh toán

• Đặc tả OpenAI Delegated Payment — luồng token có phạm vi, object allowance (max_amount, expires_at, merchant_id, checkout_session_id, reason), lưu ý phạm vi PCI, ngôn ngữ merchant-of-record.
• Tài liệu OpenAI Commerce — tổng quan tích hợp merchant.
• Stripe — Agentic Commerce (ACP) — Shared Payment Token, triển khai tương thích Delegated Payment đầu tiên.
• Stripe — đặc tả giao thức ACP — xây endpoint checkout.

UCP (state machine checkout tương ứng)

• Google for Developers — hướng dẫn UCP — cách trình bày merchant-of-record và điều kiện đủ phía Google/Shopify.

Nền tảng / mạng thanh toán

• Shopify — yêu cầu Agentic Storefronts — Điều khoản bổ sung và trạng thái early access của Google AI Mode/Gemini tại thời điểm nghiên cứu.
• Visa — Agentic Commerce: Mối đe dọa và rủi ro — cách trình bày Trusted Agent Protocol.

Trích dẫn từ nguồn

Các phát biểu công khai về cách agentic checkout hoạt động và nơi còn câu hỏi mở. Deep link dẫn đến đoạn được trích khi trang nguồn hỗ trợ.

ACP / OpenAI — đặc tả

• “Merchant maintains full control over inventory, pricing, tax calculations, and payment processing.” (bản dịch) «Merchant giữ toàn quyền kiểm soát kho, giá, tính thuế và xử lý thanh toán.» — Tài liệu ACP Checkout API. Đi đến trích dẫn
• Enum trạng thái checkout, giữ nguyên văn: “incomplete not_ready_for_payment requires_escalation authentication_required ready_for_payment pending_approval complete_in_progress completed canceled in_progress expired.” (bản dịch) «Chuỗi gồm các trạng thái chưa hoàn thiện, chưa sẵn sàng thanh toán, cần chuyển cấp, cần xác thực, sẵn sàng thanh toán, chờ phê duyệt, đang hoàn tất, đã hoàn tất, đã hủy, đang xử lý và hết hạn.» — Tài liệu ACP Checkout API. Đi đến trích dẫn
• “OpenAI is not the merchant of record.” (bản dịch) «OpenAI không phải merchant of record.» Trong ACP, merchant dùng PSP riêng; settlement, refund, chargeback và compliance vẫn thuộc merchant cùng PSP. — Đặc tả OpenAI Delegated Payment. Đi đến trích dẫn
• Về luồng token: PSP hoặc vault trả một “payment token scoped to the delegated payment” (bản dịch) «token thanh toán có phạm vi giới hạn cho khoản thanh toán được ủy quyền», nằm ngoài phạm vi PCI. — Đặc tả OpenAI Delegated Payment. Đi đến trích dẫn

Tiếng nói trong ngành — câu hỏi trách nhiệm

• “Agentic commerce brings efficiency, but also a new layer of fraud and confusion that legacy systems cannot interpret.” (bản dịch) «Agentic commerce đem lại hiệu quả nhưng cũng tạo tầng gian lận và nhầm lẫn mới mà hệ thống cũ không thể diễn giải.» — Ben Herut, chuyên gia Fraud và Chargeback, Chargeflow. Đọc nguồn
• Về việc quy tắc đã rõ chưa, phân tích Chargeflow nói “there are no clean answers yet” (bản dịch) «chưa có câu trả lời rõ ràng»; mạng thẻ, issuer và nền tảng đều đang giải quyết. Đọc nguồn
• “Both protocols keep the merchant as the merchant of record — responsible for fulfillment, chargebacks, and disputes.” (bản dịch) «Cả hai giao thức giữ merchant làm merchant of record, chịu trách nhiệm fulfillment, chargeback và dispute.» — Arjun Bhargava, đồng sáng lập kiêm CEO Rye. Đọc nguồn

Mạng thanh toán — khuôn khổ mới hình thành

• Về cách tiếp cận của Visa: Trusted Agent Protocol là “a standards-based framework enabling merchants to verify agent identity and intent in real time, preventing impersonation without degrading user experience.” (bản dịch) «khuôn khổ dựa trên tiêu chuẩn giúp merchant xác minh danh tính và ý định agent theo thời gian thực, ngăn giả mạo mà không làm giảm trải nghiệm». — Visa, Agentic Commerce: Mối đe dọa và rủi ro. Đi đến trích dẫn

Thực tế áp dụng

• Về lý do checkout hoàn toàn tự động chậm hơn lời quảng bá: “Real-time catalog normalization across tens of millions of SKUs is a decade-scale problem Google already solved with Merchant Center, and consumers still default to checkout flows they trust—Apple Pay, Google Wallet, and Amazon one-click.” (bản dịch) «Chuẩn hóa catalog thời gian thực cho hàng chục triệu SKU là bài toán quy mô thập kỷ Google đã giải bằng Merchant Center; người dùng vẫn chọn các luồng checkout họ tin như Apple Pay, Google Wallet và Amazon one-click.» — Leigh McKenzie, Giám đốc Online Visibility tại Semrush, qua Search Engine Land. Đọc nguồn

Nên chọn đường tích hợp thanh toán nào?

Quyết định kiến trúc thật đầu tiên trong agentic checkout là cách ủy quyền thanh toán, vì nó trực tiếp quyết định phạm vi PCI và lượng công việc cần xây. Hãy đi theo cây quyết định:

Lượt kiểm thử trước khi ra mắt agentic checkout

Chạy trong chế độ sandbox/test trước khi bật agentic checkout ở production. Đây là tầng vận hành mà lời khuyên chiến lược “làm sạch nguồn cấp” bỏ qua.

1. Tạo checkout session và đi happy path. POST /checkout_sessions, xác nhận phản hồi 201 và session ở not_ready_for_payment hoặc incomplete. Thêm lựa chọn fulfillment; xác nhận chuyển sang ready_for_payment.
2. Xác minh tổng số là nguồn thẩm quyền. Kiểm tra totals[] của session (subtotal / tax / fulfillment / discounts / total) khớp backend và giá trong feed. Chênh giá feed/checkout phá niềm tin.
3. Hoàn tất session. POST /checkout_sessions/{id}/complete; xác nhận thanh toán xử lý, đơn được tạo và trạng thái thành completed.
4. Hủy session. POST /checkout_sessions/{id}/cancel; xác nhận trả kho để không giữ hàng bị rò rỉ.
5. Ép đường escalation. Mô phỏng requires_escalation / authentication_required. Chạy 3DS step-up và xác nhận xử lý AuthenticationResult bao phủ denied, rejected, abandoned, canceled, not_supported, không chỉ authenticated.
6. Kiểm thử idempotency. Gửi cùng yêu cầu create/complete hai lần với cùng key; xác nhận chỉ một đơn, và retry thật sự không idempotent trả request_not_idempotent thay vì thu hai lần.
7. Kiểm thử lỗi logic nghiệp vụ so với lỗi HTTP. Gây lỗi trong session như hết hàng, xác nhận nó xuất hiện dưới dạng MessageError trong messages[]; yêu cầu sai định dạng phải trả object lỗi cấp HTTP. Client phải xử lý cả hai.
8. Xác minh chữ ký webhook. Gửi webhook order_create hợp lệ, kiểm tra HMAC Merchant-Signature và trả 200. Gửi payload bị sửa và xác nhận từ chối 401. Phải gửi toàn object Order, không phải delta.
9. Kiểm thử back-pressure webhook. Xác nhận sender xử lý 429 bằng retry/backoff thay vì bỏ sự kiện.
10. Xác nhận ghi attribution. Đánh dấu đơn hoàn tất là từ agent ở cấp OMS vì không có GA4 session.

Lỗi thường gặp và cách làm đúng

Cho rằng “agentic checkout” là mua hoàn toàn tự động, không con người. Sai vì mọi triển khai đáng tin đều giữ điểm authorization/escalation: requires_escalation, authentication_required, 3DS step-up, approval_required B2B. Đặc tả và mạng thẻ hiện không coi tự chủ hoàn toàn thiếu human-in-the-loop authorization là thiết kế chuẩn. Nên làm: thiết kế continue_url, 3DS và approval như luồng hạng nhất để giao dịch cần người có thể escalate sạch thay vì đi vào ngõ cụt.

Coi điều này đã phổ biến vì tiêu đề báo chí ồn ào. Sai vì chỉ khoảng một tá merchant Shopify từng chạy ChatGPT checkout trước khi OpenAI thu hẹp phiên bản trong chat tháng 3 năm 2026. Nên làm: xây theo khả năng giao thức thật và đã đặc tả, nhưng lập kế hoạch như early adopter, không phải người chậm chân.

Tin rằng trách nhiệm gian lận đã giải quyết vì merchant-of-record đã rõ. Sai vì merchant-of-record được xác nhận cho settlement/refund/compliance, nhưng khuôn khổ bằng chứng chargeback — chứng minh giao dịch tranh chấp được ủy quyền khi người mua là agent AI — được chuyên gia mô tả là chưa giải quyết. Nên làm: lưu log ủy quyền agent và risk signal ngay bây giờ, coi Visa TAP/Mastercard Agent Pay là khuôn khổ đang hình thành, và không giả định bằng chứng phòng vệ chargeback hiện tại sẽ chuyển nguyên vẹn.

Cho rằng agent bỏ qua website nên checkout trên site không quan trọng. Sai vì “luôn bỏ qua website merchant” là thông điệp ban đầu của ChatGPT Instant Checkout, nhưng triển khai tiêu biểu ACP đã chuyển sang khám phá rồi chuyển hướng tháng 3 năm 2026. Khả năng giao thức không phụ thuộc cách triển khai. Nên làm: giữ checkout hosted vững và hỗ trợ luồng session bằng chương trình; bước hoàn tất có thể ở trong chat hoặc trên site tùy bề mặt.

Nghĩ agent xử lý số thẻ khách hàng. Sai vì dữ liệu thẻ thô không đến agent theo thiết kế; token có phạm vi/ủy quyền như Shared Payment Token và mô hình instrument/handler tách rời của UCP là toàn bộ mục đích tầng thanh toán. Nên làm: chuyển ủy quyền qua PSP để token khóa theo merchant, giới hạn số tiền, một lần dùng thực hiện công việc và giữ phạm vi PCI nhỏ.

Xử lý retry không idempotent. Sai vì agent và mạng đều retry. ACP có loại lỗi request_not_idempotent vì retry ngây thơ tạo đơn hoặc thu tiền hai lần. Nên làm: yêu cầu idempotency key khi create/complete và bảo đảm lời gọi lặp cùng key an toàn.

Bảng tra nhanh agentic checkout

Enum trạng thái checkout session ACP

State machine tương ứng của UCP: incomplete → requires_escalation (con người qua continue_url) → ready_for_complete.

Endpoint checkout (ACP)

• POST /checkout_sessions — tạo (201)
• GET /checkout_sessions/{id} — truy xuất
• POST /checkout_sessions/{id} — cập nhật
• POST /checkout_sessions/{id}/complete — xử lý thanh toán + tạo đơn
• POST /checkout_sessions/{id}/cancel — hủy + trả kho

Token thanh toán có phạm vi — bốn giới hạn

• merchant_id + checkout_session_id → khóa theo merchant và session
• max_amount → giới hạn số tiền
• expires_at (RFC 3339) → giới hạn thời gian
• reason: "one_time" → một lần dùng

Webhook đơn (ACP)

• Sự kiện: order_create, order_update
• Chữ ký: header HMAC Merchant-Signature bắt buộc
• Payload: toàn object Order, không phải delta
• Phản hồi: 200 thành công · 401 chữ ký xấu · 429 giới hạn tốc độ
• Trạng thái đơn: created · manual_review · confirmed · canceled · shipped · fulfilled

Trigger con người can thiệp

• Trạng thái requires_escalation / authentication_required
• InterventionCapabilities (3ds, address_verification; enforcement always/conditional/optional)
• Kết quả AuthenticationResult (authenticated/denied/rejected/abandoned/…)
• approval_required B2B; continue_url UCP

Trách nhiệm nhìn nhanh

• Merchant = merchant-of-record → settlement/refund/chargeback thuộc merchant + PSP ✅ đã rõ
• Quy tắc bằng chứng chargeback cho người mua là agent ⚠️ chưa giải quyết giữa năm 2026
• Visa TAP / Mastercard Agent Pay → khuôn khổ đang hình thành, chưa hoàn tất

Đoạn mã làm việc với agentic checkout

Các đoạn này dùng để kiểm tra và thử nghiệm tích hợp của chính bạn, không thực hiện mua hàng thật. Hãy dùng thông tin sandbox/test.

Xác minh chữ ký webhook (Node.js, HMAC)

Từ chối mọi yêu cầu có Merchant-Signature không khớp. So sánh theo thời gian không đổi.

import crypto from "node:crypto";

// secret = your shared webhook signing secret; rawBody = the exact bytes received
function verifyMerchantSignature(rawBody, signatureHeader, secret) {
  const expected = crypto
    .createHmac("sha256", secret)
    .update(rawBody)          // sign the raw body, not the parsed JSON
    .digest("hex");
  const a = Buffer.from(expected);
  const b = Buffer.from(signatureHeader || "");
  return a.length === b.length && crypto.timingSafeEqual(a, b);
}
// In your handler: if (!verify) return res.status(401).end();  // else 200

Poll trạng thái checkout session (shell)

Theo dõi session sandbox đi qua state machine khi kiểm thử.

# Retrieve a session and print just its status field (needs jq)
SESSION_ID="cs_test_123"
curl -s "https://api.example.com/checkout_sessions/$SESSION_ID" \
  -H "Authorization: Bearer $ACP_TEST_KEY" \
  | jq -r '.status'          # e.g. not_ready_for_payment → ready_for_payment → completed

Gửi lời gọi create với idempotency key (Python)

Chứng minh retry cùng key chỉ tạo một đơn, không phải hai.

import uuid, requests

key = str(uuid.uuid4())  # reuse this SAME key on retry
headers = {
    "Authorization": f"Bearer {ACP_TEST_KEY}",
    "Idempotency-Key": key,
    "Content-Type": "application/json",
}
payload = {"line_items": [{"id": "sku_1", "quantity": 1}]}
r1 = requests.post(f"{BASE}/checkout_sessions", json=payload, headers=headers)
r2 = requests.post(f"{BASE}/checkout_sessions", json=payload, headers=headers)  # retry
print(r1.json().get("id") == r2.json().get("id"))  # expect True — same session, no dupe

Đoạn Console — quét trang đã render để tìm profile UCP .well-known

Kiểm tra nhanh trong DevTools Console xem merchant có công bố khám phá UCP không; dán ở console trên origin của merchant:

fetch("/.well-known/ucp")
  .then(r => (console.log("status:", r.status), r.ok ? r.json() : null))
  .then(p => console.log("capabilities:", p && p.capabilities));

Bookmarklet — nhảy đến enum trạng thái checkout trong tài liệu ACP

Lưu đoạn này làm bookmark để mở tài liệu ACP Checkout ngay danh sách trạng thái:

javascript:location.href='https://www.agenticcommerce.dev/docs/reference/checkout#:~:text=incomplete';

Lỗi agentic checkout thường gặp

Retry tạo hai đơn hoặc thu tiền hai lần

Triệu chứng: cùng checkout session tạo đơn trùng sau timeout hoặc retry mạng. Nguyên nhân có thể: lời gọi create/complete không có key và không an toàn khi replay. Cách sửa: yêu cầu idempotency key, trả kết quả gốc cho retry cùng key và xác nhận hai lời gọi sandbox giống nhau chỉ tạo một session cùng một đơn.

Checkout không bao giờ sẵn sàng thanh toán

Triệu chứng: session vẫn ở not_ready_for_payment hoặc incomplete. Nguyên nhân có thể: lựa chọn fulfillment, trường địa chỉ hoặc rule nghiệp vụ bắt buộc chưa được giải quyết. Cách sửa: kiểm tra trường bắt buộc và messages[], cung cấp lựa chọn còn thiếu rồi xác nhận trạng thái thành ready_for_payment hoặc ready_for_complete.

Yêu cầu hợp lệ có vẻ thành công nhưng giỏ không thể hoàn tất

Triệu chứng: yêu cầu HTTP thành công trong khi session chứa lỗi hết hàng hoặc lỗi nghiệp vụ khác. Nguyên nhân có thể: client chỉ xử lý lỗi HTTP và bỏ qua MessageError. Cách sửa: xử lý cả lỗi truyền tải lẫn message session, rồi xác nhận người dùng hoặc agent thấy lỗi có thể hành động.

Xác minh con người âm thầm đi vào ngõ cụt

Triệu chứng: checkout vào requires_escalation hoặc authentication_required rồi không trở lại. Nguyên nhân có thể: bàn giao 3DS, đăng nhập, approval hoặc continue_url bị coi là lỗi ngoại lệ thay vì trạng thái được hỗ trợ. Cách sửa: giữ session qua bàn giao, xử lý mọi kết quả authentication và xác nhận cả luồng thành công lẫn từ bỏ kết thúc rõ ràng.

Trạng thái đơn ngừng cập nhật sau thanh toán

Triệu chứng: merchant có đơn nhưng bề mặt agent vẫn pending hoặc cũ. Nguyên nhân có thể: chữ ký webhook sai, chỉ gửi delta hoặc bỏ phản hồi 429. Cách sửa: ký đúng payload, gửi toàn object Order, retry sự kiện bị giới hạn với backoff và xác nhận receiver chấp nhận.

Mô hình tư duy cho agentic checkout

Checkout là state machine, không phải một lời gọi API

Mỗi phản hồi phải chuyển session sang trạng thái đã biết hoặc nêu lý do đã biết khiến nó không thể chuyển. Thiết kế client quanh transition, trạng thái kết thúc, retry và escalation thay vì một yêu cầu “mua” duy nhất.

Thẩm quyền vẫn thuộc merchant

Agent biểu đạt ý định, nhưng merchant vẫn là nguồn thẩm quyền về giá, kho, thuế, fulfillment, trạng thái đơn và nghĩa vụ merchant-of-record. Hãy coi giỏ agent yêu cầu là input, còn giỏ merchant trả về là sự thật.

Ủy quyền thu hẹp quyền hạn

Token thanh toán có phạm vi an toàn vì khóa theo merchant, gắn session, giới hạn số tiền, thời gian và một lần dùng. Đánh giá mọi khả năng được ủy quyền bằng cách hỏi nó làm được gì, cho ai, bao nhiêu và trong bao lâu.

Escalation là một nhánh thành công

Con người can thiệp không có nghĩa checkout tự động thất bại. Bàn giao 3DS, đăng nhập, địa chỉ hoặc phê duyệt B2B rõ ràng là giao thức hoạt động đúng thiết kế.

Giao nhận bất đồng bộ sau khi hoàn tất

Hoàn tất thanh toán không kết thúc tích hợp. Webhook toàn object đã ký mang sự thật về đơn sau checkout, nên xác minh chữ ký, an toàn replay và xử lý retry là một phần độ tin cậy checkout.

Chỉ số cho agentic checkout

Hoàn tất checkout theo trạng thái kết thúc

• Chỉ số: tỷ lệ session completed, canceled hoặc expired trên tổng session khởi tạo.
• Cho biết gì: state machine kết thúc ở đâu và bao nhiêu ý định mất trước khi có đơn.
• Cách lấy: tổng hợp thay đổi trạng thái checkout session từ commerce API hoặc nền tảng đơn, chia theo giao thức và bề mặt merchant.
• Mốc chuẩn / khoảng thực tế: tạo đường cơ sở cho cơ cấu sản phẩm của bạn và so sánh luồng tương đương; chưa thể bảo vệ một tỷ lệ chung ở giai đoạn áp dụng này.
• Tần suất: giám sát hằng ngày, xem xu hướng hằng tuần.

Tỷ lệ phục hồi sau escalation

• Chỉ số: phiên đã được chuyển cấp quay lại và hoàn tất sau xác thực 3-D Secure, đăng nhập, địa chỉ hoặc phê duyệt.
• Cho biết gì: bàn giao cho con người là đường dùng được hay ngõ cụt.
• Cách lấy: nối sự kiện chuyển cấp với lần đổi trạng thái sau đó bằng mã định danh phiên thanh toán.
• Mốc chuẩn / khoảng thực tế: lập đường cơ sở riêng cho từng loại can thiệp vì xác thực và phê duyệt B2B có ma sát khác nhau.
• Tần suất: hằng tuần và sau mọi thay đổi luồng bàn giao.

Tỷ lệ đơn trùng và webhook thất bại

• Chỉ số: đơn trùng từ retry cùng key cộng các lần gửi webhook bị từ chối hoặc hết retry.
• Cho biết gì: idempotency và đồng bộ đơn bất đồng bộ có an toàn khi lỗi không.
• Cách lấy: so sánh idempotency key, order ID, lỗi chữ ký, 401, 429, retry và dead-letter event trong log ứng dụng.
• Mốc chuẩn / khoảng thực tế: đơn trùng phải bằng không; thiết lập đường cơ sở retry thoáng qua bình thường và điều tra sai lệch kéo dài.
• Tần suất: cảnh báo ngay, tổng hợp hằng tuần.

Tài nguyên đáng xem

Bài viết liên quan của tôi

• Hai giao thức chứa agentic checkout được trình bày sâu trên website: Agentic Commerce Protocol (ACP) và Universal Commerce Protocol (UCP); bài này đi sâu cơ chế checkout nằm dưới cả hai.
• Hướng dẫn nhập môn SEO thương mại điện tử — checkout hướng agent nằm ở đâu trong bức tranh ecommerce.

Bài thuyết trình của tôi

• Cách Search hoạt động (SlideShare) — phần trình bày về khám phá, lập chỉ mục và xếp hạng; là bối cảnh hữu ích cho tầng giao dịch qua agent nằm phía trên. Tuyên bố miễn trừ thường trực: “This is my understanding of systems… not going to be 100% complete or accurate.” (bản dịch) «Đây là cách tôi hiểu các hệ thống… sẽ không đầy đủ hoặc chính xác 100%».

Nguồn trong ngành

• Agentic Commerce Protocol — tài liệu Checkout (OpenAI/Stripe) — enum trạng thái có thẩm quyền, trường session và object can thiệp/authentication.
• Đặc tả OpenAI Delegated Payment — luồng token có phạm vi cùng ngôn ngữ merchant-of-record / phạm vi PCI.
• Tài liệu webhook đơn ACP (OpenAI/Stripe) — cơ chế đồng bộ đơn push, ký HMAC, toàn object.
• Chargeback trong Agentic Commerce: Ai chịu trách nhiệm khi AI mua? (Chargeflow) — cách nhìn trung thực “chưa có câu trả lời rõ ràng” về bằng chứng.
• Agentic Commerce: Mối đe dọa và rủi ro (Visa) — Trusted Agent Protocol và cách nhìn danh tính agent.
• Kế hoạch ChatGPT Instant Checkout lớn của OpenAI vừa thay đổi (Search Engine Land) — bước chuyển tháng 3 năm 2026 và trích dẫn thực tế áp dụng.
• Agentic Checkout là gì? (Rye) — định nghĩa độc lập rõ và xác nhận merchant-of-record.
• Phân tích sâu: Mastercard Verifiable Intent so với Visa Trusted Agent Protocol (Fintech Wrap Up / Finextra) — so sánh khuôn khổ mạng thanh toán; coi phân bổ trách nhiệm cụ thể là được thuật lại, chưa xác nhận.

Số liệu đáng trích dẫn

Các con số định hình tình trạng thực của agentic checkout; hãy coi số merchant tự báo và số được thuật lại là định hướng, đồng thời xác minh trước khi dựa vào.

• Khoảng một tá merchant Shopify đang dùng công cụ AI checkout — được mô tả là không đáng kể so với toàn bộ merchant Shopify — theo chủ tịch Shopify, được Search Engine Land thuật lại khi đưa tin bước chuyển tháng 3 năm 2026. Nguồn
• Tháng 3 năm 2026: bước chuyển. OpenAI chuyển Instant Checkout của ChatGPT từ hoàn tất mua hàng trong chat sang khám phá rồi chuyển hướng sau ma sát onboarding, độ chính xác và giỏ nhiều sản phẩm. Nguồn
• Phạm vi token = 4 giới hạn. Token thanh toán ủy quyền bị giới hạn bởi max_amount, expires_at, merchant_id/checkout_session_id và reason: one_time; đây là cơ chế cụ thể giữ thẻ thô khỏi agent. Nguồn
• Quy tắc webhook: luôn toàn object. ACP yêu cầu trường data mang toàn object Order thay vì delta tăng dần, và mọi yêu cầu phải ký HMAC. Nguồn

Tự kiểm tra: Agentic Checkout

Năm câu hỏi nhanh về cơ chế checkout. Chọn đáp án rồi kiểm tra.

Nhật ký thay đổi