Ödeme Hataları, İptal ve İade Süreçleri Nasıl Yönetilir?
Ders 4 / 10 · 30 dakika okuma · İleri
Başarısız ve belirsiz ödeme sonuçlarını sınıflandırmayı; iptal, tam/kısmi iade, mükerrer ödeme ve işlem uyuşmazlıklarını sipariş ve finans kayıtlarıyla tutarlı biçimde yönetmeyi öğrenin.
Bu Derste Öğrenecekleriniz
- ✓Ödeme hatalarını finansal ret, doğrulama, teknik hata ve belirsiz sonuç olarak sınıflandırmak
- ✓Retry kararını hata türüne göre vermek
- ✓İptal ile iade arasındaki operasyonel farkı açıklamak
- ✓Tam ve kısmi iadelerde iade edilebilir bakiye kontrolü kurmak
- ✓Birden fazla iade işlemini orijinal tahsilatla ilişkilendirmek
- ✓Mükerrer ödeme ve çift tahsilat vakalarını yönetmek
- ✓İade durumu ile sipariş/ürün iade durumunu birbirinden ayırmak
- ✓Hata ve iade KPI'larını kök neden iyileştirmesine bağlamak
Ödeme operasyonunun kalitesi yalnız başarılı işlemlerde değil, sorun çıktığında belli olur. Müşteri ödeme yapamadığında, işlem sonucu bilinmediğinde veya tahsil edilen tutarın geri gönderilmesi gerektiğinde sistemin ne yapacağı önceden tanımlanmış olmalıdır.
1. Ödeme hatalarını tek bir 'başarısız' durumuna sıkıştırmayın
| Hata sınıfı | Örnek | Tipik yaklaşım |
|---|---|---|
| Finansal/kart reddi | İşlem banka tarafından onaylanmadı | Alternatif kart/yöntem veya kullanıcı aksiyonu |
| Doğrulama hatası | 3D Secure tamamlanamadı | Doğrulamayı yeniden başlatma |
| Teknik hata | Gateway/servis erişim sorunu | Kontrollü retry veya alternatif kanal |
| Belirsiz sonuç | İstek gitti, cevap alınamadı | İşlemi sorgula; yeni tahsilatı beklet |
| İş kuralı hatası | Tutar/para birimi/sipariş uyuşmazlığı | İşlemi durdur ve incele |
Bu ayrım müşteri deneyimini, retry davranışını ve hata analitiğini doğrudan etkiler. Kesin banka reddini sistem arızası gibi otomatik tekrar etmek veya timeout'u kesin ret saymak farklı riskler doğurur.
2. Hata kodlarını normalize edin
Birden fazla banka veya ödeme sağlayıcısı kullanıldığında aynı temel problem farklı kodlarla dönebilir. İşletme sağlayıcı kodunu saklarken kendi ortak hata sınıflarını da oluşturabilir.
| İç hata sınıfı | Sağlayıcı kodu | Müşteri aksiyonu | Retry uygunluğu |
|---|---|---|---|
| DECLINED | Sağlayıcıya özgü | Başka kart/yöntem | Genellikle kullanıcı aksiyonu gerekir |
| AUTH_FAILED | Sağlayıcıya özgü | Doğrulamayı yeniden dene | Koşula bağlı |
| TEMPORARY_ERROR | Sağlayıcıya özgü | Kısa süre sonra tekrar | Kontrollü |
| UNKNOWN_RESULT | Timeout/network | Bekle/sonucu doğrula | Sorgulamadan yeni ödeme yok |
| INVALID_REQUEST | Validation | İşletme hatası | Düzeltmeden retry yok |
3. Retry politikasını güvenli sınırlarla kurun
Geçici teknik hatada kontrollü retry yararlı olabilir; ancak sonsuz tekrar, müşteriye art arda doğrulama ekranı göstermek veya kesin reddedilen işlemi aynı şekilde yeniden göndermek doğru değildir. Maksimum deneme, bekleme ve hangi hata sınıflarında retry yapılacağı belirlenmelidir.
Uyarı — Belirsiz sonucu yeniden tahsil etmeyin
4. İptal ve iadeyi işlem yaşam döngüsüne göre ayırın
Ödeme sistemlerinde 'iptal/void' ve 'iade/refund' kavramlarının teknik uygulanışı sağlayıcı ve işlem yaşam döngüsüne göre değişebilir. İşletme entegrasyonu, sağlayıcının hangi aşamada hangi operasyonu desteklediğini esas almalıdır.
| Operasyon | İşletme açısından amaç | Kontrol |
|---|---|---|
| İptal/void | Uygun aşamadaki işlemi finansal tamamlanmadan geri almak | İşlem durumu ve sağlayıcı desteği |
| Tam iade | Tahsil edilen uygun tutarın tamamını geri göndermek | Kalan iade edilebilir bakiye |
| Kısmi iade | Tahsilatın belirli kısmını geri göndermek | Toplam iadelerin orijinal tutarı aşmaması |
Uyarı — Terminoloji sağlayıcıya göre değişebilir
5. Her iadeyi orijinal tahsilata bağlayın
İade bağımsız bir para çıkışı olarak tutulmamalıdır. Hangi başarılı ödeme işlemine ait olduğu, iade tutarı, nedeni, zamanı, sağlayıcı iade ID'si ve sonucu saklanmalıdır.
| Alan | Örnek |
|---|---|
| Original payment ID | PAY-10425 |
| Refund ID | REF-00081 |
| İade tutarı | 750 TL |
| Neden | Ürün iadesi |
| Durum | Bekliyor/Başarılı/Başarısız |
| Sağlayıcı referansı | Provider refund ID |
| İşlemi başlatan | Yetkili kullanıcı/sistem |
6. İade edilebilir bakiyeyi hesaplayın
Bir ödeme birden fazla kısmi iadeye konu olabilir. Yeni iade oluşturulmadan önce başarılı orijinal tahsilattan daha önce başarıyla tamamlanan iadeler düşülerek kalan iade edilebilir tutar kontrol edilmelidir.
Örnek — Kısmi iade hesabı
7. İade talebi ile iade sonucunu ayırın
Kullanıcının 'iade et' butonuna basması paranın müşteriye başarıyla döndüğü anlamına gelmez. Sağlayıcı işlemi reddedebilir, işlem bekleyebilir veya teknik hata oluşabilir. Refund kaydı kendi durum yaşam döngüsüne sahip olmalıdır.
| İade durumu | Anlam |
|---|---|
| Created | İade talebi oluşturuldu |
| Processing | Sağlayıcı işlemi sürüyor |
| Succeeded | İade başarılı |
| Failed | İade tamamlanamadı |
| Unknown | Sonuç doğrulanmalı |
8. Sipariş/ürün iadesi ile ödeme iadesini senkronize edin
Müşterinin ürünü iade etmesi lojistik ve ticari bir süreçtir; paranın geri gönderilmesi finansal ödeme sürecidir. Ürün depoya dönmeden para iadesi yapılmayacaksa bu iş kuralı sistemde açık olmalıdır. Tersi durumda da müşteri iade onayı aldığı halde ödeme iadesinin başarısız kaldığı fark edilmelidir.
Örnek — İki farklı durum
9. Mükerrer ödemeyi otomatik tespit etmeye çalışın
Aynı sipariş için kısa sürede birden fazla başarılı tahsilat oluşması, müşteri retry'ı veya entegrasyon hatası kaynaklı olabilir. Aynı sipariş, benzer tutar, aynı müşteri ve yakın zaman aralığındaki başarılı işlemler risk sinyali olarak işaretlenebilir.
Uyarı — Otomatik iade kararı dikkat ister
10. Yetkisiz veya hatalı iadeyi önleyin
İade para çıkışıdır. Yetki matrisi, maksimum iade tutarı, neden kodu, gerekiyorsa çift onay ve audit trail özellikle yüksek tutarlı iadelerde önemlidir. Kullanıcıların serbestçe herhangi bir ödeme ID'sine iade başlatabilmesi kontrol zafiyeti yaratır.
| Kontrol | Amaç |
|---|---|
| Rol/yetki | Kim iade başlatabilir? |
| Tutar limiti | Hangi tutara kadar tek yetki yeterli? |
| Neden kodu | İade neden yapılıyor? |
| Sipariş/ödeme bağı | İade meşru işleme mi ait? |
| Kalan bakiye | Aşırı iade engelleniyor mu? |
| Audit trail | Kim, ne zaman, ne yaptı? |
11. Hata ve iade KPI'larını kök nedene bağlayın
Yüksek iade oranı yalnız ödeme ekibinin problemi olmayabilir; yanlış ürün açıklaması, stok, lojistik veya müşteri beklentisi kaynaklı olabilir. Benzer biçimde ödeme hata oranı sağlayıcı, banka, kart türü, cihaz veya entegrasyon sürümüne göre analiz edilmelidir.
| KPI | Boyutlar | Olası aksiyon |
|---|---|---|
| Payment failure rate | Sağlayıcı, hata sınıfı, cihaz, zaman | Teknik/UX/sağlayıcı analizi |
| Unknown result rate | Sağlayıcı, endpoint, sürüm | Timeout ve sorgu akışı iyileştirme |
| Refund rate | Ürün, kategori, neden | Ürün/lojistik/kalite analizi |
| Refund failure rate | Sağlayıcı, hata kodu | Operasyon ve entegrasyon düzeltmesi |
| Duplicate payment vakası | Sipariş, kanal, retry | Idempotency ve retry iyileştirme |
12. Gün sonu mutabakatı açık kalan vakaları yakalamalıdır
Sipariş sistemi 'başarısız' derken sağlayıcıda başarılı görünen ödeme, sistemde başarılı görünen ancak sağlayıcıda bulunamayan işlem veya başarılı görünen iadenin sağlayıcı tarafında başarısız kalması mutabakatla tespit edilmelidir.
- Sipariş ödenmedi görünüyor ancak sağlayıcıda tahsilat var
- Sipariş ödendi görünüyor ancak sağlayıcı işlemi yok/başarısız
- Aynı siparişte beklenmeyen birden fazla başarılı tahsilat var
- İade sistemde tamamlandı görünüyor ancak sağlayıcıda başarısız
- Tutar veya para birimi uyuşmuyor
- Sağlayıcı işlem kaydı sipariş/ödeme referansıyla eşleşmiyor
İlgili çözüm: Ödeme Entegrasyonları
Şimdi Uygulayın
Uygulama Görevi — Hata, İptal ve İade Karar Matrisi
En sık karşılaşabileceğiniz sekiz ödeme vakasını seçin: banka reddi, doğrulama hatası, timeout, callback gecikmesi, müşteri iptali, tam iade, kısmi iade ve mükerrer tahsilat. Her vaka için otomatik aksiyon, manuel inceleme gereksinimi, müşteri mesajı ve mutabakat kontrolünü tanımlayın.
| Vaka | Otomatik aksiyon | Manuel kontrol | Müşteri mesajı | Mutabakat |
|---|---|---|---|---|
| Banka reddi | … | … | … | … |
| Timeout | … | … | … | … |
| Tam iade | … | … | … | … |
| Kısmi iade | … | … | … | … |
| Mükerrer ödeme | … | … | … | … |
İpucu — Kabul testi
Bu Derste Ne Öğrendik?
- ✓Ödeme operasyonunda başarısızlıkların tamamı aynı değildir.
- ✓Kesin ret, doğrulama sorunu, teknik hata ve sonucu belirsiz işlem farklı aksiyon gerektirir.
- ✓Başarılı tahsilat sonrasında iptal/iade süreçleri orijinal ödeme kaydıyla ilişkilendirilmeli; iade edilebilir bakiye aşılmamalı ve tam/kısmi iadeler ayrı izlenmelidir.
- ✓Sipariş iadesi ile paranın müşteriye geri gönderilmesi de ayrı fakat ilişkili süreçlerdir.