Zaman aşımı sonrası ödemeyi yeniden denemek ne zaman tehlikelidir?

Zaman aşımı yalnızca çağrıyı yapan sistemin ne bildiğini söyler

Bir ağ zaman aşımı, çağrıyı yapan tarafın beklenen süre içinde kesin yanıt alamadığı anlamına gelir. Uzak sistemin isteği reddettiğini, geri aldığını veya hiç işlemediğini kanıtlamaz. Ödeme sistemlerinde bu ayrım kritiktir; provizyon, tahsilat veya iade gibi işlemler istemci hata görse bile finansal sonuç üretmiş olabilir.

Bu nedenle belirsiz bir zaman aşımı sonrasında en güvenli durum doğrudan başarısız değildir. Sonuç bilinmiyor veya doğrulama bekleniyor gibi ayrı bir durum kullanmak, farklı finansal gerçekleri tek bir başarısız etiketi altında toplamayı ve mükerrer işlem riskini azaltır.

Idempotency yeniden deneme kararını değiştirir

Sağlayıcı ilgili işlem için açık bir idempotency mekanizması sunuyorsa ve ilk istekte kullanılan anahtar yeniden kullanılabiliyorsa yeniden deneme çok daha güvenlidir. Anahtar HTTP çağrısını değil, aynı ticari işlemi tanımlamalıdır. Her denemede yeni anahtar üretmek idempotency'nin amacını bozar; sağlayıcı her çağrıyı yeni bir finansal işlem olarak değerlendirebilir.

Idempotency davranışı sağlayıcıdan sağlayıcıya değişir. Hangi işlemlerin desteklendiği, anahtarın ne kadar süre saklandığı, eşzamanlı mükerrer isteklerin nasıl ele alındığı ve tekrar çağrısının ilk sonucu mu yoksa güncel işlem durumunu mu döndürdüğü bilinmelidir. Bu ayrıntılar genel bir yeniden deneme katmanında gizlenmemeli; ödeme kurtarma mantığının parçası olmalıdır.

İkinci finansal hareketi yaratmadan önce işlem durumunu doğrula

Sonuç belirsizse sistem önce beklenen işlem ile sağlayıcıdaki gerçek durumu eşleştirmeye çalışmalıdır. İşyeri referansıyla sağlayıcıdan sorgu yapmak, sağlayıcı olayını tüketmek veya ilk denemeyle sağlayıcı kaydı arasında kalıcı eşleştirme kullanmak buna örnektir. Durum doğrulanamıyorsa ancak o zaman yeni bir işlem yolu düşünülmelidir.

Bu yüzden ödeme yeniden denemesi yalnızca HTTP güvenilirliği konusu değildir; orchestration konusudur. Karar, ticari duruma, sağlayıcının işlem mantığına, geçen zamana, önceki denemelere ve aynı hareketin tekrar edilmesinin finansal sonucuna bağlıdır.

Pratik kural

İşlemi yalnızca sağlayıcının idempotency garantisi altında güvenli olduğu biliniyorsa veya ilk hareketin tamamlanmadığı doğrulanabiliyorsa otomatik olarak yeniden dene. Aksi halde ödemeyi kontrollü bir doğrulama veya kurtarma durumuna taşı ve belirsizlik çözülmeden ikinci finansal hareketi başlatma.

İletişim hatasını işlem durumundan ayırın

Güvenilir bir ödeme durum modeli en az üç şeyi birbirinden ayırmalıdır: çağrının teknik sonucu, sağlayıcıdaki işlemin gerçek durumu ve kendi sisteminizin dışarıya göstereceği ticari durum. Normal akışta bunlar çoğu zaman birlikte ilerlediği için tek durum gibi görünür. Risk ağ güvenilmez olduğunda ortaya çıkar. İstek istemci tarafında zaman aşımına uğrarken sağlayıcıdaki işlem başarılı olabilir; sağlayıcı isteği kabul edip sonucu ilk çağrı sonlandıktan sonra webhook veya başka bir asenkron kanal üzerinden bildirebilir.

Pratik sonuç şudur: iletişim hatası geri döndürülemez finansal durum değişikliklerini otomatik olarak tetiklememelidir. Zaman aşımına uğrayan bir ödeme için doğrulama bekleniyor, sonuç bilinmiyor veya kurtarma gerekli gibi açık durumlar kullanılabilir. Böylece sistem yeni kanıt toplayana kadar otomatik ilerleme durur ve sonraki servisler yanıt gelmemesini 'para hareket etmedi' şeklinde yorumlamaz.

Sağlayıcının yeteneklerine göre bir kurtarma sırası kurun

Kurtarma en güçlü doğrulama kaynağıyla başlamalıdır. Sağlayıcı idempotency anahtarı, işyeri referansı, ödeme niyeti veya sağlayıcı işlem kimliği üzerinden sorgu sunuyorsa ikinci bir deneme yaratmadan önce bunu kullanın. Kalıcı bir sağlayıcı olayı bekleniyorsa onu ilk denemeyle ilişkilendirip sınırlı bir doğrulama süresi içinde bekleyin. Bunların hiçbiri mümkün değilse tahmin yürütmek yerine işlemi manuel inceleme veya gecikmeli mutabakat sürecine alın.

Bu yaklaşım genel HTTP yeniden deneme kütüphanelerinin finansal işlemler için neden yeterli olmadığını gösterir. Okuma isteğini tekrar etmek provizyonu tekrar etmekle aynı değildir; provizyonu tekrar etmek tahsilatı tekrar etmekle aynı değildir; iadeyi tekrar etmek ise müşteriye dönük işlem zaten tamamlanmış olabileceği için daha da riskli olabilir. Yeniden deneme politikası ağ katmanından çok ödeme işleminin anlamına yakın yerde yaşamalıdır.

Gözlemlenebilirliği belirsizlik etrafında tasarlayın

Operasyon panelleri belirsiz ödemeleri ayrı bir grup olarak görünür kılmalıdır. Kaç denemenin belirsiz duruma girdiğini, hangi sağlayıcılarda yoğunlaştığını, doğrulamanın ne kadar sürdüğünü ve kaç işlemin sorgu, webhook, mutabakat veya manuel incelemeyle çözüldüğünü izleyin. Bu işlemler genel hata oranına gömülürse ekipler yanlış metriği optimize edip daha fazla yeniden denemeye yönelebilir; bu da mükerrer işlem riskini büyütür.

Uyarılar belirsiz sonuç artışını açık banka reddi artışından ayırmalıdır. Daha fazla issuer decline üreten sağlayıcı ile isteği aldıktan sonra zaman aşımı üreten sağlayıcı aynı problem değildir. İlki dönüşümü etkileyebilir; ikincisi hem dönüşüm belirsizliği hem de finansal bütünlük riski yaratır. Farklı hata sınıfları farklı operasyon prosedürleri gerektirir.

Otomatik yeniden denemeden önce dört soruyu yanıtlayın

İlk işlemin tamamlanmadığı biliniyor mu? Sağlayıcı bu işlem ve anahtar için idempotent davranışı garanti ediyor mu? İlk deneme sorgu veya mutabakatla doğrulanabiliyor mu? Her iki deneme de tamamlanırsa finansal sonuç ne olur? İlk iki sorunun cevabı belirsiz ve mükerrer işlem sonucu önemliyse otomatik yeniden deneme durmalıdır.

Bu yaklaşım bilinçli olarak anlık tamamlanma hızından önce finansal doğruluğu önceler. Bu kötü müşteri deneyimini kabul etmek anlamına gelmez. Gerekirse doğrulama bekleniyor durumunu gösterin, kontrolü arka planda sürdürün ve müşteriyi ancak ödeme durumu yeterli kanıtla desteklendiğinde bilgilendirin. Birkaç saniyelik açık belirsizlik; mükerrer tahsilat, destek talebi, iade, itiraz ve güven kaybından genellikle daha ucuzdur.