Delegated Payment
Kullanıcının payment credential veya harcama yetkisinin belirli tutar, süre ve kullanım koşullarıyla agent/merchant flow'una güvenli biçimde devredilmesidir.
Neden önemli?
Agentic commerce'da model reasoning ile deterministic transaction sistemleri aynı akışta buluşur. Tool erişimi, commerce state, payment authorization ve user intent aynı şey değildir; her katmanın sınırı ve authority modeli ayrı tanımlanmalıdır.
Pratikte nasıl görünür?
Bir travel agent önce MCP veya provider API üzerinden capability kullanabilir, sonra UCP/ACP benzeri commerce contract'ıyla checkout hazırlayabilir ve AP2/MPP/x402 gibi ayrı payment/authorization katmanları devreye girebilir. Bu protokoller aynı problemi çözmez.
Uygulamada sorulması gerekenler
- Agent hangi capability'lere erişebiliyor?
- Kullanıcı hangi işlem ve tutara açık yetki verdi?
- Transaction state'i modelden bağımsız deterministic sistemde mi tutuluyor?
- Audit trail ve human approval checkpoint'leri nerede?
Yaygın hatalar
- LLM kararını payment authorization kabul etmek
- Tool access ile purchase authority'yi aynı şey sanmak
- Protocol adlarını tek bir agentic-commerce standardı gibi kullanmak
Travel stack içinde nerede kullanılır?
Delegated Payment, çoğunlukla agentic katmanlarıyla ilişkilidir. İlgili sistemlerde source-of-truth, identity, freshness ve transaction ownership sınırlarını açık tanımlamak gerekir.
İlgili terimler
İlgili teknik içerikler
Agentic Travel Authorization, Mandate ve Human-in-the-Loop
AI agent'ın travel purchase ve servicing side-effect'leri için user intent, mandate, delegated authority ve human-in-the-loop checkpoint'lerini tasarlayın.
İncele →Agentic Travel Reference Architecture
AI agent → search → offer → reprice → confirmation → payment → booking → servicing akışını travel-specific authorization, idempotency ve audit sınırlarıyla tasarlayın.
İncele →Agentic Travel Transaction Safety
Agent loop, retry ve tool invocation kaynaklı duplicate booking/payment riskini idempotency, transaction guards ve UNKNOWN-aware recovery ile yönetin.
İncele →Idempotency ve Duplicate Booking Prevention
Travel booking create, payment, cancellation ve refund operasyonlarında idempotency sınırlarını ve duplicate booking önleme desenlerini tasarlayın.
İncele →NDC Offer/Order Lifecycle: Search'ten Servicing'e
NDC Offer/Order lifecycle'ını search, offer, revalidation, order create, payment, ticketing, servicing ve reconciliation state'leriyle modelleyin.
İncele →Order Confirmed but Ticket Not Issued Troubleshooting
Flight order confirmed görünürken ticket/document issuance tamamlanmadığında order, payment ve ticketing state'lerini ayrı teşhis edin.
İncele →