Ödeme bildirimleri gelmiyorsa loglarda hangi kayıtlar aranmalı?

Ödeme bildirimi gelmediğinde sorun çoğu zaman tek bir noktadan kaynaklanmaz; ödeme sağlayıcısı, uygulama, e-posta servisi, webhook uç noktası, güvenlik duvarı veya hosting ortamındaki zaman aşımı kayıtları birlikte incelenmelidir. Doğru loglara doğru sırayla bakmak, hem müşterinin ödeme durumunu netleştirir hem de aynı hatanın tekrar etmesini önler.

İlk kontrol: Ödeme sağlayıcısı tarafındaki işlem ve webhook logları

PayTR, iyzico, Stripe, PayPal veya banka sanal POS entegrasyonlarında ödeme başarılı olsa bile uygulamaya bildirim düşmeyebilir. Bu nedenle ilk bakılması gereken yer sağlayıcının panelindeki işlem geçmişi ve webhook bildirim kayıtlarıdır.

Aranması gereken temel kayıtlar şunlardır:

• Transaction ID veya sipariş numarası ile eşleşen ödeme kaydı
• Webhook gönderim zamanı
• HTTP durum kodu: 200, 301, 302, 403, 404, 500, 502, 504
• Tekrarlı gönderim denemeleri ve hata mesajları
• İmza doğrulama, callback URL veya SSL hatası uyarıları

Sağlayıcı loglarında 200 dışında bir yanıt görünüyorsa bildirim büyük ihtimalle uygulamaya ulaşmış ancak doğru işlenmemiş ya da sunucu isteği reddetmiştir. 403 hataları güvenlik kuralına, 404 yanlış webhook adresine, 500 ise uygulama tarafındaki PHP veya entegrasyon hatasına işaret eder.

Sunucu erişim loglarında aranacak kayıtlar

Webhook isteğinin gerçekten sunucuya ulaşıp ulaşmadığını anlamak için access log kayıtları incelenmelidir. Bu loglarda ödeme sağlayıcısının IP adresi, istek yapılan URL, tarih-saat, HTTP metodu ve yanıt kodu görünür.

Özellikle şu desenler aranmalıdır:

• POST /callback, POST /webhook veya entegrasyonun kullandığı özel URL
• Aynı sipariş saatine denk gelen 403, 404, 500 kayıtları
• POST yerine GET isteği gelmesi
• Yönlendirme nedeniyle oluşan 301 veya 302 cevapları
• Yanıt süresi çok uzun olan istekler

Webhook URL’si HTTP’den HTTPS’ye yönleniyorsa bazı ödeme sağlayıcıları bu yönlendirmeyi takip etmeyebilir. Bu durumda erişim logunda 301 veya 302 görünür, fakat uygulama ödeme durumunu güncellemez. Callback adresinin doğrudan nihai HTTPS URL olarak tanımlanması daha güvenlidir.

Hata loglarında uygulama kaynaklı problemleri ayıklama

Access log isteğin geldiğini gösteriyor ancak ödeme bildirimi işlenmiyorsa error log kayıtlarına geçilmelidir. WordPress, WooCommerce veya özel PHP entegrasyonlarında sık görülen problemler genellikle burada yakalanır.

Aranabilecek tipik kayıtlar:

• PHP Fatal error
• Uncaught Exception
• Allowed memory size exhausted
• Maximum execution time exceeded
• cURL error veya bağlantı zaman aşımı
• Permission denied
• Database connection veya sorgu hataları

Özellikle ödeme bildiriminin geldiği dakika ile hata logundaki kayıtları eşleştirmek gerekir. Saat farkı varsa sunucu saat dilimi, uygulama saat dilimi ve ödeme sağlayıcısı panelindeki zaman dilimi karşılaştırılmalıdır. Yanlış zaman yorumlaması, hatanın hiç oluşmadığı izlenimini verebilir.

WordPress ve WooCommerce loglarında kontrol edilmesi gerekenler

WordPress tabanlı sistemlerde ödeme bildirimleri yalnızca web sunucusu loglarında değil, eklenti loglarında da iz bırakır. WooCommerce kullanılıyorsa WooCommerce > Durum > Günlükler bölümünde ödeme ağ geçidine ait kayıtlar incelenmelidir.

Burada sipariş numarası, ödeme yöntemi, durum değişikliği ve sağlayıcıdan dönen cevaplar aranmalıdır. “Pending payment” durumunda kalan siparişler, bildirimin alınmadığını ya da doğrulama aşamasında başarısız olduğunu gösterir. “Processing” veya “Completed” durumuna geçip müşteri bildirimi gitmiyorsa sorun ödeme entegrasyonunda değil, e-posta gönderim katmanında olabilir.

E-posta bildirimleri için mail logları nasıl okunmalı?

Ödeme sisteme işlenmiş ancak müşteriye veya yöneticiye bildirim gitmemişse mail logları kontrol edilmelidir. Bu aşamada SMTP eklentisi kayıtları, sunucu mail kuyruğu ve varsa dış e-posta servis sağlayıcısı logları birlikte değerlendirilmelidir.

Şu kayıtlar önemlidir:

• SMTP authentication failed
• Connection timed out
• Relay access denied
• Message queued ancak teslim edilmemiş e-postalar
• SPF, DKIM veya DMARC doğrulama hataları
• Alıcı adresinin engellenmesi veya bounce kayıtları

Birçok ekip yalnızca ödeme sağlayıcısına odaklanır; ancak sipariş durumu doğru güncellendiği halde e-posta çıkışı başarısız olabilir. Bu ayrımı yapmak, gereksiz entegrasyon değişikliklerini önler.

Güvenlik duvarı, ModSecurity ve rate limit kayıtları

Webhook bildirimleri bazen güvenlik sistemi tarafından şüpheli istek olarak algılanır. ModSecurity, WAF, bot koruma veya rate limit kuralları ödeme sağlayıcısının isteğini engelleyebilir. Bu durumda erişim logunda 403 görünürken güvenlik loglarında kural ID’si yer alır.

Aranacak ifadeler arasında ModSecurity, Access denied, rule matched, blocked by firewall ve rate limit exceeded bulunur. Eğer aynı sağlayıcı IP’sinden kısa aralıklarla birden fazla bildirim geliyorsa rate limit tetiklenebilir. Güvenli çözüm, tüm korumayı kapatmak değil; ödeme sağlayıcısının doğrulanmış IP aralıkları ve webhook URL’si için kontrollü istisna tanımlamaktır.

Yanlış teşhisleri önlemek için pratik kontrol sırası

İnceleme yaparken önce ödeme sağlayıcısında işlemin başarılı olup olmadığı doğrulanmalı, ardından webhook gönderim sonucu kontrol edilmelidir. Sonra sunucu access loglarında ilgili POST isteği aranmalı, hata kodu varsa error log ile eşleştirilmelidir. Uygulama siparişi güncelliyorsa mail logları incelenmelidir.

Bu sıra izlenmediğinde örneğin e-posta sorunu, ödeme bildirimi sorunu sanılabilir. Benzer şekilde yanlış callback URL’si varken PHP kodunda hata aranması zaman kaybettirir. Kurumsal yapılarda her ödeme için transaction ID, sipariş ID, zaman damgası ve yanıt kodunun birlikte kaydedilmesi operasyonel takibi ciddi ölçüde kolaylaştırır.

Kalıcı izleme için alınabilecek önlemler

Ödeme bildirimleri kritik iş süreçlerinden biridir; bu nedenle yalnızca hata oluştuğunda log bakmak yeterli değildir. Webhook uç noktaları için ayrı erişim kaydı tutulması, 200 dışındaki yanıtlar için alarm üretilmesi ve başarısız bildirimlerin tekrar işlenebilmesi gerekir.

Hosting altyapısında log saklama süresi kısa ise sorun fark edildiğinde ilgili kayıtlar silinmiş olabilir. En azından ödeme, e-posta ve uygulama hataları için yeterli saklama politikası belirlenmeli; canlı sistemde test ödeme senaryoları düzenli aralıklarla çalıştırılmalıdır. Böylece bildirim zincirinin hangi halkasında aksama yaşandığı hızlıca görülebilir.