UCP dari Google menempelkan empat header di setiap pembayaran. Tiga di antaranya untuk perselisihan yang datang belakangan

Pada 11 Januari 2026, Google merilis Universal Commerce Protocol — standar sumber terbuka yang memungkinkan agen AI berbelanja, dikembangkan bersama Shopify dan didukung lebih dari 20 mitra, termasuk Etsy, Wayfair, Target, Walmart, Adyen, American Express, Mastercard, Stripe, Visa, dan Zalando.

Liputan yang menyusul semuanya soal belanja. Agen yang menelusuri toko untuk Anda, agen yang membayar untuk Anda, akhir dari keranjang belanja, dan seterusnya.

Lalu Anda membaca spesifikasinya, dan ternyata belanja adalah hal paling tidak menarik di dalamnya. Yang distandarkan UCP dengan kehati-hatian yang tidak biasa bukanlah pembeliannya. Melainkan bukti bahwa pembelian itu terjadi persis seperti yang dikatakan kedua pihak.

Ringkasnya:

• Setiap permintaan UCP yang mengubah keadaan membawa empat header, dan tiga di antaranya — request-signature, idempotency-key, request-id — tidak berbuat apa-apa untuk transaksinya sendiri. Ketiganya ada supaya nanti seseorang bisa membuktikan apa yang diminta, bahwa itu diminta tepat sekali, dan bisa menemukannya kembali.
• Ketiadaan penyangkalan adalah fitur yang punya nama sendiri. Dalam ekstensi mandat AP2 yang bersifat opsional (dev.ucp.shopping.ap2_mandate), pelaku usaha menandatangani syarat pembayaran secara kriptografis, sementara platform menyediakan mandat kriptografis yang membuktikan pengguna telah mengizinkannya. Tujuan yang dinyatakan spesifikasi: "menurunkan risiko pemalsuan dan sengketa secara signifikan".
• Jumlah pendukung bukan jumlah integrasi. "Lebih dari 20 mitra global" adalah rumusan yang diterbitkan Google, dan itu menggambarkan dukungan. Sampai tulisan ini dibuat, kami tidak menemukan sumber primer mana pun yang menyebut jumlah pedagang yang benar-benar berjalan di atas UCP.

Susunan header diambil dari panduan praktik yang Google terbitkan pada hari peluncuran. Sumber ada di bagian akhir.

Apa itu UCP, dalam sesedikit mungkin kata yang tetap benar

Sebelum masuk ke argumen, ini fakta-fakta yang bisa Anda cek sendiri. Semuanya berasal dari spesifikasi yang diterbitkan di ucp.dev dan dari blog pengembang Google, keduanya diambil pada 5 September 2026.

Dua baris di tabel itu layak dijeda, karena kebanyakan tulisan melewati keduanya.

Yang pertama baris transport. UCP bukan urusan MCP, dan bukan urusan REST. Data yang dideklarasikan itu-itu juga ditawarkan lewat REST, MCP, A2A, dan satu binding tersemat, dan pelaku usaha yang memilih. Ini penolakan yang disengaja untuk tidak bertaruh pada perpipaan agen mana yang bakal menang.

Yang kedua versi berbasis tanggal. 2026-04-08 bukan versi semantik, melainkan sebuah hari. Alasan yang dinyatakan spesifikasi adalah urutan kronologis dan perbandingan yang tidak ambigu — tapi efek praktisnya lain: setiap sesi yang telah dinegosiasikan ikut mencatat tanggal aturan yang menaunginya. Ini keputusan pengarsipan yang menyamar sebagai keputusan versi, dan ia menentukan nada seluruh sisa dokumen.

Kemacetan yang hendak dibunuhnya

Cara Google membingkainya adalah masalah N×N. Setiap perusahaan yang ingin muncul di dalam permukaan percakapan harus membangun koneksi khusus untuk masing-masing permukaan; setiap permukaan harus mengonboarding tiap perusahaan secara terpisah; ujungnya tidak ada yang meluncur.

Tulisan teknik Shopify, terbit di hari yang sama oleh distinguished engineer Ilya Grigorik, mendatangi masalah yang sama dari bawah. Setelah lebih dari 20 tahun, miliaran transaksi, dan jutaan pedagang, pelajarannya adalah bahwa perdagangan menolak dinormalkan: "opsi dan aturan pembayaran berbeda menurut properti keranjang, pembeli, dan pasar; diskon punya aturan penumpukan dan kombinasi yang bisa menandingi kitab undang-undang pajak; opsi pemenuhan meledak jadi permutasi yang tak terkendali". Lalu datang kalimat yang layak disimpan: "Kerumitan ini bukan bug, melainkan sifat yang muncul dari keberagaman peritel."

Satu baris itu menjelaskan seluruh arsitekturnya. Kalau Anda menerima bahwa para pedagang memang berbeda dan tak bisa disederhanakan, Anda tidak bisa menstandarkan perilakunya. Yang bisa distandarkan hanyalah cara seorang pedagang mendeklarasikan perilakunya, dan cara sebuah agen mencari tahu apa yang barusan ia setujui.

Struktur yang diterbitkan sebuah perusahaan di /.well-known/ucp. Sumber: spesifikasi UCP 2026-04-08, Overview.

Penemuan terjadi sebelum percakapan dimulai

Berikut alurnya, persis seperti dijelaskan spesifikasi dan panduan Google. Layak diikuti secara harfiah, sebab urutannya itulah argumennya.

1. Perusahaan menerbitkan sebuah profil di /.well-known/ucp. Di situ ia mendeklarasikan versi protokol, satu atau lebih layanan (dev.ucp.shopping), capability di dalamnya, transport dan endpoint, penangan pembayaran yang tersedia, dan — ini penting nanti — signing_keys publiknya.
2. Agen mengumumkan profilnya sendiri di tiap permintaan, lewat header UCP-Agent bersintaks kamus RFC 8941: UCP-Agent: profile="https://agent.example/profiles/shopping-agent.json". Pada transport MCP, informasi yang sama menumpang di objek meta.
3. Perusahaan menghitung irisannya. Dari capability miliknya, ia menyimpan yang juga dideklarasikan platform; untuk tiap yang lolos, ia memilih versi tertinggi yang ada di kedua array; kalau tidak ada versi yang sama-sama dimiliki, capability itu gugur seluruhnya.
4. Ekstensi yatim dipangkas. Ekstensi yang mendeklarasikan extends: "dev.ucp.shopping.checkout" lenyap kalau checkout tidak lolos. Pemangkasan diulang sampai tidak ada lagi yang gugur, sehingga rantai turunan pun tertangani.
5. Yang memilih adalah perusahaan. UCP memakai arsitektur di mana server yang menyeleksi: pedagang, bukan agen, yang memutuskan apa yang aktif untuk sesi itu, lalu mengembalikan registri capability aktif di dalam responsnya.

Penamaan bukan konvensi melainkan hal yang ditata. Setiap capability ditulis {domain-terbalik}.{layanan}.{capability} — dev.ucp.shopping.checkout untuk yang standar, com.example.payments.installments untuk milik seorang pedagang. Seorang peritel bisa menciptakan capability yang tidak dimiliki siapa pun tanpa meminta izin dan tanpa bentrok dengan siapa pun, karena domain terbaliklah otoritasnya.

Kegagalan pun punya taksonomi tersendiri, dan pemisahannya menjelaskan banyak hal. Spesifikasi memisahkan kegagalan penemuan (galat transport: invalid_profile_url mengembalikan 400, profile_unreachable mengembalikan 424, profile_malformed mengembalikan 422) dari kegagalan negosiasi, yang merupakan hasil bisnis sehingga kembali sebagai 200 biasa dengan capabilities_incompatible di badan respons. "Saya tidak bisa menjangkau Anda" dan "kita tidak punya kesamaan" adalah dua peristiwa berbeda, dan UCP menolak melebur keduanya jadi satu 400.

Empat header menumpang di setiap permintaan yang mengubah keadaan

Sekarang lihat satu pemanggilan sungguhan. Ini contoh Google sendiri dari hari peluncuran: membuat sesi checkout di sebuah toko bunga contoh.

POST /checkout-sessions
UCP-Agent: profile="https://agent.example/profile"
request-signature: test
idempotency-key: 0b50cc6b-19b2-42cd-afee-6a98e71eea87
request-id: 6d08ae4b-e7ea-44f4-846f-d7381919d4f2
Content-Type: application/json

Empat header. Tanyakan masing-masing untuk apa, dan sebuah pola muncul.

Tiga dari empat bukan untuk transaksinya. Ketiganya untuk perselisihan tentang transaksi itu.

Ini bukan kebetulan dari kebersihan API. Kunci idempotensi dan ID permintaan memang praktik baik yang lazim di dunia pembayaran — tapi spesifikasi ini melangkah jauh lebih jauh, dan makin jauh ia melangkah, makin jelas niatnya.

Ketiadaan penyangkalan itu tujuan desain, bukan tambalan kepatuhan

UCP menyebut empat mekanisme autentikasi yang boleh diterima sebuah perusahaan: kunci API, OAuth 2.0, mTLS, dan tanda tangan pesan HTTP sesuai RFC 9421. Tiga yang pertama biasa saja. Yang keempat sedang melakukan sesuatu yang spesifik.

Dengan tanda tangan pesan, kedua pihak menerbitkan kunci publik mereka di array signing_keys pada dokumen profil yang sama persis dengan yang mendeklarasikan capability mereka. Pemverifikasi menarik keyid dari header Signature-Input, mencocokkannya dengan kid di himpunan kunci yang diterbitkan penanda tangan, lalu memeriksa tanda tangannya. Tanpa rahasia bersama, tanpa pendaftaran, tanpa akun. Spesifikasi menyebut hasilnya sebagai onboarding tanpa izin: "platform mana pun yang punya profil yang dapat ditemukan bisa berinteraksi dengan perusahaan mana pun tanpa pendaftaran sebelumnya".

Lubang yang jelas ditutup oleh pengikatan identitas. Apa pun mekanismenya, pemverifikasi wajib memastikan bahwa pihak yang terautentikasi memang berwenang bertindak untuk profil yang disebut di UCP-Agent, dan menolak permintaan bila keduanya berbenturan. Anda tidak bisa terautentikasi sebagai diri sendiri lalu mengaku sebagai agen orang lain.

Dan webhook dari perusahaan ke platform wajib ditandatangani. Bukan sebaiknya — wajib. Pembaruan siklus hidup pesanan seperti pengiriman, penerimaan, dan pengembalian adalah satu-satunya tempat di protokol ini yang persyaratannya mutlak, karena itulah pesan-pesan yang tiba setelah uang berpindah dan tidak ada yang mengawasinya secara langsung.

Sumber: spesifikasi UCP 2026-04-08, bagian Identity & Authentication dan Transaction Integrity.

Lalu ada puncak tangganya. Untuk agen otonom dan transaksi bernilai tinggi, UCP mendefinisikan sebuah ekstensi opsional, dev.ucp.shopping.ap2_mandate. Ketika kedua pihak menegosiasikannya:

• perusahaan menyediakan tanda tangan kriptografis atas syarat checkout, dan
• platform menyediakan mandat kriptografis yang membuktikan pengguna telah mengizinkannya.

Agen menandatangani objek mandat memakai kunci privat pengguna di sebuah permukaan non-agentik — artinya manusianya memberi izin di layar yang ia kendalikan, bukan di dalam gelung agen yang sebentar lagi membelanjakan uangnya. Pernyataan tujuan dari spesifikasi itu sendiri layak dikutip apa adanya, sebab ini bukan kalimat keamanan basa-basi: mekanisme ini "memberikan jaminan kriptografis yang kuat dan ujung ke ujung mengenai rincian transaksi dan persetujuan para pihak, serta menurunkan risiko pemalsuan dan sengketa secara signifikan".

Ini intinya. Protokol yang dirancang semata agar agen bisa berbelanja tidak akan membutuhkan satu pun dari semua itu. Syarat bertanda tangan di sisi pedagang dan mandat bertanda tangan di sisi pengguna bukan fitur untuk membeli. Keduanya fitur untuk bertengkar soal pembelian itu, enam minggu kemudian, di hadapan seseorang yang harus memutuskan siapa yang benar.

Di mana narasinya mendahului bukti

Ada tiga hal yang terus diulang soal UCP tetapi tidak didukung sumber primer sebagaimana dinyatakannya.

"Lebih dari 20 mitra" adalah hitungan pendukung. Rumusan Google adalah bahwa UCP "dikembangkan bersama dan didukung oleh lebih dari 20 mitra". Dukungan adalah pernyataan sokongan publik. Itu bukan integrasi yang sudah dirilis, apalagi pedagang yang sudah beroperasi. Kami mencari sumber primer berisi jumlah pedagang yang bertransaksi lewat UCP dan tidak menemukannya.

"Standar terbuka" dan "standar Google" sama-sama benar, dan keteganganya nyata. Spesifikasinya sumber terbuka, repositori GitHub-nya menerima pull request, dan konvensi penamaannya sengaja membiarkan siapa pun mengklaim namespace sendiri. Sekaligus: Google yang membangun implementasi rujukan pertama, dan untuk ikut serta di implementasi itu, sebuah perusahaan butuh akun Google Merchant Center aktif dengan produk yang memenuhi syarat checkout. Protokolnya netral, panggung pertamanya berpintu.

UCP tidak menyingkirkan pedagang. Ini cukup sering dipelintir sehingga perlu dikatakan tegas: di bawah UCP, perusahaan tetap memegang logika bisnisnya sendiri dan tetap menjadi Merchant of Record. Embedded Checkout Protocol milik Shopify membuat komitmen yang sama dari arah sebaliknya — ketika alurnya butuh manusia, agen memuat sebuah continue_url dan halaman checkout asli pedagang dirender di dalam permukaan agen lewat kanal JSON-RPC 2.0, dengan pedagang yang menuntaskan transaksinya. Agen adalah permukaan, bukan pengganti.

Empat hal yang tidak bisa kami verifikasi, kami tandai apa adanya

Spesifikasi yang diterbitkan di ucp.dev saat pengambilan bernomor versi 2026-04-08, dan daftar capability standarnya — Cart, Checkout, Identity Linking, Order — berbeda dari panduan 11 Januari, yang contoh-contohnya berjalan di versi 2026-01-11 dan menampilkan checkout, discount, serta fulfillment. Ada sesuatu yang ditambahkan di antara dua tanggal itu. Kami tidak menemukan catatan perubahan primer yang menyebut kapan, maupun catatan rilis bertanggal untuk versi-versi antara, sehingga kami melaporkan perbedaannya, bukan sebuah peristiwa rilis.

Kami tidak menemukan angka terbitan mengenai jumlah pedagang yang beroperasi di atas UCP, baik dari Google, Shopify, maupun mitra pendukung mana pun. Tidak adanya angka bukan bukti bahwa angkanya kecil, tetapi itulah alasan kami tidak mencetak angka apa pun.

Google menyatakan telah membangun implementasi rujukan pertama yang menggerakkan pembelian di dalam AI Mode pada Penelusuran dan aplikasi Gemini. Kami belum memverifikasi secara independen ketersediaan, cakupan wilayah, atau skala peluncuran tersebut.

Apakah UCP akan menjadi standar perdagangan agentik, pada saat tulisan ini dibuat mustahil diketahui, dan tulisan mana pun yang berkata sebaliknya sedang menebak. Pembacaan yang jujur lebih sempit: sebuah spesifikasi ada, ia terbuka untuk umum, ia luar biasa cermat soal pembuktian, dan beberapa perusahaan yang sangat besar ikut menandatangani pengumumannya.

Separuh yang belum ditandatangani

Mari menjauh dari perdagangan, karena bagian yang menariknya bisa digeneralisasi.

UCP menggambarkan dunia di mana mesin bertindak atas nama Anda dan setiap langkah tindakan itu meninggalkan sesuatu: siapa yang meminta, bertanda tangan; syarat apa, bertanda tangan; berapa kali, berkunci; dalam urutan apa, terkorelasi. Enam minggu kemudian, ketika penagihannya disengketakan, ada artefaknya. Tidak ada yang perlu mengingat.

Sekarang pikirkan dari mana sebenarnya kewenangan untuk tindakan-tindakan itu berasal. Sebuah agen membeli 400 unit karena ada keputusan pengadaan. Sebuah kontrak diperpanjang karena seseorang menyetujui satu klausul. Lingkup pekerjaan berubah karena dua orang membicarakannya pada Kamis dan salah satunya bilang iya.

Percakapan-percakapan itulah separuh yang belum ditandatangani dari alur kerja yang sama. Separuh mesinnya sedang dibangun dengan tanda terima kriptografis dan sebuah spesifikasi yang memperlakukan sengketa sebagai skenario kelas satu. Separuh manusianya, di kebanyakan organisasi, adalah ingatan seseorang, ingatan orang lain yang berbeda, dan sebuah ringkasan yang ditulis dari keduanya.

Ketimpangan ini akan memburuk sebelum membaik, karena separuh mesin membaik mengikuti irama sebuah spesifikasi sementara separuh manusia tidak membaik sama sekali. Dan bentuk kegagalannya spesifik: bukan soal orang berbohong. Soalnya, artefak turunan — ringkasan, notulen, daftar tindak lanjut — mulai diperlakukan sebagai catatan itu sendiri begitu hal yang menurunkannya lenyap. Ringkasan memang kehilangan informasi secara desain. Justru itulah yang membuatnya berguna. Dan justru itu pula yang membuatnya jadi sumber primer yang buruk: setelah aslinya dibuang, tidak ada cara membedakan ringkasan yang kehilangan detail dari ringkasan yang akurat.

Para perancang UCP memahami ini di lapisan protokol dan menuliskannya: simpan aslinya yang bertanda tangan, turunkan apa pun yang Anda mau darinya, dan pastikan turunannya selalu bisa dicek terhadap sesuatu yang tidak bergeser. Ini disiplin, bukan teknologi, dan berlaku sama baiknya untuk satu jam orang berbicara seperti halnya untuk sebuah POST /checkout-sessions.

Intinya: perdagangan agentik adalah standar bukti transaksi yang berkostum belanja

Universal Commerce Protocol biasanya digambarkan sebagai cara agar agen AI bisa membeli barang. Dibaca dari awal sampai akhir, ia lebih tepat digambarkan sebagai upaya menjawab satu pertanyaan yang akan terus dihadapi segala hal yang agentik: ketika sebuah mesin bertindak untuk saya, apa persisnya yang bisa dibuktikan tentang apa yang saya setujui?

Jawaban UCP adalah jawaban yang bagus: deklarasikan capability Anda secara terbuka, tandatangani syaratnya, tandatangani persetujuannya, beri kunci pada percobaan ulang, korelasikan pemanggilannya, dan tandatangani pula webhook yang belakangan melaporkan apa yang terjadi. Apakah protokol ini akan menang benar-benar masih terbuka. Pertanyaan yang menjadi pusatnya tidak akan hilang, siapa pun pemenangnya.

Tersisa satu pertanyaan yang layak direnungkan. Sebentar lagi agen-agen Anda akan punya catatan yang lebih baik tentang apa yang mereka setujui dibanding catatan Anda tentang apa yang Anda setujui. Ke mana ini akan bermuara?

---

Di mana Telli.sh berada: kami membangun separuh yang belum ditandatangani itu. Telli.sh merekam percakapan, memisahkan pembicara, menerjemahkan secara langsung ke 15 bahasa, dan menyimpan rekaman asli beserta transkrip lengkap di samping setiap ringkasan yang dihasilkannya — supaya artefak turunan tidak pernah menjadi satu-satunya artefak. Telli.sh tidak mengimplementasikan UCP dan tidak mengklaim demikian; kami menangani ujung yang lain dari masalah yang sama, yaitu bahwa keputusan-keputusan yang mengizinkan agen bertindak umumnya dibuat secara lisan dan tidak disimpan di mana pun.

Rekam rapat pengambilan keputusan Anda berikutnya

Sumber

• Spesifikasi Universal Commerce Protocol, Overview, versi 2026-04-08 — model layanan, capability, dan ekstensi, konvensi penamaan, versi berbasis tanggal, algoritma irisan capability, kode galat negosiasi dan tanda tangan, capability standar (Cart, Checkout, Identity Linking, Order), transport, header UCP-Agent dan sintaks RFC 8941, mekanisme autentikasi dan onboarding tanpa izin, penemuan kunci lewat signing_keys, pengikatan identitas, kewajiban menandatangani webhook, serta bagian Transaction Integrity and Non-Repudiation; diambil 5 September 2026
• Google Developers Blog, "Under the Hood: Universal Commerce Protocol (UCP)", 11 Januari 2026 — daftar mitra dan angka lebih dari 20 pendukung, kompatibilitas AP2, A2A, dan MCP, pembingkaian N×N, manifes /.well-known/ucp, panduan lima langkah dan susunan header POST /checkout-sessions, Merchant of Record dan opsi tersemat, implementasi rujukan Google di AI Mode dan Gemini, serta syarat Merchant Center; diambil 5 September 2026
• Shopify Engineering, Ilya Grigorik, "Building the Universal Commerce Protocol", 11 Januari 2026 — pembingkaian 20+ tahun, miliaran transaksi, dan jutaan pedagang, argumen "bukan bug melainkan sifat yang muncul", empat prinsip desain, serta serah terima Embedded Checkout Protocol lewat JSON-RPC 2.0 dengan continue_url; diambil 5 September 2026
• Agent Payments Protocol (AP2) — protokol pembayaran yang dinyatakan kompatibel oleh UCP
• Universal Commerce Protocol di GitHub — repositori sumber terbuka yang disebut di kedua pengumuman
• Bacaan kami atas GPT-6 Astra dan apa yang masih ditentukan lapisan perekaman — argumen yang sama dari sisi model: kualitas penalaran dibatasi oleh apa pun yang menghasilkan catatan yang dinalarnya