Çoğu kişi ödeme güvenliğini bankanın işi sanır. "Ben zaten lisanslı bir altyapı kullanıyorum, ödeme sağlayıcım büyük bir firma, para hesabıma düşüyorsa iş tamamdır" diye düşünür. Oysa paranın hesabına düşmesiyle sistemindeki bakiyenin artması iki ayrı olaydır ve bu ikisini birbirine bağlayan tek şey, sunucuna gelen o küçük bildirim isteğidir. O isteği kim gönderirse gönderdi diye kabul ediyorsan, aslında kasanın anahtarını internete asmış oluyorsun.
Sahada gördüğümüz tablo tam olarak şu: bakiyesi sabah gelip de "ben yüklemedim ama 40 bin TL bakiyem var" diyen kullanıcılar, çoğunlukla açık bulmuş dâhiler değil. Sadece ödeme dönüş adresini tarayıcıdan çağırıp, parametreleri elle yazıp göndermeyi denemiş meraklılar. Bir e-pin satış scripti içinde imza doğrulaması doğru kurulmuşsa bu deneme ilk saniyede reddedilir; kurulmamışsa bakiye artar ve arkasından e-pin kodları çekilip gider. Bu yazıda o doğrulama katmanını, Pinova gibi profesyonel bir dijital ürün satış yazılımı kurarken hangi sırayla ele almanız gerektiğini adım adım açıyorum.
Ödeme bildirimi dediğin şey aslında ne? Neden tarayıcıya güvenmek en pahalı hatan?
Ödeme akışında iki dönüş vardır ve bunları karıştırmak en yaygın ölümcül hatadır. Birincisi kullanıcının tarayıcısının döndüğü başarılı/başarısız sayfası; ikincisi ödeme sağlayıcısının sunucusundan doğrudan senin sunucuna gelen sunucudan sunucuya bildirim. Birinci yolda gelen her veri kullanıcının elindedir: adres satırındaki tutarı değiştirir, durum alanını "success" yapar, gönderir. Bakiyeyi o sayfada yüklüyorsan, kullanıcıya "kendi paranı kendin yaz" demiş olursun.
Doğru mantık şudur: tarayıcı dönüşü yalnızca görsel bir bilgilendirmedir, hiçbir yazma işlemi yapmaz; para ve bakiye hareketi sadece bildirim ucunda gerçekleşir. Kullanıcı dönüş sayfasında "ödemen işleniyor" görür, arkada bildirim geldiğinde sipariş kapanır. Bu ayrımı yapmayan bir epin yazılım kurgusunda hiçbir imza algoritması seni kurtarmaz, çünkü saldırgan imzayı hiç dert etmeden zayıf kapıdan girer.
İmza nasıl üretilir ve sıralamayı bozmak neden doğrulamayı çöpe atar?
İmza, ödeme sağlayıcısının sadece kendisinin ve senin bildiği gizli anahtarla, bildirimdeki alanları belirli bir sırada birleştirip özetlemesiyle oluşur. Kritik nokta şu: birleştirme sırası ve biçim sağlayıcının dokümanındaki ile harfi harfine aynı olmalı. Tutarı 100 yerine 100.00 yazmak, ondalık ayırıcıyı nokta yerine virgül koymak, sipariş numarasını başındaki sıfırlarla göndermek imzayı tamamen değiştirir.
Burada işletmelerin düştüğü tuzak, imza tutmadığında doğrulamayı gevşetmek oluyor. "Sürekli hata veriyordu, biz de kontrolü kapattık, ödemeler akmaya başladı" cümlesini duyduğumdan çok oldu. Hata vermesi kötü bir haber değildi, bilgi veriyordu. Yapılması gereken, gelen tüm ham veriyi bir kayıt tablosuna yazıp kendi ürettiğin özetle sağlayıcının gönderdiğini yan yana koymak ve farkı bulmaktı. Bir e-pin scripti yönetirken imza karşılaştırmasını da sıradan bir eşitlik kontrolüyle değil, karakter karakter sızdırmayan sabit süreli karşılaştırma fonksiyonuyla yapmalısın.
| Kontrol katmanı | Ne engelliyor | Yoksa olası sonuç | Zorluk |
|---|---|---|---|
| Gizli anahtarlı imza özeti | Elle uydurulmuş bildirim | Bedava bakiye yükleme | Orta |
| Sağlayıcı IP aralığı kontrolü | Üçüncü sunuculardan gelen istek | Otomatik deneme saldırısı | Kolay |
| Tutar ve para birimi eşleşmesi | 1 TL ödeyip 1.000 TL yükleme | Doğrudan zarar | Kolay |
| Tek kullanımlık işlem kilidi | Aynı bildirimin tekrarı | Çift bakiye, çift kod teslimi | Orta |
| Ham istek kaydı ve arşivi | İtiraz ve inceleme körlüğü | Kanıtsız kalma | Kolay |
| HTTPS ve sertifika zorunluluğu | Araya girip veri değiştirme | Sessiz manipülasyon | Kolay |
Aynı bildirim iki kez gelirse ne olur? Tekrar gönderim sessiz katildir
Ödeme sağlayıcıları, senin sunucun zamanında "aldım" yanıtı vermediğinde aynı bildirimi tekrar gönderir. Bu bir arıza değil, tasarımdır. Senin tarafında tekrar koruması yoksa, aynı ödeme için bakiye iki, bazen üç kez yüklenir. İşin acı tarafı bunun saldırı olmadan, tamamen kendi kendine gerçekleşmesidir; bir yavaş sorgu, bir zaman aşımı yeter.
Çözüm basit ama disiplin ister: her bildirimi işlemeye başlamadan önce sağlayıcının işlem numarasını benzersiz bir sütuna yazmayı dene. Yazma başarısızsa bu bildirim daha önce işlenmiş demektir; hiçbir şey yapmadan "aldım" dön. Yazma başarılıysa işlemi tek bir veritabanı hareketi içinde tamamla. Böylece aynı anda gelen iki istekten yalnızca biri işi bitirir. İyi kurulmuş bir e-pin satış yazılımı bunu kullanıcıya hiç göstermeden arka planda halleder.
Başarısız imza doğrulamalarının gerçek nedenleri
- Alan sırası ve birleştirme hatası 45%
- Tutar ve kodlama biçimi farkı 25%
- Test ile canlı anahtar karışması 20%
- Tekrar gönderim ve zaman aşımı 10%
Tutar kontrolünü atlıyorsan imzan hiçbir işe yaramıyor
İmza doğru olabilir, IP doğru olabilir, işlem tekil olabilir; ama sipariş kaydındaki tutarla bildirimde gelen tutarı karşılaştırmıyorsan kapı yine açıktır. Özellikle ödeme başlatma isteğini tarayıcı üzerinden gönderen kurgularda, kullanıcı tutarı düşürüp ödemeyi tamamlar, bildirim de o düşük tutarla imzalı olarak gelir. Sistem "imza geçerli" der ve siparişin tam değerini bakiyeye yazar.
Bu yüzden kural nettir: ödeme tutarının tek doğru kaynağı senin veritabanındaki sipariş kaydıdır. Bildirimden gelen tutar yalnızca bu kayıtla eşleşip eşleşmediğini sınamak için kullanılır. Eşleşmiyorsa sipariş kapanmaz, insan onayına düşer. Para birimi kontrolünü de unutma; farklı bir birimle gelen aynı sayı, aradaki kur kadar zarar demektir.
Bildirim geldiğinde sırayla sor: imza doğru mu, bu işlem daha önce işlendi mi, tutar benim kaydımla aynı mı? Üçünden biri "hayır" ise hiçbir bakiye hareketi yapılmaz, sadece kayıt tutulur ve uyarı gider.
Bildirim geldiğinde kodu hemen teslim etmeli misin?
E-pin işinde ödemeyi doğrulamak işin yarısıdır; diğer yarısı teslimdir. Doğrulama geçtiği anda stoktan kod çekip göndermek kulağa hızlı gelir ama iade ve itiraz riskini büyütür. Sağlıklı akış, doğrulamadan sonra siparişi "ödendi" durumuna almak, stoktan kodu rezerve etmek ve teslimi bu rezervasyon üzerinden yapmaktır. Böylece bir sorun çıkarsa kodu serbest bırakabilir, aynı kodu iki müşteriye göndermekten kurtulursun.
Ayrıca teslim edilen kodun kime, hangi ödeme işlemiyle, hangi saniyede gittiğini izleyen bir kayıt zinciri tut. Bu zincir hem itirazlarda kanıt, hem de tedarikçiyle aranda mutabakat aracıdır. Ciddi bir dijital ürün satış scripti bu izleri kullanıcıdan bağımsız, silinemez biçimde saklar; Pinova tarafında bunu yönetim panelinden tek ekranda görebiliyorsun. Özelliklerin tamamını özellikler bölümünde inceleyebilirsin.
Kendi kurulumunu bu listeyle denetle: bir gece yeter
Aşağıdaki tabloyu alıp kendi sisteminde tek tek işaretle. Bu bir teori listesi değil; her satır, gerçek bir işletmenin zarar ettiği bir olaydan geriye çıkarılmış kontrol. "Bizde şu yok" dediğin her satır, bu ay kapatılması gereken bir açıktır.
| # | Kontrol maddesi | Nasıl test edilir | Beklenen sonuç |
|---|---|---|---|
| 1 | Bildirim adresi imzasız isteği reddediyor | Parametresiz düz istek gönder | İşlem yok, hata kaydı var |
| 2 | Tarayıcı dönüşü bakiye yazmıyor | Dönüş adresini elle çağır | Sadece bilgi ekranı |
| 3 | Aynı bildirim ikinci kez etkisiz | Geçerli bildirimi iki kez gönder | Tek bakiye hareketi |
| 4 | Tutar kayıtla karşılaştırılıyor | Tutarı düşürerek dene | Sipariş açık kalıyor |
| 5 | Gizli anahtar kod içinde değil | Yapılandırma dosyasını denetle | Sunucu ortamında saklı |
| 6 | Test ve canlı anahtar ayrı | Ortam değişkenlerini incele | Karışma imkânı yok |
| 7 | Tüm ham bildirimler arşivde | Son 30 günü sorgula | Eksiksiz kayıt |
| 8 | Şüpheli durumda bildirim gidiyor | Bilerek geçersiz imza üret | Yöneticiye uyarı |
Ödeme katmanını kendin yazmak zorunda değilsin
Pinova, imza doğrulama, tekrar koruması ve tutar eşleşmesini kutudan çıktığı gibi hazır sunan lisanslı bir e-pin satış yazılımıdır. Fiyatlandırmayı ve paketleri hemen görebilirsin.
İmza doğrulaması olmadan ödeme almak mümkün mü?
Teknik olarak mümkün, ticari olarak intihar. İmza doğrulaması olmayan bir sistemde bakiye yüklemek için para göndermek bile gerekmez; bildirim adresini bilen biri isteği kendi üretir.
IP kontrolü tek başına yeterli olur mu?
Hayır. IP listeleri sağlayıcı tarafında değişebilir ve bazı ara sunucu kurgularında yanıltıcı sonuç verir. IP kontrolü ek bir katmandır, imzanın yerine geçmez.
Ödeme geldi ama sipariş kapanmadı, sorun nerede?
Vakaların çoğunda bildirim sunucuya ulaşmış ama imza tutmadığı için reddedilmiştir. Ham istek kaydına bakıp kendi ürettiğin özetle gelen özeti karşılaştırmak sorunu dakikalar içinde çözer.
Pinova farklı ödeme sağlayıcılarıyla çalışıyor mu?
Evet. Her sağlayıcının imza kuralı kendi modülünde tanımlıdır; yönetim panelinden anahtarları girip aktif etmen yeterlidir, kod tarafında değişiklik yapmana gerek kalmaz.
Ödeme güvenliği, bir gün oturup yazılan tek bir fonksiyon değil; her bildirimde aynı sırayla çalışan bir disiplindir. Bu disiplini sıfırdan kurmak yerine hazır ve denenmiş bir altyapıyla başlamak istiyorsan, panelin bu kontrolleri nasıl yönettiğini canlı demo üzerinden kendi gözlerinle görebilir, ardından fiyat tablosuna bakıp kendi ölçeğine uygun paketi seçebilirsin.