Timeout sonrası ödemeyi yeniden denemek ne zaman tehlikelidir?

Timeout yalnızca istemcinin ne bildiğini söyler

Bir network timeout, çağrıyı yapan tarafın beklenen süre içinde kesin bir yanıt alamadığı anlamına gelir. Uzak sistemin isteği reddettiğini, rollback yaptığını veya hiç almadığını kanıtlamaz. Payment sistemlerinde bu ayrım kritiktir; authorization, capture, refund gibi aksiyonlar istemci exception görse bile finansal yan etki üretmiş olabilir.

Bu nedenle belirsiz bir timeout sonrasında en güvenli state failed değil, unknown'dur. Unknown'u failed olarak modellemek iki farklı finansal gerçeği tek state'e indirger ve duplicate execution riskini artırır.

Idempotency retry kararını değiştirir

Sağlayıcı ilgili operasyon için açık bir idempotency mekanizması sunuyorsa ve ilk istekte kullanılan key yeniden kullanılabiliyorsa retry çok daha güvenlidir. Key, HTTP denemesini değil business action'ı tanımlamalıdır. Her retry'da yeni key üretmek idempotency'nin amacını bozar; sağlayıcı her isteği yeni bir aksiyon olarak değerlendirebilir.

Idempotency davranışı sağlayıcıdan sağlayıcıya değişir. Hangi operasyonların desteklendiği, key'in ne kadar tutulduğu, eşzamanlı duplicate isteklerin nasıl ele alındığı ve tekrar isteğinin ilk sonucu mu yoksa güncel resource state'ini mi döndürdüğü bilinmelidir. Bu detaylar generic retry middleware'inde gizlenmemeli, payment recovery mantığının parçası olmalıdır.

İkinci finansal aksiyonu üretmeden önce state'i geri kazan

Sonuç belirsizse sistem önce intended action ile provider state'i eşleştirmeye çalışmalıdır. Merchant reference ile provider'dan sorgu yapmak, provider event'ini tüketmek veya attempt ile provider resource arasında kalıcı eşleştirme kullanmak buna örnektir. Ancak bu state recovery başarısız olursa yeni bir execution path düşünülmelidir.

Bu yüzden payment retry sadece HTTP reliability konusu değildir; orchestration konusudur. Karar business state'e, provider semantics'e, geçen zamana, önceki denemelere ve aynı aksiyonun tekrarlanmasının finansal sonucuna bağlıdır.

Pratik kural

Operasyonu ancak provider'ın idempotency kontratı altında güvenli olduğu biliniyorsa veya ilk aksiyonun tamamlanmadığı sistem tarafından doğrulanabiliyorsa otomatik retry et. Aksi halde ödeme explicit bir recovery state'ine taşınmalı ve belirsizlik çözülmeden yeniden çalıştırılmamalıdır.

Transport hatasını iş durumu hatasından ayırın

Güvenilir bir payment state machine en az üç ayrı kavramı ayırmalıdır: istemci isteğinin durumu, provider tarafındaki operasyonun durumu ve kendi sisteminizin dışarıya göstereceği business state. Normal akışta bu durumlar çoğu zaman aynı yönde ilerlediği için ekipler bunları tek bir state altında toplamak ister. Risk, ağ güvenilmez olduğunda ortaya çıkar. İstek istemci tarafında timeout ile biterken uzaktaki operasyon başarılı olabilir; provider isteği kabul edip sonucu ilk çağrı timeout olduktan sonra asynchronous olarak yayınlayabilir.

Pratik sonuç şudur: transport error, geri döndürülemez business transition'ları otomatik olarak tetiklememelidir. Timeout ile biten bir payment attempt için pending verification, unknown veya recovery required gibi açık bir state gerekebilir. Bu state, sistem daha fazla kanıt toplayana kadar otomatik ilerlemeyi durdurur ve downstream servislerin cevap yokluğunu 'para hareket etmedi' kanıtı olarak yorumlamasını engeller.

Provider-aware bir recovery hiyerarşisi kurun

Recovery en güçlü mevcut source of truth ile başlamalıdır. Provider idempotency key, merchant reference, payment intent veya provider transaction ID üzerinden lookup sunuyorsa ikinci bir attempt yaratmadan önce bunu kullanın. Kalıcı bir provider event bekleniyorsa onu ilk attempt ile ilişkilendirip sınırlı bir recovery window içinde bekleyin. Bunların hiçbiri yoksa tahmin yürütmek yerine işlem manual veya delayed reconciliation yoluna alınmalıdır.

Provider-aware recovery, generic HTTP retry library'lerinin finansal operasyonlar için neden yetersiz olduğunun temel örneğidir. Bir read request'i tekrar etmek authorization'ı tekrar etmekle aynı değildir; authorization'ı tekrar etmek capture'ı tekrar etmekle aynı değildir; refund'u tekrar etmek ise müşteri-facing işlem zaten tamamlanmış olabileceği için daha da riskli olabilir. Recovery policy bu nedenle yalnız network semantics'e değil payment semantics'e yakın yerde yaşamalıdır.

Observability'yi belirsizlik etrafında tasarlayın

Operasyon dashboard'ları belirsiz payment'ları ayrı bir cohort olarak görünür kılmalıdır. Kaç attempt'in ambiguous state'e girdiğini, hangi provider'ların bunu ürettiğini, recovery'nin ne kadar sürdüğünü ve kaç işlemin lookup, webhook, reconciliation veya manual intervention ile çözüldüğünü izleyin. Unknown state'ler generic error rate içine gömülürse ekipler yanlış metriği optimize eder ve daha fazla retry ile cevap verme eğilimine girer; bu da duplicate riskini büyütür.

Alert'ler ambiguous outcome artışını explicit decline artışından ayırmalıdır. Daha fazla issuer decline üreten provider ile request'i aldıktan sonra timeout üreten provider aynı problem değildir. İlki conversion'ı etkileyebilir; ikincisi hem conversion belirsizliği hem de financial-integrity riski yaratır. Farklı failure class'ları farklı operational playbook gerektirir.

Automatic retry öncesi karar çerçevesi

Retry öncesinde dört soruyu yanıtlayın: İlk operasyonun tamamlanmadığı biliniyor mu? Provider bu operasyon ve key için idempotent handling garanti ediyor mu? İlk attempt query veya reconciliation ile doğrulanabiliyor mu? Her iki attempt de tamamlanırsa finansal sonuç nedir? İlk iki sorunun yanıtı belirsiz ve duplicate sonucu önemliyse automatic retry durmalıdır.

Bu yaklaşım bilinçli biçimde anlık completion yerine financial correctness'i önceler. Bu kötü customer experience kabul etmek anlamına gelmez. Recovery'yi açık hale getirmek anlamına gelir: gerekiyorsa pending state gösterin, verification'ı asynchronous sürdürün ve müşteriyi ancak payment state kanıtla desteklendiğinde bilgilendirin. Birkaç saniyelik dürüst belirsizlik, duplicate charge ve ardından gelen support, refund, dispute ve güven maliyetinden genellikle daha ucuzdur.