E-ticarette ödeme başarısızlığı artıyorsa ilk bakılacak metrik yalnızca başarısız sipariş sayısı değildir. Sorunu teşhis etmek için ödeme adımına gelen kullanıcı sayısını, ödeme başlatanları, banka yanıtlarını, 3D Secure geçişlerini ve teknik hata kayıtlarını aynı akışta incelemek gerekir. Aksi halde banka tarafından reddedilen kart işlemleriyle sitenin oluşturamadığı ödeme istekleri aynı problem gibi görünür. E-Ticarette Ödeme Başarısızlığı Neden Artar? Hata Kodları değerlendirmesinde bu ayrımı baştan kurmak, sonraki analizlerin doğruluğunu artırır.
Önce kaybın hangi ödeme adımında oluştuğunu bulun
Ödeme hunisini tek bir dönüşüm oranıyla değerlendirmek teşhisi zorlaştırır. En azından aşağıdaki olayların ayrı ayrı kaydedilmesi gerekir:
- Ödeme sayfasının görüntülenmesi
- Ödeme formunun gönderilmesi
- Ödeme kuruluşuna veya sanal POS’a istek iletilmesi
- Banka ya da kart kuruluşundan yanıt alınması
- 3D Secure doğrulamasının başlatılması
- 3D Secure doğrulamasının tamamlanması
- Siparişin başarılı veya başarısız olarak sonuçlanması
Örneğin ödeme formu gönderiliyor, fakat ödeme kuruluşuna hiç istek ulaşmıyorsa kart limiti veya banka reddi üzerinde çalışmak zaman kaybettirir. Buna karşılık banka yanıtı “reddedildi” olarak dönüyor ve hata oranı belirli kart tiplerinde yükseliyorsa sorun ödeme altyapısının teknik erişiminden çok yetkilendirme aşamasındadır. E-Ticarette Ödeme Başarısızlığı Neden Artar? Hata Kodları analizinde ilk ayrım, kaybın bu olaylardan hangisinde başladığıdır.
E-Ticarette Ödeme Başarısızlığı Neden Artar? Hata Kodları: Hata sinyalini dört ana gruba ayırın
| Hata grubu | Tipik sinyal | İlk kontrol noktası |
|---|---|---|
| Banka veya kart reddi | İstek karşı tarafa ulaşır, işlem olumsuz yanıtlanır | Yanıt kodu, kart tipi, taksit ve tutar |
| 3D Secure problemi | Doğrulama ekranında terk, zaman aşımı veya başarısız doğrulama | 3DS durum kodu, cihaz ve yönlendirme akışı |
| Teknik hata | İstek oluşmaz, zaman aşımına uğrar veya beklenmeyen yanıt döner | API logları, callback ve sunucu yanıtları |
| Operasyon ve veri hatası | Geçersiz tutar, para birimi, taksit veya sipariş bilgisi | Sepet, ödeme isteği ve sipariş kayıtlarının karşılaştırması |
Bu sınıflandırma, ekiplerin farklı sorumluluk alanlarını birbirine karıştırmasını önler. Banka reddini yazılım ekibine, callback kopmasını da müşteri hizmetlerine aktarmak çözüm süresini uzatır.
Banka ve kart reddini hata koduyla birlikte okuyun
Ödeme kuruluşlarının kullandığı hata kodları ve açıklamalar birbirinin tam karşılığı değildir. “Declined”, “do not honor”, yetersiz bakiye, limit aşımı, kartın kullanıma kapalı olması veya güvenlik nedeniyle reddedilmesi farklı aksiyonlar gerektirebilir. Kodun yanında şu boyutları da raporlayın:
- İşlem tutarı ve para birimi
- Kartın kredi, banka veya sanal kart olması
- Yurt içi ya da yurt dışı kart kullanımı
- Taksit seçimi ve taksit sayısı
- İşlemin ilk deneme mi, yeniden deneme mi olduğu
- Reddin belirli banka, kart türü veya cihaz grubunda yoğunlaşıp yoğunlaşmadığı
Örneğin toplam hata oranı yükselmeden yalnızca belirli bir taksit seçeneğinde ret oranı artıyorsa genel bir ödeme kesintisinden söz edilemez. Bu durumda taksit yapılandırması, ilgili kart grubu veya ödeme kuruluşunun o kombinasyona verdiği yanıt incelenmelidir. Hata kodlarını yorumlarken sağlayıcının kendi açıklamasını esas almak gerekir; farklı kuruluşların aynı ifadeyi farklı işlem durumları için kullanması mümkündür. Stripe’ın resmi kart reddi dokümantasyonu, ret mesajlarının tek başına kesin kök neden anlamına gelmeyebileceğini ve ek işlem bağlamının gerektiğini açıklar. E-Ticarette Ödeme Başarısızlığı Neden Artar? Hata Kodları sorusuna yanıt ararken kodu, işlem bağlamından bağımsız değerlendirmemek gerekir.
3D Secure sorununu banka reddiyle karıştırmayın
3D Secure, kart sahibinin doğrulanması için kullanılan ayrı bir aşamadır. Kullanıcı doğrulama ekranına hiç ulaşamıyorsa yönlendirme, tarayıcı, pop-up, JavaScript veya sağlayıcı entegrasyonu incelenmelidir. Ekrana ulaşıyor fakat doğrulamayı tamamlamıyorsa SMS, mobil bankacılık, oturum süresi veya bankanın risk kararı devreye girebilir.
EMVCo’nun 3-D Secure açıklamasında doğrulama akışının kartı çıkaran kuruluş, iş yeri ve ödeme ekosistemindeki diğer taraflar arasında yürüdüğü belirtilir. Bu yapı nedeniyle mağaza panelinde görülen “3D Secure başarısız” ifadesi, her zaman mağazanın hatalı olduğu anlamına gelmez.
Analizde “3DS başlatıldı”, “kart sahibi doğrulandı”, “doğrulama başarısız oldu” ve “sonuç mağazaya iletildi” olaylarını ayrı tutun. Özellikle sonuç mağazaya ulaşmadan sipariş oluşturuluyorsa kullanıcı ödeme yapmış olabilir, fakat sistem sipariş durumunu güncelleyemediği için satış başarısız görünebilir. E-Ticarette Ödeme Başarısızlığı Neden Artar? Hata Kodları incelemesinde bu aşamaların her biri ayrı bir kayıp noktası olarak izlenmelidir.
Teknik hataları ödeme kuruluşundan dönen retlerden ayırın
Teknik problemler çoğu zaman hata kodundan önce zamanlama ve log davranışıyla anlaşılır. Aynı dakikada ödeme isteği sayısı düşüyor, sunucu yanıt süresi uzuyor veya callback kayıtları kayboluyorsa banka retlerini incelemek doğru başlangıç değildir.
| Kontrol | Aranacak belirti | Olası yorum |
|---|---|---|
| İstek logu | Form gönderildiği halde istek kaydı yok | Tarayıcı, uygulama veya doğrulama katmanında kopma |
| Yanıt süresi | Belirli saatlerde timeout artışı | Ödeme kuruluşu, ağ veya sunucu kapasitesi sorunu |
| Callback | Ödeme sonucu geliyor, sipariş güncellenmiyor | Webhook, imza doğrulama veya durum eşleme problemi |
| Tekrarlı istek | Aynı sipariş için birden fazla deneme | Idempotency veya kullanıcıya gösterilen durum sorunu |
Ödeme entegrasyonunda yalnızca “başarılı” veya “başarısız” sonucu saklamak yeterli değildir. İstek zamanı, sağlayıcı işlem numarası, yanıt kodu, sipariş numarası, kart markası, 3DS sonucu ve callback durumu birlikte tutulmalıdır. Kart numarası ve CVV gibi hassas veriler ise loglara yazılmamalıdır. PCI Security Standards Council’ın iş yerleri için güvenlik rehberleri, ödeme verilerinin korunması ve kart verisi kapsamının azaltılması açısından temel başvuru noktasıdır. E-Ticarette Ödeme Başarısızlığı Neden Artar? Hata Kodları değerlendirmesinde teknik loglar, banka yanıtlarıyla birlikte okunmalıdır.
Ödeme başarısızlığı oranını nasıl raporlayın?
Raporlama paydasını doğru seçmezseniz oranlar yanıltıcı olur. Ödeme başarısızlığı oranını tüm site oturumlarına bölmek yerine ödeme başlatan veya ödeme kuruluşuna istek iletilen işlemler üzerinden hesaplamak daha anlamlıdır. Ancak bu iki oran aynı soruyu cevaplamaz:
- Ödeme sayfasından siparişe dönüşüm: Kullanıcıların ödeme adımında ne kadar kaybedildiğini gösterir.
- Yetkilendirme başarı oranı: Ödeme kuruluşuna giden işlemlerin ne kadarının onaylandığını gösterir.
- 3DS tamamlama oranı: Doğrulama akışındaki kaybı gösterir.
- Teknik hata oranı: Sistemin ödeme isteğini sağlıklı biçimde işleyip işlemediğini gösterir.
Bu metrikleri gün, saat, cihaz, tarayıcı, ödeme yöntemi, kart türü ve taksit bazında kırın. Toplam oran normal görünürken mobil Safari’de veya belirli bir banka kartında ciddi kayıp bulunabilir. iyzico’nun resmi geliştirici dokümantasyonu ödeme akışlarındaki istek ve sonuç alanlarını incelerken sağlayıcıya ait işlem kayıtlarının kullanılmasını destekleyen teknik referanslar sunar. E-Ticarette Ödeme Başarısızlığı Neden Artar? Hata Kodları sorusunu yanıtlamak için bu kırılımları birlikte izlemek gerekir.
Teşhis sonrasında uygulanacak düzeltmeler
Her hata grubu için farklı müdahale gerekir. Banka reddinde alternatif ödeme yöntemi, taksit kombinasyonu ve kullanıcıya gösterilen açıklama test edilebilir. 3D Secure kaybında yönlendirme akışı, mobil uyumluluk ve oturum süresi kontrol edilmelidir. Teknik hatalarda timeout, callback yeniden denemesi, idempotency ve izleme alarmları ele alınmalıdır.
Mesajları da hata türüne göre ayırın. “Kartınız reddedildi” ifadesi teknik bir bağlantı probleminde kullanıcıyı yanlış yönlendirir. Kullanıcıya güvenlik açığı yaratmadan yeniden deneme, farklı kart veya alternatif ödeme yöntemi gibi uygulanabilir seçenekler sunulabilir. Sağlayıcı değişikliği ise ancak sorun belirli bir kuruluşta kalıcı ve ölçülebilir biçimde yoğunlaşıyorsa değerlendirilmelidir.
Kısa karar çerçevesi
Ödeme kaybını çözmek için önce olay akışını tamamlayın, ardından hatayı banka, 3D Secure, teknik ve veri kaynaklı olarak sınıflandırın. Hata kodunu tek başına karar ölçütü yapmayın; kart grubu, cihaz, tutar, taksit ve zaman bilgileriyle birlikte okuyun. Bu yaklaşım, toplam başarısızlık oranını düşürmekten önce hangi siparişlerin neden kaybedildiğini görünür hale getirir. E-Ticarette Ödeme Başarısızlığı Neden Artar? Hata Kodları değerlendirmesi, bu karar çerçevesiyle ölçülebilir bir teşhis sürecine dönüşür.
