Sanal POS ve ödeme yöntemi seçimi: tahsilat altyapısı kurmak
Sanal POS mu ödeme kuruluşu mu, hangi ödeme yöntemleri açılmalı? Provizyondan mutabakata kadar tahsilat altyapısının nasıl kurulduğunu mekanizmasıyla anlatıyoruz.
Perşembe akşamı saat dokuzu geçiyor. Bir yapı malzemeleri satıcısının sitesinde on dört kalemlik bir sepet toplanmış; müşteri kartını giriyor, bankanın doğrulama ekranı açılıyor, telefonun tarayıcısı sekmeyi kaybediyor. İkinci deneme, üçüncü deneme. Dördüncüde müşteri vazgeçip satış hattına yazıyor: havale yapsam olur mu? Ertesi sabah para hesaba düşüyor, ama açıklama alanında yalnızca bir isim var, sipariş numarası yok. Ön muhasebe o ödemeyi dört gün sonra, ekstre satırlarını tek tek okuyarak buluyor. Sipariş de dört gün geç çıkıyor. Panelde ise her şey normal görünür: o sepet terk edilmiş sayılır, üç başarısız kart denemesi hiçbir rapora girmez.
Tahsilat altyapısındaki kayıpların çoğu böyle davranır; şikâyet olarak değil, sessizlik olarak görünür. Bu yazıda sanal POS'un teknik olarak neyi yapıp neyi yapmadığını, banka sanal POS'u ile ödeme kuruluşu arasındaki farkı, hangi ödeme yönteminin hangi kaybı kapattığını, taksitin nasıl bir karar olduğunu, ödeme sayfasının nerede durması gerektiğini, maliyetin hangi kalemlerden oluştuğunu, paranın ne zaman hesabınıza geçtiğini, mutabakatın neden tutmadığını, iade ile ters ibraz arasındaki farkı, saklamamanız gereken verileri ve izlemeniz gereken sayıları sırayla ele alıyoruz.
Sanal POS aslında hangi işi yapar?
Sanal POS'u bir para alma aracı sanmak, sonraki bütün yanlış anlamaların kaynağıdır. Yaptığı iş yetkilendirmedir: kart bilgisini bankaya taşır, bankadan bu tutarın kartta bulunduğu ve bloke edildiği cevabını alır, o cevabı sipariş kaydınıza yapıştırır. Bu aşamanın adı provizyondur ve provizyon para değildir; müşterinin limitinde ayrılmış bir yerdir. Paranın gerçekten el değiştirmesi, çekim adımında olur ve bu adım çoğu kurulumda ayrı bir komuttur.
Ayrım pratik bir sonuç doğurur. Provizyonun bir ömrü vardır, sınırsız değildir. Siparişi provizyona bakarak sevk edip çekimi günler sonra yapan ekipler, süre dolduğunda ürünü göndermiş ama tahsilat yapamamış olur. Müşteri iyi niyetli olsa bile kartın yeniden çekilmesi gerekir ve o telefon görüşmesi kimsenin yapmak istemediği görüşmedir. Stoktan düşme ile çekim arasındaki sırayı kim belirliyorsa, tahsilat riskini de fiilen o belirlemiş olur.
Banka sanal POS'u mu, ödeme kuruluşu mu, platform altyapısı mı?
Üç model var ve aralarındaki asıl fark teknik değil, sorumlulukla ilgili. Doğrudan banka sanal POS'unda her bankayla ayrı sözleşme yapar, ayrı ekran yönetir ve taksit kampanyalarını tek tek takip edersiniz; buna karşılık zincir kısadır, para doğrudan sizin hesabınıza akar. Ödeme kuruluşu modelinde tek entegrasyonla birçok bankaya ve karta ulaşırsınız, panel tek yerdedir, ama araya para akışını yöneten bir taraf girer. Platform veya pazaryeri altyapısında tahsilatı çoğunlukla platform yapar ve size hakedişinizi aktarır; bu durumda ödeme deneyimi üzerinde neredeyse hiç söz hakkınız kalmaz.
Seçim yapılırken sorulacak asıl soru hangisinin daha ucuz olduğu değil, bir şey ters gittiğinde kiminle konuşulacağıdır. Ters ibraz (chargeback) geldiğinde dosyayı kim açıyor, gün sonu tutmadığında kim bakıyor, banka tarafında bir kural değiştiğinde bunu size kim haber veriyor? Beş kişilik bir ekipte tek muhatap bulmak, ince farklardan çok daha değerlidir. Altyapı kararının site tarafındaki karşılığını e-ticaret altyapısı seçimi yazısında ayrıca ele alıyoruz.
Ekstrede görünen isim bir tasarım kararıdır
Müşterinin kart ekstresinde sizin bildiği adınız değil de tanımadığı bir kısaltma görünüyorsa, o satır bir gün bankaya sorulur ve itiraz dosyası açılır. Karşınızdaki kötü niyetli biri değil, hatırlayamayan bir insandır. Ekstrede görünecek metni sözleşme aşamasında sormak ve müşterinin tanıyacağı biçime getirmek, hiçbir ek maliyeti olmayan ama itirazların bir bölümünü doğrudan silen bir adımdır. Aynı mantık, ödeme sonrası gönderdiğiniz bilgilendirme mesajının başlığı için de geçerlidir.
Hangi ödeme yöntemi hangi kaybı kapatır?
Ödeme yöntemi eklemek pazarlama kararı gibi görünür; aslında bir operasyon kararıdır. Her yöntem kendi mutabakat yükünü, kendi iade mantığını ve kendi başarısızlık biçimini beraberinde getirir. Aşağıdaki liste yöntemleri özellik sırasına göre değil, kapattıkları somut kayba göre diziyor.
- Kredi ve banka kartı: Anında onay verir, siparişi bekletmez; karşılığında doğrulama adımında terk riski ve sonradan itiraz ihtimali taşır.
- Taksitli kart: Sepet büyüdükçe kararı kolaylaştırır; maliyeti satıcı tarafında kalır ve vade uzadıkça artar.
- Havale ve EFT: Kesinti tarafında en sade yöntemdir, ama siparişe özel referans kodu üretilmezse eşleştirme elle yapılır ve sevkiyat bekler.
- Ödeme linki: Sepet akışı olmayan ya da satışı telefonda kapatan ekiplerin kart altyapısını kullanmasını sağlar; teklif ile tahsilat arasındaki boşluğu kapatır.
- Kart saklama ve tekrarlayan ödeme: Abonelik ve bakım sözleşmelerinde her dönem yeniden tahsilat kovalamayı bitirir; kartın süresi dolduğunda ne olacağını önceden kurgulamayı şart koşar.
- Al şimdi öde sonra: Nakdi sıkışık alıcıyı kurtarır ve tahsilat riskini üçüncü tarafa taşır; ürün iadesi geldiğinde akış kartlı satıştan farklı işler.
- Kapıda ödeme: Güven eşiği yüksek müşteride siparişi kurtarır; teslimat başarısız olduğunda taşıma maliyeti tamamen sizde kalır.
Yaygın tavsiye mümkün olan her yöntemi açmayı söyler. Bu tavsiyenin sınırı nettir: açtığınız her yöntem, ay sonunda mutabakat edilecek yeni bir kaynak, destek ekibinin ezberlemesi gereken yeni bir iade kuralı ve ödeme ekranında bir seçenek daha demektir. Ağırlıklı olarak kurumsal müşteriye satan bir şirkette kartın payı düşükse, dört yeni yöntem açmak yerine havale açıklamasına otomatik referans kodu koymak çok daha fazla kazandırır. Teklifi tahsilata bağlayan ödeme linkiyle tahsilat yöntemini, riski üçüncü tarafa taşıyan al şimdi öde sonra modelini ve düzenli tahsilatın kurgusunu abonelik ve yenileme satışları yazısında ayrıntılandırıyoruz.
Taksit: kararın Türkiye'ye özgü kısmı
Türkiye'de kartla ödeme denince akla gelen şey tek çekim değil, taksittir; müşteri taksit seçeneğini bir ayrıcalık değil, standart bir alan olarak görür. Mekanizma şu: banka satış tutarını size taksit takvimine bağlı biçimde aktarır ve vade uzadıkça satıcı tarafındaki yük büyür. Bu yükü üç şekilde karşılayabilirsiniz: kendi marjınızdan yersiniz, ürün fiyatına gömersiniz ya da müşteriye vade farkı olarak açıkça gösterirsiniz. Üçü de savunulabilir, ama üçü farklı bir müşteri davranışı doğurur.
Beklenmedik kısım şurası: taksit yalnızca dönüşümü değil, sepetin bileşimini de değiştirir. Taksit açıldığında ortalama sepet büyür, çünkü müşteri daha pahalı seçeneğe kayar. Marjınız tam olarak o pahalı üründe inceyse, ciro artarken kâr düşer ve tabloya bakan kimse nedenini anlamaz. Bunu görmek için taksitli ve tek çekim satışların brüt kârını ayrı ayrı raporlamak gerekir. Ayrıca taksit seçeneğini yalnızca ödeme adımında değil ürün sayfasında göstermek, kararı çok daha erken kolaylaştırır.
Ödeme sayfası nerede durmalı?
Üç yerleşim var. Sağlayıcının kendi sayfasına yönlendirmek en hızlı kurulan ve uyum yükü en düşük seçenektir; bedeli, müşterinin sitenizden çıkması ve markanın kaybolmasıdır. Sayfayı kendi sitenize gömmek arada bir yol sunar. Kart alanlarını tamamen kendi arayüzünüzde toplamak en iyi deneyimi verir, ama kart verisine temas ettiğiniz anda uyum sorumluluğunun ağırlığı da size geçer. Küçük ekiplerin çoğunda doğru cevap, gömülü çözümle başlayıp gerçekten gerekiyorsa ileri gitmektir.
Dönüşümü belirleyen asıl unsur genellikle sağlayıcının kendisi değil, doğrulama adımının nasıl kurgulandığıdır. Müşteri banka ekranına geçip geri döndüğünde sepetini bulabiliyor mu? Hata mesajı banka kodunu mu yazıyor, yoksa ne yapması gerektiğini mi söylüyor? Başarısız denemeden sonra ikinci kartı denemek bir tıkla mümkün mü? Bu üç sorunun cevabı, sağlayıcı değiştirmekten daha fazla fark yaratır. Denemesi yarım kalan sepetlerin nasıl geri kazanıldığını terk edilen sepet otomasyonu yazısında anlatıyoruz.
Maliyet gerçekte hangi kalemlerden oluşur?
Sağlayıcı karşılaştırmalarının neredeyse tamamı tek bir kaleme, işlem başına kesintiye odaklanır. Oysa tahsilat altyapısının size yükü, birbirinden bağımsız en az altı yerden gelir ve bunların çoğu sözleşmenin ön yüzünde durmaz. Aşağıdaki tablo kalemleri, nerede doğduklarına ve nasıl gözden kaçtıklarına göre diziyor.
| Maliyet kalemi | Nerede ortaya çıkar | Nasıl gözden kaçar |
|---|---|---|
| İşlem başına kesinti | Her başarılı çekimde | Ciro brüt izlendiği için marj ekranına hiç ulaşmaz |
| Taksit yükü | Vade uzadıkça artan biçimde | Ürün fiyatına gömülür, marjda erir |
| Hesaba geçiş süresi | Satış ile paranın gelmesi arasında | Hiçbir kesinti tablosunda yazmaz |
| İade ve itiraz iş yükü | İptal, iade ve ters ibraz dosyalarında | Destek ile muhasebe saatine yazılır |
| Entegrasyon ve bakım | Kurulumda ve her sürüm değişikliğinde | Tek seferlik sanılır, oysa tekrar eder |
| Ek hizmetler | Kart saklama, dolandırıcılık filtresi, ek rapor | Sözleşmenin ekinde kalır |
Bu kalemleri yan yana koymanın pratik yolu, sağlayıcıları oran üzerinden değil senaryo üzerinden karşılaştırmaktır. Tipik bir ayınızı tarif edin: kaç işlem, hangi yöntem dağılımı, kaç iade, kaç itiraz, ne kadar taksit. Aynı senaryoyu her adaya verip toplam etkiyi sorduğunuzda, tek satırlık kesinti oranlarının sıralamayı nasıl değiştirdiğini görürsünüz. İade ve iptalin belge tarafı ise ayrı bir konudur; hangi belgenin ne zaman düzenleneceği konusunda kendi durumunuz için mali müşavirinize danışın.
Para ne zaman hesabınıza geçer?
Satışın gerçekleşmesi ile paranın hesaba geçmesi arasındaki süre, tahsilat altyapısının en az konuşulan ama nakit akışını en çok etkileyen özelliğidir. Taksitli satışta banka ödemeyi taksit takvimine yayar; hafta sonu ve resmi tatiller araya girer; yeni açılan üye iş yerlerinde bir süre boyunca bekletme uygulanabilir. Bunların hiçbiri gizli değildir, ama hiçbiri de kesinti oranıyla aynı cümlede söylenmez.
İkinci sürpriz, iadelerin ödeme paketlerinden düşülmesidir. Yoğun iade alınan bir haftada beklediğiniz aktarım küçülür, uç durumlarda ters yönde bir borç bile doğar. Sezon sonu indirimi yapan ekiplerin ay sonu nakit tahminini şaşırmasının en sık nedeni budur. Bu gecikmenin işletme sermayesi üzerindeki etkisini nakit akışı yönetimi yazısındaki çerçeveyle birlikte okumak, kararı çok daha somut hale getirir.
En düşük kesintiyi veren sağlayıcı parayı en geç veriyorsa indirim almadınız, farkında olmadan kredi verdiniz.
Mutabakat neden tutmaz?
Ödeme panelindeki günlük toplam ile banka hesabına düşen tutarın birbirini tutmaması bir arıza değil, tasarımın sonucudur. Sağlayıcılar genellikle kesintiyi aktarmadan önce düşer, birden fazla günün işlemini tek pakette gönderir ve iadeleri aynı paketin içinde netleştirir. Yani banka ekstresindeki bir satır, sizin sistemde onlarca sipariş demektir. Sipariş toplamını doğrudan ekstre satırıyla eşleştirmeye çalışan her ekip, kısa sürede elle tutulan bir yan defter üretir.
Çalışan yaklaşım üç seviyeli eşleştirmedir: sipariş ile işlem, işlem ile ödeme paketi, ödeme paketi ile ekstre satırı. Her seviyede farkın nereden geldiği bellidir; kesinti, iade, bekletme ve kur farkı ayrı ayrı görünür. Bu zincirin ilk halkasını ödeme-CRM entegrasyonu, son halkasını ise banka ekstresi entegrasyonu ve otomatik eşleştirme yazısında ayrıntılı anlatıyoruz.
İade, iptal ve ters ibraz aynı şey değildir
Üçü sıklıkla tek kelimeyle anılır ve bu karışıklık paraya mal olur. Gün sonu alınmadan yapılan iptal, provizyonu düşürür ve genellikle en ucuz yoldur. İade ise tamamlanmış bir çekimin geri döndürülmesidir, kendi işlem yükünü doğurur ve müşterinin kartına ulaşması gün alır. Ters ibraz ise sizin başlatmadığınız bir süreçtir: müşteri bankasına başvurur, banka tutarı geri alır ve savunma yükü tamamen sizin üstünüze kalır.
Bu yüzden ters ibraz geldiğinde toplanan değil, önceden hazır duran bir kanıt dosyasına ihtiyaç vardır: sipariş kaydı, onaylanan sözleşme veya mesafeli satış metni, teslimat kanıtı, müşteriyle yapılan yazışma ve ödeme kaydının kendisi. Bu beş parça tek müşteri kartında duruyorsa dosya dakikalar içinde açılır; farklı yerlerdeyse çoğu ekip süreyi kaçırır. İade politikanızın müşteri tarafındaki karşılığını tüketici hakları ve iade süreçleri yazısında bulabilirsiniz.
Neyi hiç saklamamalısınız?
En basit kural en güçlü korumadır: kart numarasını ve güvenlik kodunu hiçbir yerde tutmayın. Telefonda alınıp bir kâğıda yazılan, ekran görüntüsü olarak mesajlaşma uygulamasında duran ya da müşteri kaydının not alanına düşülen kart bilgisi, sonradan silinemeyecek bir riski şirkete taşır. Tekrarlayan tahsilat gerekiyorsa çözüm kartı saklamak değil, sağlayıcının ürettiği bir jetonu saklamaktır; o jeton yalnızca sizin hesabınızda anlamlıdır.
İkinci risk daha az konuşulur: paneldeki yetkiler. İade butonu, sipariş alan kişiyle aynı elde durduğunda kontrol ortadan kalkar. İade yetkisini ayırmak, belirli bir tutarın üzerindeki iadeleri ikinci onaya bağlamak ve paneldeki oturum kayıtlarını düzenli okumak, hiçbir yazılım almadan uygulanabilecek adımlardır. Erişim ve yedekleme tarafındaki genel çerçeveyi KOBİ için siber güvenlik yazısında topladık.
Hangi sayıları izlemeli, nereden başlamalısınız?
Altı gösterge çoğu ekip için yeterlidir. Onay oranı, denenen ödemelerin ne kadarının başarıya ulaştığını söyler ve bunu bankaya göre kırmadan bakmak yanıltıcıdır; tek bir bankanın oranı çökmüşse bu piyasa değil, konfigürasyon sorunudur. Doğrulama adımındaki terk oranı, ödeme sayfası tasarımının notudur. Ret kodlarının dağılımı, en az okunan ama en çok şey söyleyen rapordur. Kalan üçü ise iade oranı, ters ibraz oranı ve satıştan hesaba geçişe kadar geçen ortalama süredir.
Kuruluma başlarken alışılmış hata, mutlu senaryoyu test edip yayına almaktır. Gerçek dersler kırık yollardadır: doğrulama ekranında zaman aşımı, aynı sepetin iki kez gönderilmesi, kısmi iade, süresi dolmuş provizyon, ödeme paketi aktarıldıktan sonra gelen iade. Bu beş senaryoyu canlıya çıkmadan önce elle deneyin ve her birinin sipariş kaydında nasıl göründüğünü yazın. İki hafta tek yöntemle çalışıp mutabakatı elle kapatmak, sonraki bir yılın kurallarını yazmanın en ucuz yoludur.
Sipariş, ödeme, cari hesap ve fatura kaydını aynı yerde tutmak, tahsilat altyapısındaki sızıntıları görünür kılmanın en kısa yoludur. Rocketly'de ödeme kayıtları müşteri kartına, cari hesaba ve faturaya bağlı ilerliyor, mutabakat farkları da aynı ekranda kalıyor; ücretsiz hesap açarak kendi tahsilat akışınızı kurup deneyebilirsiniz.