Sanal POS & Ödeme Hataları 2025: Çözüm Kılavuzu

Sanal POS ve Ödeme Hataları Çözüm Kılavuzu​

Sanal POS hataları yalnızca teknik hata kodu değildir; ödeme onay oranını, müşteri güvenini, destek yükünü ve günlük nakit akışını doğrudan etkiler. 3D Secure dönüşü, zaman aşımı, banka reddi, komisyon farkı ve webhook gecikmesi düzenli izlenmezse satış var gibi görünür ama tahsilat ve mutabakat bozulur.
Bu kılavuz, ödeme hatalarını sınıflandırmak, tekrar eden sorunları önceliklendirmek ve checkout akışını daha güvenilir hale getirmek için hazırlanmıştır. Hedef, her hatayı tek tek ezberlemek değil; hatayı doğru gruba ayırıp kanıtla çözmektir.

---

Neden Önemli?​

Ödeme adımı mağazanın en hassas noktasıdır. Kullanıcı ürünü seçmiş, sepeti kabul etmiş ve kart bilgisini girmiştir; bu noktada belirsiz hata mesajı veya yavaş yönlendirme, satışın kaybı anlamına gelir.
Hataları ölçmeden yapılan sağlayıcı değişikliği de kalıcı çözüm değildir. Önce hata tipi, cihaz, banka, kart türü, tutar, saat, 3DS sonucu ve sipariş durumu kayıt altına alınmalıdır. Böylece sorun sağlayıcıdan mı, entegrasyondan mı, checkout deneyiminden mi kaynaklanıyor ayrılır.

Hata Kodlarını Sınıflandırma​

• Kart ve limit hataları: Yetersiz bakiye, limit, kart kapalı, yanlış CVV veya son kullanma tarihi gibi kullanıcı taraflı durumlar.
• 3D Secure hataları: Kullanıcının doğrulamayı tamamlamaması, banka ekranından dönememesi veya oturum süresinin dolması.
• Timeout ve bağlantı: Sağlayıcı, banka, sunucu veya kullanıcı ağı nedeniyle ödeme sonucunun geç dönmesi.
• Risk ve fraud: Şüpheli işlem, yüksek tutar, farklı ülke/IP veya sağlayıcı risk motoru tarafından reddedilen işlemler.
• Mutabakat farkı: Sipariş başarılı görünürken tahsilatın eksik, beklemede veya farklı komisyonla gelmesi.

3D Secure ve Mobil Deneyim​

3D Secure hatalarının önemli kısmı teknik entegrasyondan çok kullanıcı deneyiminden doğar. Mobilde banka ekranına geçiş yavaşsa, geri dönüş linki belirsizse veya kullanıcı başarısız denemeden sonra sepete dönemiyorsa terk artar.
Ödeme ekranında kısa açıklama, net hata mesajı ve güvenli geri dönüş yolu olmalıdır. Kullanıcıya 'ödeme başarısız' demek yerine, işlem reddedildiyse farklı kart denemesi, banka doğrulaması tamamlanmadıysa tekrar deneme, teknik zaman aşımı varsa destek bağlantısı gösterilmelidir.

Timeout, Retry ve Idempotency​

Ödeme sistemlerinde en riskli senaryo, bağlantı koparken işlemin gerçekten gerçekleşip gerçekleşmediğinin bilinmemesidir. Aynı siparişi kontrolsüz tekrar göndermek çift çekim riski doğurabilir; hiç tekrar denememek ise ödeme kaybına neden olur.
Bu yüzden ödeme isteği, sipariş numarası ve tekrar deneme davranışı idempotent tasarlanmalıdır. Sağlayıcı destekliyorsa aynı işlem için benzersiz bir anahtar kullanılmalı; zaman aşımından sonra önce işlem sonucu sorgulanmalı, sonra gerekirse kullanıcıya kontrollü tekrar deneme sunulmalıdır.

Komisyon, Mutabakat ve Net Gelir​

• Komisyon hesabını yalnızca oran olarak değil, sabit ücret, taksit farkı, iade maliyeti ve chargeback etkisiyle okuyun.
• Günlük tahsilat raporu ile mağaza sipariş raporunu eşleştirin.
• Kısmi iade ve iptal işlemlerinin stok, fatura ve muhasebe tarafını doğru güncellediğini kontrol edin.
• Sağlayıcı panelindeki başarılı işlem ile mağaza sipariş durumunun aynı anlama geldiğinden emin olun.
• Yüksek hata oranı görülen banka, kart türü veya cihaz kırılımını ayrı raporlayın.

Loglama ve Alarm​

Ödeme hatası çözümü için log şarttır; ancak loglarda kart numarası, CVV veya gereksiz kişisel veri tutulmamalıdır. Güvenli log; sipariş id, sağlayıcı işlem id, hata kodu, zaman, tutar, cihaz tipi ve sonuç durumunu içermelidir.
Alarm eşiği basit başlayabilir: son 30 dakikada başarısız ödeme oranı belirli bir seviyeyi aşarsa, webhook gecikmesi artarsa veya başarılı ödeme sonrası sipariş durumu güncellenmezse ekip bilgilendirilir. Bu sayede sorun müşteri şikayetiyle değil, sistem sinyaliyle yakalanır.

Mikro Vaka​

Bir mağazada mobil ödeme reddi yüksek görünüyordu. Loglar incelendiğinde reddin bankadan değil, 3DS dönüşünden sonra checkout sayfasının eski oturuma dönememesinden kaynaklandığı görüldü. Dönüş URL'si ve hata mesajı düzeltildiğinde aynı sağlayıcıyla onay oranı yükseldi.
Bu örnek, sağlayıcı değiştirmeden önce kanıt toplamayı hatırlatır. Hata kodu tek başına değil, cihaz, oturum ve sipariş durumu ile birlikte okunmalıdır.

Basit Formül​

SSS​

• En sık ödeme hatası hangisidir? Mağazaya göre değişir; kart reddi, 3DS tamamlanmaması ve timeout ayrı raporlanmalıdır.
• Timeout olursa tekrar ödeme alınmalı mı? Önce işlem sonucu sorgulanmalı; çift çekim riskine karşı idempotent tasarım kullanılmalıdır.
• 3DS hataları nasıl azalır? Mobil yönlendirme, geri dönüş sayfası, açık hata mesajı ve tekrar deneme yolu iyileştirilmelidir.
• Komisyon nasıl karşılaştırılır? Oran, sabit ücret, taksit, iade, chargeback ve ödeme vadesi birlikte hesaplanmalıdır.
• Loglarda ne tutulmamalı? Kart numarası, CVV ve gereksiz kişisel veri tutulmamalıdır.
• Hangi metrik izlenmeli? Onay oranı, timeout oranı, webhook gecikmesi, mutabakat farkı ve ödeme kaynaklı destek talebi izlenmelidir.

Ödeme Hatası İnceleme Akışı​

Bir ödeme hatası geldiğinde önce müşteriye açık ve sakin bir yanıt verilmelidir; teknik araştırma ise ayrı kanaldan yürütülür. İncelemede sipariş id, sağlayıcı işlem id, hata kodu, banka yanıtı, cihaz, tarayıcı, tutar, saat, 3DS sonucu ve webhook durumu birlikte okunur. Bu alanlardan biri eksikse hata gerçek nedenine ulaşmadan 'kart sorunu' diye kapatılabilir.
Araştırma sırası basit tutulmalıdır: önce mağaza sipariş kaydı, sonra ödeme sağlayıcı paneli, ardından sunucu logu ve son olarak banka/sağlayıcı destek yanıtı. Böylece ekip aynı işlem için dağınık ekran görüntüleriyle değil, tek olay kaydıyla ilerler.

Müşteri Mesajı Nasıl Yazılmalı?​

Başarısız ödeme mesajı kullanıcıyı suçlamamalı ve teknik kodla boğmamalıdır. 'İşleminiz tamamlanamadı' ifadesinin yanında farklı kart deneme, bankayı kontrol etme, birkaç dakika sonra tekrar deneme veya destekle iletişim kurma seçenekleri verilmelidir. Kullanıcı kartından para çekilip çekilmediğini merak eder; bu yüzden tahsilat durumu mümkün olduğunca net anlatılmalıdır.

Destek notu' Alıntı:

Müşteriye gösterilen kısa mesaj ile destek ekibinin gördüğü teknik hata kodu ayrı tutulmalıdır.

Genişletmek için tıkla ...

Destek ekibi için hazır cevap şablonları hazırlanabilir. Ancak her şablon işlem id ve tahsilat durumu kontrol edildikten sonra kullanılmalıdır; aksi halde yanlış güvence daha büyük güven kaybı yaratır.

Haftalık Ödeme Sağlığı Raporu​

• Toplam ödeme denemesi, başarılı ödeme ve başarısız ödeme oranı.
• 3DS tamamlanmama oranı ve mobil/kart kırılımı.
• Timeout, webhook gecikmesi ve sipariş durumu uyuşmazlığı sayısı.
• İade, iptal, chargeback ve komisyon farkı kayıtları.
• Ödeme kaynaklı destek talebi ve tekrar ödeme denemesi oranı.

Bu rapor haftalık okunursa sorunlar kampanya döneminde büyümeden yakalanır. Sağlayıcı değişimi, checkout sadeleştirme veya hata mesajı iyileştirme kararı da ölçüye dayanır.

Mevcut Grafikler​

Ödeme akışı ve komisyon karşılaştırması için mevcut grafikler korunmuştur.

İç Bağlantılar​

• Ödeme sistemleri sıfırdan kurulum
• Ödeme sistemleri teknik SEO rehberi
• E-ticaret sıfırdan kurulum
• E-ticaret audit rehberi

Dış Kaynak​

• PCI Security Standards Council
• Stripe Docs: idempotent requests
• iyzico resmi dokümantasyonu

Özetle​

Ödeme hataları hata kodu ezberleyerek değil, sınıflandırma, güvenli log, idempotent tekrar deneme ve düzenli mutabakatla çözülür. Önce kanıt toplayın, sonra checkout deneyimini ve entegrasyonu düzeltin.

Güncelleme: 2026-06-16

---