İyzico mu PayTR mı? E-Ticaret İçin Ödeme Altyapısı Karşılaştırması

İyzico mu PayTR mı?

İyzico ve PayTR, e-ticaret sitelerinde kartla ödeme alınmasını sağlayan ödeme hizmeti sağlayıcılarıdır. İkisi de farklı entegrasyon seçenekleri, 3D Secure akışları ve ödeme sonucu bildirimleri sunar. “Hangisi daha iyi?” sorusunun tek bir cevabı yoktur; doğru seçim işletmenin teknik ekibine, satış modeline, sepet yapısına, taksit ihtiyacına, iade operasyonuna ve alınan güncel ticari teklife bağlıdır.

Hazır ödeme ekranıyla hızlı canlıya çıkmak isteyen bir mağazanın önceliği ile doğrudan API, kayıtlı kart, abonelik veya özel ödeme deneyimi isteyen bir projenin önceliği aynı değildir. Bu nedenle karşılaştırma önce teknik kapsam, ardından ticari koşullar üzerinden yapılmalıdır.

İyzico ve PayTR temel karşılaştırma tablosu

Entegrasyon modellerini karşılaştırın

İlk karar, kart alanlarının kimin ekranında çalışacağıdır. Hazır form yaklaşımında ödeme hizmeti sağlayıcısı formu üretir; site token veya oturum alarak formu açar. Doğrudan API yaklaşımında ise kart formu, doğrulama alanları ve hata mesajları daha fazla ölçüde uygulama tarafından yönetilir.

Hazır form ne zaman avantajlıdır?

• Hızlı canlıya çıkılması gerekiyorsa
• Ödeme ekranında standart ve test edilmiş akış isteniyorsa
• Kart verisiyle doğrudan temas azaltılmak isteniyorsa
• BIN, taksit ve 3D yönlendirmesinin sağlayıcı tarafından yönetilmesi tercih ediliyorsa

İyzico’nun resmî Checkout Form başlatma dokümanı, bir ödeme oturumu oluşturulup form içeriği veya ödeme sayfası bağlantısı alınmasını açıklar. PayTR’nin iFrame API dokümanı da ödeme formunun site içinde açıldığı entegrasyon modelini anlatır.

Doğrudan API ne zaman gerekir?

Özel B2B ödeme ekranı, gelişmiş taksit kuralı, kayıtlı kart, farklı sipariş tipleri veya tamamen markaya özel kullanıcı deneyimi gerekiyorsa doğrudan API değerlendirilebilir. Ancak bu modelde doğrulama, hata yönetimi, güvenlik ve test sorumluluğu artar.

Ödeme ekranı ve kullanıcı deneyimi

Ödeme sağlayıcısı seçilirken yalnızca teknik bağlantının çalışması değil, mobil formun hızı ve hata mesajlarının açıklığı da ölçülmelidir. Kart numarası biçimlendirme, son kullanma tarihi, CVV, taksit alanı, 3D ekranına geçiş ve geri dönüş birlikte test edilmelidir.

Başarılı ve başarısız sayfalar müşteriye bilgi vermek içindir; finansal doğrulamanın kaynağı değildir. Müşteri tarayıcısı dönüş sayfasına ulaşmasa bile sunucu bildirimi ve işlem sorgusu üzerinden ödeme durumu tamamlanabilmelidir.

3D Secure ve sunucu bildirimi

3D Secure aşamasında kart sahibi bankasının doğrulama ekranına gider. Doğrulamanın ardından ödeme işleminin sonucu sunucu tarafında kontrol edilmelidir. İyzico’nun 3DS uygulama dokümanı başlatma, doğrulama ve webhook bileşenlerini; PayTR’nin iFrame API bildirim adımı ise ödeme sonucunun bildirim URL’sine gönderilmesini açıklar.

1. Sunucu sipariş tutarını veritabanından alır.
2. Ödeme denemesi için tekil bir kayıt ve referans oluşturur.
3. Sağlayıcıdan form/token veya 3D başlangıç cevabı alır.
4. Müşteri doğrulama ve ödeme adımını tamamlar.
5. Sunucu imzalı bildirimi doğrular.
6. Tutar, para birimi ve sipariş referansı karşılaştırılır.
7. Aynı bildirim yeniden gelirse ikinci kez sipariş işlemi yapılmaz.
8. Belirsiz durumda sağlayıcının işlem sorgusu kullanılır.

Taksit ve kart ailesi yönetimi

Taksit seçenekleri sabit HTML metni olarak tutulmamalıdır. Kart ailesi, işletme yetkisi, ürün grubu, tutar ve güncel oranlar değişebilir. PayTR doğrudan API dokümanında BIN sorgusu ve taksit oranı sorgulama servisi bulunur. İyzico 3DS ödeme dokümanlarında da hesap ve kart programı uygunluğuna göre taksit alanları yer alır.

• Taksit seçeneklerini ödeme başlatılmadan önce sunucudan üretin.
• Vade farkı müşteriye yansıyorsa toplamı açıkça gösterin.
• Bankaya gönderilen tutarla sipariş toplamını yeniden karşılaştırın.
• Debit, kredi, yabancı ve ticari kart senaryolarını test edin.
• Taksit kapalı kartlarda tek çekime güvenli dönüş sağlayın.

İptal ve iade süreçleri

Ödeme entegrasyonu yalnızca tahsilatla tamamlanmaz. İptal, tam iade, kısmi iade ve işlem sorgusu yönetim panelinden izlenebilmelidir. İyzico’nun iptal ve iade servisleri ile PayTR’nin İade API dokümanı ilgili işlem referansları ve tutarlarla geri ödeme akışını açıklar.

Kart saklama ve abonelik ihtiyacı

Tekrarlayan ödeme veya kayıtlı kart gerekiyorsa sağlayıcının güncel tokenizasyon ve kart saklama ürünleri ayrıca değerlendirilmelidir. “Ödeme alabiliyoruz” demek, otomatik abonelik tahsilatı veya kartın sonraki alışverişte kullanılacağı anlamına gelmez. Müşteri onayı, kart token’ı yaşam döngüsü, başarısız yenileme ve iptal senaryoları ayrı tasarlanmalıdır.

İyzico’nun tokenizasyon ve abonelik dokümanları ile PayTR’nin Direkt API kart saklama servisleri hesap uygunluğuna göre incelenmelidir. Bu özelliklerin açılması başvuru, sözleşme ve teknik onay gerektirebilir.

Komisyon, valör ve sözleşme koşulları

Komisyon oranı tek başına toplam maliyeti göstermez. Ödeme sağlayıcısından teklif alırken aşağıdaki alanları aynı sepet profiliyle karşılaştırın:

• Tek çekim ve taksitli işlem oranları
• Valör veya ödeme aktarım süresi
• Yabancı kart ve para birimi koşulları
• İptal, iade ve ters ibraz operasyonu
• Aylık sabit ücret veya ek hizmet bedelleri
• Risk incelemesi ve bloke/rezerv uygulamaları
• Teknik destek ve canlıya geçiş süresi

Oranların işletmenin ciro, sektör, ortalama sepet ve risk profiline göre değişebilmesi nedeniyle blogdaki herhangi bir sabit oran kısa sürede eskiyebilir. Karar güncel sözleşme ve teklif üzerinden verilmelidir.

Güvenlik ve PCI kapsamı

Kart numarası ve CVV’nin uygulama sunucusundan geçip geçmemesi güvenlik kapsamını etkiler. Hazır form veya sağlayıcı tarafından barındırılan ödeme ekranı kullanılsa bile API anahtarları, callback doğrulaması, log temizliği ve yönetim paneli yetkileri korunmalıdır.

• Canlı ve test anahtarlarını ayrı tutun.
• API gizli anahtarlarını tarayıcı koduna yazmayın.
• Kart numarası ve CVV’yi uygulama loglarına kaydetmeyin.
• Bildirim imzasını ve kaynak verisini doğrulayın.
• Ödeme ve iade işlemlerinde kullanıcı bazlı denetim kaydı tutun.
• Ödeme sayfasındaki üçüncü taraf scriptleri sınırlayın.

Hangi senaryoda hangi yaklaşım daha uygundur?

Sağlayıcı geçişi ve çoklu ödeme mimarisi

Ödeme kodu doğrudan tek sağlayıcının alan adlarına ve cevaplarına bağlanırsa ileride geçiş zorlaşır. Uygulamada ortak bir ödeme katmanı oluşturmak; başlatma, doğrulama, sorgu, iptal ve iade işlemlerini sağlayıcı adaptörleri üzerinden yürütmek daha sürdürülebilir olur.

Çoklu sağlayıcı kullanılıyorsa aynı sipariş için iki tahsilat oluşmasını engelleyen ödeme denemesi anahtarı şarttır. Sağlayıcı değişimi ödeme başlamadan önce yapılmalı; müşteri 3D ekranındayken başka altyapıya yönlendirilmemelidir.

Ne zaman teknik destek gerekir?

Para çekildiği hâlde siparişin başarısız kalması, aynı siparişten iki tahsilat oluşması, callback imzasının doğrulanmaması, taksit toplamlarının farklı görünmesi veya iadelerin mükerrerleşmesi durumunda ödeme, sipariş ve sağlayıcı logları birlikte incelenmelidir. Sağlayıcı değiştirilecekse eski ve yeni sistemin eş zamanlı çalışma planı canlıya çıkmadan hazırlanmalıdır.

Sık sorulan sorular

İyzico mu PayTR mı daha ucuz?

Bu soru sabit bir oranla cevaplanamaz. Komisyon, valör, taksit ve diğer koşullar işletmeye verilen güncel teklife göre karşılaştırılmalıdır.

İki ödeme altyapısı aynı anda kullanılabilir mi?

Evet, ancak ortak ödeme kayıt modeli, tekilleştirme, yönlendirme kuralı ve ayrı mutabakat gerekir.

Hazır ödeme formu kullanınca callback kontrolü gereksiz mi?

Hayır. Siparişin ödenmiş sayılması için sunucu tarafı bildirimin doğrulanması ve gerektiğinde işlem sorgusu yapılması gerekir.