Ajanlı ödeme nedir? Yapay zekâ nasıl öder?

20 Ekim’de iki kart ağı aynı gün, yapay zekâ ajanlarının ödeme yapmasını gerçek işlemlerle denemeye başladı. Visa, fatura ödeme platformu BILL ve tedarikçi portalı Billtrust’la canlı bir pilot duyurdu. Mastercard da aynı gün geliştiricilere “Agent Pay for Machines” için erken erişim açtı (The Block).

Ajanlı ödeme (agentic payments), insanın sınırını önceden çizdiği bir yetkiyle bir yazılımın, yani bir yapay zekâ ajanının ödemeyi kendisi yapması. Haberi ilk okuduğumda iki şeyi anlamadım: ödemeyi yapay zekâ mı yapacak, kart numarası olmadan nasıl ödeyecek? İkisinin cevabı da haberin içinde.

Ödemeyi yapay zekâ mı yapacak?

Kararı hâlâ insan veriyor. Visa pilotunda BILL’in ödeme ajanı yalnızca alıcının daha önce onayladığı faturaları ödüyor; Visa’ya göre ajan ödeme kararı vermiyor, onaylanmış talimatı yerine getiriyor. Eskiden biri her tedarikçinin portalına tek tek girip öderdi, şimdi bu tekrarı ajan yapıyor. Pilot canlıda ve gerçek işlemler işleniyor.

Mastercard’ın tarafı makineden makineye ödeme. Bir yazılım iş yaparken kullanım başına ücretli bir servise ihtiyaç duyuyor; insan bir bütçe veriyor, ajan o bütçe içinde kendisi ödüyor. Sistem, ödemeyi HTTP’nin içine gömen açık protokol x402 üzerine kurulu: servis 402 Payment Required dönüyor, ajan imzalı bir ödeme kuponu gönderiyor, satıcı kuponu doğrulayıp hizmeti veriyor ve kuponlar sonra toplu tahsil ediliyor. 402 kodu HTTP standardında hâlâ “ileride kullanılmak üzere” ayrılmış duruyor. Demoda bir ajan, onaylı tek bir bütçeden iki sağlayıcıya dokuz ödeme yaptı. Mastercard’ın teknik dokümanı henüz herkese açık değil; ayrıntılar şimdilik basın haberlerinden.

“Bana 3.000 liranın altında bir uçak bileti bul ve al” diyen bireysel kullanıcı ise bu pilotların kapsamında değil.

Kart numarası olmadan nasıl ödüyor?

İki ayrı parça birlikte çalışıyor: parayı token taşıyor, kimliği imza kanıtlıyor.

Token. Visa pilotunda ajan, tokenize edilmiş ödeme bilgisiyle ödüyor. Apple Pay ya da Google Pay’de olan da bu: telefon satıcıya karta bağlı ayrı bir numara gönderir, kart ağı onu arkada gerçek kartla eşleştirir ve para yine kart hesabından çıkar. Visa ajan token’ının biçimini ve hangi sınırları taşıyabildiğini açıklamadı.

İmza. Satıcı, karşısındakinin kayıtlı bir ajan mı yoksa sıradan bir bot mu olduğunu Visa’nın Trusted Agent Protocol şartnamesiyle anlıyor. Ajan her HTTP isteğini RFC 9421 HTTP Message Signatures ile imzalıyor; satıcı ajanın açık anahtarını Visa’nın /keys uç noktasından JWK olarak çekip imzayı doğruluyor. Şartnamedeki kurallar kısa:

• İmzada en az @authority, @path, created, expires, keyid, alg, nonce ve tag bulunmalı; biri eksikse istek engellenir.
• created ile expires arası 8 dakikayı geçemez.
• Satıcı son 8 dakikada gördüğü nonce’ları tutar, aynısı tekrar gelirse isteği engeller. Bu, idempotency ile aynı aileden bir kontrol: aynı isteğin ikinci kez işlenmemesi.
• tag gezinmede agent-browser-auth, ödemede agent-payer-auth değerini taşır.

Visa’ya göre bu doğrulama, sitelerin bugüne kadar CAPTCHA ve bot engelleme ile sağladığı korumanın yerini tutabiliyor. Ajan ayrı bir portal girişine de ihtiyaç duymuyor.

Benim yorumum

Fikir bana mantıklı geliyor ama temkinliyim. Bu haberdeki parçaların hiçbiri ödeme dünyası için yeni değil; yeni olan, bankalarla tek tek kurduğumuz şeylerin ilk kez herkes için standart hâle gelmesi.

Token’ı düşünelim. Daha önce çalıştığım bir kart saklama modülünde kartı şifreleyip saklıyor, işlemi o kartın token’ıyla yapıyorduk. Ama o token yalnızca bizim sistemimizin içinde anlam taşıyordu. Bankaya giderken şifre çözülüyor, kart numarası yine yola çıkıyordu. Ağ düzeyindeki token’da gerçek numara hiç dolaşmıyor. Kart numarasının nerelere sızabildiğini gören biri için bu küçük bir fark değil.

İmza tarafı bana çok tanıdık geldi. Bir bankayla entegrasyonda body açık gidiyor, header’da body’nin private key ile imzalanmış hâli taşınıyordu. İmzanın içinde zaman damgası ve requestId gibi tek kullanımlık bir değer de vardı. Visa’nın 8 dakika ve nonce kuralı bunun standart hâli. Bugün her banka kendi header adını, kendi kuralını istiyor ve anahtarlar PEM dosyası olarak elle değiş tokuş ediliyor. Burada anahtar bir dizinden geliyor ve kural herkes için aynı.

Limit kısmında daha az eminim. Günlük tutar limiti gibi kurallar “ne kadar” sorusunu çözüyor, “doğru şeyi mi aldı” sorusunu çözmüyor. Onaylı bir fatura gibi önceden bilinen ödemede bu yeter. Ajanın kendi seçtiği bir alışverişte yetmez.

Türkiye’de de benzer bir ayrım görüyorum. Benim gördüğüm kadarıyla saklı kartla tekrarlı ödemede ilk işlem 3DS ile onaylanıyor, sonrakiler 3DS sormadan geçebiliyor. Önceden onaylı ajan ödemesi bu kalıba oturur; ajanın kendi seçtiği alışveriş ise yine 3DS ister.

Asıl açık soru sorumluluk. Ajan limit içinde ama yanlış bir ödeme yaparsa parayı kim geri öder: kart sahibi mi, ajanı yapan şirket mi, satıcı mı? Bunu henüz kimse bilmiyor. Pilotların zaten onaylanmış faturalarla başlamasının sebebi de bence bu.

Bugün yapabileceğin tek şey varsa, kendi imzalama yapına bakmak: istekler zaman damgası ve tek kullanımlık bir değer taşıyor mu, aynı istek ikinci kez gelince reddediliyor mu? Ajanlar Türkiye’ye geldiğinde ilk sorulacak soru büyük ihtimalle bu olacak.