Agentic Commerce 2026: Khi AI Agent Tự Thanh Toán

Posted on: 5/28/2026 1:13:06 AM

Bạn nhắn cho một AI agent: "Mua giúp tôi đôi giày chạy bộ màu trắng dưới 2 triệu, giao trong tuần này". Vài giây sau, agent đã so sánh giá ở năm cửa hàng, chọn được mẫu phù hợp, và… bấm thanh toán. Nghe thì mượt, nhưng đằng sau câu lệnh đó là một câu hỏi nặng ký mà cả ngành đang phải trả lời gấp trong năm 2026: khi một con bot tự quẹt thẻ của bạn, ai chịu trách nhiệm nếu nó mua sai?

Đây chính là khoảng trống mà Agentic Commerce — thương mại do agent thực hiện — đang lấp đầy. Bài viết này mổ xẻ tầng giao thức mới ra đời để AI agent có thể thanh toán một cách an toàn, có thể kiểm chứng và quy được trách nhiệm: AP2 của Google, ACP của OpenAI & Stripe, và UCP hợp nhất chuỗi mua sắm. Nếu bạn từng đọc về MCP như giao thức kết nối agent với công cụ, hãy coi đây là mảnh ghép còn thiếu: giao thức kết nối agent với tiền.

1. Vì sao agent biết gọi tool vẫn chưa biết tiêu tiền

Năm 2024–2025, ngành AI đã giải xong hai bài toán kết nối lớn. MCP (Model Context Protocol) cho phép agent đọc dữ liệu và gọi công cụ. A2A (Agent2Agent) cho phép các agent nói chuyện với nhau. Nhưng cả hai đều dừng lại ngay trước cánh cửa cuối cùng: khoảnh khắc tiền thật rời khỏi tài khoản của bạn.

Hệ thống thanh toán hiện tại được thiết kế trên một giả định ngầm tồn tại suốt 60 năm: có một con người đang ngồi sau giao dịch — gõ số thẻ, nhìn màn hình OTP, bấm "Xác nhận". Khi chủ thể khởi tạo giao dịch là một AI agent chạy lúc 3 giờ sáng, giả định đó sụp đổ. Ngân hàng không có cách nào phân biệt giữa "agent được chủ nhân ủy quyền hợp lệ" và "agent bị prompt injection lừa mua nhầm".

flowchart TB
    U["Người dùng"] --> AG["AI Agent"]
    subgraph STACK["Ngăn xếp giao thức cho agent"]
        direction TB
        MCP["MCP
agent ↔ công cụ & dữ liệu"]
        A2A["A2A
agent ↔ agent"]
        AP2["AP2 / ACP / UCP
agent ↔ thanh toán & merchant"]
    end
    AG --> MCP
    AG --> A2A
    AG --> AP2
    AP2 --> PAY["Mạng thanh toán
Visa / Mastercard / Stripe"]
    style AP2 fill:#e94560,stroke:#fff,color:#fff
    style MCP fill:#f8f9fa,stroke:#e94560,color:#2c3e50
    style A2A fill:#f8f9fa,stroke:#e94560,color:#2c3e50
    style PAY fill:#16213e,stroke:#fff,color:#fff

2. Bài toán 3A: Ủy quyền, Xác thực, Quy trách nhiệm

Mọi giao thức Agentic Commerce đều xoay quanh việc giải ba câu hỏi mà tôi gọi là bài toán 3A:

Điểm tinh tế: ba câu hỏi này không thể giải bằng cách "tin tưởng agent". Một agent là phần mềm xác suất, có thể bị prompt injection, có thể hiểu sai ý định. Lời giải của cả ngành hội tụ về một ý tưởng kinh điển trong bảo mật: không tin chủ thể, hãy tin bằng chứng ký số (cryptographic proof). Thay vì hỏi "agent này có đáng tin không", hệ thống hỏi "agent này có cầm trong tay một mảnh giấy ủy quyền do đúng người dùng ký không".

3. AP2 — Chuỗi mandate ký số của Google

AP2 (Agent Payments Protocol) do Google công bố cùng Coinbase và hơn 60 tổ chức (Mastercard, Visa, PayPal, American Express…). Ý tưởng trung tâm của AP2 là mandate — một văn bản ủy quyền chống giả mạo, được người dùng ký số. AP2 chuỗi ba loại mandate lại với nhau, mỗi loại trả lời một phần của bài toán 3A.

sequenceDiagram
    participant U as Người dùng
    participant A as Shopping Agent
    participant M as Merchant
    participant N as Mạng thanh toán
    U->>A: "Tìm giày trắng dưới 2tr"
    A->>U: Yêu cầu ký Intent Mandate
    U-->>A: Intent Mandate (đã ký)
    Note over A: Agent tìm & dựng giỏ hàng
    A->>U: Trình giỏ hàng + giá cụ thể
    U-->>A: Cart Mandate (đã ký)
    A->>M: Gửi Cart Mandate
    M->>N: Payment Mandate (credential)
    N-->>M: Chấp thuận giao dịch
    M-->>U: Xác nhận đơn hàng

Ba mandate, ba lớp bằng chứng

• Intent Mandate — người dùng ủy quyền cho agent ý định mua: phạm vi, ngân sách, điều kiện ("giày trắng, dưới 2 triệu, giao trong tuần"). Đây là gốc của chuỗi tin cậy.
• Cart Mandate — người dùng phê duyệt một giỏ hàng cụ thể ở một mức giá cụ thể. Đây là bằng chứng "đúng món này, đúng giá này".
• Payment Mandate — credential dẫn xuất mà mạng thanh toán nhìn thấy, liên kết ý định – giỏ hàng – thanh toán thành một chuỗi không thể chối bỏ.

Về kỹ thuật, các mandate là tài liệu JSON-LD theo chuẩn W3C Verifiable Credentials (VC), ký bằng ECDSA trên đường cong P-256 (hoặc mạnh hơn) với hàm băm SHA-256 để đảm bảo toàn vẹn. Mỗi mandate là một mắt xích trong audit trail có thể kiểm chứng độc lập.

{
  "@context": ["https://www.w3.org/ns/credentials/v2"],
  "type": ["VerifiableCredential", "CartMandate"],
  "issuer": "did:example:user-anhtu",
  "issuanceDate": "2026-05-28T09:12:00Z",
  "credentialSubject": {
    "agent": "did:example:shopping-agent-01",
    "cart": {
      "item": "Giày chạy bộ trắng - Model X",
      "price": { "amount": 1890000, "currency": "VND" },
      "merchant": "did:example:shop-abc"
    },
    "constraints": { "maxAmount": 2000000, "deadline": "2026-06-01" }
  },
  "proof": {
    "type": "EcdsaSecp256r1Signature2019",
    "created": "2026-05-28T09:12:00Z",
    "proofValue": "z3FXQ...signature..."
  }
}

4. Human Present vs Human Not Present

AP2 phân biệt rạch ròi hai kịch bản, và đây là điểm khiến nó thực dụng:

flowchart LR
    subgraph HP["Human Present"]
        direction TB
        H1["User nêu ý định"] --> H2["Agent dựng giỏ"]
        H2 --> H3["User ký Cart Mandate
NGAY tại thời điểm mua"]
    end
    subgraph HN["Human Not Present"]
        direction TB
        N1["User ký Intent Mandate chi tiết
TRƯỚC, kèm luật giá & thời gian"] --> N2["Agent chờ điều kiện"]
        N2 --> N3["Đủ điều kiện → agent tự dựng Cart Mandate"]
    end
    style H3 fill:#e94560,stroke:#fff,color:#fff
    style N1 fill:#e94560,stroke:#fff,color:#fff

• Human Present — bạn đang ở đó. Ý định ban đầu được ghi vào Intent Mandate, rồi bạn ký Cart Mandate ngay khi agent trình giỏ hàng. Phù hợp mua sắm tương tác.
• Human Not Present — bạn ủy quyền trước: "Mua vé concert ngay khi mở bán, tối đa 3 triệu/vé". Bạn ký một Intent Mandate chi tiết với luật cụ thể; agent tự sinh Cart Mandate khi điều kiện thỏa. Đây là kịch bản "agent tự chủ thật sự" — và cũng là nơi rủi ro cao nhất, nên ràng buộc trong Intent Mandate phải chặt.

5. Các vai trò trong một giao dịch agentic

AP2 dùng kiến trúc dựa trên vai trò (role-based). Hiểu rõ ai làm gì giúp bạn thiết kế tích hợp đúng:

6. ACP & Instant Checkout của OpenAI + Stripe

Trong khi AP2 đi theo hướng "chuẩn mở, trung lập về nền tảng thanh toán", thì ACP (Agentic Commerce Protocol) do OpenAI bắt tay Stripe lại tập trung vào trải nghiệm: Instant Checkout ngay trong ChatGPT. Người dùng mua hàng trực tiếp trong cuộc hội thoại, không rời khỏi giao diện chat.

flowchart LR
    U["User trong ChatGPT"] --> C["Instant Checkout"]
    C --> S["Stripe
token hóa & xử lý"]
    S --> M["Merchant"]
    M --> C
    C -. "phí ~4% / giao dịch" .-> O["OpenAI"]
    style C fill:#e94560,stroke:#fff,color:#fff
    style S fill:#16213e,stroke:#fff,color:#fff

Điểm đáng chú ý về mặt kinh tế: đầu năm 2026, OpenAI áp phí giao dịch ~4% cho mỗi đơn được agent chốt thành công — một mô hình doanh thu mới, đặt nền tảng AI vào vị trí "kênh bán hàng" chứ không chỉ "trợ lý". Điều này làm dấy lên câu hỏi lớn cho merchant: khi agent trở thành lớp trung gian giữa bạn và khách, ai sở hữu mối quan hệ khách hàng?

7. UCP — Hợp nhất cả hành trình mua sắm

Tháng 1/2026 tại NRF, Google công bố UCP (Universal Commerce Protocol) — chuẩn web mở (hợp tác cùng Shopify) nhằm tạo khả năng tương tác giữa agent và hệ thống bán lẻ xuyên suốt hành trình: từ khám phá → thanh toán → hậu mãi. UCP không thay thế mà bao trùm: đặc tả của nó hỗ trợ transport REST và JSON-RPC, đồng thời tích hợp AP2 (thanh toán), A2A (agent-agent) và MCP (công cụ/dữ liệu).

8. So sánh AP2 vs ACP vs UCP

9. Rủi ro, tranh chấp và góc nhìn developer

Agentic Commerce mở ra bề mặt tấn công hoàn toàn mới. Vài rủi ro đáng lưu tâm:

• Prompt injection dẫn tới chi tiền — một trang web độc có thể nhúng chỉ thị ẩn lừa agent "mua thêm" hoặc đổi merchant. Đây là lý do Cart Mandate phải nằm trong ràng buộc của Intent Mandate, và vì sao tầng phòng thủ kiểu lethal trifecta trở nên sống còn khi agent chạm tới tiền.
• Tranh chấp (dispute) kiểu mới — chargeback truyền thống giả định con người bấm nút. Với agent, chuỗi mandate ký số trở thành bằng chứng phân định: ý định có hợp lệ không, giỏ có vượt ngân sách không.
• Over-authorization — Intent Mandate quá rộng ("mua bất cứ thứ gì bạn thấy hợp lý") là thảm họa chờ sẵn. Nguyên tắc least-privilege áp dụng nguyên xi: ràng buộc càng hẹp càng an toàn.

Về phía kiến trúc backend, một merchant muốn "agent-ready" cần ít nhất: (1) endpoint phơi bày catalog & giá theo dạng máy đọc được, (2) bộ xác minh Verifiable Credentials, (3) idempotency cho thanh toán để agent retry không gây double-charge — bài học cũ từ thiết kế payment gateway vẫn đúng, chỉ là người gọi giờ là bot.

10. Tương lai và lời kết

Agentic Commerce không phải là "thêm một nút mua hàng cho chatbot". Nó là việc tái thiết kế lớp tin cậy của thương mại điện tử cho một thế giới nơi chủ thể khởi tạo giao dịch không còn là con người. Bài học cốt lõi rất kỹ thuật và rất cũ: khi không thể tin chủ thể, hãy tin bằng chứng ký số có thể kiểm chứng và quy được trách nhiệm.

Với developer, đây là thời điểm để bắt đầu nghĩ về backend của mình theo hướng "machine-first": catalog máy đọc được, xác minh credential, idempotency chặt. Agent sẽ là một lớp khách hàng mới — và như mọi lớp khách hàng, nó cần một hợp đồng rõ ràng. Mandate ký số chính là hợp đồng đó.

Nguồn tham khảo

• Google Cloud — Announcing Agent Payments Protocol (AP2)
• AP2 Protocol — Official Specification
• Wikipedia — Agentic commerce (UCP, governance frameworks)
• Charle — Agentic Commerce: The Complete 2026 Guide
• Vellum — Google's AP2: A new protocol for AI agent payments