Ajan Tabanlı Ödeme

Kısaca — Ajan tabanlı ödeme, yapay zekâ destekli alışverişin “benim için satın al” aşamasıdır. Bir yapay zekâ asistanı bir ürün bulup satın alma işlemini sizin adınıza tamamladığında, bu son işlem adımı ajan tabanlı ödemedir. OpenAI’ın yetkilendirilmiş ödeme akışında ajan, ham kart numarası yerine kapsamı sınırlı bir ödeme jetonu kullanır; oturum açma veya ek doğrulama gibi riskli bir durumda durup denetimi insana devreder. Bu, daha büyük protokollerin (ACP ve UCP) bir parçasıdır; tek başına ayrı bir ürün değildir.

Ajan tabanlı ödeme nedir?

“Yapay zekâ destekli alışveriş” denilen sürecin büyük bölümü keşiftir: asistandan bir şey bulmasını istersiniz; o da satıcıların ürün akışlarını okuyup seçenekler önerir. Ajan tabanlı ödeme bundan sonraki adımdır — ajanın gerçekten siparişi oluşturduğu; teslimat seçeneğini belirlediği, vergi ve kargo bedelini hesapladığı, ödemeyi aktardığı ve satın alma işlemini sonuçlandırdığı bölümdür.

Buradaki kilit sözcük adım sözcüğüdür. Ajan tabanlı ödeme ayrı bir ürün veya şirket değildir. OpenAI ile Stripe’ın Agentic Commerce Protocol (ACP) ve Google ile Shopify’ın Universal Commerce Protocol (UCP) adlı iki büyük ajan tabanlı ticaret standardına yerleştirilmiş işlem tamamlama yeteneğidir. Bu standartlara genel bakış için ilgili kardeş yazılara bakabilirsiniz; bu sayfa doğrudan ödeme mekaniklerine odaklanır.

İnsanların yanlış anladığı üç konu

• “Yapay zekâ, insan hiç devreye girmeden satın alır.” Pek öyle değil. Her iki protokolde de oturum açma, ek kart doğrulaması veya onay için yerleşik bir “bekle ve insana sor” adımı vardır. Teknik özellikler tamamen insansız ödemeye göre tasarlanmamıştır.
• “Yapay zekâ kredi kartımı görür.” Hayır. Ödeme, kapsamı sınırlı bir jeton olarak aktarılır: tek satıcıya, tek tutara ve belirli bir zaman aralığına kilitli, yalnızca bir kez kullanılabilen bir temsilci değerdir. Ham kart numarası ajana hiç ulaşmaz.
• “Bu artık olağan; çoğu mağazada var.” Bu da doğru değil. 2026 ortası itibarıyla henüz erken aşamadadır: OpenAI Mart 2026’da tamamen sohbet içi sürümü daraltmadan önce yalnızca yaklaşık bir düzine Shopify mağazası ChatGPT ödemesini canlıya almıştı.

Bir sorun çıkarsa kim sorumludur?

Satın aldığınız mağaza yine mağazadır; buna kayıtlı satıcı (merchant of record) denir. Normal bir çevrimiçi alışverişte olduğu gibi sipariş, iadeler ve uyuşmazlıkları satıcı yönetir. Henüz kimsenin tam olarak çözemediği asıl karmaşık konu, “alışveriş yapan” bir yapay zekâ ajanı olduğunda itiraz edilen bir tahsilata ne olacağıdır. Ayrıntılar Gelişmiş sekmesinde.

Gerçek durum makinesini, ödeme jetonlarının nasıl sınırlandırıldığını, insanın nerede devreye girmesi gerektiğini ve satıcıların sistemi açmadan önce neleri test etmesi gerektiğini mi arıyorsunuz? Gelişmiş sekmesine geçin.

Kısaca — Ajan tabanlı ödeme, ajan tabanlı ticaretin işlem tamamlama yeteneğidir: bir ödeme oturumu oluşturur, günceller, tamamlar veya iptal eder; ödemeyi yetkilendirir ve siparişi onaylar. ACP’nin bir, UCP’nin de bir yapı taşıdır; bağımsız bir protokol değildir. Teknik omurgası bir durum makinesidir: ACP, oturumu not_ready_for_payment → ready_for_payment → (gerektiğinde requires_escalation / authentication_required) → completed durumlarından geçirir; bu akış UCP’nin incomplete → requires_escalation → ready_for_complete zincirini yansıtır. Müdahale durumları, kasıtlı insan denetimi bağlantısıdır. Ödeme yetkilendirmesi, satıcıya kilitli, tutarı sınırlı, süreli ve tek kullanımlı jetonlar kullanır; böylece ajan ham kart verisini hiç tutmaz. Sipariş onayı itilir: satıcılar HMAC imzalı, tam nesne içeren webhook’ları POST eder. Satıcı kayıtlı satıcı olarak kaldığı için mutabakat, iadeler ve ters ibrazlar satıcı ile PSP’sine aittir; ancak ters ibraz kanıt çerçevesi 2026 ortası itibarıyla gerçekten çözülmemiştir. Sistemi açmadan önce idempotent güvenli yeniden denemeleri, webhook imza doğrulamasını ve müdahale yollarını geliştirip test edin.

Kapsam: protokolün tamamı değil, işlem adımı

Ajan tabanlı ödeme tek bir yetenektir. ACP’de kelimenin tam anlamıyla beş bloktan biri olan Agentic Checkout bloğudur; diğerleri Product Feed, Delegate Payment, Delegate Authentication ve Orders/Webhooks’tur. UCP’de ise yetenek uzlaşısına dayalı daha geniş bir teknik özellik içindeki ödeme yeteneğidir. ACP ve UCP hakkındaki kardeş yazılar, akış kalitesi, /.well-known/ucp profili ve Mart 2026 değişikliğinin keşif etkileri dâhil protokolü ve ticari bağlamı ele alır. Bu sayfa işlemi tamamlama mekaniklerine odaklanır: oturum yaşam döngüsü, ödeme yetkilendirmesi, insanın devreye girdiği yer, sipariş onayı ve sorumluluk.

ACP hakkındaki kardeş yazıdan burada da geçerli olan ve yeniden tartışmayacağımız bir çerçeve: ajanlar taranmış HTML’nizle değil, akışlar ve API’lerle işlem yapar. Dolayısıyla burada optimize edilen, sayfa metni değil ödeme güvenilirliğidir.

Ödeme oturumu durum makinesi

Ajan tabanlı ödemeyi diğerlerinden ayıran ve çoğu açıklamanın atladığı en önemli nokta şudur: ödeme, durumu olan bir oturumdur ve bu durum tanımlı bir makine içinde ilerler.

ACP’nin Checkout referansı tam durum listesini verir: incomplete, not_ready_for_payment, requires_escalation, authentication_required, ready_for_payment, pending_approval, complete_in_progress, completed, canceled, in_progress ve expired. Başarılı yol kısadır: not_ready_for_payment → ready_for_payment → in_progress → completed; diğer son durum canceled olarak tanımlanır. ACP’nin yaşam döngüsü kavramlarına göre gerekli teslimat seçeneğinin sağlanması, oturumu not_ready_for_payment durumundan ready_for_payment durumuna geçirir; başarısız ödeme ise yeniden denemek için oturumu ready_for_payment durumuna döndürebilir.

Asıl ilginç durumlar, başarılı yolun dışında kalanlardır:

• requires_escalation / authentication_required — ajan tek başına ilerleyemez; bir insan veya ek doğrulama gerekir (sonraki bölüme bakın).
• pending_approval — B2B satın alma siparişi onayı gibi bir onay bekleniyor.
• expired — oturum zaman aşımına uğradı (CheckoutSession, expires_at alanını taşır).

Bu, incomplete → requires_escalation → ready_for_complete zincirini izleyen UCP ödemesiyle aynı temel tasarımdır. Burada requires_escalation, denetimi bir continue_url aracılığıyla insana devreder (UCP kardeş yazısında ele alınmıştır). İki ayrı protokol, aynı noktada birleşen tek desen: ödeme bazen insana bir şey sormak için durmadan tamamlanamaz. Bu sonradan eklenmiş bir sınırlama değil, tasarımın temel biçimidir.

ACP ile entegrasyon kuranlar için pratik bir not: hatalı biçimlendirilmiş bir istek, HTTP düzeyinde bir hata nesnesi (type değeri invalid_request, request_not_idempotent, processing_error veya service_unavailable) döndürür. Buna karşın, biçimsel olarak geçerli bir oturumdaki iş mantığı sorunu HTTP hatası olarak değil, oturumun messages[] dizisindeki bir MessageError nesnesi olarak gelir. İkisini de ele almalısınız; erken entegrasyon çalışmalarında karıştırılmaları kolaydır.

Ödeme yetkilendirmesi nasıl çalışır?

Ödeme yetkilendirme katmanının temel amacı, ham kart verisinin ajana hiç ulaşmamasıdır. Alıcının ödeme bilgileri, ajana kart numarası vermek yerine kapsamı sınırlı bir jetona dönüştürülür.

OpenAI Delegated Payment teknik özelliğine göre yetkilendirilmiş ödeme verisi doğrudan satıcının PSP’sine veya kasasına gönderilir. PSP veya kasa, PCI kapsamı dışındaki yetkilendirilmiş ödemeyle sınırlı bir ödeme jetonu döndürür. Bu jeton dört eksende sınırlıdır:

• reason — şu anda "one_time": tek kullanımlı.
• max_amount — tahsilatı ödeme toplamıyla sınırlar; jeton fazla tahsilat için kullanılamaz.
• expires_at (RFC 3339) — jetonun kesin bir son kullanma zamanı vardır.
• merchant_id + checkout_session_id — tek satıcıya ve tek oturuma bağlıdır.

Dolayısıyla yetkilendirilmiş bir jeton satıcıya kilitli, tutarı sınırlı, süreli ve tek kullanımlıdır. Bu mekanizma, yeniden kullanılabilir kart bilgileri ajana emanet edilmeden ajanın “para harcamasını” sağlar. ACP tarafında Stripe’ın Shared Payment Token uygulaması, Delegated Payment Spec ile uyumlu ilk uygulama olarak tanımlanır; başka PSP’lerin de eklenmesi beklenir. UCP ise ödeme araçlarını işleyicilerden ayıran, paralel ve ayrıştırılmış bir model kullanır (UCP hakkındaki kardeş yazıda ele alınmıştır).

PCI kapsamı burada gerçek bir karardır. OpenAI’ın teknik özelliği, Delegated Payment Spec ile doğrudan entegrasyonun kart sahibi verilerini doğrudan işlemek anlamına geldiğini, PCI kapsamınızı etkileyebileceğini ve PCI DSS Level 1 statüsü gerektirdiğini açıkça belirtir. Çoğu satıcı için jetonlaştırılmış yol (ağ jetonları veya yetkilendirmeyi yöneten bir PSP), kart sahibi verilerini kendi ortamının dışında tutmanın yoludur. “CHD’yi doğrudan işle” ile “PSP jetonlaştırsın” arasındaki seçim ilk mimari karardır; Karar sekmesi bu seçimi sırayla ele alır.

İnsan nerede devreye girmeye devam eder?

“Alışveriş yapan kişi yine de yetki veriyor” ifadesi doğrudur ama belirsizdir. Protokol düzeyindeki tetikleyiciler nettir; bunları adlandırmak, sessiz bir çıkmaza girmek yerine devir akışını tasarlamanızı sağlar:

• 3-D Secure / ek doğrulama. ACP bunu InterventionCapabilities ile modeller: desteklenen türlere 3ds ve address_verification, enforcement düzeyine always / conditional / optional, display_context değerine ise native / webview / modal / redirect dâhildir. Ek doğrulamanın sonucu authenticated, denied, rejected, abandoned, canceled veya not_supported gibi değerler içeren bir AuthenticationResult olarak döner.
• requires_escalation / authentication_required durumları. Bunlar, “ilerlemeden önce bir insana veya ek kontrole ihtiyacım var” diyen oturum durumlarıdır.
• B2B approval_required. PaymentData nesnesi B2B alanlarını (purchase_order_number, payment_terms, due_date, approval_required) taşır; ajan tabanlı ödeme yalnızca DTC için değildir.
• UCP continue_url devri. UCP’nin requires_escalation durumu, alıcının oturum açma, onay veya yaş kontrolü gibi işlemleri kendisinin tamamlayacağı bir continue_url sunar. Aynı bağlantı noktası, farklı protokol.

Sonuç: sorunsuz biçimde müdahaleye geçen bir işlem, sessizce çıkmaza giren bir işlemden çok daha iyidir. Müdahale yollarını hata durumu olarak değil, birinci sınıf akışlar olarak tasarlayın.

Sipariş onayı çekilmez, itilir

Rakip açıklamaların çoğunlukla atladığı bir nokta: satın alma işleminden sonra ajan platformu, sipariş durumunu öğrenmek için API’nizi sürekli yoklamaz. Satıcı, imzalı webhook’ları platforma iter.

ACP webhook referansına göre satıcılar, ajan platformunun teslimat düzeyindeki gerçekle eşzamanlı kalabilmesi için sipariş olaylarını POST eder. Bunu iki olay türü taşır: yeni siparişler için order_create, durum değişiklikleri için order_update. Belirtilen sipariş durumu değerleri arasında created, manual_review, confirmed, canceled, shipped ve fulfilled bulunur. Uygulayan herkes için üç ayrıntı önemlidir:

• İstekler, Merchant-Signature başlığındaki HMAC imzasıyla imzalanmalıdır. İmzasız veya hatalı imzalanmış istekler 401 alır.
• data alanı, artımlı farkları değil tam Order nesnesini içermelidir. Her seferinde durumun tamamını gönderirsiniz.
• Ele alınacak yanıt kodları: başarı için 200, geçersiz imza için 401, hız sınırı için 429.

Dolayısıyla “platform siparişin gerçekleştiğini nasıl bilir?” sorusunun somut bir yanıtı vardır: imzalı ve tam nesne içeren bir POST ile siz bildirirsiniz; platformun 429 geri basıncını da siz yönetirsiniz.

Dolandırıcılık, ters ibrazlar ve sorumluluk: kesinleşen ve açık kalan konular

Bu en açık sözlü ve en ayırt edici bölüm; bu nedenle “karara bağlanmış” ile “açık” arasındaki sınırı net biçimde anlatacağım.

Karara bağlanmış konu: kayıtlı satıcı. OpenAI’ın kendi ödeme teknik özelliği, OpenAI’ın kayıtlı satıcı olmadığını belirtir. ACP kapsamında satıcılar kendi PSP’lerini getirir; mutabakat, iadeler, ters ibrazlar ve uyumluluk satıcı ile PSP’sinde kalır. Rye’dan Arjun Bhargava bunu bağımsız olarak doğrular: her iki protokol de satıcıyı; teslimat, ters ibraz ve uyuşmazlıklardan sorumlu kayıtlı satıcı olarak tutar. Bu, iki kardeş sayfadaki kayıtlı satıcı çerçevesiyle tutarlıdır; bunu yeniden türetmek yerine ileriye taşıyın.

Karara bağlanmamış konu: ters ibraz kanıt çerçevesi. Kayıtlı satıcı kuralı, uyuşmazlığı varsayılan olarak kimin üstleneceğini söyler. “Müşteri” bir yapay zekâ ajanı aracılığıyla işlem yaptığında itirazı nasıl kazanacağınızı söylemez. Geleneksel ters ibraz savunması, insanın oluşturduğu kanıt izlerine (IP, cihaz, gezinme davranışı, “satın al” düğmesine basan insan) dayanır. Ajanın oluşturduğu yetkilendirme kayıtları farklı bir kanıt türüdür ve kart ağı uyuşmazlık kuralları bunlar için yazılmamıştır. Chargeflow’un dolandırıcılık uzmanı Ben Herut, ajan tabanlı ticaretin eski sistemlerin yorumlayamadığı yeni bir dolandırıcılık ve kafa karışıklığı katmanı getirdiğini söyler. Chargeflow’un analizi daha da nettir: henüz temiz yanıtlar yoktur; kart ağları, ihraççılar ve platform sağlayıcıları bu sorular üzerinde çalışmaktadır.

Ortaya çıkan çerçeveler henüz tamamlanmış değil. Visa’nın Trusted Agent Protocol çözümü, kullanıcı deneyimini bozmadan kimliğe bürünmeyi önlemek üzere satıcıların ajan kimliğini ve niyetini gerçek zamanlı doğrulamasını sağlayan standart tabanlı bir çerçeve olarak tanımlanır. Mastercard’ın Nisan 2025’te duyurulan Agent Pay çözümü, Digital Enablement Service hizmetinin uzantısı olan “Agentic Tokens” kullanır. Üçüncü taraf haberlerine (Fintech Wrap Up / Finextra) göre Mastercard sorumluluğunun standart jetonlaştırılmış işlemlerle aynı kuralları izlediği; jeton geçerli biçimde ihraç edilip yetkilendirmede kabul edildiğinde dolandırıcılık sorumluluğunu ihraççının taşıdığı söyleniyor. Ancak bu belirli dağılım Mastercard’ın kendi belgelerinde yer alana kadar bildirilmiş, doğrulanmamış kabul edilmelidir. Visa’nın tüketicilere yönelik sıfır sorumluluk garantisi, kart sahiplerini yetkisiz tahsilatlardan korur; asıl açık soru olan satıcı tarafındaki uyuşmazlığı çözmez. İkisini karıştırmayın.

Satıcıların geliştirip test etmesi gerekenler

Mevcut içerik stratejik hazırlık önerileri sunar (temiz akışlar, sadakat programları). Burada ise operasyon katmanı var: sistemi açmadan önce gerçekte geliştirmeniz ve doğrulamanız gerekenler:

• PCI duruşunuza karar verin. Jetonlaştırılmış/ağ jetonu yolu ile doğrudan CHD işleme (Level 1) arasında seçim yapın. Çoğu satıcı yetkilendirmeyi PSP’nin tutmasını ister.
• Yeniden denemeleri idempotent güvenli yapın. ACP’de request_not_idempotent hata türü boşuna yoktur. Bir ajan veya kararsız ağ, oluşturma/tamamlama çağrısını yeniden deneyecektir. Bir idempotency anahtarı gönderin ve aynı anahtarlı yinelenen çağrıları güvenli hale getirin; böylece iki kez tahsilat veya sipariş oluşturmazsınız.
• Webhook imzalarını doğrulayın. Gelen her sipariş webhook’unda Merchant-Signature HMAC değerini doğrulayın, uyuşmazlıkta reddedin ve yük altında 200/429 yanıtlarını doğru döndürdüğünüzü onaylayın.
• Müdahale yollarını sandbox’ta benzetin. requires_escalation / authentication_required durumlarını zorlayın, 3DS ek doğrulaması çalıştırın ve AuthenticationResult işlemenizin yalnızca authenticated değil, denied/rejected/abandoned sonuçlarını da kapsadığını doğrulayın.
• Akış/ödeme fiyat eşitliğini uzlaştırın. Ajan akışta bir fiyat görüp ödemede başka fiyatla karşılaşırsa güven hızla azalır. ACP kardeş yazısı bunu akışlar için açıklar; en sert etkisi ödeme sırasında görülür.
• Ajan siparişi ilişkilendirmesini kurun. Tamamlanan ajan tabanlı ödeme, GA4 oturumu olmadan gelebilir. Web sitesi ziyareti beklemek yerine sipariş/OMS düzeyinde izleyin.

Test SOP’si ve Kısa Başvuru sekmeleri bunu somut bir test turuna dönüştürür.

2026 ortasında gelinen nokta

Sunuma değil, benimsenme gerçeğine dayanın. Shopify başkanı Harley Finkelstein, yalnızca yaklaşık bir düzine Shopify satıcısının yapay zekâ ödeme araçlarını etkin olarak kullandığını belirtti; bu sayı Shopify’ın toplam satıcı tabanına kıyasla önemsizdir. OpenAI da katılım, doğruluk ve çok ürünlü sepet zorluklarının ardından Instant Checkout’un tamamen sohbet içi sürümünü Mart 2026’da keşif ve yönlendirme modeline daralttı. Semrush’tan Leigh McKenzie sürtünmeyi iyi özetledi: on milyonlarca SKU için gerçek zamanlı katalog normalleştirme on yıllık ölçekte bir sorundur; tüketiciler de Apple Pay, Google Wallet ve Amazon tek tıkla satın alma gibi güvendikleri ödeme akışlarını varsayılan olarak kullanır.

Bunların hiçbiri ajan tabanlı ödemenin hayal ürünü olduğu anlamına gelmez. Protokol yeteneği — bir oturumu program aracılığıyla oluşturma/güncelleme/tamamlama, yetkilendirilmiş ödeme ve imzalı sipariş webhook’ları — gerçektir, tanımlanmıştır ve buna göre geliştirme yapmaya değer. Yalnızca “zaten olağan” değildir; son adımın sohbet içinde mi yoksa sitenizde mi tamamlandığı, bir kez değişmiş ve yeniden değişebilecek bir uygulama ayrıntısıdır.

Yapay zekâ özeti

Gelişmiş sürümün kısa özeti:

• Ajan tabanlı ödeme, ajan tabanlı ticaretin işlem tamamlama adımıdır: ajan, alışveriş yapan kişi adına bir ödeme oturumu oluşturur, günceller, tamamlar veya iptal eder. ACP’nin bir, UCP’nin de bir yapı taşıdır; bağımsız protokol değildir.
• Bir durum makinesidir. ACP: not_ready_for_payment → ready_for_payment → (requires_escalation/authentication_required) → completed; başarılı yol dışında canceled, expired, pending_approval bulunur. UCP’nin incomplete → requires_escalation → ready_for_complete zincirini yansıtır.
• Müdahale durumları insan denetimi bağlantısıdır: oturum açma, 3DS ek doğrulaması, adres kontrolü, B2B approval_required, UCP continue_url. Teknik özellikler tamamen özerk ve insansız ödemeye göre tasarlanmamıştır.
• Ödeme, kapsamı sınırlı jetonlar kullanır: satıcıya kilitli (merchant_id + checkout_session_id), tutarı sınırlı (max_amount), süreli (expires_at), tek kullanımlı (reason: one_time). Ajan ham kart verisini hiç tutmaz. Doğrudan CHD işlemek PCI kapsamını (Level 1) etkiler; çoğu satıcı PSP/jetonlaştırılmış yolu kullanır.
• Sipariş onayı itilir: satıcılar HMAC imzalı (Merchant-Signature), tam nesne içeren webhook’ları (order_create/order_update) POST eder ve 200/401/429 yanıtlarını ele alır.
• Sorumluluk: satıcı kayıtlı satıcı olarak kalır (OpenAI teknik özelliğine göre mutabakat/iadeler/ters ibrazlar satıcı + PSP’dedir); ancak bir yapay zekâ ajanının yaptığı satın almaya itiraz etme kanıtı sorunu 2026 ortası itibarıyla çözülmemiştir. Visa TAP ve Mastercard Agent Pay tamamlanmış değil, gelişen çerçevelerdir.
• Test edin: idempotent güvenli yeniden denemeler (request_not_idempotent), webhook imza doğrulaması, benzetilmiş müdahale/3DS yolları, akış/ödeme fiyat eşitliği, ajan siparişi ilişkilendirmesi (GA4 oturumu yoktur).
• Benimsenme erken aşamadadır: OpenAI’ın Mart 2026’da keşif ve yönlendirmeye geçişinden önce yaklaşık bir düzine canlı Shopify satıcısı vardı.

resmî dokümantasyon

Ödeme mekanikleri için birincil kaynak belgeleri.

ACP — ödeme, yaşam döngüsü, webhook’lar

• ACP Checkout API reference — ödeme oturumu uç noktaları, tam durum listesi, CheckoutSession alanları, hata/MessageError nesneleri, RiskSignals, AuthenticationResult ve InterventionCapabilities.
• ACP Checkout lifecycle / concepts — durum geçişleri (teslimat seçeneği → ready_for_payment; başarısız ödemeyi yeniden deneme).
• ACP Order webhooks — order_create/order_update, Merchant-Signature HMAC gereksinimi, tam nesne veri yükleri, yanıt kodları.
• GitHub’da ACP teknik özelliği — OpenAPI/JSON Schema ve tarihe dayalı sürümler.

OpenAI / Stripe — ödeme yetkilendirmesi

• OpenAI Delegated Payment spec — kapsamı sınırlı jeton akışı, izin nesnesi (max_amount, expires_at, merchant_id, checkout_session_id, reason), PCI kapsamı notu, kayıtlı satıcı dili.
• OpenAI Commerce docs — satıcı entegrasyonuna genel bakış.
• Stripe — Agentic Commerce (ACP) — Delegated Payment ile uyumlu ilk uygulama olan Shared Payment Token.
• Stripe — ACP protocol specification — ödeme uç noktalarını geliştirme.

UCP (paralel ödeme durum makinesi)

• Google for Developers — UCP kılavuzu — Google/Shopify tarafındaki kayıtlı satıcı ve uygunluk çerçevesi.

Platform / ödeme ağı

• Shopify — Agentic Storefronts gereksinimleri — Ek Koşullar ve araştırma tarihindeki Google AI Mode/Gemini erken erişim durumu.
• Visa — Ajan tabanlı ticaret: Tehditler ve riskler — Trusted Agent Protocol çerçevesi.

Kaynaktan alıntılar

Ajan tabanlı ödemenin nasıl çalıştığı ve hangi soruların açık kaldığı hakkında kayda geçmiş açıklamalar. Kaynak sayfa desteklediğinde derin bağlantılar doğrudan alıntılanan pasaja gider.

ACP / OpenAI — teknik özellik

• “Merchant maintains full control over inventory, pricing, tax calculations, and payment processing.” (Türkçe çeviri) “Satıcı; stok, fiyatlandırma, vergi hesaplamaları ve ödeme işleme üzerinde tam denetimi korur.” — ACP Checkout API reference. Alıntıya gidin
• Ödeme durum listesinin birebir metni: “incomplete not_ready_for_payment requires_escalation authentication_required ready_for_payment pending_approval complete_in_progress completed canceled in_progress expired.” (Türkçe çeviri) “Bunlar teknik özellikteki ödeme durumu adlarının birebir listesidir.” — ACP Checkout API reference. Alıntıya gidin
• “OpenAI is not the merchant of record.” (Türkçe çeviri) “OpenAI kayıtlı satıcı değildir.” ACP kapsamında satıcılar kendi PSP’lerini getirir; mutabakat, iadeler, ters ibrazlar ve uyumluluk satıcı ile PSP’sinde kalır. — OpenAI Delegated Payment spec. Alıntıya gidin
• Jeton akışı hakkında: PSP veya kasa, PCI kapsamı dışında “payment token scoped to the delegated payment” (Türkçe çeviri) “yetkilendirilmiş ödemeyle kapsamı sınırlandırılmış ödeme jetonu” döndürür. — OpenAI Delegated Payment spec. Alıntıya gidin

Sektörden görüşler — sorumluluk sorusu

• “Agentic commerce brings efficiency, but also a new layer of fraud and confusion that legacy systems cannot interpret.” (Türkçe çeviri) “Ajan tabanlı ticaret verimlilik getirirken eski sistemlerin yorumlayamadığı yeni bir dolandırıcılık ve belirsizlik katmanı da getirir.” — Ben Herut, Chargeflow Dolandırıcılık ve Ters İbraz Stratejisti. Haberi okuyun
• Kuralların kesinleşip kesinleşmediği hakkında: Chargeflow analizine göre “there are no clean answers yet” (Türkçe çeviri) “henüz net yanıtlar yok”; kart ağları, ihraççılar ve platform sağlayıcıları bu sorular üzerinde çalışıyor. Haberi okuyun
• “Both protocols keep the merchant as the merchant of record — responsible for fulfillment, chargebacks, and disputes.” (Türkçe çeviri) “Her iki protokol de satıcıyı sipariş karşılama, ters ibrazlar ve uyuşmazlıklardan sorumlu kayıtlı satıcı olarak tutar.” — Arjun Bhargava, Rye Kurucu Ortağı ve CEO’su. Haberi okuyun

Ödeme ağları — gelişmekte olan çerçeveler

• Visa’nın yaklaşımı hakkında: Trusted Agent Protocol, “a standards-based framework enabling merchants to verify agent identity and intent in real time, preventing impersonation without degrading user experience.” (Türkçe çeviri) “Satıcıların ajan kimliğini ve niyetini gerçek zamanlı doğrulamasını sağlayarak kullanıcı deneyimini bozmadan kimliğe bürünmeyi önleyen, standartlara dayalı bir çerçeve.” — Visa, Ajan tabanlı ticaret: Tehditler ve riskler. Alıntıya gidin

Benimsenme gerçeği

• Tamamen özerk ödemenin neden söylentilerden daha yavaş ilerlediği hakkında: “Real-time catalog normalization across tens of millions of SKUs is a decade-scale problem Google already solved with Merchant Center, and consumers still default to checkout flows they trust—Apple Pay, Google Wallet, and Amazon one-click.” (Türkçe çeviri) “On milyonlarca SKU genelinde gerçek zamanlı katalog normalleştirme, Google’ın Merchant Center ile zaten çözdüğü on yıllık ölçekte bir sorundur; tüketiciler de Apple Pay, Google Wallet ve Amazon tek tık gibi güvendikleri ödeme akışlarını varsayılan olarak kullanmayı sürdürür.” — Leigh McKenzie, Director of Online Visibility, Semrush; Search Engine Land aracılığıyla. Haberi okuyun

Hangi ödeme entegrasyonu yolunu seçmelisiniz?

Ajan tabanlı ödemedeki ilk gerçek mimari karar, ödemenin nasıl yetkilendirileceğidir; çünkü bu karar PCI kapsamınızı ve geliştirmeniz gereken miktarı doğrudan belirler. Sırayla ilerleyin:

Ajan tabanlı ödeme için lansman öncesi test turu

Bunu üretimde ajan tabanlı ödemeyi etkinleştirmeden önce sandbox/test modunda çalıştırın. Stratejik “akışınızı temizleyin” önerisinin atladığı operasyon katmanı budur.

1. Bir ödeme oturumu oluşturup başarılı yolu izleyin. POST /checkout_sessions isteği gönderin; 201 ve not_ready_for_payment (veya incomplete) durumunda bir oturum aldığınızı doğrulayın. Teslimat seçeneği ekleyin ve durumun ready_for_payment değerine geçtiğini onaylayın.
2. Toplamların yetkili kaynak olduğunu doğrulayın. Oturumun totals[] değerlerinin (ara toplam / vergi / teslimat / indirimler / toplam) arka ucunuzun hesaplamalarıyla ve fiyatın akışınızdaki fiyatla eşleştiğini onaylayın. Akış/ödeme fiyat uyuşmazlığı güveni yok eder.
3. Oturumu tamamlayın. POST /checkout_sessions/{id}/complete isteği gönderin; ödemenin işlendiğini, siparişin oluştuğunu ve durumun completed değerine ulaştığını doğrulayın.
4. Oturumu iptal edin. POST /checkout_sessions/{id}/cancel isteği gönderin; ayrılan stokun sızıntı yapmaması için serbest bırakıldığını onaylayın.
5. Müdahale yollarını zorlayın. requires_escalation / authentication_required durumlarını benzetin. Bir 3DS ek doğrulaması çalıştırın ve AuthenticationResult işlemenizin yalnızca authenticated değil, başarısızlık sonuçlarını (denied, rejected, abandoned, canceled, not_supported) da kapsadığını onaylayın.
6. Idempotency’yi test edin. Aynı idempotency anahtarıyla aynı oluşturma/tamamlama isteğini iki kez gönderin; iki değil tek sipariş aldığınızı ve gerçekten idempotent olmayan yeniden denemenin iki kez tahsilat yerine request_not_idempotent ürettiğini doğrulayın.
7. İş mantığı hataları ile HTTP hatalarını test edin. Oturum içi bir sorun (stokta olmayan satır öğesi gibi) tetikleyin; bunun messages[] içinde MessageError olarak, hatalı biçimlendirilmiş isteğin ise HTTP düzeyinde hata nesnesi olarak geldiğini doğrulayın. İstemciniz ikisini de ele almalıdır.
8. Webhook imzalarını doğrulayın. Geçerli bir order_create webhook’u gönderip Merchant-Signature HMAC değerini doğruladığınızı ve 200 döndürdüğünüzü onaylayın. Değiştirilmiş bir webhook gönderip 401 ile reddettiğinizi doğrulayın. Fark değil, tam Order nesnesi gönderdiğinizi onaylayın.
9. Webhook geri basıncını test edin. Göndericinizin platformdan gelen 429 yanıtında olayı bırakmak yerine yeniden deneme/geri çekilme uyguladığını doğrulayın.
10. İlişkilendirme kaydını doğrulayın. Tamamlanan siparişin OMS düzeyinde ajan kaynaklı olarak etiketlendiğini doğrulayın; bu sipariş için GA4 oturumu olmayacaktır.

Yaygın hatalar ve bunların yerine yapılacaklar

“Ajan tabanlı ödeme”nin tamamen özerk, insansız satın alma anlamına geldiğini varsaymak. Neden yanlış: güvenilir her uygulama bir yetkilendirme/müdahale bağlantısı tutar: requires_escalation, authentication_required, 3DS ek doğrulaması, B2B approval_required. İnsan denetimli yetkilendirme olmadan tam özerklik, ne teknik özelliklerin tasarımına ne de kart ağlarının bu işlemlere bugün yaklaşımına uyar. Bunun yerine: continue_url, 3DS ve onay gibi müdahale yollarını birinci sınıf akışlar olarak tasarlayın; insan gerektiren işlem çıkmaza girmek yerine sorunsuzca müdahaleye geçsin.

Başlıklar gürültülü olduğu için bunu zaten olağan kabul etmek. Neden yanlış: OpenAI Mart 2026’da sohbet içi sürümü daraltmadan önce yalnızca yaklaşık bir düzine Shopify satıcısı ChatGPT ödemesini canlıya almıştı. Bunun yerine: gerçek ve tanımlanmış olan protokol yeteneğine göre geliştirin; ancak planlamayı ve personeli, geriden yetişen değil erken benimseyen olduğunuzu kabul ederek yapın.

“Kayıtlı satıcı” konusu kesinleştiği için dolandırıcılık sorumluluğunun tamamen çözüldüğüne inanmak. Neden yanlış: mutabakat/iadeler/uyumluluk açısından kayıtlı satıcı doğrulanmıştır; ancak alıcı bir yapay zekâ ajanı olduğunda itiraz edilen işlemin doğru yetkilendirildiğini kanıtlayan ters ibraz kanıt çerçevesi, sektörün dolandırıcılık uzmanları tarafından açıkça çözülmemiş olarak tanımlanıyor. Bunun yerine: ajan yetkilendirme kayıtlarını ve risk sinyallerini şimdiden yakalayın; Visa TAP/Mastercard Agent Pay’i tamamlanmış değil, gelişen çerçeveler olarak görün ve mevcut ters ibraz savunma kanıtınızın aynen aktarılacağını varsaymayın.

Ajan web sitenizi atladığı için site içi ödemenin önemsiz olduğunu varsaymak. Neden yanlış: “satıcının sitesini her zaman atlar” ifadesi ChatGPT Instant Checkout’un ilk vaadiydi; ancak ACP’nin amiral uygulaması Mart 2026’da keşif ve yönlendirme modeline geçti. Protokol yeteneği belirli bir uygulamaya bağlı değildir. Bunun yerine: kendi barındırdığınız ödemeyi sağlam tutun ve programlı oturum akışını destekleyin; kullanılan yüzeye göre işlemi sohbet içinde veya sitede tamamlayabilirsiniz.

Ajanın müşterinin kart numarasını işlediğini düşünmek. Neden yanlış: tasarım gereği ham kart verisi ajana hiç ulaşmaz. Kapsamlı/yetkilendirilmiş jetonlar (Shared Payment Token, UCP’nin ayrıştırılmış araç/işleyici modeli), ödeme yetkilendirme katmanının asıl amacıdır. Bunun yerine: satıcıya kilitli, tutarı sınırlı ve tek kullanımlı jetonun işi yapması için yetkilendirmeyi PSP’niz üzerinden yönlendirin; PCI kapsamınızı küçük tutun.

Idempotent olmayan yeniden deneme yönetimi. Neden yanlış: ajanlar ve ağlar yeniden dener. ACP’de request_not_idempotent hata türü vardır; çünkü saf yeniden denemeler iki kez tahsilat veya sipariş oluşturabilir. Bunun yerine: oluşturma/tamamlama işlemlerinde idempotency anahtarlarını zorunlu kılın ve aynı anahtarlı yinelenen çağrıları güvenli hale getirin.

Ajan tabanlı ödeme — kısa başvuru

ACP ödeme oturumu durum numaralandırması

UCP’nin paralel makinesi: incomplete → requires_escalation (insan aracılığıyla continue_url) → ready_for_complete.

Ödeme uç noktaları (ACP)

• POST /checkout_sessions — oluştur (201)
• GET /checkout_sessions/{id} — getir
• POST /checkout_sessions/{id} — güncelle
• POST /checkout_sessions/{id}/complete — ödemeyi işle + sipariş oluştur
• POST /checkout_sessions/{id}/cancel — iptal et + stoku serbest bırak

Kapsamı sınırlı ödeme jetonu — dört sınır

• merchant_id + checkout_session_id → satıcıya ve oturuma kilitli
• max_amount → tutarı sınırlı
• expires_at (RFC 3339) → süreli
• reason: "one_time" → tek kullanımlı

Sipariş webhook’ları (ACP)

• Olaylar: order_create, order_update
• İmza: Merchant-Signature HMAC başlığı (zorunlu)
• Veri yükü: farklar değil, tam Order nesnesi
• Yanıtlar: 200 başarılı · 401 hatalı imza · 429 hız sınırlı
• Sipariş durumları: created · manual_review · confirmed · canceled · shipped · fulfilled

İnsan müdahalesi tetikleyicileri

• requires_escalation / authentication_required durumları
• InterventionCapabilities (3ds, address_verification; zorlama always/conditional/optional)
• AuthenticationResult sonuçları (authenticated/denied/rejected/abandoned/…)
• B2B approval_required; UCP continue_url

Bir bakışta sorumluluk

• Satıcı = kayıtlı satıcı → mutabakat/iadeler/ters ibrazlar satıcı + PSP’de ✅ kesinleşmiş
• Ajan alıcılar için ters ibraz kanıt kuralları ⚠️ çözülmemiş (2026 ortası)
• Visa TAP / Mastercard Agent Pay → tamamlanmış değil, gelişen çerçeveler

Ajan tabanlı ödemeyle çalışmak için kod parçacıkları

Bunlar canlı satın almaları yönlendirmek için değil, kendi entegrasyonunuzu incelemek ve test etmek içindir. Sandbox/test kimlik bilgilerini kullanın.

Webhook imzasını doğrulayın (Node.js, HMAC)

Merchant-Signature değeri eşleşmeyen her şeyi reddedin. Sabit zamanda karşılaştırın.

import crypto from "node:crypto";

// secret = your shared webhook signing secret; rawBody = the exact bytes received
function verifyMerchantSignature(rawBody, signatureHeader, secret) {
  const expected = crypto
    .createHmac("sha256", secret)
    .update(rawBody)          // sign the raw body, not the parsed JSON
    .digest("hex");
  const a = Buffer.from(expected);
  const b = Buffer.from(signatureHeader || "");
  return a.length === b.length && crypto.timingSafeEqual(a, b);
}
// In your handler: if (!verify) return res.status(401).end();  // else 200

Ödeme oturumunun durumunu yoklayın (shell)

Test sırasında bir sandbox oturumunun durum makinesinde ilerleyişini izleyin.

# Retrieve a session and print just its status field (needs jq)
SESSION_ID="cs_test_123"
curl -s "https://api.example.com/checkout_sessions/$SESSION_ID" \
  -H "Authorization: Bearer $ACP_TEST_KEY" \
  | jq -r '.status'          # e.g. not_ready_for_payment → ready_for_payment → completed

Idempotency anahtarıyla oluşturma çağrısı gönderin (Python)

Aynı anahtarla yeniden denemenin iki değil tek sipariş oluşturduğunu kanıtlayın.

import uuid, requests

key = str(uuid.uuid4())  # reuse this SAME key on retry
headers = {
    "Authorization": f"Bearer {ACP_TEST_KEY}",
    "Idempotency-Key": key,
    "Content-Type": "application/json",
}
payload = {"line_items": [{"id": "sku_1", "quantity": 1}]}
r1 = requests.post(f"{BASE}/checkout_sessions", json=payload, headers=headers)
r2 = requests.post(f"{BASE}/checkout_sessions", json=payload, headers=headers)  # retry
print(r1.json().get("id") == r2.json().get("id"))  # expect True — same session, no dupe

Konsol kodu — oluşturulmuş bir sayfada .well-known UCP profili arayın

Bir satıcının UCP keşfini sunup sunmadığını hızlıca denetleyen DevTools Console kontrolü (satıcının kaynağında tarayıcı konsoluna yapıştırın):

fetch("/.well-known/ucp")
  .then(r => (console.log("status:", r.status), r.ok ? r.json() : null))
  .then(p => console.log("capabilities:", p && p.capabilities));

Yer imi kodu — ACP belgelerindeki ödeme durumu listesine gidin

ACP Checkout referansını durum listesinde açmak için bunu bir yer imine ekleyin:

javascript:location.href='https://www.agenticcommerce.dev/docs/reference/checkout#:~:text=incomplete';

Yaygın ajan tabanlı ödeme arızaları

Yeniden deneme iki sipariş veya tahsilat oluşturuyor

Belirti: zaman aşımı veya ağ yeniden denemesinden sonra aynı ödeme oturumu yinelenen siparişler oluşturuyor. Olası neden: oluşturma veya tamamlama çağrıları anahtarlanmamış ve yeniden oynatmaya güvenli değil. Düzeltme: idempotency anahtarı zorunlu kılın, aynı anahtarlı yeniden denemede ilk sonucu döndürün ve iki özdeş sandbox çağrısının tek oturum ile tek sipariş oluşturduğunu doğrulayın.

Ödeme hiçbir zaman ödemeye hazır duruma gelmiyor

Belirti: oturum not_ready_for_payment veya incomplete durumunda kalıyor. Olası neden: gerekli teslimat seçeneği, adres alanı veya iş kuralı çözülmemiş. Düzeltme: oturumun gerekli alanlarını ve messages[] dizisini inceleyin, eksik seçeneği sağlayın ve durumun ready_for_payment veya ready_for_complete değerine ilerlediğini doğrulayın.

Geçerli istek başarılı görünüyor ancak sepet tamamlanamıyor

Belirti: HTTP isteği başarılı olurken oturumda stokta bulunmayan ürün veya başka bir iş hatası var. Olası neden: istemci yalnızca HTTP hatalarını ele alıyor ve MessageError girdilerini yok sayıyor. Düzeltme: hem aktarım hatalarını hem oturum mesajlarını işleyin; ardından kullanıcının veya ajanın uygulanabilir hatayı gördüğünü doğrulayın.

İnsan doğrulaması sessizce çıkmaza girer

Belirti: ödeme requires_escalation veya authentication_required durumuna giriyor ve geri dönmüyor. Olası neden: 3DS, oturum açma, onay veya continue_url devri desteklenen durum yerine istisnai hata olarak ele alınmış. Düzeltme: oturumu devir boyunca kalıcı tutun, tüm kimlik doğrulama sonuçlarını ele alın ve hem başarılı hem terk edilmiş akışların sorunsuz çözümlendiğini doğrulayın.

Ödemeden sonra sipariş durumu güncellenmeyi bırakıyor

Belirti: satıcıda sipariş var ancak ajan yüzeyi beklemede veya eski durumda kalıyor. Olası neden: webhook imzası başarısız, yalnızca fark gönderilmiş veya 429 yanıtları düşürülmüş. Düzeltme: tam veri yükünü imzalayın, tam Order nesnesini gönderin, hızı sınırlanan olayları geri çekilmeyle yeniden deneyin ve alıcının olayı kabul ettiğini doğrulayın.

Ajan tabanlı ödeme için zihinsel modeller

Ödeme tek bir API çağrısı değil, bir durum makinesidir

Her yanıt oturumu bilinen bir duruma taşımalı veya neden ilerleyemediğini bilinen bir gerekçeyle açıklamalıdır. İstemcileri tek bir “satın al” isteği etrafında değil; geçişler, son durumlar, yeniden denemeler ve müdahaleler etrafında tasarlayın.

Yetki satıcıda kalır

Ajan niyeti ifade eder; ancak fiyat, stok, vergi, teslimat, sipariş durumu ve kayıtlı satıcı yükümlülüklerinde yetkili taraf satıcı olmaya devam eder. Ajanın istediği sepeti girdi, satıcının döndürdüğü sepeti gerçek kabul edin.

Yetkilendirme izni daraltır

Kapsamı sınırlı ödeme jetonu; satıcıya kilitli, oturuma bağlı, tutarı sınırlı, süreli ve tek kullanımlı olduğu için güvenlidir. Her yetkilendirilmiş yeteneği ne yapabildiğini, kimin için, ne kadarlık tutarda ve ne kadar süreyle yapabildiğini sorarak değerlendirin.

Müdahale başarılı bir daldır

İnsan müdahalesi, başarısız bir özerk ödeme değildir. Sorunsuz bir 3DS, oturum açma, adres veya B2B onay devri, protokolün tasarlandığı gibi çalışmasıdır.

Tamamlamadan sonra teslimat eşzamansızdır

Ödemenin tamamlanması entegrasyonu sona erdirmez. İmzalı, tam nesne içeren webhook’lar ödeme sonrası sipariş gerçeğini taşır; dolayısıyla imza doğrulama, yeniden oynatma güvenliği ve yeniden deneme yönetimi ödeme güvenilirliğinin parçasıdır.

Ajan tabanlı ödeme metrikleri

Son duruma göre ödeme tamamlanma oranı

• Metrik: başlatılan oturumlar içinde tamamlanan, iptal edilen veya süresi dolan oturumların payı.
• Ne anlatır: ödeme durum makinesinin nerede sona erdiğini ve sipariş oluşmadan önce ne kadar niyetin kaybolduğunu.
• Nasıl alınır: ticaret API’si veya sipariş platformundaki ödeme oturumu durum değişikliklerini protokol ve satıcı yüzeyine göre bölümleyerek toplayın.
• Karşılaştırma / gerçekçi aralık: kendi ürün karması için temel çizgi oluşturun ve benzer akışları karşılaştırın; bu benimsenme aşamasında savunulabilir evrensel oran yoktur.
• Sıklık: haftalık eğilim incelemesiyle günlük izleme.

Müdahaleden dönüş oranı

• Metrik: 3DS, oturum açma, adres veya onay müdahalesinden sonra geri dönüp tamamlanan müdahaleli oturumlar.
• Ne anlatır: insan devrinin kullanılabilir bir yol mu yoksa çıkmaz mı olduğunu.
• Nasıl alınır: ödeme oturumu kimliğini kullanarak müdahale olaylarını sonraki durum geçişleriyle birleştirin.
• Karşılaştırma / gerçekçi aralık: kimlik doğrulama ile B2B onayı farklı sürtünmeye sahip olduğu için her müdahale türünün temel çizgisini ayrı belirleyin.
• Sıklık: haftalık ve her devir akışı değişikliğinden sonra.

Yinelenen sipariş ve webhook arıza oranı

• Metrik: aynı anahtarlı yeniden denemelerden kaynaklanan yinelenen siparişler ile reddedilen veya deneme hakkı tükenen webhook teslimatları.
• Ne anlatır: arıza sırasında idempotency ve eşzamansız sipariş eşzamanlamasının güvenli olup olmadığını.
• Nasıl alınır: uygulama günlüklerinde idempotency anahtarlarını, sipariş kimliklerini, imza hatalarını, 401 ve 429 yanıtlarını, yeniden denemeleri ve ölü mektup olaylarını karşılaştırın.
• Karşılaştırma / gerçekçi aralık: yinelenen sipariş sayısı sıfır olmalıdır; geçici yeniden denemeler için olağan temel çizgi belirleyin ve kalıcı sapmayı araştırın.
• Sıklık: anında uyarı, haftalık özet.

Zaman ayırmaya değer kaynaklar

İlgili yazılarım

• Ajan tabanlı ödemenin içinde yer aldığı iki protokol bu sitede ayrıntılı olarak ele alınıyor: Agentic Commerce Protocol (ACP) ve Universal Commerce Protocol (UCP) yazılarına bakın. Bu sayfa, ikisinin altında yer alan ödeme mekanikleri derinlemesine incelemesidir.
• The Beginner’s Guide to Ecommerce SEO — ajanlara yönelik ödemenin daha geniş e-ticaret tablosundaki yeri.

Konuşmalarım

• Arama nasıl çalışır? (SlideShare) — keşif, dizine ekleme ve sıralama hakkındaki anlatımım; ajan aracılı işlem katmanının bunun üzerine nasıl yerleştiğini anlamak için yararlı bir arka plan. (Kalıcı sorumluluk reddim geçerlidir: “This is my understanding of systems… not going to be 100% complete or accurate.” (Türkçe çeviri) “Bu, sistemlere ilişkin benim anlayışımdır; yüzde 100 eksiksiz veya doğru olmayabilir.”)

Sektörden kaynaklar

• Agentic Commerce Protocol — Ödeme referansı (OpenAI/Stripe) — yetkili durum listesi, oturum alanları ve müdahale/kimlik doğrulama nesneleri.
• OpenAI Delegated Payment spec — kapsamı sınırlı jeton akışı ve kayıtlı satıcı / PCI kapsamı dili.
• ACP Order webhooks reference (OpenAI/Stripe) — itmeye dayalı, HMAC imzalı, tam nesne içeren sipariş eşzamanlama mekanikleri.
• Ajan tabanlı ticarette ters ibrazlar: Yapay zekâ satın aldığında kim sorumlu? (Chargeflow) — kanıt sorunu hakkındaki açık sözlü “no clean answers yet” değerlendirmesi.
• Ajan tabanlı ticaret: Tehditler ve riskler (Visa) — Trusted Agent Protocol ve ajan kimliği çerçevesi.
• OpenAI’ın büyük ChatGPT Instant Checkout planı değişti (Search Engine Land) — Mart 2026 yön değişikliği ve benimsenme gerçeği alıntıları.
• Ajan tabanlı ödeme nedir? (Rye) — açık bir bağımsız tanım ve kayıtlı satıcı doğrulaması.
• Derinlemesine: Mastercard Verifiable Intent ve Visa Trusted Agent Protocol karşılaştırması (Fintech Wrap Up / Finextra) — karşılaştırılan ödeme ağı çerçeveleri (belirli sorumluluk dağılımını doğrulanmış değil, bildirilmiş olarak ele alın).

Alıntılamaya değer istatistikler

Ajan tabanlı ödemenin gerçekte bulunduğu noktayı çerçeveleyen sayılar: satıcıların bildirdiği ve aracılarla aktarılan rakamları yön gösterici kabul edin, bunlara dayanmadan önce doğrulayın.

• Shopify başkanına göre yapay zekâ ödeme araçlarını etkin olarak kullanan yaklaşık bir düzine Shopify satıcısı vardı; bu sayı Shopify’ın toplam satıcı tabanına kıyasla önemsiz olarak tanımlandı ve Mart 2026 değişikliğine ilişkin Search Engine Land haberi aracılığıyla aktarıldı. Haber
• Mart 2026: yön değişikliği. OpenAI, katılım, doğruluk ve çok ürünlü sepet sürtünmesinin ardından ChatGPT Instant Checkout’u tamamen sohbet içi satın alma tamamlamasından keşif ve yönlendirmeye taşıdı. Haber
• Jeton kapsamı = 4 sınır. Yetkilendirilmiş ödeme jetonu max_amount, expires_at, merchant_id/checkout_session_id ve reason: one_time ile sınırlandırılır; ham kartı ajandan uzak tutan somut mekanizma budur. Kaynak
• Webhook kuralı: her zaman tam nesne. ACP, webhook data alanının artımlı farklar yerine tam Order nesnesini taşımasını ve her isteğin HMAC ile imzalanmasını gerektirir. Kaynak

Kendinizi sınayın: Ajan Tabanlı Ödeme

Ödeme mekanikleri hakkında beş kısa soru. Her biri için bir yanıt seçin, ardından kontrol edin.

Değişiklik günlüğü