Ana içeriğe geç

Ödeme Noktasında Tarayıcı Ajanları: Onay için Sözleşme Güncellemesi Değil, Bir Kayıt Defteri Gerekir

Ödeme noktasını tarayıcı ajanlarına açmak, onayı makine tarafından müzakere edilen bir sözleşmeye dönüştürür. Kalıcı bir onay kayıt defteri olmadan, ajanın neyi kabul ettiğini kaydeden hiçbir artefakt yoktur.

Sığ alan derinliği altında ince izleri, lehim bağlantılarını ve bileşen işaretlerini gösteren bir devre kartının makro fotoğrafı.

Ödeme noktası ajanlara açıldığında ne değişti

Bir satın alımı tamamlayan tarayıcı ajanı, bir formu tıklayarak geçmiyor. Devredilmiş harcama yetkisini kullanıyor. Kullanıcı, bir yazılım sürecine bir satıcı seçme, sepet oluşturma, kayıtlı bir ödeme yöntemi seçme ve toplamı onaylama yeteneğini vermiştir. Bu, hukuki anlamda bir asil-vekil ilişkisidir ve DOM olayları ile ağ çağrılarından oluşan bir yörüngeye sıkıştırılmıştır.

Ancak satıcı bir oturum görür. Bir user-agent dizesi, bir çerez, bir cihaz parmak izi ve bir ödeme token'ı görür. Bir asil görmez. Kullanıcı bir sonuç görür: bir sipariş onayı, bir tahsilat, bir teslimat tahmini. Kullanıcı, bu sonucu üretmek için kurulan sözleşmeyi görmez. Ve ajanın yörünge ortasında kabul ettiği şartlar — satıcının güncel hizmet şartları, iade politikası, tahkim maddesi, abonelik yenileme şartları — ajanın çalışma sona erdiğinde atılan bağlam penceresinden başka hiç kimse tarafından görülmez.

Yapısal değişiklik budur. Ödeme noktası eskiden bir tıklama geçişiydi: bir insan bir şartlar sayfasını okur (ya da okumaz) ve bir düğmeye tıklardı. Tıklama rızaydı ve sayfa kayıttı. Şimdi rıza bir model tarafından üretiliyor, sayfa hiçbir zaman bir insana gösterilmemiş olabilir ve kayıt, kimsenin saklamadığı bir token dizisidir. Onay sorunu bir kullanıcı arayüzü olayından makine tarafından müzakere edilen bir sözleşmeye taşındı ve bunu belgelemek için kullanılan artefaktlar onunla birlikte taşınmadı.

Bir ayarlar anahtarı neden yetersizdir

Yaygın kurumsal yanıt bir ayarlar anahtarıdır: ajan platformunda ajanın işlem yapıp yapamayacağını söyleyen bir anahtar, belki bir satıcı izin listesiyle birlikte. Bu bir onay modeli değildir. Bir yetenek bayrağıdır.

Ticarette onay küresel değildir. İşlem başına, satıcı başına ve tutar bandı başına geçerlidir. Bir kullanıcı, bir ajana bilinen bir tedarikçiden mütevazı bir üst sınıra kadar yedek filtre satın alma yetkisi verebilir ve ayrı olarak, sepeti inceledikten sonra daha yüksek bir tutarda tanımadığı bir satıcıdan tek seferlik bir satın alma yetkisi verebilir. Tek bir anahtar bu ayrımı ifade edemez ve yinelenen bir abonelik yenilemesi ile ilk satın alma arasındaki farkı da ifade edemez. Yetkinin bir şekli vardır: asil, ajan, satıcı, kapsam, üst sınır, son kullanma. Bir boolean'ın şekli yoktur.

İptal de aynı sorunu yaşar. Onayın tek temsili bir anahtarsa, iptal, anahtarı çevirmek ve ajanın bunu gözlemlemesini ummaktır. Ancak yörünge ortasındaki bir ajan zaten bir sepet oluşturmuş, bir ödeme yöntemi seçmiş ve bir onay adımını bekliyor olabilir. İptal, yörünge ortasında mümkün olmalıdır; bu da yetkinin adreslenebilir bir nesne olmasını gerektirir — yörünge uçuş halindeyken adlandırılabilen, aranabilen ve geçersiz kılınabilen bir şey. Bir anahtar adreslenebilir değildir. Bir kayıt değil, bir durumdur.

Minimalist facade with orange and white geometric panels

Anlaşmazlıklar üçüncü başarısızlığı ortaya çıkarır. Bir tahsilata itiraz edildiğinde soru, kullanıcının geçen ay ayarlarının ne olduğu değildir. Soru, ajanın kabul anında hangi şartları kabul ettiği ve bu şartların kullanıcının verdiği kapsam içinde olup olmadığıdır. Şartlar sayfaları değişir. Satıcılar tahkim maddelerini, yeniden stoklama ücretlerini ve yenileme dilini haber vermeden günceller. Kullanıcının son ziyareti sırasındaki şartların bir kaydı, ihtilaflı işlemde neyin kararlaştırıldığının kanıtı değildir. İşlem başına bir artefakt olmadan, anlaşmazlık sürecinin üzerinde akıl yürütebileceği hiçbir şey yoktur; satıcının güncel sayfası ve kullanıcının hatırladıkları dışında.

Bir onay kayıt defteri taslağı

Bunu ele alan mekanizma bir onay kayıt defteridir: her harcama yetkisi devrinin, yetkinin kullanıldığı anda yazıldığı, yalnızca ekleme yapılabilen, sorgulanabilir bir kaydı.

Her giriş en azından aşağıdaki alanları taşımalıdır:

entry_id        benzersiz, monoton
principal       yetkiyi veren insan veya kuruluş
agent_id        yetkiyi kullanan yazılım kimliği
merchant_id     karşı taraf
scope           örn. tek seferlik satın alma, abonelik yenileme, iade
amount_ceiling  ajanın taahhüt edebileceği maksimum toplam
currency        ISO kodu
expiry          yetkinin geçersiz olduğu zaman damgası
terms_hash      kabul anında sunulan şartların özeti
terms_uri       şartlar belgesinin konumu
timestamp       girişin yazıldığı zaman
parent_entry    iptaller ve değişiklikler için

Şartlar özeti (terms hash) yük taşıyan alandır. Tam şartlar belgesini saklamayı gerektirmez, yalnızca bir satıcının yayımlanmış sürüm geçmişine karşı kontrol edilebilecek bir özet gerektirir. Satıcı sayfayı daha sonra değiştirirse, özet yine de kabul anında geçerli olan sürümü tanımlar. terms_uri, anlaşmazlık sürecine onu almak için bir işaretçi verir.

Girişler yalnızca ekleme yapılabilir. İptal, orijinal yetkiyi değiştirmez; parent_entry alanı yetkiyi işaret eden ve kapsamı revoked olan yeni bir giriş yazar. Orijinal sorgulanabilir kalır. Bu önemlidir çünkü bir anlaşmazlık yalnızca onayın geri çekildiğini değil, ne zaman geri çekildiğini ve ajanın işlemi iptal gelmeden önce zaten taahhüt edip etmediğini de tespit etmeyi gerektirebilir. Yalnızca ekleme yapılabilen bir günlük bu soruyu yanıtlar; değiştirilebilir bir bayrak ise onu siler.

Kayıt defteri, farklı çıkarlara sahip iki taraf tarafından sorgulanabilir olmalıdır. Kullanıcının, ajanlarının kullandığı her devri, üst sınırlar ve son kullanma tarihleriyle birlikte tek bir görünümde görmesi ve hâlâ geçerli olanları iptal edebilmesi gerekir. Satıcının anlaşmazlık sürecinin, kullanıcının diğer yetkilerine görünürlük kazanmadan belirli bir işlem için şartlar özetini ve kapsamı alması gerekir. Bu bir depolama sorunu değil, bir okuma yetkilendirme sorunudur ve ilk uygulamada enPerson pointing at a vintage oscilloscope screen displaying a waveform in a tech settingk-network-cables-f7a795-35eb46.jpg)

Somut bir etkileşim: bir ajan bir ödeme noktasına ulaşır, satıcının sayfası şartları sunar, ajan özeti hesaplar ve satıcı, kapsam, üst sınır ve özet ile bir kayıt defteri girişi yazar. Ödeme yetkilendirmesi entry_id alanını taşır. Kullanıcı, ajan bir onay adımını beklerken iptal ederse, iptal girişi yazılır ve ajanın kayıt defterindeki bir sonraki okuması iptal edilmiş bir durum döndürür ve yörüngeyi terk etmesine neden olur. İşlem yine de gerçekleşirse, kayıt defteri sıralamayı gösterir: yetki, iptal, gerçekleşme. Bu sıralama kanıttır.

Dürüst ödünleşim

Bir onay kayıt defteri her ajanlı ödeme noktasına gecikme ve bir bağımlılık ekler. Bir giriş yazmak, şartları özetlemek ve iptali kontrol etmek, bir düğmeye tıklayan bir insanın ödemediği gidiş-dönüşlerdir. Kayıt defteri kullanılamıyorsa, ajan ya kapalı başarısız olur — meşru bir satın alımı terk eder — ya da açık başarısız olur, ki bu amacı boşa çıkarır. Tasarım seçim yapmak zorundadır ve hiçbir seçim bedava değildir. Bir yörüngenin her adımında sorgulanan bir kayıt defteri ajanı yavaşlatır; yalnızca yetkilendirmede sorgulanan bir kayıt defteri yörünge ortası iptalleri kaçırır. Pratik uzlaşma, yetkilendirmede yazmak ve iptal için sınırlı bir aralıkta yoklamaktır; bu, iptal edilmiş bir yetkinin hâlâ taahhüt edebileceği bir pencereyi kabul etmek anlamına gelir. Bu pencere girişte belirtilmeli, gizlenmemelidir.

Bir gizlilik maliyeti de vardır. Bir harcama devirleri kayıt defteri zengin bir davranışsal kayıttır. Satıcıların yalnızca kendi işlemleriyle ilgili girişleri görmesi ve kullanıcının, anlaşmazlık saklama gereksinimlerine tabi olarak kendi girişlerini dışa aktarma ve silme yeteneğini koruması için kapsamlandırılmalıdır. Yalnızca ekleme yapılabilir olmak ölümsüz olmak anlamına gelmez; silmenin kendisinin bir giriş olduğu anlamına gelir.

Ticari risk ile etkileşim

Ajanlı ticareti işaretleyen bankalar ve kart ağları, yalnızca dolandırıcılık oranlarına tepki vermiyor. Bir artefaktın yokluğuna tepki veriyorlar. Her zaman yetkilendirme noktasında hazır bir insana dayanan bir risk modeli, şimdi asil olmayan, okunabilir rızası olmayan ve şartlar kaydı olmayan bir oturumla karşı karşıya. Dolandırıcılık sinyali zayıftır çünkü meşru desen ile kötüye kullanım deseni ağın tarafından aynı görünür: yazılım tarafından kullanılan, döngüde insan olmayan kayıtlı bir kimlik bilgisi.

Bir onay kayıt defteri bu belirsizliği ortadan kaldırmaz, ancak risk sistemlerine puanlayacak bir şey verir. Eşleşen bir yetki, makul bir üst sınır ve geçerli bir son kullanma ile entry_id taşıyan bir yetkilendirme, kaynağı olmayan bir yetkilendirmeden farklı bir nesnedir. Zamanla, artefaktın varlığı kendi başına bir sinyal haline gelir ve yokluğu reddetmek için bir neden olur. Bu konuda ilk hareket eden kurumlar ajanlar konusunda temkinli değiller; ajanlı ticareti zaten yöneten sistemler için okunabilir kılan kaydı inşa ediyorlar.

Şartlar güncellemesi cevap değildir. Kayıt defteri cevaptır.

İlgili okumalar

Bunun yanıtladığı sorular

Why is a settings toggle not enough for browser agent checkout?

Consent is per-transaction, per-merchant and per-amount-band. A global toggle cannot express that shape, cannot be revoked mid-run because it is a state rather than an addressable object, and cannot record the terms live at the moment of acceptance.

What fields should a consent ledger entry contain?

At minimum: principal, agent identity, merchant, scope, amount ceiling, currency, expiry, terms hash, terms URI, timestamp and a parent entry reference for revocations and amendments.

Why must revocation be append-only rather than a mutation?

A dispute may need to establish when consent was withdrawn and whether the transaction committed before or after. An append-only revocation entry preserves that ordering; mutating the original grant erases it.

How does a consent ledger interact with bank fraud models?

An authorisation carrying a ledger entry ID with a matching grant, plausible ceiling and live expiry is a different object from one with no provenance. The presence or absence of that artefact becomes a scoreable signal.