Paran Hesabına Geçmiş Sanıyorsun Ama Provizyonda Bekliyor: E-pin Satışında Ön Provizyon ve İade Sürelerinin Sana Anlatılmayan İşleyişi

Panelinde "ödeme başarılı" yazısını gördüğün an çoğu satıcı işin bittiğini düşünür. Kod gider, müşteri memnun olur, sipariş kapanır. Gerçekte o anda olan şey bambaşkadır: bankanın yaptığı çoğu zaman bir tahsilat değil, kartın limitinden bir tutarın bloke edilmesidir. Para ne müşterinin hesabından tam olarak çıkmıştır ne de senin hesabına girmiştir; arada bir bekleme odasında durur.

Bu ayrımı bilmeyen bir satıcı, dijital ürün işinin en pahalı hatalarından birini yapar: bloke edilmiş bir tutara güvenip anında teslim edilen bir kodu elinden çıkarır. E-pin gibi geri alınamayan bir üründe bu, iade ve itiraz süreçlerini tamamen senin aleyhine çeviren bir açıktır. Aşağıda ön provizyonun mekaniğini, iade sürelerinin hangi günden itibaren saymaya başladığını ve bir e-pin scriptinin bu durumları nasıl modellemesi gerektiğini tek tek açıyorum.

Ön Provizyon Aslında Ne Yapar, Para Nerede Bekler?

Ön provizyon, kartın kullanılabilir limitinden belirli bir tutarın satıcı lehine ayrılmasıdır. Banka şunu der: "bu tutar şu an bu işlem için rezerve edildi, başka yere harcanamaz." Ama bu rezervasyon, paranın senin hesabına aktarılması demek değildir. Aktarım, işlemin satışa dönüştürülmesiyle yani provizyonun kapatılmasıyla gerçekleşir.

Kapatma işlemi kimi kurulumda otomatik ve anında, kimi kurulumda gün sonu toplu süreçle yapılır. Arada kalan pencerede provizyon iptal edilirse müşterinin limiti serbest kalır ve senin tarafında hiçbir tahsilat oluşmaz. Dikkat edilmesi gereken nokta şu: provizyon iptali, iade değildir. İptalde para hiç hareket etmediği için müşteri genelde ekstresinde bir satır bile görmez; iadede ise para geri döner ve bu birkaç gün sürer.

E-pin Anında Teslim Edilirken Provizyon Neden Sorun Çıkarır?

Fiziksel ürün satan biri için provizyon rahat bir mekanizmadır: kargo çıkana kadar bekler, sonra kapatır. Dijital üründe böyle bir tampon yoktur. Müşteri kodu saniyeler içinde ister; sen provizyonun satışa dönüşmesini bekleyemezsin. Bu yüzden dijital satışta doğru kural şudur: teslimat, provizyonun kapatıldığı doğrulanmadan tetiklenmemeli.

Uygulamada bu, ödeme sağlayıcısının işlem durumunu yetkili kaynak kabul etmek anlamına gelir. Dönüş sayfasındaki parametreye değil, sunucudan sunucuya gelen bildirime ve sorgu sonucuna bakılır. Aradaki fark bir kelime gibi görünür ama sonucu büyüktür: tarayıcıdan gelen dönüş bilgisi taklit edilebilir, sunucu sorgusu edilemez. Pinova'da bu ayrım ödeme katmanının temel kuralıdır; teslimat kuyruğu yalnızca doğrulanmış işlem durumuyla açılır. Özellikler sayfasında teslimat kuyruğunun nasıl tetiklendiğini görebilirsin.

İade Talebi Geldiğinde Süre Hangi Günden Sayılır?

Satıcıların en sık karıştırdığı konu bu. Mesafeli satışta cayma hakkı süresi, hizmet ve dijital içerikte kural olarak sözleşmenin kurulduğu gün; fiziksel üründe ise teslim tarihinden itibaren işlemeye başlar. Dijital içerikte ayrıca kritik bir istisna vardır: müşteri bilgilendirilmiş ve onay vermişse, anında ifa edilen ve elektronik ortamda teslim edilen içerikte cayma hakkı kullanılamaz.

Bu istisna kendiliğinden işlemez. İstisnadan yararlanmak için ön bilgilendirmede bunun açıkça yazılı olması, müşterinin satın alma anında bu bilgiyi onaylaması ve bu onayın kayıt altına alınması gerekir. Onay kutusunu koyup tıklanan zamanı, IP'yi ve gösterilen metnin sürümünü saklamayan bir sistem, itiraz anında elinde hiçbir kanıtı olmadan kalır. İyi kurulmuş bir dijital ürün satış yazılımı bu onayı sipariş kaydının parçası olarak tutar.

Teslim Edilmiş Bir Kodda İade Politikası Nasıl Yazılır?

"İade yapılmaz" yazmak bir politika değil, bir temenni. Uygulanabilir politika, kodun durumuna göre kademelenir. Henüz teslim edilmemiş sipariş için tam iade; teslim edilmiş ama sistemde kullanılmadığı doğrulanabilen kod için tedarikçi onayına bağlı iade; kullanıldığı görülen kod için iade yok. Bu üç kademeyi metne dökerken hangi kanıtın kabul edildiğini de yazman gerekir.

Bir de operasyonel tarafı var: kodun kullanılıp kullanılmadığını sorabildiğin bir tedarikçin yoksa, orta kademe fiilen boş kalır. O yüzden politikayı tedarikçi sözleşmelerinle uyumlu yazmak şart. Ayrıca teslim edilmiş her kodun ilk gösterim zamanını ve kaç kez görüntülendiğini kaydet; müşteri "kod gelmedi" dediğinde tek ihtiyacın olan kanıt bu satırdır. Bir e-pin satış scripti bu görüntüleme günlüğünü tutmuyorsa, her tartışmayı kaybedersin.

İade ile Kart İtirazı Aynı Şey mi? Farkı Bilmezsen Ödersin

İade senin başlattığın, kontrollü bir geri ödemedir: tutarı sen belirlersin, kaydı sende durur, komisyonun bir kısmı kimi kurulumda geri gelir. Kart itirazı ise müşterinin bankası üzerinden başlattığı bir şikâyet sürecidir; tutar senden geçici olarak geri çekilir ve haklı olduğunu belgeyle kanıtlaman istenir. İkisi aynı sonucu üretiyor gibi görünür ama itirazın ek bir işlem ücreti ve birikince sağlayıcı nezdinde risk puanı vardır.

Bu yüzden akıllı satıcı, itiraz olmadan iade eder. Müşteri "kart benim değil" ya da "ürünü alamadım" diyorsa; sen haklı olsan bile itiraz sürecine girmek pahalıdır. Doğru hamle, kanıtını hazır tutup makul talepte hızlı iade etmek. İtiraz oranını düşük tutmak, ileride taksit ve komisyon konuşmalarında da elini güçlendirir. Fiyatlandırma sayfasındaki paketlerde iade ve itiraz kayıt modülünün hangi seviyede geldiğine bakabilirsin.

Scriptin Provizyon Durumlarını Nasıl Modellemeli?

Çoğu basit kurulum ödemeyi iki değerle tutar: başarılı veya başarısız. Bu model gerçek hayata yetmez. En az beş durum gerekir: başlatıldı, provizyon alındı, tahsil edildi, iade edildi, itiraz altında. Her durum değişimi zaman damgası ve kaynağıyla (sağlayıcı bildirimi mi, panelden elle mi) kaydedilmeli.

Bu yapı kurulduğunda üç şey kendiliğinden çözülür: açık provizyonları görebilirsin, hangi siparişin teslimatının hangi doğrulamayla açıldığını izleyebilirsin ve muhasebeye giden tutar gerçek tahsilatı yansıtır. Doğru durum modeli, iade tartışmalarının yarısını başlamadan bitirir çünkü konuşacak somut bir kayıt vardır.

Provizyon ve iade, dijital ürün satışının en az konuşulan ama kârı en çok etkileyen iki kalemi. Bunları doğru modellemek ekstra bir özellik değil, işin temel hijyeni. Ödeme durumlarının, teslimat kuyruğunun ve onay kayıtlarının aynı ekranda nasıl birleştiğini görmek istersen canlı demo üzerinden bir sipariş oluşturup her aşamada hangi kaydın düştüğünü kendi gözünle takip et.