Request Trace ve İzlenebilirlik

Bir ödeme “neden böyle bitti?” sorusu çoğu zaman tek bir alanla cevaplanmaz. Request ve trace kimlikleri, routing plan, charge denemeleri ve event kayıtlarını aynı payment üzerinde birleştirmenizi sağlar.

Request ve trace

Alan	Kullanım
`request_id`	Tek API çağrısını (ör. bir confirm) etiketler
`trace_id`	Aynı iş akışındaki adımları birlikte okumak için

Bu alanlar korelasyon içindir; kimlik doğrulama veya secret taşımaz. Loglarda PAN veya credential ile birlikte yazılmamalıdır.

Confirm sonrası neyi eşleştirirsiniz?

Tipik sorular:

Bu payment hangi confirm isteğiyle başladı?
Kaçıncı sağlayıcı adayı denendi?
Hangi charge DECLINED, hangisi CAPTURED?
Webhook hangi payment ID ile geldi?

Routing plan ve event kayıtlarında request_id / trace_id alanları bu eşleştirmeyi kolaylaştırır.

Event kayıtlarında ilişki alanları

Alan	Ne işe yarar?
`payment_id`	Ana ödeme kaydı
`charge_id`	Sağlayıcı denemesi
`checkout_session_id`	Hosted checkout kaynağı
`routing_plan_id`	Hangi planla yönlendirildi
`refund_id`	İade akışı

Operasyon ve destek ekipleri önce payment_id, gerekirse charge_id ve event zaman çizelgesi ile ilerlemelidir.

Dashboard’da okuma sırası

Payment status ve tutar.
Charge listesi (deneme sayısı, status).
Routing plan (aday sırası, current index).
Event listesi ve detay payload (maskeli).

Redirect sonucu tek başına final kanıt sayılmamalı; payment GET veya webhook ile kapatın.

Örnek korelasyon (sozel)

Confirm isteği
  → routing plan oluşur (request/trace yazılır)
  → charge attempt(ler)
  → domain event’ler
  → webhook teslimatı
  → dashboard aynı payment ID üzerinden hepsini gösterir

Güvenlik

Trace ID güvenlik token’ı değildir.
Event payload debug içindir; hassas alanlar maskelenmiş olmalıdır.
Sandbox trace, production davranışı garantisi vermez; süreç alışkanlığı içindir.