Coinbase mengusung x402 ke posisi netral Stripe bertaruh di luar MPP di kedua sisi

Penulis: Charlie Liu, Mitra Generative Ventures

Teman-teman yang belakangan ini saya lihat semakin banyak fokus pada agentic commerce, tetapi berbagai protokol dan para pemainnya juga semakin membuat semua orang bingung.

Terutama minggu lalu—orang-orang masih sibuk memahami Stripe / Tempo MPP, tapi seketika Stripe malah bergabung dengan x402 Foundation milik pesaing mereka, Coinbase.

Dan Cloudflare sekarang mendukung keduanya. Google juga ikut dalam permainan ini, tetapi mereka punya AP2 dan UCP sendiri.

Visa, Mastercard juga datang, tetapi jelas bukan untuk menjadi pendukung stablecoin.

Linux Foundation secara terbuka mendefinisikan x402 sebagai “markas” yang netral dan tata kelola industri yang dijalankan bersama. Cloudflare sendiri dengan tegas memasukkan x402 dan MPP sekaligus ke dalam Agents SDK mereka. Stripe juga secara terbuka menuliskan bahwa mereka mendukung MPP dan x402 sekaligus.

Pada akhirnya, siapa yang bersaing dengan siapa, dan siapa yang saling tumpang tindih?

Tapi makin saya lihat beberapa hari ini, justru saya makin merasa: kekacauan ini bukan karena pasar tidak punya arah, melainkan karena pasar sudah sangat jelas—dan seperti yang saya sebutkan sebelumnya: sejak hari pertama, urusan ini tidak akan disatukan oleh satu protokol saja sekaligus.

Lebih mirip satu skenario yang sangat umum dalam infrastruktur internet—lapisan yang berbeda sama-sama “tumbuh”, perusahaan yang berbeda menaruh taruhan di lapisan yang berbeda, dan pada akhirnya semuanya berjalan dulu berkat interoperabilitas.

Cerita strategi yang sesungguhnya adalah: siapa yang mendefinisikan default control layer untuk paid machine access di agentic web; dan para pemain kunci jelas berada dalam pola multi-home, karena semua orang masih bertaruh bahwa bottleneck nyata di masa depan akan jatuh pada otorisasi, distribusi, atau settlement.

I. Mengapa Coinbase melepas: menyerahkan x402 Foundation ke Linux?

Jika x402 hanya protokol Coinbase, maka ia sulit menjadi opsi default industri.

Ini bukan kalimat yang sekadar benar secara politik, melainkan logika standarisasi yang sangat realistis.

Linux Foundation kali ini sangat jelas dalam pernyataannya: yang mereka tekankan adalah netralitas penyedia layanan, tata kelola komunitas, dan infrastruktur bersama, bukan “sebuah perusahaan meluncurkan fitur produk baru”.

Yang lebih penting lagi: halaman x402 Foundation sekarang masih menuliskan bahwa proyek tersebut berada pada tahap dibangun; mekanisme tata kelola dan dewan direksinya juga masih sedang dirancang.

Artinya, langkah ini pertama-tama bukan mengumumkan “produknya sudah matang”, melainkan mengumumkan “kami akan memberikan protokol ini rumah yang netral”.

Di balik itu, maknanya sebenarnya sederhana.

Jika x402 terus “tumbuh” dengan wajah fungsi produk Coinbase (misalnya seperti Base saat ini), maka penyedia cloud, perusahaan pembayaran, organisasi kartu, dan pemain tipe platform—meski secara teknis bersedia mengintegrasikan—akan ragu secara politik.

Tidak ada yang mau menyerahkan masa depan paid access layer kepada satu platform saja. Meletakkannya di bawah Linux Foundation bukan karena Coinbase tidak ingin mengendalikan; justru karena Coinbase terlalu ingin x402 diadopsi secara luas, sehingga pertama-tama harus melepas beban bahwa “ini protokol milik Coinbase”.

Poin ini sebenarnya penting, karena banyak orang yang memandang aksi sejenis yayasan seperti ini akan mudah menganggapnya hanya sebagai PR atau sikap open-source.

Tapi dalam perang protokol, tata kelola adalah bagian dari produk.

Terutama ketika sebuah standar masih di fase awal dan belum punya efek jaringan yang mutlak, “netral dan dipercaya” tidak kalah pentingnya dibanding keindahan teknis.

Sebaliknya, jika suatu hari x402 benar-benar bisa menjadi semacam HTTP-native paid access baseline, kemungkinan besar bukan karena kodenya paling indah, melainkan karena lebih cepat menurunkan biaya politik dibanding skema lain.

Dengan kata lain, di sini tata kelola bukan pemeran pendukung; tata kelola itu sendiri adalah mesin pertumbuhan.

II. Apa sebenarnya yang dilakukan Stripe dalam “adu kiri-kanan” ini?

Pemain yang paling layak diperhatikan kali ini, pasti Stripe, karena aksi Stripe paling mudah membuat orang bingung.

Di satu sisi, pada 18 Maret mereka meluncurkan MPP secara gamblang dan membungkusnya sebagai standar terbuka untuk pembayaran mesin.

Di sisi lain, mereka juga adalah founding contributor x402 Foundation, dan dokumentasi mereka sendiri mendukung x402 machine payments.

Dokumen Cloudflare bahkan lebih langsung—sampai secara tegas menuliskan bahwa inti alur pembayaran MPP untuk x402 adalah backward-compatible, sehingga MPP client bisa langsung mengonsumsi layanan x402 yang sudah ada.

Jika hanya melihatnya lewat kerangka “persaingan protokol”, Stripe seperti sedang melakukan “adu kiri-kanan”.

Tapi jika kamu mengangkat sudut pandang sedikit lebih tinggi, justru ada logika bisnis.

Karena yang benar-benar ingin Stripe jaga, mungkin tidak hanya handshake 402 itu sendiri.

Yang ingin mereka amankan adalah beberapa lapisan di atas handshake: credentials, compliance, risk, reporting, tax, refunds, dan merchant integration.

Stripe tampaknya bukan penganut sejati dari satu protokol tertentu, melainkan memastikan bahwa apa pun standar handshake yang akhirnya menang, Stripe tetap menjadi lapisan abstraksi default untuk agent payments.

Mendukung x402 adalah agar tidak ketinggalan dari ekosistem terbuka; mendorong MPP adalah agar ikut mendefinisikan semantik dasar; lalu mendorong ACP dan Shared Payment Tokens di atasnya adalah untuk mempertahankan nilai yang lebih tebal pada lapisan workflow dan bukti pembayaran.

Jadi bagian paling “aneh” dari Stripe kali ini sebenarnya justru yang paling jujur.

Mereka tidak berpura-pura bahwa ke depannya akan segera tersisa hanya satu protokol. Mereka sedang memberi tahu lewat tindakanmu: setidaknya pada tahap ini, tidak ada yang seharusnya hanya bertaruh pada satu sisi saja.

III. Ini sebenarnya cerita infrastruktur B2B

Saya makin merasa banyak media menggeser fokus dari hal ini.

Saat orang membicarakan agent payments, yang paling mudah terbayang selalu ritel: AI bantu beli tiket pesawat, bantu pesan hotel, bantu melakukan pemesanan, bantu melewati checkout.

Tapi kalau kamu melihat skenario yang benar-benar sudah dipublikasikan dan benar-benar mulai berjalan saat ini—yang pertama kali hidup bukan checkout ritel, melainkan paid access B2B yang lebih membosankan sekaligus lebih nyata: paid API, paid data, paid tools, sesi browser berbayar, dan paid agent workflow.

Cloudflare sekarang secara terbuka mendukung penagihan untuk konten HTTP, API, dan MCP tools menggunakan x402 dan MPP.

Jalur adopsi terkuat x402 ada pada paid APIs dan tools developer-to-developer, karena “no account + pay-per-request” di sini bukan sekadar slogan—ini benar-benar bisa diimplementasikan.

Perubahan yang mendasarinya sebenarnya sangat besar.

Dulu, jika sebuah API ingin dipakai dengan model biaya, biasanya harus melewati serangkaian proses “ramah manusia”: buka akun, hubungkan billing, terbitkan API key, atur kuota, rekonsiliasi, lalu mengurus izin pembayaran.

Bagi manusia itu sudah cukup menyebalkan, apalagi untuk agent.

Bagian x402 yang paling menarik bukan karena lebih crypto, bukan juga karena lebih AI, melainkan karena ia mencoba memasukkan kembali “akses berbayar” ke dalam HTTP itu sendiri, sehingga kontrol akses dan negosiasi pembayaran terjadi seperti permintaan biasa request-response.

Server mengembalikan 402, memberi tahu berapa harga permintaan ini; lalu client membayar, kemudian mencoba ulang permintaan yang sama menggunakan bukti pembayaran.

Kalau model ini dilihat dari perspektif B2B software dan machine-to-machine access, ia jauh lebih mulus dibanding dilihat dari perspektif ritel.

Dan makin kamu bergerak ke sisi B2B, keunggulan x402 makin jelas, sementara kekurangannya tidak terasa sedramatis itu.

Karena di consumer commerce, refund, chargeback, merchant-of-record, consumer protection, dan penentuan tanggung jawab adalah masalah-masalah yang keras; tapi di pemanggilan API dan tool B2B, pentingnya masalah-masalah tersebut jelas menurun.

Sebaliknya, kebutuhan nyata adalah “tidak perlu akun, bayar per pemanggilan, dapat hasil lalu selesai.”

Ritel tentu lebih besar, lebih ramai, dan lebih mudah menarik perhatian; tetapi definisi seperti apa yang benar-benar menjadi protokol, biasanya bukan berasal dari skenario paling heboh, melainkan dari skenario yang paling awal memperlihatkan kebutuhan nyata.

Untuk gelombang agent payments saat ini, kemungkinannya skenario itu bukan keranjang belanja, melainkan paid access yang semakin banyak di antara software, di antara agent, dan di antara workflow.

IV. Perkembangan industri memvalidasi penilaian saya tentang interoperability sebelumnya

Penilaian inti dalam artikel saya sebelumnya adalah interoperability.

Saat itu, penilaian tersebut terdengar masih ada sedikit “rasa” sebagai sesuatu yang ideal dari sisi arsitektur.

Sekarang, penilaian itu makin terasa seperti batasan nyata, karena pasar publik sudah menggunakan “kaki” mereka untuk memberi suara.

Cloudflare tidak memilih salah satu pihak, melainkan secara langsung mendukung x402 dan MPP sekaligus, dan juga jelas melakukan pemetaan kompatibilitas.

Google ikut terlibat dalam x402 sambil terus mendorong AP2 dan UCP.

Visa dan Mastercard juga tidak menyatakan strategi mereka dengan sikap “all in one winner”; mereka di satu sisi bergabung dengan x402, di sisi lain terus menambah agent token, verifikasi identitas, verifikasi instruksi, dan dispute signals.

Taruhan multilateral para raksasa adalah keputusan rasional, bukan kemunafikan komersial.

Kenapa bisa begitu? Karena protokol-protokol ini sebenarnya tidak berada pada lapisan yang sama.

Setidaknya sampai saat ini, x402 dan MPP lebih dekat ke lapisan paid HTTP handshake, yang menangani “bagaimana permintaan membawa kemampuan pembayaran kembali”.

AP2 lebih dekat ke otorisasi dan maksud yang dapat dipercaya, yang menangani “apakah agent ini benar-benar berhak membelanjakan uang tersebut”.

Sementara UCP dan ACP lebih mirip lapisan workflow, menangani discovery, checkout, relasi merchant, passing kredensial, dan masalah-masalah yang lebih atas.

Banyak perusahaan mendukung x402, MPP, AP2, dan UCP bukan karena mereka tidak bisa memutuskan, melainkan karena arsitektur yang akhirnya menang kemungkinan besar melintasi banyak lapisan, bahkan membutuhkan beberapa protokol yang disusun bersama.

Jadi jika ingin merangkum dengan satu kalimat kembali ke penilaian saya sebelumnya, saya sekarang makin yakin bahwa tanpa interoperability, ekosistem gelombang ini tidak akan benar-benar lahir.

Sekarang terlihat, pasar sedang memvalidasi penilaian itu secara aktif.

Lebih jauh lagi, penilaian ini juga penting untuk B2B vs ritel.

Karena dalam dunia ritel, pada akhirnya mungkin saja dunia tersedot ke dalam beberapa platform besar dan beberapa workflow besar; tetapi dunia B2B tidak seperti itu.

Perusahaan hidup dalam realitas multicloud, berbagai metode pembayaran, banyak sistem workflow, dan sistem identitas serta otoritas yang saling tumpang tindih.

Siapa pun yang mencoba mendorong seluruh stack perusahaan roboh lalu dibangun ulang dengan satu protokol baru, besar kemungkinan justru cepat mati.

Hal yang benar-benar mau dibayar oleh klien B2B biasanya bukan “protokol yang satu-satunya benar”, melainkan kemampuan untuk membuat sistem yang ada tetap bisa bekerja di lingkungan mult-protokol.

Logika ini membuat interoperability lebih keras di skenario enterprise dibanding pada consumer.

V. Ini bukan sekadar persaingan protokol, melainkan persaingan stack setelah dilapis

Begitu kamu memahami masalah ini sebagai persaingan stack berlapis, banyak fenomena yang sebelumnya tampak kacau akan langsung menjadi lebih masuk akal.

Lapisan paling bawah adalah paid access handshake.

Lapisan ini peduli dengan: bagaimana HTTP request mengekspresikan “di sini perlu membayar”, dan bagaimana setelah pembayaran, bukti pembayaran itu dibawa kembali.

x402 dan MPP terutama bermain di sini. MPP mencoba menarik 402 ke arah semantik auth HTTP yang lebih resmi; sedangkan x402 lebih mirip mem-”platform-kan” 402, melalui header kustom, facilitator, abstraksi settlement on-chain, dan integrasi ekosistem, supaya bisa jalan dulu.

Satu jalur lebih seperti standarisasi semantik; satu jalur lebih seperti jalur distribusi platform.

Lapisan di atasnya adalah authority to spend, yaitu “siapa yang mengotorisasi uang ini”.

Di sinilah banyak orang belum sepenuhnya menyadari kuncinya.

Mesin akan membayar—itu tidak sesulit itu; mesin bisa diotorisasi untuk membayar dengan cara yang tepercaya—itulah yang benar-benar sulit.

AP2 menjadi penting karena tidak hanya “bagaimana membayar”, melainkan menyelesaikan mandates, verifiable credentials, authenticity, dan accountability.

Agent token, instruction validation, passkeys, dispute signals yang belakangan Visa dan Mastercard genjot pun pada dasarnya semuanya ada di sini.

Lapisan di atasnya lagi adalah workflow dan distribution.

Yaitu discovery, checkout, merchant relationship, credential sharing, dan AI surface integration—hal-hal yang lebih dekat dengan “siapa yang mengendalikan traffic dan orkestrasi transaksi”.

UCP dan ACP lebih mirip yang bertarung memperebutkan lapisan ini.

Untuk B2B, lapisan ini mungkin tidak semeriah itu dalam jangka pendek, tetapi dalam jangka panjang nilainya bisa sangat tinggi.

Karena jika semakin banyak software perusahaan dikoordinasikan, dipanggil, melakukan pembelian, dan melakukan pembayaran oleh agent, maka siapa yang memegang workflow language tidak hanya mengurus satu pembayaran, melainkan mengendalikan seluruh workflow.

Begitu kamu memisahkan ketiga lapisan ini, kamu akan menemukan fakta yang sangat sederhana: tidak perlu mengharapkan satu protokol bisa mencakup semua masalah.

Jalur yang lebih realistis adalah: ketiga lapisan ini tumbuh masing-masing dulu, lalu dengan interoperabilitas perlahan saling “mengunci”.

Dan justru karena itulah taruhan multihak bukanlah kebimbangan, melainkan rasional.

VI. Risiko sesungguhnya x402: mungkin bukan regulasi, melainkan ekonomi di bawah konkurensi

Kalau kita hanya menyadari “banyak protokol hidup berdampingan”, itu masih belum cukup dalam.

Risiko terbesar x402, mungkin bukan regulasi terlebih dulu, melainkan time-of-check/time-of-use economics akibat verifikasi dan settlement yang terpisah dalam dua langkah (verify–settle).

Secara sederhana: jika verifikasi pembayaran dan settlement akhir bukan hal yang sama, maka dalam lingkungan internet yang nyata—konkurensi tinggi, retry, lapisan agent, lapisan caching—akan muncul jendela “pay once, access multiple times”.

Ekosistem x402 sekarang juga sedang menutup celah, misalnya settlement cache, idempotency extension, dan payment identifier, tetapi justru ini menunjukkan bahwa masalahnya bukan sekadar teori.

Kenapa poin ini patut sangat diperhatikan oleh pembaca B2B?

Karena yang paling ditakuti dunia B2B bukanlah demo yang tampak rapi tidak bisa dibuat, melainkan edge case terlalu banyak sehingga begitu masuk produksi mulai bocor.

Monetization API terlihat seolah tiap request tinggal bayar beberapa sen—terlihat ringan; tetapi jika produkmu dibebankan biaya berdasarkan pemanggilan, berdasarkan hasil, atau berdasarkan workflow, maka “bayar sekali lalu dapat sekali” versus “bayar sekali lalu dapat berkali-kali” bukan lagi detail produk, melainkan garis kehidupan.

Jadi jika suatu hari x402 benar-benar bisa jalan di B2B, salah satu prasyarat pentingnya bukan narrative, melainkan mekanisme default-safe ini harus dibuat sedemikian “tanpa perlu dipikirkan” (cukup aman secara standar); kalau tidak, perusahaan tidak akan berani memasukkan traffic nyata.

VII. Protokol bisa saja gratis, tapi gerbang tol tidak akan hilang

Ada satu hal lagi yang menurut saya layak dijelaskan tuntas di tulisan ini.

Kebanyakan open protocol akhirnya akan sampai pada tempat yang sangat familiar: protokolnya sendiri makin murah, bahkan gratis; tapi gerbang tol yang sesungguhnya akan tumbuh di sampingnya.

x402 juga begitu.

Standar itu sendiri tentu menekankan keterbukaan, kenetralan, dan 0 fees yang dibangun ke dalam standar, tetapi itu tidak berarti value capture akan menghilang.

Jika x402 berhasil, nilai tidak akan terutama tertahan di protokol; melainkan akan bergeser ke lapisan-lapisan bersebelahan seperti facilitator, wallet, key management, discovery, policy engine, dan trust wrapper.

Ini sangat penting bagi B2B.

Karena klien perusahaan tidak akan mau membayar hanya untuk satu protokol baru lalu melakukan remodel besar-besaran seluruh sistem. Yang benar-benar mereka bersedia bayar adalah: siapa yang bisa membantu mereka membereskan kerumitan seperti orchestration, policy, risk, compliance, audit, settlement, dan batas otoritas dalam lingkungan mult-protokol.

Dengan kata lain, protokol akan semakin mirip bahasa tingkat bawah, tetapi ketika “menerjemahkan bahasa-bahasa itu menjadi kemampuan agar perusahaan bisa yakin go-live”, justru lapisan itu yang lebih mudah berubah menjadi platform baru sekaligus gerbang tol baru.

Itulah sebabnya saya merasa saat ini kita melihat x402, tidak boleh hanya menatap Coinbase, Cloudflare, dan Stripe yang mana yang terlihat seperti “tokoh utama”.

Yang benar-benar patut diperhatikan adalah siapa yang punya kesempatan untuk berdiri di lapisan-lapisan bersebelahan ini.

Cloudflare punya posisi di edge dan distribusi traffic; Stripe punya posisi di infrastruktur pembayaran dan relasi merchant; Visa dan Mastercard punya posisi di credentials, network token, dan posisi consumer trust; Google punya posisi di workflow dan discovery surface.

Value capture yang sesungguhnya tidak harus terjadi pada “siapa yang mendefinisikan 402”, melainkan lebih mungkin terjadi pada “siapa yang menghubungkan 402 ke sistem enterprise yang lebih besar”.

VIII. Penutup

Kasus x402 Foundation ini bukanlah pengumuman bahwa x402 sudah menang di semua protokol agentic commerce.

Ini adalah pengakuan terbuka bahwa generasi agent payments ini sejak hari pertama tidak akan menjadi dunia protokol tunggal.

Coinbase menyerahkan x402 ke Linux Foundation adalah agar x402 terlihat seperti lapisan publik yang netral, bukan produk eksklusif.

Stripe, di satu sisi mendorong MPP dan di sisi lain masuk ke x402, bukanlah sikap ragu-ragu; melainkan karena mereka tahu sekarang tidak boleh hanya bertaruh di satu sisi.

Cloudflare mendukung dua versi sekaligus karena mereka paling dekat dengan traffic yang nyata.

Langkah Google, Visa, Mastercard, Adyen, dan pemain lain juga menunjukkan hal yang sama: biarkan sistem saling berinteroperasi dulu, lalu baru bicara siapa yang akhirnya menguasai lapisan mana.

Dan jika sudut pandang digeser dari ritel, penilaian ini jadi makin lancar.

Karena yang pertama kali benar-benar membutuhkan protokol-protokol ini, mungkin bukan keranjang belanja, melainkan makin banyak software dan layanan B2B yang memungut biaya berdasarkan panggilan, berdasarkan tugas, dan berdasarkan hasil.

Ritel tentu lebih besar; tetapi B2B biasanya lebih cepat mengungkap kebutuhan nyata, dan lebih cepat mendefinisikan seperti apa bentuk infrastruktur pada akhirnya.

Di artikel saya sebelumnya, saya menempatkan interoperability di pusat. Saya merasa jawaban yang diberikan pasar saat ini sebenarnya sangat jelas: ya—dan bahkan lebih cepat daripada yang saya bayangkan saat itu.

Dalam arti itu, x402 Foundation bukanlah akhir dari cerita ini.

Ia hanya membuat kita melihat lebih awal bahwa tema yang sesungguhnya bukan “siapa yang akan menang”, melainkan “dunia ini ditakdirkan untuk saling berinteroperasi lebih dulu, dan siapa yang bisa menempati lapisan paling bernilai setelah interoperabilitas tercapai”.