E-pin sitesine giren müşterilerin büyük bölümü artık telefonundan alışveriş yapıyor; kart bilgisini ezbere yazmak yerine cüzdan uygulamasına, operatör faturasına ya da QR koduna dokunmayı tercih ediyor. Sorun şu ki çoğu e-pin scripti hâlâ masaüstü mantığıyla, tek bir kredi kartı formu etrafında kurulu. Bu yazıda mobil ödeme yöntemlerinin bir e-pin yazılımına teknik olarak nasıl bağlandığını, hangi riskleri beraberinde getirdiğini ve Pinova'nın bu yükü nasıl hafiflettiğini adım adım anlatıyoruz.
Mobil ödeme olmadan bir e-pin sitesi neden eksik kalır?
Dijital ürün alıcısının profili diğer e-ticaret kategorilerinden farklı. Oyun kodu, UC, Steam bakiyesi ya da sosyal medya paketi arayan kullanıcı genellikle genç, dürtüsel karar veriyor ve masasında değil, elinde telefonla alışveriş yapıyor. Bu kitlenin önemli bir kısmının kredi kartı yok; buna karşılık neredeyse hepsinin bir cep telefonu hattı, bir dijital cüzdan ya da mobil bankacılık uygulaması var.
Sadece klasik kart ödemesi sunan bir site bu grubu doğrudan kaybediyor. Sepete kadar gelen ama ödeme adımında "kartım yok" diyerek çıkan kullanıcı, aslında dönüşüm oranını en çok düşüren nedenlerden biri. Mobil ödeme entegrasyonu bu noktada bir "ekstra özellik" değil, hedef kitlenin ödeme alışkanlığına site tarafının uyum sağlaması anlamına geliyor.
- Kredi kartı olmayan ama operatör faturası olan kullanıcıya erişim
- Cüzdan bakiyesiyle anında ödeme yapan kullanıcının işlemi tamamlaması
- Kart bilgisi girmek istemeyen, güven endişesi taşıyan müşterinin ikna olması
- Sepet terk oranının ödeme adımında değil, ürün seçiminde ölçülebilmesi
Türkiye'de e-pin alışverişinde hangi mobil ödeme yöntemleri öne çıkıyor?
Mobil ödeme tek bir yöntem değil, birbirinden oldukça farklı çalışan birkaç sistemin toplamı. E-pin sitesi kurarken bunları tek tek değerlendirmek gerekiyor çünkü her biri farklı bir entegrasyon mantığı, farklı bir onay süresi ve farklı bir komisyon yapısı getiriyor.
- Mobil cüzdanlar (Paycell, Papara vb.): Kullanıcının önceden yüklediği bakiyeden anlık düşüm yapan, genellikle API tabanlı ve onay süresi saniyeler süren yöntemler.
- Operatör faturasına yansıtma: Ödemenin telefon faturasına ya da kontör bakiyesine eklendiği, özellikle kartsız genç kullanıcıda tercih edilen yöntem; onay süresi diğerlerine göre daha uzun olabiliyor.
- QR kod ile mobil bankacılık: Kullanıcının kendi banka uygulamasını açıp QR okutarak ödediği, kart bilgisi paylaşmadan işlem tamamlanan yöntem.
- Mobil tarayıcı üzerinden 3D Secure kart ödemesi: Klasik kart akışının mobil ekrana uyarlanmış, tek elle tamamlanabilir hâli.
Bu yöntemlerin hepsini aynı anda sunmak zorunlu değil; ama en az ikisinin — biri cüzdan, biri kart tabanlı — bir arada bulunması dönüşüm oranını gözle görülür şekilde etkiliyor.
Entegrasyon perde arkasında teknik olarak nasıl işliyor?
Mobil ödeme yöntemi ne olursa olsun, bir e-pin yazılımına bağlanma mantığı özünde aynı iskelet üzerinden ilerliyor. Fark, bu iskeletin her sağlayıcı için ayrı ayrı, ayrı hata kodlarıyla, ayrı imzalama yöntemleriyle yeniden kurulması gerekmesi.
- Ödeme başlatma isteği: Sipariş tutarı, sipariş numarası ve kullanıcı bilgisi sağlayıcının API'sine gönderilir, dönen yönlendirme adresine kullanıcı taşınır.
- Callback / webhook dinleme: Sağlayıcı ödemeyi onayladığında ya da reddettiğinde sitenize bir bildirim (callback) gönderir; bu bildirimin imzasının doğrulanması gerekir.
- Sipariş durumu senkronizasyonu: Callback doğrulandıktan sonra sipariş "ödendi" durumuna alınır ve tedarikçi API'sinden (Turkpin, Pinabi gibi) kod çekme tetiklenir.
- Zaman aşımı ve tekrar deneme mantığı: Kullanıcı ödeme ekranında oyalanır ya da bağlantı koparsa sipariş "askıda" kalmamalı, belirli bir süre sonra otomatik iptal ya da tekrar sorgulama devreye girmeli.
Bu dört adım kulağa basit gelse de her sağlayıcının kendi terminolojisi, kendi hata kodu tablosu ve kendi test ortamı var. Üç farklı mobil ödeme yöntemi eklemek, üç ayrı entegrasyon projesi anlamına geliyor — ve her biri canlıya alındıktan sonra da bakım istiyor.
Mobil ödemede en çok göz ardı edilen güvenlik riski hangisi?
Masaüstü kart ödemesinde en büyük tehdit genelde çalıntı kart kullanımıyken, mobil ödemede risk profili biraz kayar. Operatör faturasına yansıtmada SIM değişimi (SIM swap) ve hat devri sonrası eski numara üzerinden yapılan denemeler, cüzdan ödemelerinde ise hesap ele geçirme sonrası hızlı ve art arda sipariş girme davranışı öne çıkıyor.
E-pin ürünleri saniyeler içinde teslim edildiği ve iadesi neredeyse imkânsız olduğu için, bu riskler diğer e-ticaret kategorilerine göre çok daha maliyetli sonuçlar doğurabiliyor. Ödemesi onaylanan ama sahte olduğu sonradan anlaşılan bir siparişte kod zaten kullanıcının elindedir.
- Callback imzasının her seferinde doğrulanması, sahte "ödeme onaylandı" bildirimlerine karşı zorunlu
- Aynı cihaz/IP'den kısa sürede tekrarlayan siparişlerde otomatik gecikme ya da manuel onay
- Yüksek tutarlı ilk siparişlerde teslimatın birkaç dakika ertelenmesi
- Mobil ödeme sağlayıcısının kendi risk skorunun sipariş kararına dahil edilmesi
Mobil checkout'ta müşteri neden vazgeçiyor?
Ödeme yöntemi ne kadar iyi entegre edilirse edilsin, ekranın kendisi mobil kullanıcıya göre tasarlanmadıysa dönüşüm yine düşüyor. Küçük ekranda uzun formlar, zoom yapmayı gerektiren butonlar ve yavaş yönlendirme sayfaları, teknik olarak çalışan bir entegrasyonu bile pratikte işe yaramaz hâle getirebiliyor.
- Ödeme yöntemi seçim ekranının tek parmakla, kaydırmadan görülebilmesi
- Sağlayıcı uygulamasına yönlendirme sonrası siteye otomatik dönüş (uygulama açık kalıp kullanıcının kaybolmaması)
- Sipariş durumunun "bekleniyor" ekranında canlı güncellenmesi, sayfa yenilemeye gerek kalmaması
- Hatalı işlemde net, Türkçe ve yönlendirici bir hata mesajı
Bu detaylar küçük görünse de, mobil trafiğin çoğunlukta olduğu bir e-pin sitesinde toplam dönüşüm oranını doğrudan belirliyor.
Bu entegrasyonu tek tek kurmak mı, hazır altyapı mı daha mantıklı?
Sıfırdan bir e-pin scripti geliştirenler için her mobil ödeme yöntemi ayrı bir yazılım işi demek: API dokümantasyonunu okumak, test ortamı kurmak, callback güvenliğini yazmak, hata senaryolarını denemek ve sağlayıcı API'si değiştiğinde bunu takip etmek. Küçük bir ekip için bu, aylarca sürebilecek bir iş yükü.
| Konu | Manuel / Elle | Pinova ile |
|---|---|---|
| Yeni mobil ödeme yöntemi ekleme | Haftalar süren ayrı geliştirme | Panelden yöntem seçip aktif etme |
| Callback güvenlik doğrulaması | Her sağlayıcı için elle yazılır | Altyapıda hazır, standart imza kontrolü |
| Sipariş durumu senkronizasyonu | Manuel takip, sık hata riski | Otomatik, tedarikçi teslimatına bağlı |
| Şüpheli işlem / SIM swap davranışı | Ayrıca kurulması gereken risk katmanı | Sipariş kural motoruna entegre |
| Sağlayıcı API güncellemesi takibi | Ekibin sürekli izlemesi gerekir | Yazılım tarafında sürekli güncellenir |
Pinova, PayTR ve Shopier gibi ödeme sağlayıcılarını ve site cüzdanı/bakiye sistemini kendi altyapısına gömülü şekilde sunduğu için, mobil ödeme yöntemlerinin çoğu ayrı bir yazılım projesi olmaktan çıkıp kurulum adımına indirgeniyor. Kendi sunucunuza kurulan bir yazılım olduğu için veri ve müşteri tamamen sizde kalıyor, ödeme akışı üzerinde de tam kontrol sizde oluyor.
Yeni bir mobil ödeme yöntemi eklemeden önce mevcut sipariş verinizi inceleyin: hangi tutar aralığında hangi cihazdan gelen siparişlerin iptal/iade oranı yüksek? Yeni yöntemi önce o segmente değil, güvenilir davranış gösteren kullanıcı grubuna açarak başlamak riskleri azaltır.
Mobil ödeme altyapınızı bugün mü kurmak istersiniz?
Pinova ile Paycell, Papara, PayTR ve havale/EFT gibi yöntemleri tek panelden yönetir, mobil kullanıcının ödeme adımında sizi terk etmesini önlersiniz.
Mobil ödeme yöntemlerinin hepsini aynı anda eklemek gerekir mi?
Hayır. Hedef kitlenizin alışkanlığına göre bir cüzdan/faturaya yansıtma yöntemi ve bir kart tabanlı yöntemi birlikte sunmak genellikle yeterli; fazla seçenek bazen kararsızlığa yol açabiliyor.
Operatör faturasına yansıtma yönteminde teslimat gecikir mi?
Bu yöntemde onay süresi kart ödemesine göre biraz daha uzun olabilir; bu yüzden teslimatın onay bildirimi geldikten sonra tetiklenmesi, "ödeme bekleniyor" durumundaki siparişlerin otomatik kod almaması önemlidir.
Mevcut e-pin sitem sadece kart ödemesi alıyor, mobil yöntem eklemek mevcut sistemi bozar mı?
Doğru kurulduğunda hayır; yeni ödeme yöntemi mevcut sipariş ve teslimat akışına paralel bir seçenek olarak eklenir, kart ödemesi çalışmaya devam eder.
Pinova hangi mobil ödeme sağlayıcılarını destekliyor?
Pinova; PayTR, Shopier ve havale/EFT gibi yöntemlerin yanında site cüzdanı/bakiye sistemini de barındırıyor, böylece mobil kullanıcı bakiyesini yükleyip anında harcayabiliyor.