Ödeme Sistemleri Entegrasyonu: Kredi Kartı, E-Cüzdan ve Alternatif Ödeme Yöntemleri
E-ticarette ödeme sayfası, bütün sitenin “kasa”sıdır. Ürün sayfaların mükemmel olabilir, kampanya şahane olabilir; ama ödeme akışın yavaşsa, güvensiz görünüyorsa veya hata veriyorsa satışın orada biter. Ödeme entegrasyonu bu yüzden “tak-çalıştır” değil, mimari bir konu.
Ödeme yöntemlerini geniş tutmak neden satış getirir?
Her müşteri aynı şekilde ödeme yapmak istemez. Kimi kart kullanır, kimi havale ister, kimi cüzdanla “tek tık” ister, kimi de taksit olmazsa vazgeçer. Sen seçenekleri artırdıkça, müşterinin “bahane” sayısı azalır.
- Daha az terk: Müşterinin istediği yöntem yoksa checkout terk edilir.
- Daha yüksek dönüşüm: Hızlı yöntemler (cüzdan, kaydedilmiş kart) ödeme bariyerini düşürür.
- Daha geniş kitle: Bazı sektörlerde kapıda ödeme/havale hâlâ kritik.
- Daha iyi sepet: Taksit ve alternatif finansman sepeti büyütebilir.
Ödeme yöntemleri haritası: hangisi ne işe yarar?
| Yöntem | Avantaj | Dikkat |
|---|---|---|
| Kredi/Banka Kartı (Sanal POS) | Yaygın, güvenilir, taksit mümkün | Komisyon, 3D Secure, iade/chargeback süreçleri |
| E-Cüzdan | Hızlı ödeme, mobilde çok iyi | Desteklenen pazar/ülke, kullanıcı alışkanlığı |
| Havale/EFT | Düşük komisyon, bazı kitlelerde tercih | Onay ve muhasebe operasyonu, gecikme riski |
| Kapıda Ödeme | Güven eşiğini düşürür (özellikle ilk alışveriş) | İade/iptal maliyeti, kargo firması kısıtları |
| BNPL / Taksitli Finansman | Sepeti büyütebilir | Onay süreçleri, komisyon, iade kurgusu |
| Kripto vb. alternatifler | Niş kitle, PR etkisi | Regülasyon, muhasebe, volatilite |
Entegrasyonun “görünmeyen” zor kısımları
1) 3D Secure stratejisi
3D Secure güvenliği artırır ama yanlış kurgulanırsa dönüşümü düşürebilir. İyi yaklaşım: riskli işlemlerde zorunlu, düşük riskte akıllı yönlendirme. (Sektöre ve fraud oranına göre değişir.)
2) İade/iptal akışı (refund/void)
Ödeme almak kadar iade yönetimi de önemlidir. Kısmi iade (partial refund), kargo iadesi, kuponla ödenen sepetin iadesi gibi senaryoları baştan tasarlamazsan destek ekibi ve muhasebe “yangın” yaşar.
3) Chargeback ve itiraz yönetimi
Kartlı ödemelerde chargeback (ters ibraz) gerçeği var. Sipariş teslim kanıtı, loglar, sözleşmeler ve açık politika metinleri bu süreçte hayat kurtarır.
4) Taksit ve komisyon mantığı
“Taksit var” demek yetmez. Hangi karta kaç taksit, hangi komisyonla, sepet limitleri neler? Bunlar checkout ekranında net görünmeli; sürpriz komisyon güven kırar.
Mimari yaklaşım: tek sağlayıcıya mahkum olma
Burada en kritik tasarım fikri şu: ödeme sistemini “modül” gibi düşün. Bugün bir sağlayıcıyla çalışırsın, yarın komisyon artar veya sorun yaşarsın. Değiştirebilmek için altyapın hazır olmalı.
Önerilen yapı
- Payment Provider Adapter: Her sağlayıcı için ayrı adapter (iyzico/PayTR/Stripe vb.)
- Ortak Payment Service: Uygulamanın geri kalanına tek arayüz
- Durum makinesi: Pending → Authorized → Captured → Refunded gibi net statüler
- Webhook doğrulama: “Banka gönderdi” diye gelen bildirim gerçekten bankadan mı?
- Idempotency: Aynı ödeme isteği iki kez gelirse iki kez çekme!
Basit bir ödeme durum seti:
Initiated(başlatıldı)Authorized(provizyon alındı)Captured(çekim tamamlandı)Failed(başarısız)Refunded(iade edildi)Chargeback(ters ibraz)
Güvenlik: fraud önleme “kural seti” ile başlar
Fraud önleme, tek bir “anti-fraud” ürünü satın almak değildir. Önce temel kuralları koyarsın:
- Şüpheli IP/ülke eşleşmesi
- Aynı kartla kısa sürede çok deneme
- Fatura adresi ve teslimat adresi uyumsuzluğu
- Yeni hesap + yüksek tutar + hızlı alışveriş kombinasyonu
- Dijital ürünlerde anında teslimatı risk skoruna bağlama
Özellikle dijital ürün satıyorsan (epin/gift card gibi) “anında teslimat” fraud için cazip olabilir. Bu yüzden riskli işlemlerde teslimatı otomatik değil, kontrollü akışa bağlamak mantıklıdır.
Checkout UX: ödeme başarısı tasarımdan da geçer
- Adım sayısını azalt: Gereksiz form alanlarını kaldır.
- Güven işaretleri: SSL, 3D Secure, iade politikası linki.
- Hata mesajı net olsun: “Bir hata oluştu” değil; ne yapmalı?
- Mobil öncelik: Kart girişinde doğru klavye, otomatik formatlama.
- Yükleme süresi: Ödeme ekranı yavaşsa terk artar.
En büyük iyileştirme bazen yeni bir ödeme yöntemi eklemek değil, mevcut ödeme akışını sürtünmesiz hale getirmektir.
Test ve operasyon: “Prod’da deneriz” deme
Ödeme entegrasyonu test edilmeden yayına alınmaz. Nokta.
- Test kartlarıyla 3D/3D olmayan senaryolar
- Webhook kesilince ne olur?
- İade/iptal ve kısmi iade
- Tekrar deneme (retry) ve idempotency
- Loglar ve müşteri destek ekranı (ödeme geçmişi)
BerkiTech yaklaşımı: ödeme altyapısı “değiştirilebilir” olmalı
BerkiTech tarafında hedef; ödeme modülünü tek bir firmaya kilitlemeden, çoklu sağlayıcı desteği, güçlü webhook doğrulaması ve net bir ödeme durum modeliyle kurmak. Böylece hem ölçek büyürken hem de pazar koşulları değişirken ödeme tarafı sistemin zayıf halkası olmaz.