Ödeme var, sipariş hâlâ bekliyor
Müşterinin ödemesi başarılı olabilirken mağazada sipariş ödenmemiş görünebilir. Ödeme sağlayıcısı ile mağaza ayrı kayıtlar tutar. Aralarındaki bildirim gecikebilir, tekrarlanabilir veya yanlış işlenebilir. Son gelen webhook'u gerçeğin tamamı kabul etmek, bu ayrılığı düzeltmeyi zorlaştırır.
Webhook, bir iş kaydını değerlendirmek için gelen sinyaldir. Ödeme durumunu, sevkiyatı ve müşteri iletişimini hangi sistemin yönettiğini belirlemez. Ödeme sağlayıcısı ödeme sorusuna cevap verir; deponun paketi gönderip göndermediğine değil. Bu sorumlulukları ayırmak gerekir.
İşe başlamadan önce bildirimi güvenle kabul edin
Alıcı endpoint göndericiyi doğrulamalı, bildirimi kalıcı olarak kaydetmeli ve işi işlemciye devretmelidir. Başarılı alındı yanıtı, bütün işlemlerin bittiğini değil, mesajın güvenle kabul edildiğini ifade etsin. Kalıcı kayıt başarısızken başarılı yanıt vermek, yapılmamış işi gizler.
Stripe belgeleri imza doğrulamasını, yinelenen teslimatı ve olay sırasının garanti edilmediğini açıkça anlatıyor. Bunlar test sırasında geçiştirilecek istisnalar değil, entegrasyonun çalışma koşulları. Stripe webhook belgesi bu sistem için temel referanstır.
Alındı kaydında sağlayıcının olay referansı, ilgili iş kaydı, teslim zamanı ve işlem durumu bulunsun. Teşhis için gerekli veriyi uygun erişim ve saklama kurallarıyla koruyun. Uygulama süreci kapanınca kaybolan log satırı, kalıcı teslim kaydı değildir.
Tekrarlanan mesaj aynı etkiyi yeniden üretmesin
Örnek bir akış, ödemeyi kaydettikten sonra müşteriye onay gönderiyor olsun. Gelen olayı ayıklamak faydalıdır, ancak işlemci mesajı gönderdikten sonra tamamlandı kaydını yazamadan durabilir. İş yeniden oynatıldığında onay tekrar gider.
Bu nedenle teslim denemesiyle iş etkisini ayrı izleyin. Onay mesajı, stok ayırma ve geri ödeme kendi kalıcı işlem referansına sahip olsun. Hedef servis idempotency desteği veriyorsa aynı niyetin tekrarlarında aynı referansı kullanın. Desteklemiyorsa belirsiz sonucun yeniden denemeden önce nasıl araştırılacağını belirleyin.
Sıralama için de açık kurallar gerekir. Eski ödeme bildirimi sonradan geldi diye geri ödeme durumunu ezmemeli. İzin verilen durum geçişlerini değerlendirin; olay mevcut durumu güvenle açıklamıyorsa yetkili sistemdeki kayda bakın. Varış sırası, iş kuralı değildir.
Kurtarma başka bir webhook'a bağlı kalmasın
Düzenli karşılaştırma işi, sistemlerdeki ilgili kayıtları karşılaştırıp açıklanabilir farklar çıkarmalı. Ödemesi bulunan ama siparişi güncellenmemiş kayıtları veya sonucu başka yerde belli olduğu hâlde bekleyen siparişleri bulabilir. Kapsamı, sayfalaması ve kaldığı yerden devam noktası tanımlı olmalı.
Her farkı otomatik düzeltmeyin. Sevkiyat sürerken geçici ayrılık normal olabilir; belirsiz bir referans ise operatör kararı gerektirebilir. Güvenli düzeltmeleri kanıt isteyen durumlardan ayırın. Her müdahalenin gerekçesini kaydedin.
Gözden kaçan maliyet, gerçekten takip edilen operasyon ekranı veya rapordur. Teslimat göstergeleri sağlıklı görünürken iş kayıtları yanlış kalabilir. Sahibi olmayan karşılaştırma sonucu da işlenmemiş bir mesajdır.
Bu hafta kurtarma provası yapın
Zararsız bir test siparişini sağlayıcı kaydından yerel duruma ve müşteri iletişimine kadar izleyin. Olayı yeniden oynatın, ilişkili mesajların sırasını değiştirin, bir dış etki oluştuktan sonra işlemciyi durdurun. Sonucun hâlâ açıklanabildiğini kontrol edin.
Ardından test ortamında bildirimi hiç ulaştırmayın. Karşılaştırma yolu, yeni olay beklemeden farkı bulmalı. Düzeltmeyi kimin onaylayacağını, hangi kanıtı göreceğini ve tamamlanmanın nasıl kaydedileceğini yazın. Böylece yalnız endpoint'i değil, entegrasyonun toparlanmasını sınamış olursunuz.