Çoğu işletme sahibi ödeme sağlayıcısı değiştirmeyi bir pazarlık meselesi sanır: komisyon oranını yarım puan düşürürsün, entegrasyon dokümanını geliştiriciye verirsin, iş biter. Gerçekte ödeme sağlayıcısı bir tedarikçi değil, satış akışının kalp kapakçığıdır. Para akışının yönünü değiştirdiğinde sadece komisyon değişmez; teslimat tetikleyicisi, iade mantığı, sahtecilik filtresi, taksit görünürlüğü ve muhasebe mutabakatı da değişir.
Bir e-pin satış scripti göçünde ödeme tarafı, tüm projenin en sessiz ama en pahalı kırılma noktasıdır. Çünkü ödeme hatası her zaman görünür değildir. Para düşer, müşteriye kod gitmez; ya da tersi olur: para düşmez, kod gider. İkisi de birkaç saat fark edilmez, sonra yüzlerce sipariş birikmiş olur. Bu yazıda ödeme sağlayıcısı değişimini bir e-pin satış yazılımı göçünün içine nasıl güvenli biçimde yerleştireceğini, hangi sırayla test edeceğini ve hangi tuzakların cironu buharlaştırdığını anlatıyorum.
Ödeme sağlayıcısını göçle aynı anda değiştirmek gerçekten mantıklı mı?
Cevap sandığından daha nüanslı. İki değişikliği aynı geceye koymak teorik olarak verimli görünür: tek kesinti, tek test turu, tek duyuru. Pratikte ise bir sorun çıktığında sebebin yeni panel mi yeni sağlayıcı mı olduğunu ayırt edemezsin. Teşhis süresi ikiye katlanır, üstelik geri dönüş planın da karmaşıklaşır; çünkü paneli geri alsan ödeme akışı, ödemeyi geri alsan panel uyumsuz kalır.
Pratik kural şu: eğer eski sağlayıcı çalışıyorsa, göç gecesi onu koru. Yeni dijital ürün satış yazılımı tarafında eski sağlayıcıyı aynı yapılandırmayla ayağa kaldır, iki hafta stabil çalışsın, sonra sağlayıcı değişimini ayrı bir proje olarak yap. Sağlayıcı zaten senden kopmak üzereyse ya da oranlar sürdürülemezse ikisini birleştirebilirsin; ama o zaman göç gecesini iki ayrı doğrulama fazına böl.
Webhook mutabakatı neden tüm ödeme göçünün can damarı?
E-pin işinde teslimat anlıktır ve geri alınamaz. Bu yüzden "ödeme başarılı" bilgisinin kaynağı hayati önemde. Zayıf kurulumlarda teslimat, kullanıcının tarayıcısının geri dönüş adresine ulaşmasıyla tetiklenir. Kullanıcı sayfayı kapatırsa sipariş askıda kalır; sayfayı iki kez yenilerse iki kod düşer. Doğru mimaride tek otorite sunucudan sunucuya gelen bildirimdir ve tarayıcı dönüşü sadece bir bilgilendirme ekranıdır.
Sağlayıcı değiştirirken burada üç şey mutlaka yeniden kurulur: bildirim imzasının doğrulanması, aynı bildirimin birden çok kez gelmesine karşı tekillik koruması ve bildirim gecikirse çalışacak yoklama mekanizması. Üçü olmadan geçiş yapan her işletme, ilk yoğun günde ya çift teslimat ya da kayıp sipariş yaşar. Tekillik korumasını sipariş referansı üzerine kur; sağlayıcının kendi işlem numarasına güvenme, çünkü sağlayıcı değişince o numara biçimi de değişir.
| Ödeme Bileşeni | Eski Sağlayıcıda | Yeni Sağlayıcıda Yapılması Gereken | Kırılma Belirtisi |
|---|---|---|---|
| Teslimat tetikleyici | Tarayıcı dönüşü | Sunucu bildirimi otorite yapılır | Askıda kalan sipariş yığını |
| Bildirim imzası | Eski gizli anahtar | Yeni imza algoritması doğrulanır | Sahte bildirim riski |
| Tekillik koruması | Sağlayıcı işlem no | Kendi sipariş referansına taşınır | Çift kod teslimi |
| İade akışı | Panel üstünden manuel | Kısmi iade desteği test edilir | İade edilemeyen sipariş |
| Taksit / vade görünümü | Sabit tablo | Yeni oranlar sepete yansıtılır | Yanlış fiyat gösterimi |
| Sahtecilik filtresi | Öğrenmiş geçmiş var | Sıfırdan eşik ayarı yapılır | Meşru siparişin reddi |
| Mutabakat dosyası | Günlük dökümle uyumlu | Alan eşlemesi yeniden yazılır | Muhasebe farkı |
Komisyon oranı pazarlığında hangi rakam seni yanıltıyor?
Sağlayıcılar teklifi tek bir yüzdeyle sunmayı sever, ama gerçek maliyet en az beş kalemden oluşur: işlem komisyonu, taksit maliyeti, ters ibraz bedeli, para çekme kesintisi ve bloke süresi. Bu son kalem bilançoda görünmez ama nakit akışını doğrudan vurur. E-pin işinde tedarikçiye peşin ödeme yaptığın için yedi gün bloke, yarım puan komisyondan daha pahalıya gelebilir.
Hesabı şöyle kur: aylık işlem hacmini, ortalama sepeti ve taksit dağılımını yaz; her sağlayıcı için efektif toplam maliyeti tek bir işlem başı kuruş rakamına indir. Sonra buna bloke süresinin finansman maliyetini ekle. Çoğu işletme bu hesabı yaptığında "daha ucuz" sanılan sağlayıcının aslında pahalı olduğunu görür. İyi bir epin yazılım altyapısı bu karşılaştırmayı yapabilmen için sağlayıcı bazlı işlem raporu sunar; sunmuyorsa oranları körlemesine pazarlıyorsun demektir.
Ödeme geçişinde yaşanan sorunların dağılımı
- Bildirim / webhook hataları 40%
- İade ve kısmi iade uyumsuzluğu 25%
- Sahtecilik filtresinin yanlış reddi 20%
- Taksit ve fiyat gösterim hataları 15%
Geçiş gecesinde açık kalan siparişleri nasıl kapatacaksın?
Sağlayıcı değişiminin en tatsız kısmı, iki sistem arasında kalan işlemlerdir. Kullanıcı eski sağlayıcının sayfasına gitmiş, kart bilgisini girmiş, tam o anda sen yeni sağlayıcıya geçmişsin. Para eski hattan düşer, bildirim eski uca gelir, senin yeni sistemin onu tanımaz. Bu senaryo kaçınılmazdır; hazırlıksız yakalanmak ise değil.
Çözüm üç katmanlı. Birincisi, geçişten 30 dakika önce yeni ödeme başlatmayı kapat ama mevcut oturumların tamamlanmasına izin ver. İkincisi, eski sağlayıcının bildirim ucunu en az yedi gün daha açık tut; gelen bildirimi yeni sisteme iletecek bir köprü bırak. Üçüncüsü, geçiş penceresindeki tüm işlemleri manuel gözden geçirmek için ayrı bir liste tut. Bu üç önlemle açıkta kalan sipariş sayısını tek haneye indirebilirsin.
İade ve ters ibraz süreci yeni sağlayıcıda neden bambaşka işler?
E-pin geri alınamaz bir üründür; bu yüzden iade politikası ödeme sağlayıcısının kurallarıyla uyumlu olmak zorundadır. Bazı sağlayıcılar kısmi iadeye izin verir, bazıları vermez. Bazıları iadeyi yalnızca aynı işlem üzerinden kabul eder, bazıları ayrı bir transfer olarak işler. Bu fark, muhasebe kaydını ve müşteriye söyleyeceğin cümleyi doğrudan değiştirir.
Göçte yapılması gereken, iade politikanı yeni sağlayıcının yeteneklerine göre yeniden yazmak ve panelde görünür kılmaktır. Teslim edilmiş kod için iade yoksa bunu sipariş ekranında, sözleşmede ve fatura notunda aynı ifadeyle belirt. Ters ibraz geldiğinde savunma dosyası oluşturabilmek için teslimat kanıtını (kodun görüntülenme zamanı, IP, oturum) sistemin otomatik saklaması gerekir. Bu kayıt yoksa itirazların neredeyse tamamını kaybedersin.
Sipariş referansını her zaman sen üret ve her sağlayıcıya aynı referansı gönder. Sağlayıcı değişse de bu alan sabit kaldığı için mutabakat, iade eşleştirmesi ve tekillik koruması hiç bozulmaz.
Çok sağlayıcılı yapıya geçmek küçük işletme için abartı mı?
Hayır, tam tersine sigortadır. Tek sağlayıcıyla çalışan bir dijital ürün satıcısı, sağlayıcı kaynaklı bir kesintide tamamen durur. İki sağlayıcıyı paralel tutmak ise hem kesintide otomatik yönlendirme sağlar hem de pazarlıkta elini güçlendirir. Maliyeti de sandığın kadar yüksek değildir; ikinci sağlayıcıyı düşük hacimle canlı tutmak yeterlidir.
Burada dikkat edilecek nokta kullanıcı deneyimidir. Müşteriye iki ödeme butonu koyup seçim yükünü ona bırakmak dönüşümü düşürür. Doğru yaklaşım, arka planda otomatik yönlendirme ve yalnızca ilk seçenek hata verdiğinde alternatifin devreye girmesidir. Pinova gibi modern bir dijital ürün satış scripti birden fazla geçidi aynı sepet akışında yönetebilir; böylece hem yedekliliği hem de tek tıkla ödeme sadeliğini korursun.
| Kontrol Maddesi | Test Yöntemi | Beklenen Sonuç | Zorunluluk |
|---|---|---|---|
| Başarılı ödeme sonrası teslimat | Gerçek düşük tutarlı işlem | Kod anında görünür | Zorunlu |
| Tarayıcı kapatılınca teslimat | Dönüş sayfasına gitmeden bekle | Sipariş yine tamamlanır | Zorunlu |
| Aynı bildirimin iki kez gelmesi | Bildirim tekrar gönderimi | Tek kod, tek kayıt | Zorunlu |
| Başarısız ödeme | Yetersiz bakiye senaryosu | Stok geri bırakılır | Zorunlu |
| Tam ve kısmi iade | Panelden iade denemesi | Muhasebe kaydı oluşur | Zorunlu |
| Taksitli işlem tutarı | Farklı vade seçimi | Sepet ve döküm birebir | Zorunlu |
| Günlük mutabakat dosyası | Sağlayıcı dökümüyle karşılaştır | Fark sıfır | Zorunlu |
| Yedek sağlayıcıya devir | Birincil geçidi kapat | Ödeme kesintisiz sürer | Önerilir |
Ödeme akışını tek bir noktadan yönetmeye başla
Pinova; çok sağlayıcılı ödeme yönetimi, sunucu taraflı teslimat otoritesi, tekillik koruması ve günlük mutabakat raporlarıyla geçişi öngörülebilir kılar. Özellikleri gör,
Ödeme sağlayıcısı değişiminde site kaç saat kapalı kalır?
Kapalı kalmak zorunda değilsin. Yeni geçit devreye alınırken eski geçidin bildirim ucu açık bırakılır ve yeni ödeme başlatma kısa bir pencerede durdurulur. Bu pencere genelde 20-30 dakikadır; sipariş alımı tamamen durmaz.
Çift teslimat yaşadım, nasıl önlerim?
Teslimatı tarayıcı dönüşüne değil sunucu bildirimine bağla ve sipariş referansı üzerinde veritabanı seviyesinde tekillik kısıtı kur. Aynı referans için ikinci bildirim geldiğinde sistem yeni kod düşmek yerine mevcut kaydı döndürmelidir.
Yeni sağlayıcıda sahtecilik filtresi meşru siparişleri reddediyor, ne yapmalıyım?
Filtre geçmiş veriyle öğrenir; sıfır geçmişle geldiği için ilk hafta eşikleri gevşek tutup manuel inceleme listesi kullanmak gerekir. Reddedilen her meşru siparişi sağlayıcıya bildirerek profili hızlandırabilirsin.
Mutabakat farkı çıktığında önce nereye bakmalıyım?
İlk olarak iade ve iptal edilmiş işlemlere, ardından taksit komisyonunun hangi tarafa yazıldığına bak. Farkların büyük kısmı bu iki kalemden çıkar. Kalan farklar için kendi sipariş referansınla sağlayıcı dökümünü satır satır eşleştir.
Ödeme sağlayıcısı değiştirmek, doğru yapıldığında maliyetini birkaç ayda geri ödeyen bir hamledir; yanlış yapıldığında ise tek bir hafta içinde yılın kârını silebilir. Aradaki farkı yaratan şey oran pazarlığı değil, teslimat otoritesinin nerede durduğu ve mutabakatın hangi alana bağlandığıdır. Bu iki kararı doğru verirsen gerisi rutin işe dönüşür. Çok sağlayıcılı ödeme akışının, tekillik korumasının ve mutabakat raporlarının gerçek bir panelde nasıl göründüğünü incelemek için canlı demo üzerinden test bir sipariş oluşturup tüm zinciri kendin izleyebilirsin.