TikTok coin satan çoğu işletme sahibi riski tek kelimeyle özetliyor: "chargeback". Kartla ödeme alıyorsun, müşteri itiraz ediyor, para geri gidiyor, ürün gitmiş oluyor. Doğru bir korku ama eksik. Sahadaki kayıt tutan bayilere baktığında zararın büyük kısmının kart itirazından değil, teslimat öncesi doğrulanmamış hesap bilgisinden geldiğini görüyorsun. Yani sorun ödeme kanalında değil, senin sipariş akışında.
İkinci yanılgı da şu: "güvenlik, ödeme sağlayıcısının işi". Değil. Sağlayıcı sadece parayı taşır; kime, hangi hesaba, hangi kanıtla teslim ettiğini ispatlamak tamamen sana ait. İtiraz masasına çıktığında elinde ekran görüntüsü yerine zaman damgalı log varsa kazanırsın, yoksa kaybedersin. Bu yazıda coin satışındaki zarar zincirini halka halka açıyor, her halkayı kesen teknik önlemi ve bunun bir e-pin scripti içinde nasıl kurulduğunu anlatıyoruz.
Zarar gerçekten kart itirazından mı geliyor?
Kart itirazı görünür olduğu için akılda kalıyor: bankadan bildirim gelir, tutar düşer, canın sıkılır. Ama sessiz zarar başka yerde birikiyor. Müşteri kullanıcı adını yanlış yazıyor, teslimat gidiyor, geri gelmiyor. Ya da aynı kullanıcı adına benzeyen farklı bir hesap seçiliyor. Ya da siparişten sonra müşteri "ben almadım" diyor ve elinde hiçbir onay kaydı olmadığı için tartışmayı kaybediyorsun.
Bu üç senaryonun ortak noktası aynı: ispat eksikliği. Çözüm kart tarafında değil, form tarafında. Hedef hesabı iki kez yazdırmak, girilen bilgiyi teslimat öncesi özet ekranında müşteriye onaylatmak ve bu onayı IP, tarih, tarayıcı izi ile birlikte kaydetmek, zararın yarısını tek hamlede siliyor.
Neden hiçbir zaman şifre istememelisin?
Bazı bayiler işi hızlandırmak için müşteriden hesap şifresi istiyor. Bu, ticari olarak kısa vadede kolay, hukuken ve operasyonel olarak felaket. Bir kere şifre aldığında, o hesapta sonradan yaşanan her olumsuzluğun tek şüphelisi sen olursun. Kaybolan bir yayın geliri, değişen bir e-posta, kapanan bir hesap; hepsi kapına gelir.
Doğru yol, teslimatın hesap bilgisi değil hedef kimliği üzerinden yapılması. Kullanıcı adı ya da profil bağlantısı yeterli olmalı. Kullandığın dijital ürün satış scripti içinde ürün başına "istenecek alanlar" tanımlanabiliyorsa, bu kuralı teknik olarak zorunlu kılabilirsin: şifre alanı hiç var olmaz, personel de isteyemez. Politikayı insana değil sisteme gömmek, güvenliğin en ucuz biçimi.
| Risk türü | Nasıl ortaya çıkar | Tipik zarar | Teknik karşı önlem |
|---|---|---|---|
| Hatalı hedef hesap | Müşteri kullanıcı adını yanlış yazar | Tam sipariş tutarı | Çift giriş + özet onay ekranı |
| Kart itirazı | Ödeme sonrası banka itirazı | Tutar + işlem ücreti | Zaman damgalı teslim logu |
| Kimlik uyuşmazlığı | Ödeyen ile teslim alan farklı | Zincirleme itiraz | Yüksek tutarda ek doğrulama |
| Şifre paylaşımı | Bayi hesap erişimi ister | İtibar + hukuki risk | Şifre alanını sistemden kaldırmak |
| Çoklu sipariş suistimali | Aynı kişi kısa sürede yığın sipariş | Stok ve marj erozyonu | Hız limiti ve risk skoru |
Ödeyen ile teslim alan aynı kişi mi, bunu nasıl bilirsin?
Coin satışında en sinsi senaryo bu. Ödeme bir kartla yapılıyor, teslimat tamamen alakasız bir hesaba isteniyor. Bazen masum bir hediye, bazen değil. Tutar küçükse akışı yavaşlatmanın anlamı yok; ama belirli bir eşiğin üzerinde ek doğrulama istemek hem seni korur hem müşteriyi rahatsız etmez.
Pratik kurgu şöyle: eşik altı siparişler otomatik akar, eşik üstü siparişler "manuel onay" kuyruğuna düşer. Kuyrukta personel tek bir ekranda ödeme bilgisi, hedef hesap ve müşteri geçmişini görür. Bu ayrımı yapamayan bir e-pin satış yazılımı seni iki kötü seçeneğe mahkûm eder: ya her siparişi elle kontrol edip yavaşlarsın, ya hiçbirini kontrol etmeyip riske girersin.
Coin satışında itiraz sebeplerinin dağılımı
- Yanlış hesaba teslim 40%
- Kanıtsız sipariş kaydı 30%
- Gecikme kaynaklı iade 18%
- Gerçek kart dolandırıcılığı 12%
İtiraz masasında hangi kayıt seni kurtarır?
Ekran görüntüsü kanıt sayılmaz. Sohbet kaydı zayıf kanıttır. Seni kurtaran şey, sistem tarafından üretilmiş ve sonradan düzenlenemeyen sipariş kaydıdır. İçinde şunlar olmalı: sipariş numarası, ödeme referansı, ödeme zamanı, müşterinin girdiği hedef bilgisi, özet ekranındaki onay zamanı, teslimat zamanı, teslimatı yapan kaynak, işlem IP'si ve varsa müşteri mesajı.
Bu dokuz alanı üreten bir kurulumda itiraz oranı düşmez ama kaybedilen itiraz oranı ciddi biçimde düşer. Aradaki fark doğrudan kâr. Pinova gibi lisanslı bir altyapıda bu kayıtlar varsayılan olarak tutulur; senin yapman gereken tek şey itiraz geldiğinde ilgili siparişi açıp dökümü indirmek. Not olarak tekrar edelim: Pinova coin satmaz, coin satan işletmenin sipariş ve güvenlik altyapısıdır.
Teslimattan önce müşteriye "şu hesaba şu kadar gönderilecek" ekranını göster ve onayı kaydet. Bu tek ekran, yanlış hesap zararının neredeyse tamamını müşteri sorumluluğuna taşır.
Hız limiti koymamak neden sessizce marj yiyor?
Aynı kişinin dakikalar içinde onlarca küçük sipariş açması masum görünür. Oysa bu davranış üç şeye işaret eder: kart deneme, kampanya suistimali veya otomatik bot. Üçü de sana maliyet yazar. Basit bir hız limiti, örneğin aynı IP ve aynı hedef hesap için saatlik sipariş üst sınırı, bu yükü kaynağında kesiyor.
Bunun yanına basit bir risk skoru ekleyebilirsin: yeni kayıtlı müşteri, ilk siparişte yüksek tutar, ödeme ile teslim hedefinin uyumsuzluğu, kısa sürede tekrarlanan iptal. Her biri puan ekler; eşik aşılırsa sipariş manuel kuyruğa düşer. Bu mekanizmayı özellikler sayfasında "sipariş kuralları" başlığı altında görebilirsin.
Güvenliği personele mi, sisteme mi gömmelisin?
Personele gömülen güvenlik, personel değişince kaybolur. Yeni gelen kişi eski kuralı bilmez, yoğun günde kısayol arar, müşteriyi memnun etmek için istisna yapar. Tek bir istisna, bütün politikayı geçersiz kılar. Bu yüzden kuralı yazılımda zorunlu alan ve zorunlu adım haline getirmek gerekir.
İkinci katman yetki ayrımı. Sipariş görebilen herkesin fiyat değiştirmesi, log silmesi veya iade yapması gerekmez. Rol bazlı yetki, hem iç riski hem dışarıdan gelen sosyal mühendislik riskini azaltır. Doğru kurulmuş bir dijital ürün satış yazılımı sana bu ayrımı hazır verir; sen sadece kimin neye dokunacağını işaretlersin.
| Güvenlik kontrolü | Kurulum yeri | Zorluk | Durum |
|---|---|---|---|
| Hedef hesap çift giriş | Sipariş formu | Kolay | Zorunlu |
| Teslim öncesi özet onayı | Ödeme akışı | Kolay | Zorunlu |
| Şifre alanının tamamen kaldırılması | Ürün alan tanımı | Kolay | Zorunlu |
| Dokuz alanlı sipariş logu | Sistem kayıtları | Orta | Zorunlu |
| Tutar eşiğinde manuel onay | Sipariş kuralları | Orta | Önerilir |
| IP ve hedef bazlı hız limiti | Güvenlik ayarları | Orta | Önerilir |
| Rol bazlı personel yetkisi | Kullanıcı yönetimi | Kolay | Önerilir |
Riski forma gömen bir altyapı kur
Çift doğrulama, özet onayı, sipariş logu ve rol yetkisi hazır gelsin. Pinova lisansıyla güvenliği personelin insafına bırakmaktan çık.
Müşteriden hesap şifresi istemek bazen gerekli olmuyor mu?
Hayır. Teslimat kullanıcı adı veya profil bağlantısı üzerinden yapılabilir. Şifre aldığın anda o hesapta yaşanan her sorunun muhatabı sen olursun.
Chargeback itirazında hangi kayıt en çok işe yarıyor?
Sistem tarafından üretilmiş, sonradan düzenlenemeyen sipariş dökümü: ödeme referansı, müşterinin onay zamanı, teslimat zamanı ve IP kaydı birlikte sunulduğunda savunma güçlenir.
Her siparişi manuel kontrol etmem mi gerekiyor?
Gerekmiyor. Tutar eşiği ve risk skoru kurarsan küçük siparişler otomatik akar, sadece riskli olanlar manuel kuyruğa düşer.
Bu kontrolleri kendi yazdığım panele ekleyebilir miyim?
Ekleyebilirsin ama log bütünlüğü, rol yetkisi ve hız limiti sıfırdan yazıldığında uzun sürer. Hazır ve lisanslı bir e-pin satış scripti bu katmanları test edilmiş halde verir.
Sonuç net: coin satışında güvenlik bir ödeme sağlayıcısı seçimi değil, bir akış tasarımı meselesi. Hedefi doğrulayan, onayı kaydeden, riskli siparişi ayıran ve yetkiyi bölen bir kurulumda zarar kalemi neredeyse kapanıyor. Kendi akışını kıyaslamak istiyorsan lisans planlarına göz atmadan önce canlı demo içinde bir coin ürünü tanımlayıp özet onay ekranıyla birlikte test siparişi geçir; hangi kaydın tutulduğunu kendi gözünle görmek her açıklamadan daha ikna edici olur.