Çoğu satıcı ödeme altyapısını bir kere kurulup unutulan bir musluk sanır. Bir sanal POS alırsın, entegrasyonu e-pin scriptine bağlarsın, para akmaya başlar. Sonra bir cuma akşamı, yani ciro grafiğinin en tepesinde olduğu saatlerde, sağlayıcının 3D Secure servisi on dakika yanıt vermez. O on dakikada kaç kişi sepetini terk ettiğini hiç göremezsin, çünkü terk edilen ödeme hiçbir yere kaydolmaz. Panelinde sadece daha az sipariş görürsün ve bunu "bugün trafik düşükmüş" diye yorumlarsın.
İşin gerçeği şu: dijital ürün satışında ödeme katmanı tek noktalı bir sistem olmaya en elverişsiz katmandır. Ürün anında teslim edilir, müşteri anında ödeme bekler, bekleme toleransı saniyelerle ölçülür. Bu yüzden ciddi ölçekte çalışan hiçbir işletme tek sağlayıcıya bağlı kalmaz. Ama çoklu sağlayıcı kurmak, panele üç tane API anahtarı girmek demek de değil. Yönlendirme kuralı, devretme mantığı, mutabakat disiplini ve komisyon muhasebesi olmadan üç sağlayıcı, tek sağlayıcıdan daha büyük bir kaos üretir. Bu yazıda o sistemi kuruyoruz.
Neden tek ödeme sağlayıcısı aslında gecikmeli bir zaman bombası?
Tek sağlayıcı üç ayrı riski aynı sepete koyar. Birincisi teknik kesinti: banka tarafındaki bakım, 3D yönlendirmesinde yaşanan gecikme veya sağlayıcının kendi sunucu sorunu doğrudan senin cironu keser. İkincisi ticari risk: dijital ürün ve oyun kategorisi birçok sağlayıcı için yüksek riskli sayılır; bir sabah hesabına blokaj gelir, para hesapta ama elinde değildir. Üçüncüsü pazarlık gücü kaybı: alternatifin yoksa komisyon oranın konuşulacak bir konu değil, sana bildirilen bir konudur. Bu üçü aynı anda patlamaz ama biri mutlaka patlar. Kurgunun amacı patlamayı engellemek değil, patladığında satışın durmamasını sağlamaktır.
Sağlayıcı havuzu mantığı: yönlendirme kuralları nasıl kurulur?
Doğru kurulumda ödeme sağlayıcıları bir liste değil, bir havuzdur. Havuzda her sağlayıcının bir önceliği, bir ağırlığı ve bir uygunluk koşulu vardır. Uygunluk koşulu sepet tutarına, ürün kategorisine, müşterinin cihazına veya ödeme yöntemine göre yazılır. Örneğin 50 TL altındaki küçük e-pin siparişlerinde 3D akışı bırakıp cüzdan bakiyesini öne çıkarmak dönüşümü belirgin şekilde artırır. 2.000 TL üzeri kurumsal alımlarda ise havale/EFT otomasyonunu birinci sıraya almak komisyon maliyetini neredeyse sıfırlar. Dijital ürün satış scripti tarafında bu kuralların panelden yönetilebiliyor olması kritik; her değişiklik için kod açman gerekiyorsa o sistem pratikte esnek değildir.
Ağırlık kavramı da gözden kaçar. İki sağlayıcıyı %50-%50 ağırlıkla çalıştırdığında her ikisinde de düzenli işlem hacmi birikir. Bu, blokaj anında "ikinci sağlayıcım var ama altı aydır işlem geçmemiş, limitim yok" durumuna düşmeni engeller. Yedek sağlayıcı, canlı tutulan sağlayıcıdır.
| Tahsilat kanalı | Tipik maliyet bandı | Onay hızı | Risk profili | En uygun senaryo |
|---|---|---|---|---|
| Banka sanal POS | Orta-yüksek | Anında | Blokaj riski düşük | Kart ağırlıklı ana akış |
| Ödeme kuruluşu / aracı | Yüksek | Anında | Kategori kısıtı olabilir | Hızlı başlangıç, yedek hat |
| Havale-EFT otomasyonu | Çok düşük | Dakikalar | Manuel hata riski | Yüksek tutarlı kurumsal alım |
| Site içi cüzdan bakiyesi | Sıfır (yükleme anında ödenmiş) | Anında | Muhasebe disiplini gerekir | Tekrarlayan küçük sepetler |
| Mobil/alternatif yöntem | Değişken | Anında | Limit kısıtı | Kartsız genç kitle |
Başarısız ödemede otomatik devretme gerçekten işe yarıyor mu?
Yarıyor, ama koşullu. Devretme mantığının çalışması için scriptin ret kodlarını ayırt edebilmesi şart. "Bakiye yetersiz" cevabında ikinci sağlayıcıya geçmek anlamsızdır; aynı kart, aynı sonuç. Buna karşılık "servise ulaşılamadı", "zaman aşımı", "geçici hata" veya sağlayıcı kaynaklı 5xx yanıtlarında ikinci hatta geçmek doğrudan kurtarılmış satış demektir. Bu yüzden iyi bir e-pin satış scripti her sağlayıcı için ret kodlarını normalize eder: onlarca farklı hata metnini kendi içinde "kalıcı ret" ve "geçici ret" olarak iki kovaya ayırır. Devretme yalnızca ikinci kovada tetiklenir.
İkinci şart idempotency, yani mükerrer tahsilat koruması. Devretme sırasında müşteriden iki kez para çekilmesi, kazandığın işlemden çok daha pahalıya gelir. Her sipariş için tek bir işlem anahtarı üretilmeli, aynı anahtarla gelen ikinci deneme sağlayıcı bazında izlenmeli ve başarılı ilk cevap kilidi kapatmalı.
Başarısız ödemelerin kaynak dağılımı
- Kart/banka kaynaklı kalıcı ret 45%
- Sağlayıcı kesintisi ve zaman aşımı 25%
- 3D doğrulama yarıda bırakma 20%
- Limit, kategori ve kural engeli 10%
Mutabakat kâbusu: üç sağlayıcı, üç ayrı tablo, tek kasa
Çoklu sağlayıcının gerçek bedeli teknik değil muhasebedir. Her sağlayıcı kendi komisyonunu farklı kesiyor, farklı vadede ödüyor, iade ve itirazları farklı raporluyor. Bunu tek kasada birleştirmezsen ay sonunda kârını hesaplayamazsın. Çözüm, scriptte her işlem satırına sağlayıcı kimliği, brüt tutar, kesilen komisyon, net tutar ve beklenen ödeme tarihini yazmaktır. Böylece "hangi sağlayıcı bana ne kadara mal oluyor" sorusunun cevabı bir rapor tuşu uzağında olur. Deneyimli satıcıların yaptığı ek hamle ise beklenen ve gerçekleşen ödemeyi karşılaştıran bir fark raporudur; sağlayıcı eksik yatırdığında bunu tahminle değil kayıtla konuşursun.
Komisyon, blokaj ve limit: sağlayıcı seçimini kim yapmalı?
Cevap: müşteri değil, kural motoru. Müşteriye on ödeme kutusu göstermek dönüşümü düşürür, çünkü seçim yükü karar felcine dönüşür. Doğru yaklaşım, müşteriye en fazla üç net yöntem sunmak ve o yöntemin arkasındaki sağlayıcıyı kural motoruna seçtirmektir. Kart yazan tek bir buton, arkada sepet tutarına ve o anki sağlayıcı sağlığına göre farklı hatlara gidebilir. Müşteri bunu bilmek zorunda değil; senin bilmen ve raporlaman yeterli. Epin yazılım tarafında bu ayrım "ödeme yöntemi" ile "ödeme sağlayıcısı" kavramlarının veritabanında ayrı tutulmasıyla başlar. Aynı yöntem, birden çok sağlayıcıya bağlanabiliyorsa sistemin esnektir.
Her sağlayıcı için son 15 dakikanın başarı oranını tut. Oran belirlediğin eşiğin altına düşerse o hattı otomatik olarak havuzdan çıkar, eşiğin üstüne çıkınca geri al. Böylece müşteri çöken hatta hiç dokunmaz; devretme daha denemeden önce yapılmış olur.
Pinova'da çoklu sağlayıcı nasıl kurgulanıyor?
Pinova bir e-pin satıcısı değil, e-pin ve dijital ürün satan işletmelerin kullandığı lisanslı satış yönetim yazılımıdır. Bu yüzden ödeme katmanı tek bir entegrasyona göre değil, havuz mantığına göre tasarlanmıştır: sağlayıcılar panelden eklenir, her birine öncelik ve uygunluk koşulu tanımlanır, ret kodları tek çatı altında normalize edilir ve her işlem satırı brüt-komisyon-net üçlüsüyle birlikte kaydedilir. Kurulumun ayrıntılarını özellikler bölümünde, lisans seçeneklerini ise fiyat tablosunda görebilirsin. Amaç sana onlarca entegrasyon saymak değil; ödeme tarafında kesinti yaşadığın gün satışın durmadığını görmenizi sağlamak.
| Kontrol maddesi | Neden gerekli? | Kimde eksik? |
|---|---|---|
| En az iki aktif kart hattı | Kesinti ve blokajda satışın durmaması | Yeni başlayan satıcıların çoğu |
| Ret kodu normalizasyonu | Gereksiz devretmeyi ve çift çekimi önlemek | Hazır şablon kurulumlar |
| İşlem anahtarı ile mükerrer koruma | Aynı siparişte iki tahsilat riskini kapatmak | Elle yazılmış entegrasyonlar |
| Sağlayıcı bazlı komisyon kaydı | Gerçek net kârı görebilmek | Neredeyse herkes |
| 15 dakikalık sağlık metriği | Çöken hattı müşteri görmeden çıkarmak | Orta ölçekli satıcılar |
| Beklenen-gerçekleşen fark raporu | Eksik yatan hakedişi tespit etmek | Muhasebeyi dışarı verenler |
Ödeme tarafını şansa bırakmayı bırak
Havuz mantığı, otomatik devretme ve sağlayıcı bazlı kâr raporu hazır kurulu geliyor. Kendi lisanslı kurulumunu inceleyerek başla.
Kaç ödeme sağlayıcısıyla çalışmak ideal?
Başlangıç için iki kart hattı artı havale otomasyonu yeterlidir. Üçten fazla kart hattı mutabakat yükünü artırır ve her birinde hacmi canlı tutmak zorlaşır. Kural, sayıyı büyütmek değil her hattı aktif ve raporlanabilir tutmaktır.
Otomatik devretme müşteriden iki kez para çeker mi?
Doğru kurulumda çekmez. Her siparişe tek bir işlem anahtarı atanır, sağlayıcı bazında deneme kaydı tutulur ve ilk başarılı yanıt kilidi kapatır. Devretme yalnızca geçici hata sınıfındaki retlerde tetiklenir.
Sağlayıcı bana blokaj koyarsa satış yine durur mu?
Havuzda düzenli hacim geçen ikinci bir hat varsa durmaz; kural motoru blokajlı hattı devre dışı bırakır ve akış diğerine kayar. Risk, yedek hattın aylarca işlemsiz bırakılıp limitsiz kalmasıdır.
Bu yapıyı mevcut sistemime sonradan ekleyebilir miyim?
Ödeme yöntemi ile sağlayıcı kaydı veritabanında ayrı tutuluyorsa eklenebilir. Tek bir sağlayıcı sabit kodlanmışsa, önce bu ayrımın yapılması gerekir; aksi halde her yeni hat ayrı bir yama olarak birikir.
Ödeme altyapısı, müşterinin göremediği ama her gün hissettiği bir katman. İyi kurulduğunda kimse fark etmez; kötü kurulduğunda tek bir cuma akşamı aylık hedefini götürür. Havuz mantığını, ret kodu ayrımını ve sağlayıcı bazlı kâr raporunu gerçek bir kurulum üzerinde görmek istersen canlı demo üzerinden ödeme ayarlarını kurcalayarak başla; kendi senaryonu deneyip ne kadar esnek olduğunu birkaç dakikada anlarsın.