TotalApp Docs

Ödemeler & Takas İşlemleri

Akıllı ödeme yönlendirmeyi, ters ibraz ve itiraz savunmasını, takas ve mutabakatı, ve mali emaneti yöneten 4 ekran.

Bu grup ne yapar

Ödemeler & Takas İşlemleri, Financial Audit & Fintech Ops add-on'undaki son gruptur; akıllı ödeme yönlendirmeyi, ters ibraz/itiraz yönetimini, edinici banka (acquirer) takas partilerini ve sözleşmesel emaneti kapsar. Bu grupla birlikte add-on genelindeki 16 operasyonel ekranın tamamı implemente edilmiş olur. 4 ekranın tamamı, Genel Bakış sayfasında açıklanan aynı doğrudan-kayıt-başına iki aşamalı hibrit motoru kullanır (Aşama 1 embedding altyapısı, UI'ya bağlı değil; Aşama 2 AI motoru yönlendirmeli sentez).

Payout Routing Rules
Chargeback & Dispute
Settlement & Clearing
Financial Escrow

1. Payout Routing Rules

Amaç: Bir ödeme yönlendirme kuralının hedef gateway/rail'ini (Stripe, Adyen, FAST/EFT, SWIFT vb.), öncelik katmanını, ücret ek yükünü ve başarı oranını izleyen bir akıllı yönlendirme defteri — ödeme ekiplerinin genel gateway onay oranı sağlığını izlemesini ve bir rail'in hata oranı sıçradığında acil bir PSP failover'ı tetiklemesini sağlar.

Defter sütunları / temel alanlar

  • ID formatı PRR-YYYY-XXXX
  • ruleId, targetGatewayOrRails, priorityTier, feeOverheadPct, successRatePct, maxSingleTicket, currency
  • routingStatus (active_route / failover_active / disabled), countryCode, lastRunDate, aiRoutingDiagnostic, notes

Gösterge

Routing Efficiency Gauge — yalnızca devre dışı olmayan kayıtların ortalama başarı oranı — devre dışı rotalar ortalamadan tamamen hariç tutulur, sıfır olarak sayılmaz. Kayıt yoksa 0 döner.

Temel eylemler

  • Yeni Kayıt, AI Analiz Et (ödeme yönlendirme denetimini çalıştırır, bir yönlendirme teşhisi ve güven skoru üretir; hedef gateway/rail boşken devre dışıdır).
  • Force Gateway Failover Switch / Trigger Failover (satır aksiyonu, inline mini-form: yedek gateway) — hedef gateway'i yeni yedek gateway'e günceller, yönlendirme durumunu failover aktif olarak ayarlar ve değişikliği (eski gateway → yeni gateway) notlara ekler — bu kaydın kendi alanları üzerinde gerçek, doğrudan bir güncellemedir.
  • Silme — kalıcı, satır içi onay ile.

Bilinen sınırlama

Trigger Failover, gerçek canlı işlem trafiğini yönlendirmez. Uygulamada bugün hiçbir yerde bir ödeme gateway'i orkestrasyon/yürütme sistemi yoktur. Aksiyon, bu kaydın hedef-gateway ve yönlendirme-durumu alanlarını failover kararının sistem kaydı (system of record) olarak gerçekten günceller, ancak canlı trafiğin gerçek bir kesimi/aktarımı gerçekleşmez.

2. Chargeback & Dispute

Amaç: Bir kart şeması (card scheme) itiraz vakasını (fraud, tanınmayan işlem, ürün teslim edilmedi, diğer) tartışmalı tutarına, savunma son tarihine ve çözüm durumuna karşı izleyen bir ters ibraz (chargeback) defteri — portföy çapında representment (yeniden ibraz) kazanma oranını takip eder ve savunma son tarihinden önce kanıt paketlerinin hazırlanmasını sağlar.

Defter sütunları / temel alanlar

  • ID formatı CBD-YYYY-XXXX
  • disputeId, cardSchemeRef, merchantOrAccount, disputedAmount, currency
  • reasonCode (fraud / unrecognized_charge / item_not_received / other), aiWinProbabilityPct, defenseDueDate
  • disputeStatus (needs_evidence / representment_submitted / won / lost), countryCode, lastRunDate, aiDisputeDiagnostic, notes

Gösterge

Portfolio Dispute Win Ratio MeterÇözümlenmemiş itirazları hem payda hem paydanın dışında bırakır: hâlâ kanıt bekleyen veya zaten representment için gönderilmiş vakalar hiç sayılmaz. Formül, kazanılan vakaların (kazanılan + kaybedilen) vaka sayısına bölümü, çarpı 100'dür. Çözümlenmiş (kazanılan+kaybedilen) kayıt yoksa 0 döner. Bu kasıtlı bir tasarım kararıdır: henüz karara bağlanmamış vakaları saymak, gerçek representment performansını hâlâ devam eden vakalarla sulandırır.

Temel eylemler

  • Yeni Kayıt, AI Analiz Et (ters ibraz/itiraz denetimini çalıştırır, bir itiraz teşhisi ve kazanma-olasılığı skoru üretir; kart şeması referansı veya merchant/hesap boşken devre dışıdır).
  • Submit Representment Pack (satır aksiyonu, inline mini-form: kanıt özeti + belge referansları) — itiraz durumunu representment gönderildi olarak ayarlar ve kanıt özetini notlara loglar.
  • Silme — kalıcı.

Bilinen sınırlama

Submit Representment Pack, gerçek bir acquirer'a veya kart ağına herhangi bir belge iletmez. Uygulamada bugün hiçbir yerde bir acquirer/gateway entegrasyonu veya belge iletim sistemi yoktur. Aksiyon, itiraz durumunu representment gönderildi olarak gerçekten günceller ve kanıt özetini sistem kaydı olarak loglar, ancak gerçek bir dosya iletimi gerçekleşmez.

3. Settlement & Clearing

Amaç: Bir edinici bankadan (acquirer) veya kart ağından (Stripe, Visa Direct, Mastercard Send vb.) gelen bir takas partisini brüt hacim, rezerv kesintileri ve işlem ücretlerine karşı izleyen bir takas defteri — portföy çapında mutabakat endeksini izler ve ödeme için audit hold'larının serbest bırakılmasını sağlar.

Defter sütunları / temel alanlar

  • ID formatı SET-YYYY-XXXX
  • Parti ID, acquirer/network, brüt hacim, rezerv kesintileri, işlem ücretleri, para birimi, takas kesim tarihi
  • Takas durumu (takas edildi ve ödendi / ücret farkı hold'u / takas bekliyor), ülke kodu, son çalıştırma tarihi, AI takas teşhisi, notlar. Net Ödeme türetilir: brüt hacim eksi rezerv kesintileri eksi işlem ücretleri, negatifken kırmızı gösterilir.

Gösterge

Settlement Reconciliation Index — Standart durum-sayımı deseni: takas edildi ve ödendi olarak işaretlenen kayıtların toplam kayıt sayısına oranı, yuvarlanmış. Kayıt yoksa 0 döner.

Temel eylemler

  • Yeni Kayıt, AI Analiz Et (takas/mutabakat denetimini çalıştırır, bir takas teşhisi ve güven skoru üretir; acquirer/network boşken devre dışıdır).
  • Release Settlement Hold (satır aksiyonu, inline Evet/Hayır onayı) — takas durumunu doğrudan takas edildi ve ödendi olarak günceller ve "Settlement hold released — cleared for payout." notunu notlara ekler; zaten takas edildi ve ödendi durumundaysa devre dışıdır.
  • Silme — kalıcı.

Bilinen sınırlama, gerçek-güncelleme istisnasıyla

Release Settlement Hold, gerçek bir banka transferini tetiklemez — uygulamada bugün hiçbir yerde bir fon dağıtım/ödeme yürütme servisi yoktur. Ancak bu aksiyon, Hazine & Likidite Operasyonları grubundaki Recalibrate Credit Ceiling ve Reallocate HQLA Reserves ile aynı şekilde, kaydın kendi takas-durumu alanı üzerinde gerçek, doğrudan bir güncellemedir — durum alanının kendisi gerçektir, yalnızca altındaki banka transferi implemente edilmemiştir.

4. Financial Escrow

Amaç: Bu gruptaki ve add-on'daki son ekran. Bir alıcı/yararlanıcı için sözleşmesel bir serbest bırakma koşuluna veya kilometre taşına (milestone) karşı emanette tutulan fonları izleyen bir mali emanet (escrow) defteri — portföy çapında güven sermayesi rezervini (trust capital reserve) izler ve koşullar doğrulandığında emanet ödemelerinin gerçekleştirilmesini sağlar.

Defter sütunları / temel alanlar

  • ID formatı ESC-YYYY-XXXX
  • Emanet ID, alıcı/yararlanıcı, sözleşme referansı, kilitli rezerv tutarı, para birimi, serbest bırakma koşulu, son geçerlilik tarihi
  • Emanet durumu (emanette kilitli / kilometre taşı doğrulandı / itiraz hold'u / serbest bırakıldı), ülke kodu, son çalıştırma tarihi, AI emanet doğrulaması, notlar

Gösterge

Trust Capital Reserve BarSermaye-ağırlıklı, açıkça bir kayıt-sayımı oranı değildir: hâlâ kilitli (henüz serbest bırakılmamış) kayıtların kilitli rezerv tutarı toplamı bölü tüm kayıtların kilitli rezerv tutarı toplamı, çarpı 100. Kayıt yoksa veya toplam kilitli tutar sıfırsa 0 döner.

Neden sermaye-ağırlıklı?

Emanet hesapları büyüklük olarak muazzam ölçüde değişebilir, bu yüzden basit bir kayıt-sayımı oranı yanıltıcı olurdu. QA kaynağından somut bir örnek: 1,8 milyon dolarlık serbest bırakılmış bir emanet ve 200 bin dolarlık hâlâ emanette kilitli bir emanetten oluşan bir portföy 2 kayıttır — naif bir sayım-tabanlı oran bunu %50 hâlâ kilitli olarak okurdu. Gerçek, sermaye-ağırlıklı formül bunun yerine %10 (200 bin / 2,0 milyon toplam) sonucunu verir — sermayenin büyük çoğunluğunun zaten serbest bırakıldığını doğru şekilde yansıtır — kaç hesabın hâlâ kilitli olduğuna göre değil, emanette hâlâ tutulan dolar tutarına göre ağırlıklandırılmıştır, bu yüzden hâlâ kilitli tek büyük bir hesap, serbest bırakılmış birkaç küçük hesaptan daha fazla önem taşır.

Temel eylemler

  • Yeni Kayıt, Run Verification / AI Doğrulama (mali emanet denetimini çalıştırır, bir emanet doğrulaması ve güven skoru üretir; alıcı/yararlanıcı veya sözleşme referansı boşken devre dışıdır).
  • Execute Escrow Payout (satır aksiyonu, inline mini-form: yetkilendirme imzası) — emanet durumunu doğrudan serbest bırakıldı olarak günceller ve yetkilendirme imza referansını notlara loglar; zaten serbest bırakıldıysa devre dışıdır.
  • Silme — kalıcı.

Bilinen sınırlama, gerçek-güncelleme istisnasıyla

Execute Escrow Payout, gerçek parayı bir emanet hesabından çıkarmaz — uygulamada bugün hiçbir yerde bir emanet hesabı/bankacılık-rail fon serbest bırakma sistemi yoktur (kendi alanlarındaki Release Settlement Hold, Execute Liquidity Sweep ve Auto-Generate FX Hedge Order ile aynı kategori eksiklik). Release Settlement Hold'da olduğu gibi, bu aksiyon kaydın kendi emanet-durumu alanı üzerinde gerçek, doğrudan bir güncellemedir — yalnızca altındaki fon transferi implemente edilmemiştir.

Bu gruptaki gösterge çeşitliliği

Bu grup kasıtlı olarak dört farklı gösterge formülü kullanır, hiçbiri diğerinin desenini paylaşmaz: Routing Efficiency düz bir ortalamadır (devre dışı kayıtlar hariç); Dispute Win Ratio çözümlenmemiş vakaları hem paydan hem paydadan hariç tutar; Settlement Reconciliation Index, add-on'un standart durum-sayımı oranıdır; Trust Capital Reserve sermaye-ağırlıklıdır. Bu, add-on'un tamamındaki daha geniş bir dersi yansıtır — Transaction Audit göstergeleri çoğunlukla durum-sayımıdır, Hazine grubunun LCR göstergesi kasıtlı olarak %100 üzerinde sınırlanmamıştır, ve onun Concentration Meter'ı en büyük tek pozisyona göre ağırlıklıdır. Bu add-on'daki hiçbir gösterge "varsayılan" bir desen izlediği varsayılamaz — her zaman her göstergenin gerçekte neyi ölçtüğünü kontrol edin.

Sık Sorulan Sorular

Çözümlenmemiş bir itiraz eklemek Win Ratio'yu değiştirir mi?
Hayır — hâlâ kanıt bekleyen veya zaten representment için gönderilmiş itirazlar hem paydan hem paydadan hariç tutulur. Yalnızca kazanılan ve kaybedilen kayıtlar sayılır.
Trust Capital Reserve Bar, emanet kayıtlarının sayısına mı dayanır?
Hayır — dolar tutarına göre ağırlıklandırılmıştır. Büyük bir serbest bırakılmış emanet ve küçük bir hâlâ kilitli emanet, kayıt sayısı 50/50 görünse bile düşük bir yüzde üretebilir, çünkü formül kilitli tutarları toplar, kayıt sayısını değil.
Trigger Failover gerçekten canlı ödeme trafiğini yönlendiriyor mu?
Hayır — uygulamada bugün bir ödeme gateway'i orkestrasyon sistemi yoktur. Bu kaydın hedef gateway ve durum alanlarını gerçekten günceller, ancak gerçek bir trafik kesimi gerçekleşmez.
Release Settlement Hold ve Execute Escrow Payout gerçekten para hareket ettiriyor mu?
Hayır — hiçbiri gerçek bir banka transferini veya emanet hesabı fon hareketini tetiklemez, çünkü uygulamada bugün bir fon dağıtım servisi yoktur. Ancak ikisi de kendi kaydının durum alanını gerçekten günceller, bu da aksiyonun dürüst, gerçek kısmıdır.
Routing Efficiency neden devre dışı rotaları %0 olarak saymak yerine hariç tutuyor?
Çünkü devre dışı bir rota anlamlı bir başarı oranına hiç katkıda bulunmuyor — onu %0 olarak dahil etmek, fiilen kullanılan rotaların gerçek verimliliğini olduğundan düşük gösterirdi. Yalnızca aktif ve failover-aktif kayıtların ortalamasını alır.