İyzico ile Ödeme Altyapısı Kurmak: Türkiye Gerçekleri
Stripe kadar pürüzsüz görünmese de Türkiye'de gerçekçi seçenek İyzico. Biletlemesinden SaaS'a kadar entegrasyonlarda öğrendiklerim.
Neden Türkiye'de önce İyzico?
Yurt dışı ödeme sağlayıcıları her use case için uygun değil. Türkiye'de şirket yapısı, sözleşme süreci, 3DS zorunluluğu ve müşterinin kart alışkanlığı farklı. Etkinlik biletlemesi ve SaaS projelerinde İyzico ile çalışmak pratik bir başlangıç noktası.
Asıl mesele SDK'yı bağlamak değil; ödeme başarısız olduğunda kullanıcıya ne göstereceğiniz, webhook geciktiğinde sipariş durumunu nasıl yöneteceğiniz ve iade/iptal akışını nasıl kuracağınız.
Entegrasyonda en çok patlayan noktalar
- Webhook endpoint'inin idempotent olmaması — aynı ödeme iki kez işleniyor
- 3DS dönüşünde session/order eşleşmesinin kaybolması
- Test ortamında çalışan akışın prod merchant ayarlarında farklı davranması
- Mobil webview ile ödeme sayfası arasında cookie / redirect sorunları
- Başarılı ödeme sonrası kullanıcıya erken "tamamlandı" mesajı, webhook henüz gelmeden
Backend tarafında nasıl kurguluyorum?
Ödeme durumunu tek bir `payment_intent` veya `order_payment` tablosunda tutuyorum: `pending`, `requires_action`, `paid`, `failed`, `refunded`. Kullanıcı arayüzü bu state'e bakıyor; webhook sadece state'i güncelliyor.
NestJS veya Go tarafında webhook handler'ları mutlaka imza doğrulaması + idempotency key ile yazıyorum. Özellikle yüksek trafikli bilet satışında aynı callback'in tekrar gelmesi normal.
Prod öncesi test
Mutlaka gerçek kartla düşük tutarlı prod testi yapın. Sandbox'ta her şey düzgün olsa bile prod merchant panelindeki ayar farkı sizi şaşırtabiliyor.
Mobil uygulama vs web ödeme
Mobilde uygulama içi dijital ürün satışı App Store kurallarına giriyor; fiziksel hizmet veya gerçek dünya biletleme farklı. Bu ayrımı baştan netleştirmeden ödeme altyapısı seçmeyin.
Web checkout + deep link dönüşü mobilde çalışır; ama UX maliyeti var. Proje tipine göre native In-App Purchase, web ödeme veya hibrit model seçiyorum.