@kodkedisi · 4 gün önce
Ödeme entegrasyonunda webhook tekrarları ve mutabakat: çift sipariş yaşamamak için backend tarafında kurduğumuz yapı
Uzaktan backend geliştiriyorum, yan işlerimden biri de küçük bir abonelik ürünü. Geçen kış ödeme sağlayıcısı entegrasyonunda yaptığım bir hata yüzünden üç müşteriye iki kez ürün teslim ettik, birinden de iki kez para çektik. Para iade edildi, sorun büyümedi ama bana ödeme tarafında 'çalışıyor' ile 'doğru çalışıyor' arasındaki farkı öğretti. Aynı hatayı yapmamanız için kurduğumuz yapıyı anlatayım.
İlk ders: ödeme sağlayıcısının gönderdiği bildirimler (webhook) birden fazla gelebilir ve sırası karışık olabilir. Sağlayıcı senin sunucundan zamanında olumlu yanıt alamazsa aynı bildirimi tekrar gönderiyor. Bizim kodumuz her bildirimde siparişi onaylayıp teslimatı tetikliyordu. Çözüm, her bildirimdeki olay kimliğini veritabanında benzersiz bir alanda saklamak oldu. Aynı kimlik ikinci kez gelirse hiçbir şey yapmadan başarılı yanıt dönüyoruz.
İkinci ders: siparişin durumunu tek bir alan yerine bir durum makinesi olarak düşünmek. Bizde sipariş oluşturuldu, ödeme bekleniyor, ödendi, teslim edildi, iade edildi gibi durumlar var ve her geçişin hangi durumdan hangisine olabileceği tanımlı. Ödendi durumundaki bir sipariş, geç gelen bir ödeme başarısız bildirimiyle geri gidemiyor. Bu kural tek başına iki ayrı hatayı engelledi.
Üçüncü ders: bildirime tamamen güvenmemek. Bildirim gelince sağlayıcının API'sinden işlemin gerçek durumunu ayrıca sorguluyoruz. Bildirimin imzasını da doğruluyoruz, çünkü bildirim adresi tahmin edilebilir bir adresse dışarıdan sahte istek gelebilir. Bildirim hiç gelmezse diye de her on beş dakikada bir, ödeme bekleyen ve belirli süreyi geçmiş siparişleri sorgulayan küçük bir iş çalışıyor.
Dördüncü ders, en sıkıcı ama en faydalı olanı: günlük mutabakat. Her sabah sağlayıcının bir önceki gün için verdiği işlem listesini çekip kendi kayıtlarımızla karşılaştırıyoruz. Sağlayıcıda var bizde yok, bizde var sağlayıcıda yok, tutarı farklı olanlar ayrı bir rapora düşüyor. İlk ay bu raporda her gün bir iki satır vardı, şimdi haftalarca boş geliyor. Boş gelmesi bile insana güven veriyor.
Bu yapıların hiçbiri yeni değil, büyük ödeme ekipleri yıllardır böyle çalışıyor. Ama küçük bir yan üründe hızlıca entegrasyon yaparken insan örnek kodu kopyalayıp geçiyor. Siz entegrasyonlarınızda tekrar eden bildirimi nasıl ele alıyorsunuz, farklı bir yaklaşım kullanan var mı?
İlk ders: ödeme sağlayıcısının gönderdiği bildirimler (webhook) birden fazla gelebilir ve sırası karışık olabilir. Sağlayıcı senin sunucundan zamanında olumlu yanıt alamazsa aynı bildirimi tekrar gönderiyor. Bizim kodumuz her bildirimde siparişi onaylayıp teslimatı tetikliyordu. Çözüm, her bildirimdeki olay kimliğini veritabanında benzersiz bir alanda saklamak oldu. Aynı kimlik ikinci kez gelirse hiçbir şey yapmadan başarılı yanıt dönüyoruz.
İkinci ders: siparişin durumunu tek bir alan yerine bir durum makinesi olarak düşünmek. Bizde sipariş oluşturuldu, ödeme bekleniyor, ödendi, teslim edildi, iade edildi gibi durumlar var ve her geçişin hangi durumdan hangisine olabileceği tanımlı. Ödendi durumundaki bir sipariş, geç gelen bir ödeme başarısız bildirimiyle geri gidemiyor. Bu kural tek başına iki ayrı hatayı engelledi.
Üçüncü ders: bildirime tamamen güvenmemek. Bildirim gelince sağlayıcının API'sinden işlemin gerçek durumunu ayrıca sorguluyoruz. Bildirimin imzasını da doğruluyoruz, çünkü bildirim adresi tahmin edilebilir bir adresse dışarıdan sahte istek gelebilir. Bildirim hiç gelmezse diye de her on beş dakikada bir, ödeme bekleyen ve belirli süreyi geçmiş siparişleri sorgulayan küçük bir iş çalışıyor.
Dördüncü ders, en sıkıcı ama en faydalı olanı: günlük mutabakat. Her sabah sağlayıcının bir önceki gün için verdiği işlem listesini çekip kendi kayıtlarımızla karşılaştırıyoruz. Sağlayıcıda var bizde yok, bizde var sağlayıcıda yok, tutarı farklı olanlar ayrı bir rapora düşüyor. İlk ay bu raporda her gün bir iki satır vardı, şimdi haftalarca boş geliyor. Boş gelmesi bile insana güven veriyor.
Bu yapıların hiçbiri yeni değil, büyük ödeme ekipleri yıllardır böyle çalışıyor. Ama küçük bir yan üründe hızlıca entegrasyon yaparken insan örnek kodu kopyalayıp geçiyor. Siz entegrasyonlarınızda tekrar eden bildirimi nasıl ele alıyorsunuz, farklı bir yaklaşım kullanan var mı?
1 2 yorum
