Perdagangan Agen Membutuhkan Lapisan Identitas: Visa TAP, Google AP2, dan Mastercard Agent Pay

Poin-poin Penting

• Visa Trusted Agent Protocol (TAP), Google Agent Payments Protocol (AP2), dan Mastercard Agent Pay semuanya membuat pembelian yang dipimpin agen lebih aman, tetapi mereka memecahkan bagian masalah kepercayaan yang berbeda.
• TAP membantu pedagang mengenali agen yang disetujui dan memverifikasi niat perdagangan yang ditandatangani. AP2 membuat bukti apa yang diotorisasi pengguna. Agent Pay menggabungkan agen terdaftar, kredensial pembayaran yang di-tokenisasi, persetujuan, dan visibilitas jaringan.
• Tidak satu pun dari mekanisme ini menghilangkan kebutuhan untuk membuktikan siapa individu atau bisnisnya, menyaring risiko, menegakkan kontrol spesifik yurisdiksi, dan menyimpan jejak audit.
• Didit adalah infrastruktur netral untuk identitas dan penipuan, bukan jaringan kartu atau perusahaan pembayaran. Server Model Context Protocol (MCP) yang di-host-nya mengekspos 115 alat di 11 kategori, sementara Application Programming Interface (API) Representational State Transfer (REST) mendukung alur produksi yang tertanam.
• Paket Know Your Customer (KYC) lengkap berharga $0,33, setiap akun mencakup 500 verifikasi gratis per bulan, dan server MCP itu sendiri gratis.

Perdagangan agen dimulai ketika agen kecerdasan buatan (AI) melakukan lebih dari sekadar merekomendasikan produk. Agen membandingkan penawaran, mengumpulkan keranjang belanja, memilih metode pembayaran, dan dapat menyelesaikan pembelian dalam batasan yang ditetapkan oleh individu atau bisnis. Pergeseran tersebut menciptakan beberapa pertanyaan kepercayaan sekaligus: Agen mana yang membuat permintaan? Siapa yang mengotorisasinya? Siapa individu atau entitas hukum di baliknya? Apakah transaksi diizinkan? Dan bukti apa yang akan ada jika pembelian disengketakan?

Standar pembayaran yang muncul menjawab bagian penting dari urutan tersebut. Mereka tidak semua menjawab bagian yang sama, dan mereka tidak boleh diperlakukan sebagai dapat dipertukarkan. Bagi pengembang, pertanyaan yang berguna bukanlah merek mana yang akan “menang.” Ini adalah kontrol mana yang tetap diperlukan di bawah setiap arsitektur yang kredibel.

Tiga standar, tiga batas kepercayaan

Visa TAP: dapatkah pedagang mengenali dan mempercayai agen ini?

Visa Trusted Agent Protocol berorientasi pada pedagang. Tugas utamanya adalah membantu pedagang membedakan agen perdagangan yang disetujui dari perayap biasa, bot jahat, atau otomatisasi yang tidak dikenal. Agen menandatangani permintaan dengan kredensial yang terikat waktu dan spesifik tujuan. Pedagang atau penyedia perlindungannya memverifikasi tanda tangan dan dapat memutuskan apakah akan mengizinkan penelusuran, pembayaran, atau tindakan yang lebih sempit.

TAP menjelaskan tiga sinyal terkait: tanda tangan pengenalan agen, identitas konsumen atau perangkat yang tertaut dan ditandatangani, dan kontainer pembayaran yang tertaut dan ditandatangani. Ini adalah pemisahan yang berguna. Pengenalan agen menetapkan agen yang disetujui mana yang hadir; niat yang ditandatangani menetapkan jenis interaksi apa yang diminta; sinyal konsumen dapat membantu pedagang mengenali pelanggan yang sudah ada.

Sinyal konsumen itu tidak secara otomatis setara dengan pembuktian identitas baru. Model Visa mencakup peran penyedia identitas di hulu, tetapi pedagang masih memerlukan kebijakan untuk pelanggan baru atau berisiko tinggi: bukti apa yang diperiksa, seberapa kuat jaminan, apakah KYC diperlukan, dan kapan verifikasi ulang diperlukan. TAP dapat membawa informasi identitas tepercaya tanpa menentukan setiap keputusan orientasi yurisdiksi.

Google AP2: apa yang diizinkan pengguna untuk dibeli oleh agen?

Google Agent Payments Protocol berfokus pada otorisasi dan bukti. Ini menggunakan mandat yang ditandatangani untuk menghubungkan niat pengguna, konten pembayaran, dan pembayaran. Mandat terbuka dapat memberikan agen diskresi terbatas, seperti batasan pedagang atau batas pengeluaran. Mandat tertutup mengikat persetujuan ke keranjang dan jumlah tertentu. Tanda terima melengkapi rantai bukti.

AP2 membedakan alur yang ada manusia dan tidak ada manusia. Ketika orang tersebut hadir, mereka dapat menyetujui pembayaran tertutup dan mandat pembayaran secara langsung. Ketika tidak hadir, agen beroperasi di dalam batasan yang disetujui sebelumnya dan menandatangani mandat tertutup akhir. Pedagang atau penyedia kredensial masih dapat membawa orang tersebut kembali ke dalam lingkaran ketika batasan tidak dapat diselesaikan.

Desain ini menjawab “Apakah orang ini mengotorisasi tindakan ini dalam kondisi ini?” lebih langsung daripada “Bagaimana orang ini awalnya diverifikasi?” Kerangka kerja otorisasi AP2 mengasumsikan pendaftaran dan kredensial pengguna yang relevan ada. Oleh karena itu, pengembang masih memerlukan proses pembuktian identitas dan siklus hidup kredensial sebelum mandat tersebut dapat membawa jaminan yang berarti.

Mastercard Agent Pay: dapatkah jaringan mengenali dan mengatur pembayaran agen?

Mastercard Agent Pay dibangun di atas tokenisasi pembayaran. Kerangka kerja penerimaan Mastercard mendaftarkan dan memverifikasi agen, menetapkan identitas agen yang unik, dan menggunakan Agen Token sehingga transaksi dapat dilacak dan kredensial pembayaran tetap terlindungi. Pengenalan yang berorientasi pada pedagang dapat bekerja dengan infrastruktur pembayaran yang ada, sementara integrasi yang lebih dalam mendukung pertukaran data yang lebih kaya.

Model ini juga menekankan persetujuan konsumen, autentikasi, dan kemampuan bagi penerbit, pengakuisisi, dan pedagang untuk mengenali bahwa agen berpartisipasi. Ini membuat aktivitas agen terlihat di dalam model risiko jaringan kartu yang akrab daripada membuat otomatisasi tidak dapat dibedakan dari permintaan kartu tidak hadir biasa.

Agent Pay paling kuat dalam keamanan kredensial pembayaran, visibilitas agen, dan kontrol jaringan. Ini tidak menghilangkan kewajiban pedagang untuk memutuskan kapan verifikasi identitas, Know Your Business (KYB), penyaringan Anti-Money Laundering (AML), pemeriksaan usia, atau tinjauan yang ditingkatkan berlaku. Keputusan tersebut bergantung pada produk, pelanggan, transaksi, dan yurisdiksi—bukan hanya pada jalur pembayaran.

Di mana standar tumpang tindih—dan di mana identitas masih cocok

Ketiga pendekatan tersebut mencoba membuat perdagangan yang didelegasikan menjadi jelas. Pedagang harus dapat mengetahui bahwa otomatisasi terlibat, memverifikasi bahwa agen tersebut tepercaya, menghubungkan tindakan dengan niat pengguna, membatasi pembelian, dan menyimpan bukti. Penekanan mereka berbeda:

• TAP: pengenalan agen dan niat yang ditandatangani di batas pedagang, dengan sinyal konsumen dan pembayaran yang tertaut opsional.
• AP2: artefak otorisasi kriptografi yang mengikat niat pengguna ke hasil pembayaran dan checkout.
• Agent Pay: agen terdaftar, kredensial pembayaran yang di-tokenisasi, persetujuan, autentikasi, dan visibilitas di seluruh jaringan kartu.

Pembuktian identitas berada sebelum dan di samping kontrol ini. Otorisasi yang ditandatangani hanya berharga jika kredensial tersebut milik orang yang tepat. Agen yang disetujui masih dapat diinstruksikan oleh akun sintetis, dicuri, disanksi, di bawah umur, atau tidak memenuhi syarat. Token dapat melindungi kredensial pembayaran tanpa menetapkan bahwa penjual pasar atau penerima bisnis telah melewati uji tuntas yang diperlukan.

Identitas agen menjawab “perangkat lunak mana yang bertindak?” Otorisasi menjawab “apa yang diizinkan untuk dilakukan?” Verifikasi identitas menjawab “siapa di baliknya?” Kontrol penipuan dan kepatuhan menjawab “haruskah tindakan ini dilanjutkan?”

Apa yang harus dibangun pengembang terlepas dari pendekatan mana yang menang

• Pendaftaran dan pembuktian. Verifikasi individu atau bisnis sebelum memberikan kredensial yang dapat digunakan kembali atau otoritas pengeluaran yang didelegasikan. Terapkan pemeriksaan KYC, KYB, liveness, dokumen, database, atau biometrik sesuai risiko.
• Pengikatan kredensial. Ikatan subjek yang diverifikasi ke akun, perangkat, passkey, dompet, atau kredensial lain yang dapat berpartisipasi dalam alur agen.
• Otorisasi yang dicakup. Batasan tangkap seperti pedagang, kategori, jumlah, frekuensi, kedaluwarsa, dan apakah manusia harus kembali untuk persetujuan.
• Keputusan risiko saat runtime. Saring individu, bisnis, dompet, dan transaksi pada saat tindakan. Kontrol Know Your Transaction (KYT) dan pemeriksaan AML tetap relevan bahkan ketika niat ditandatangani.
• Pencabutan dan pemulihan. Hentikan otoritas yang didelegasikan ketika kredensial dikompromikan, pengguna menarik persetujuan, atau risiko berubah.
• Auditabilitas. Simpan hasil verifikasi, artefak otorisasi, identitas agen, keputusan transaksi, stempel waktu, dan tindakan tinjauan selanjutnya sebagai bukti terpisah.

Desain berlapis ini sengaja netral standar. Sebuah tim dapat mengadopsi TAP di batas pedagang, mandat AP2 dalam alur kerja agen, Agent Pay untuk penyelesaian kartu, atau kombinasi. Keputusan identitas dan penipuan tetap portabel karena tidak tertanam dalam satu jaringan pembayaran.

Bagaimana Didit mencakup setengah identitas hari ini

Didit menyediakan infrastruktur untuk identitas dan penipuan yang digunakan oleh 2.000+ perusahaan dalam produksi. Kemampuan yang sama tersedia melalui server MCP yang di-host untuk operasi yang digerakkan agen dan REST API untuk alur yang dikontrol aplikasi. Untuk gambaran umum arsitektur yang lebih luas, lihat bagaimana server MCP menangani verifikasi identitas dan bagaimana MCP menghubungkan pemeriksaan identitas dan penipuan untuk agen AI.

Endpoint MCP yang di-host adalah https://mcp.didit.me/mcp. Ini menggunakan Streamable Hypertext Transfer Protocol (HTTP), dengan Open Authorization (OAuth) 2.1, Proof Key for Code Exchange (PKCE), dan Dynamic Client Registration. Pengguna masuk melalui Didit Business Console dan memberikan akses yang dicakup; endpoint MCP yang di-host tidak menggunakan autentikasi kunci API.

Setelah otorisasi, agen dapat memanggil 115 alat di 11 kategori. Urutan verifikasi praktis dapat menggunakan:

didit_context_get
didit_session_create
didit_verify_id
didit_verify_passive_liveness
didit_verify_face_match
didit_session_get_decision

Alat-alat tersebut dapat membuat sesi verifikasi, menjalankan pemeriksaan yang dipilih, dan mengambil keputusan terstruktur. Alat nyata lainnya termasuk didit_verify_aml, didit_verify_kyb_search, didit_verify_kyb_select, dan didit_transaction_screen_wallet. Penulisan konsekuensi tinggi tetap tunduk pada izin pengguna yang terhubung dan perilaku konfirmasi.

REST API mencakup jalur aplikasi: membuat sesi dari backend Anda, mengirim pengguna melalui verifikasi yang di-host atau tertanam, mengonsumsi webhook, dan menyimpan keputusan di sistem Anda sendiri. Permintaan server-ke-server REST menggunakan header x-api-key; ini terpisah dari koneksi MCP yang di-host yang diautentikasi OAuth. Baca gambaran umum MCP, panduan autentikasi, dan referensi alat untuk detail implementasi.

Penetapan harga tidak tergantung pada standar pembayaran agen. Server MCP gratis. Paket KYC lengkap—Verifikasi ID, Liveness Pasif, Pencocokan Wajah, dan Analisis IP—berharga $0,33, dan setiap akun mencakup 500 verifikasi gratis per bulan.

Jalur implementasi netral standar

Mulailah dengan mendefinisikan jaminan yang diperlukan untuk setiap tindakan, bukan dengan memilih logo jaringan. Penelusuran berisiko rendah mungkin hanya memerlukan pengenalan agen. Pembuatan akun mungkin memerlukan identitas yang diverifikasi. Pembelian yang diatur mungkin memerlukan KYC atau KYB ditambah penyaringan AML. Transfer kripto dapat menambahkan penyaringan dompet. Jumlah yang lebih tinggi atau risiko yang berubah dapat mengembalikan manusia ke dalam lingkaran.

Kemudian hubungkan artefak pembayaran ke keputusan identitas dengan pengidentifikasi internal yang stabil. Jaga agar tanda tangan agen, otorisasi pengguna, bukti verifikasi, dan hasil pembayaran berbeda sehingga masing-masing dapat dicabut, ditinjau, dan ditingkatkan secara independen seiring berkembangnya standar.

Jelajahi halaman pengembang Didit MCP atau periksa repositori GitHub publik berlisensi permisif. Pengguna Claude dapat menambahkan konektor Didit dan menyelesaikan login OAuth.

Arsitektur yang tahan lama berlapis: standar pembayaran membuktikan partisipasi dan otorisasi agen; infrastruktur identitas dan penipuan membuktikan siapa yang terlibat dan apakah tindakan itu dapat diterima. Pembagian itu memungkinkan pengembang untuk mendukung standar saat ini tanpa mengkodekan kepercayaan secara keras ke satu standar.