Coinbase đưa x402 lên trung lập Stripe đặt cược hai bên ngoài MPP

Tác giả: Charlie Liu, Đối tác của Generative Ventures

Bạn bè gần đây quan tâm đến agentic commerce ngày càng nhiều, nhưng mọi loại giao thức và người chơi cũng khiến mọi người càng ngày càng khó nắm bắt được đầu đuôi.

Đặc biệt là tuần trước, mọi người còn đang bận tìm hiểu MPP của Stripe / Tempo, vậy mà chỉ trong chớp mắt, Stripe lại tham gia x402 Foundation của “đối thủ” Coinbase.

Hơn nữa, Cloudflare hiện tại hỗ trợ cả hai bộ. Google cũng đang nằm trong cuộc này, nhưng nó lại tự có AP2 và UCP.

Visa và Mastercard cũng đã vào, nhưng rõ ràng chúng không phải đến để “bảo trợ” cho stablecoin.

Linux Foundation công khai định nghĩa x402 là một “bệ phóng” trung lập, quản trị theo mô hình “ngành cùng cai trị”; còn Cloudflare thì khẳng định đưa đồng thời x402 và MPP vào Agents SDK của họ, và Stripe cũng công khai viết rằng họ hỗ trợ đồng thời MPP và x402.

Rốt cuộc là đang cạnh tranh ai với ai, và ai với ai đang chồng lấn lên nhau?

Nhưng mấy ngày nay tôi càng xem càng thấy rằng cái gọi là “hỗn loạn” này không phải vì thị trường không có hướng, mà bởi vì thị trường đã rất rõ ràng; và cũng giống như tôi đã từng đề cập: từ ngày đầu, câu chuyện này sẽ không do một giao thức nào đó tự thống nhất tất cả.

Nó giống như một kiểu cục diện rất thường gặp trong hạ tầng internet—các lớp khác nhau cùng “lớn lên”, các công ty khác nhau đặt cược ở những lớp khác nhau, và cuối cùng mọi thứ chạy được nhờ tính tương tác (interoperability).

Câu chuyện chiến lược thực sự là: ai sẽ định nghĩa lớp điều khiển mặc định cho paid machine access trên agentic web; và các bên chơi quan trọng rõ ràng đều đang multi-home, vì ai cũng đang cược rằng “cổ chai” thực sự trong tương lai sẽ rơi vào cấp phép, phân phối hay thanh toán.

I. Vì sao Coinbase lại buông tay giao x402 Foundation cho Linux?

Nếu x402 chỉ là giao thức của Coinbase, thì rất khó để nó trở thành lựa chọn mặc định của ngành.

Đây không phải một câu nói theo kiểu “chính trị đúng”, mà là một logic chuẩn hóa rất thực tế.

Lần này Linux Foundation diễn đạt rất rõ ràng: họ nhấn mạnh trung lập của nhà cung cấp dịch vụ, quản trị cộng đồng, hạ tầng dùng chung, chứ không phải kiểu “một công ty nào đó công bố thêm tính năng mới cho sản phẩm”.

Quan trọng hơn, trang x402 Foundation hiện còn ghi rằng dự án đang trong giai đoạn hình thành, cơ chế quản trị và hội đồng quản trị cũng vẫn đang được xây dựng.

Tức là, lần hành động này trước hết không phải tuyên bố “sản phẩm đã chín muồi”, mà là tuyên bố “chúng tôi sẽ tạo một ngôi nhà trung lập cho giao thức này”.

Hàm ý phía sau thực ra rất đơn giản.

Nếu x402 vẫn mang mãi khuôn mặt của một tính năng sản phẩm Coinbase (ví dụ như Base hiện tại), thì dù các nhà cung cấp cloud, công ty thanh toán, tổ chức thẻ và các bên chơi kiểu nền tảng có về mặt kỹ thuật sẵn sàng kết nối, họ vẫn sẽ do dự về mặt chính trị.

Ai cũng không muốn giao lớp paid access trong tương lai cho một nền tảng duy nhất. Đặt nó dưới Linux Foundation không phải vì Coinbase không muốn kiểm soát—mà ngược lại, vì họ quá muốn x402 được áp dụng rộng rãi, nên buộc phải trước tiên gỡ bỏ cái gánh “đây là giao thức của Coinbase”.

Điểm này thực sự quan trọng, vì nhiều người khi nhìn các hành động kiểu “thành lập foundation”, dễ chỉ xem như PR hoặc tư thế mở mã nguồn.

Nhưng trong cuộc chiến giao thức, quản trị chính là một phần của sản phẩm.

Đặc biệt khi một tiêu chuẩn vẫn còn giai đoạn sớm và chưa có hiệu ứng mạng tuyệt đối, cái gọi là “trung lập, đáng tin” chẳng kém gì sự thanh lịch về mặt kỹ thuật.

Ngược lại, nếu tương lai x402 thật sự có thể trở thành một baseline paid access kiểu “HTTP-native”, có lẽ không phải vì mã của nó đẹp nhất, mà vì** nó sớm hơn các phương án khác trong việc hạ chi phí chính trị.**

Nói cách khác, ở đây quản trị không phải vai phụ; quản trị chính là động cơ tăng trưởng.

II. Cuộc “song kiếm hợp bích” của Stripe rốt cuộc đang làm gì?

Trong lần này, người đáng chú ý nhất tuyệt đối là Stripe, vì các hành động của Stripe dễ gây bối rối nhất cho người khác.

Một mặt, họ ngày 18 tháng 3 công khai tung MPP, đóng gói nó thành một tiêu chuẩn mở cho thanh toán bằng máy.

Mặt khác, họ lại là founding contributor của x402 Foundation, và tài liệu riêng của họ cũng đang hỗ trợ x402 machine payments.

Tài liệu của Cloudflare còn trực diện hơn, thậm chí ghi rõ rằng: MPP đối với quy trình thanh toán cốt lõi của x402 là backward-compatible, và MPP client có thể trực tiếp tiêu thụ các dịch vụ x402 hiện có.

Nếu chỉ nhìn theo khung “cạnh tranh giao thức”, Stripe trông như đang “đánh hai hướng”.

Nhưng nếu bạn nâng góc nhìn lên một chút nữa, cách làm này lại có logic kinh doanh rõ ràng hơn.

Bởi vì Stripe thật sự muốn giữ không nhất thiết chỉ là bản thân 402 handshake.

Thứ họ muốn giữ là vài lớp nằm trên handshake: credentials, compliance, risk, reporting, tax, refunds, merchant integration.

Stripe có vẻ không giống một người thực sự tin vào duy nhất một giao thức; nó giống hơn là đang đảm bảo rằng—dù handshake tiêu chuẩn nào cuối cùng thắng—Stripe vẫn là lớp trừu tượng mặc định của agent payments.

Hỗ trợ x402 là để không bị vắng mặt trong hệ sinh thái mở; tự đẩy MPP là để tham gia định nghĩa ngữ nghĩa nền tảng; và đẩy thêm ACP cùng Shared Payment Tokens phía trên nữa là để giữ phần giá trị dày hơn ở lớp workflow và chứng từ thanh toán.

Vì vậy, chỗ “lạ” nhất trong lần này của Stripe—thực ra lại chính là chỗ chân thành nhất.

Họ không hề giả vờ rằng tương lai sẽ sớm chỉ còn một giao thức. Họ đang dùng hành động nói với bạn: ít nhất ở giai đoạn này, không ai nên chỉ đặt cược một phía.

III. Thực ra đây là một câu chuyện về hạ tầng cơ bản B2B

Tôi càng ngày càng cảm thấy nhiều trang tin tức đang đặt trọng tâm sai chỗ.

Khi nhắc đến agent payments, điều dễ nghĩ nhất thường là bán lẻ: AI giúp bạn mua vé máy bay, đặt khách sạn, đặt đơn, và dẫn bạn đi qua checkout.

Nhưng nếu nhìn vào những bối cảnh thật sự đã được triển khai công khai, và thực sự bắt đầu mang mùi hạ tầng, thì thứ chạy lên đầu tiên không phải là checkout bán lẻ, mà là paid access B2B—vừa vô vị hơn, vừa chân thực hơn: trả phí API, trả phí dữ liệu, trả phí công cụ, phiên hội thoại trình duyệt trả phí, và paid agent workflow.

Hiện nay Cloudflare công khai hỗ trợ thu phí nội dung HTTP, API và MCP tools bằng x402 và MPP.

Con đường áp dụng mạnh nhất của x402 nằm ở các paid APIs và tools theo mô hình developer-to-developer, vì “no account + pay-per-request” ở đây không phải chiêu trò, mà là một triển khai có thể vận hành thực sự.

Những thay đổi đằng sau điều này thực sự rất lớn.

Trước đây, nếu một API muốn thu phí, thường phải đi qua cả một quy trình “thân thiện với con người”: mở tài khoản, gắn billing, phát API key, đặt hạn mức, đối soát, rồi xử lý quyền thanh toán.

Với con người đã phiền rồi, với agent còn bực bội hơn.

Điểm khiến x402 hấp dẫn nhất không phải vì nó nhiều crypto hơn, cũng không phải vì nó nhiều AI hơn, mà vì nó cố gắng nhét “truy cập trả phí” trở lại chính bản thân HTTP, để việc kiểm soát lối vào và thương lượng thanh toán diễn ra như một request-response thông thường.

Server trả về 402, cho bạn biết yêu cầu này lần này đáng giá bao nhiêu; client thanh toán xong rồi dùng chứng từ thanh toán để thử lại chính yêu cầu đó.

Nếu bạn nhìn mô hình này từ góc độ phần mềm B2B và machine-to-machine access, nó sẽ “mượt” hơn nhiều so với khi nhìn từ góc bán lẻ.

Hơn nữa, càng nhìn về phía B2B thì lợi thế của x402 càng rõ ràng, và điểm yếu cũng không còn quá chí mạng.

Bởi trong consumer commerce, hoàn tiền, chargeback (từ chối thanh toán), merchant-of-record, consumer protection, trách nhiệm thuộc về ai—tất cả đều là bài toán hóc búa; nhưng trong B2B API và gọi công cụ thì mức độ quan trọng của các vấn đề này rõ ràng giảm đi đáng kể.

Ngược lại, “không cần tài khoản, trả phí theo lần gọi, nhận kết quả là đi” mới là nhu cầu thật.

Bán lẻ tất nhiên lớn hơn, náo nhiệt hơn, và dễ thu hút sự chú ý hơn; nhưng thứ thực sự định nghĩa hình dạng của giao thức, thường không phải là bối cảnh náo nhiệt nhất, mà là bối cảnh sớm lộ ra nhu cầu thật nhất.

Với agent payments của giai đoạn hiện tại, bối cảnh đó rất có thể không phải xe hàng, mà là paid access ngày càng nhiều giữa các phần mềm, giữa các agent, và giữa các workflow.

IV. Sự phát triển của ngành đã xác nhận phán đoán trước đó của tôi về interoperability

Phán đoán lõi nhất trong bài viết trước của tôi là interoperability.

Khi đó, phán đoán này nghe có phần như “đương nhiên theo kiến trúc thì phải như vậy”.

Giờ nhìn lại, nó ngày càng giống một ràng buộc thực tế, vì thị trường công khai đang dùng “bỏ phiếu bằng chân” (bằng hành động) của mình.

Cloudflare không đứng về bên nào cả, mà trực tiếp hỗ trợ đồng thời x402 và MPP, đồng thời cũng làm rõ việc hỗ trợ ánh xạ tương thích (compatibility mapping).

Google vừa tham gia x402, vừa tiếp tục thúc đẩy AP2 và UCP.

Visa và Mastercard cũng không dùng tư thế “all in one winner” để thể hiện chiến lược của mình; họ vừa tham gia x402, vừa tiếp tục gia tăng agent token, xác thực danh tính, kiểm tra lệnh (instruction validation) và dispute signals.

Cách các “đại gia” đặt cược đa phương là quyết định lý tính, chứ không phải sự giả dối trong kinh doanh.

Vì sao như vậy? Vì các giao thức này vốn dĩ không nằm cùng một lớp.

Ít nhất đến hiện tại, x402 và MPP gần hơn với lớp paid HTTP handshake, giải quyết vấn đề “làm sao để yêu cầu mang năng lực thanh toán trở lại”.

AP2 gần hơn với ủy quyền và ý định đáng tin cậy, giải quyết vấn đề “agent đó rốt cuộc có đủ tư cách để chi khoản tiền này hay không”.

UCP và ACP thì càng giống lớp workflow hơn, xử lý các vấn đề cấp cao hơn như discovery, checkout, quan hệ với merchant, chuyển giao chứng chỉ (credential).

Nhiều công ty hỗ trợ đồng thời x402, MPP, AP2, UCP không phải vì họ không tự hiểu rõ; mà vì kiến trúc để thắng cuộc rất có thể sẽ vượt qua nhiều lớp, thậm chí cần nhiều giao thức cùng hợp thành.

Vì vậy, nếu muốn dùng một câu để nhìn lại phán đoán của bài trước, hiện tại tôi càng tin rằng nếu không có interoperability thì hệ sinh thái này căn bản không thể hình thành.

Giờ thì thị trường đang chủ động xác nhận phán đoán đó.

Xa hơn một chút, phán đoán này cũng quan trọng cho B2B vs bán lẻ.

Bởi trong thế giới bán lẻ, có lẽ cuối cùng thật sự sẽ bị hút vào bởi một vài nền tảng lớn và một vài workflow lớn; nhưng trong thế giới B2B thì không như vậy.

Doanh nghiệp vốn sống trong một thực tế đa tồn tại: đa cloud, nhiều phương thức thanh toán, nhiều hệ thống workflow, nhiều hệ thống quyền hạn và danh tính.

Ai cố dùng một giao thức mới để “đập đổ và thay mới” toàn bộ stack doanh nghiệp, thì xác suất cao là sẽ chết trước.

Khách hàng B2B thực sự sẵn sàng chi tiền, thường không phải vì “duy nhất một giao thức đúng”, mà là vì “khả năng giúp hệ thống hiện tại vẫn hoạt động được trong môi trường đa giao thức”.

Logic này chính là interoperability trong ngữ cảnh doanh nghiệp “cứng” hơn một chút so với ngữ cảnh consumer.

V. Đây không phải chỉ là cạnh tranh giao thức, mà là cạnh tranh stack sau khi phân tầng

Một khi bạn hiểu chuyện này như một stack phân tầng, rất nhiều hiện tượng trước đây trông “loạn” sẽ ngay lập tức trở nên rõ ràng.

Lớp thấp nhất là paid access handshake.

Lớp này quan tâm: request HTTP diễn đạt “đây là thứ cần phải trả phí” như thế nào, và sau khi client thanh toán xong thì làm sao mang được chứng từ thanh toán trở lại.

x402 và MPP chủ yếu tranh nhau ở chỗ này. MPP đang cố “kéo” 402 về phía ngữ nghĩa HTTP auth trang trọng hơn; còn x402 lại giống như “phổ thông hóa” 402—thông qua header tùy chỉnh, facilitator, trừu tượng hóa thanh toán on-chain và tích hợp hệ sinh thái—để nó chạy được trước.

Một lộ trình đi theo hướng ngữ nghĩa chuẩn hóa; và một lộ trình đi theo hướng phân phối theo nền tảng.

Đi lên một lớp nữa là authority to spend—tức là “ai đã ủy quyền cho khoản tiền này”.

Chính lớp này mới là then chốt mà nhiều người hiện giờ chưa hoàn toàn nhận ra.

Máy móc trả tiền không khó lắm; khó ở chỗ máy móc được ủy quyền tin cậy để trả tiền một cách đáng tin.

AP2 quan trọng vì nó không chỉ là “cách thanh toán”, mà là đang xử lý những thứ như mandates, verifiable credentials, authenticity, accountability.

Những agent token, instruction validation, passkeys và dispute signals mà Visa và Mastercard gần đây tăng cường cũng về bản chất đều nằm ở đây.

Đi lên một lớp nữa nữa là workflow và distribution.

Tức là discovery, checkout, quan hệ merchant, credential sharing, và AI surface integration—những thứ gần với “ai nắm quyền kiểm soát lưu lượng và điều phối giao dịch”.

UCP và ACP giống như đang tranh giành lớp này.

Với B2B, lớp này trong ngắn hạn không quá sôi động, nhưng về dài hạn giá trị có thể rất cao.

Bởi nếu tương lai ngày càng nhiều phần mềm doanh nghiệp được agent điều phối, gọi, mua sắm và thanh toán, thì ai nắm workflow language sẽ không chỉ “quản một lần thanh toán”, mà là đang quản cả workflow.

Một khi bạn tách ba lớp này ra, bạn sẽ thấy một sự thật rất đơn giản: chẳng cần kỳ vọng một giao thức có thể “gói gọn” mọi vấn đề.

Con đường thực tế hơn là ba lớp này tự phát triển trước, rồi thông qua interoperability từ từ “khớp” lại với nhau.

Và cũng vì thế, việc đặt cược nhiều phía không phải do dao động, mà là quyết định lý tính.

VI. Rủi ro thực sự của x402—không nhất thiết là quy định, mà là kinh tế học trong điều kiện song song

Nếu chúng ta chỉ nhận ra “có nhiều giao thức cùng tồn tại”, thì vẫn chưa đủ sâu.

Rủi ro lớn nhất của x402 có lẽ không phải là quy định (regulation) ngay lập tức, mà có thể là “kinh tế học verify–settle” do việc tách thành hai bước gây ra, dẫn đến time-of-check/time-of-use.

Nói đơn giản: nếu việc xác minh thanh toán và việc thanh toán cuối cùng không phải là cùng một chuyện, thì trong môi trường internet thực như high concurrency, retry, lớp proxy, lớp cache, sẽ tồn tại “cửa sổ pay once, access multiple times”.

Hệ sinh thái x402 hiện cũng đang vá lỗ hổng, ví dụ settlement cache, idempotency extension, payment identifier, nhưng chính điều đó cho thấy vấn đề không phải chỉ là lý thuyết.

Vì sao điểm này đặc biệt đáng để độc giả B2B quan tâm?

Bởi thế giới B2B sợ nhất không phải là demo đẹp không làm được, mà là có quá nhiều edge case, cuối cùng đưa lên production là bắt đầu rò rỉ.

Chuyện API monetization nhìn bề ngoài thì giống như mỗi request chỉ trả vài xu, khá nhẹ; nhưng nếu sản phẩm của bạn là trả phí theo lần gọi, trả phí theo kết quả, trả phí theo workflow, thì “trả một lần lấy một lần” hay “trả một lần lấy nhiều lần” không còn là chi tiết sản phẩm, mà là ranh giới sống còn.

Vì vậy, nếu tương lai x402 thật sự chạy được trong B2B, một tiền đề quan trọng không phải là narrative, mà là các cơ chế default-safe này phải được làm đủ “ngớ ngẩn theo nghĩa không cần suy nghĩ” (vận hành an toàn mặc định), nếu không thì doanh nghiệp sẽ không yên tâm đưa lưu lượng thật vào.

VII. Giao thức có thể miễn phí, nhưng trạm thu phí sẽ không biến mất

Còn một điểm nữa, tôi nghĩ đáng để làm rõ trong bài này.

Nhiều giao thức mở cuối cùng đều đi đến một nơi rất quen thuộc: bản thân giao thức ngày càng rẻ hơn, thậm chí miễn phí, nhưng các trạm thu phí thực sự sẽ mọc lên ở bên cạnh.

x402 cũng giống như vậy.

Bản thân tiêu chuẩn tất nhiên nhấn mạnh tính mở, tính trung lập, và “0 fees built into the standard”, nhưng điều đó không đồng nghĩa với việc value capture sẽ biến mất.

Nếu x402 thành công, giá trị sẽ không nằm chủ yếu trong chính giao thức, mà sẽ dịch chuyển sang các lớp liền kề: facilitator, ví (wallet) và key management, discovery, policy engine, trust wrapper.

Điều này đặc biệt quan trọng với B2B.

Bởi khách hàng doanh nghiệp sẽ không vì một giao thức mới mà đại quy mô cải tạo toàn bộ hệ thống; thứ họ thật sự sẵn sàng trả tiền là: ai có thể giúp họ gom gọn những việc rắc rối trong môi trường đa giao thức như orchestration, policy, risk, compliance, audit, settlement, ranh giới quyền hạn.

Nói cách khác, giao thức sẽ ngày càng giống ngôn ngữ tầng thấp; nhưng khi dịch những ngôn ngữ đó thành năng lực “doanh nghiệp có thể yên tâm đưa vào vận hành”, thì lớp đó lại càng dễ trở thành nền tảng mới và trạm thu phí mới.

Đây cũng là lý do vì sao tôi nghĩ rằng khi nhìn x402 hôm nay, không thể chỉ chăm chăm xem ai giống “nhân vật chính” hơn: Coinbase, Cloudflare hay Stripe.

Thứ thực sự đáng để soi là: ai có cơ hội đứng ở những lớp liền kề đó nhiều nhất.

Cloudflare có vị trí ở rìa và phân phối lưu lượng; Stripe có vị trí về hạ tầng thanh toán và quan hệ với merchant; Visa và Mastercard có vị trí ở chứng chỉ (credentials), network token và consumer trust; Google có vị trí ở workflow và discovery surface.

Giá trị thực sự được nắm bắt không nhất định xảy ra ở chỗ “ai định nghĩa 402”, mà nhiều khả năng xảy ra ở chỗ “ai kết nối 402 vào hệ thống doanh nghiệp lớn hơn”.

VIII. Kết luận

Chuyện x402 Foundation không phải là công bố rằng x402 đã giành thắng lợi trong mọi giao thức agentic commerce.

Nó là một lời thừa nhận công khai rằng: ngay từ ngày đầu, thế hệ agent payments này sẽ không phải là thế giới chỉ có một giao thức.

Coinbase giao x402 cho Linux Foundation để nó giống một lớp công cộng trung lập hơn, chứ không phải sản phẩm độc quyền.

Stripe vừa đẩy MPP vừa tham gia x402 không phải do chần chừ, mà vì họ biết rằng hiện tại không nên chỉ đặt cược một phía.

Cloudflare hỗ trợ đồng thời hai bộ vì nó gần nhất với lưu lượng thật.

Các động thái của Google, Visa, Mastercard, Adyen… cũng đều cho thấy cùng một điều: trước tiên hãy để các hệ thống có thể liên thông, rồi hãy bàn xem cuối cùng ai sẽ chiếm lớp nào.

Và nếu chuyển góc nhìn ra khỏi bán lẻ, nhận định này còn trở nên suôn sẻ hơn.

Bởi thứ đầu tiên cần đến các giao thức này không nhất định là giỏ hàng (shopping cart), mà là ngày càng nhiều phần mềm và dịch vụ B2B tính phí theo lần gọi, theo nhiệm vụ, theo kết quả.

Bán lẻ tất nhiên lớn hơn, nhưng B2B thường sớm bộc lộ nhu cầu thật và cũng sớm định nghĩa “hạ tầng cuối cùng sẽ trông như thế nào”.

Trong bài viết trước, tôi đặt interoperability ở trung tâm; tôi nghĩ câu trả lời mà thị trường đang đưa ra hiện tại rất rõ ràng: đúng, và còn sớm hơn cả điều mà lúc đó tôi tưởng.

Theo ý nghĩa đó, x402 Foundation không phải là phần kết của câu chuyện này.

Nó chỉ giúp chúng ta nhìn thấy sớm hơn rằng: chủ đề thật sự của mọi thứ vẫn không phải “ai sẽ thắng”, mà là “thế giới này vốn được định sẵn phải liên thông trước”, và sau khi liên thông, ai sẽ chiếm được lớp đáng tiền nhất.