Ödeme Modülünü Tek Dosya Sananlar İçin Kötü Haber: Epin Satış Scriptinde Paranın Nerede Kaybolduğunu Gösteren Mimari Sırları Açıyorum

Çoğu satıcı ödeme modülünü bir entegrasyon dosyası sanır. "Sağlayıcının kodunu koyduk, test kartıyla denedik, çalışıyor" der ve konuyu kapatır. Gerçek şu: ödeme entegrasyonu ilk gün çalışır, mimari eksikliği ise üçüncü ayda faturayı keser. Ters ibraz gelir ve hangi siparişe ait olduğunu bulamazsın, sağlayıcı değiştirmek istersin ve tüm sipariş akışını yeniden yazman gerekir, callback gecikir ve müşteri parayı ödediği halde "başarısız" ekranı görür.

Bir dijital ürün satış scripti tarafında ödeme, bir dosya değil bir katmandır: soyutlama, durum makinesi, otorite kuralı, mutabakat ve iade kapıları. Bu beş parça yerinde olduğunda yeni bir sağlayıcı eklemek yarım gün sürer; olmadığında her yeni sağlayıcı sistemi biraz daha kırılgan hale getirir. Aşağıda bu katmanın nasıl kurulduğunu, hangi kararların geri dönüşü olmadığını ve neden "para geldi" ile "teslim edilebilir" ifadelerinin asla aynı şey olmadığını tek tek anlatıyorum.

Ödeme Modülünü "Bir Dosya" Sanmak Neden En Pahalı Hata?

Tipik senaryo şöyle işler: sepet sayfasında sağlayıcının form kodu vardır, dönüş sayfasında tutar kontrolü yapılır, başarılıysa doğrudan teslimat fonksiyonu çağrılır. Bu yapı test kartıyla mükemmel çalışır. Sorun, gerçek dünyanın test kartı gibi davranmamasıdır. Müşteri 3D Secure ekranında sekmeyi kapatır, ödeme banka tarafında başarılı olur ama dönüş sayfası hiç çalışmaz. Ya da callback iki kez gelir. Ya da müşteri ödeme yaptıktan sonra tarayıcı geri tuşuna basıp aynı formu yeniden gönderir. Ödeme mantığı sipariş akışının içine serpiştirilmişse bu senaryoların her biri ayrı bir yama ister ve yamalar birbirini bozar. Buna karşılık iyi tasarlanmış bir epin yazılım katmanında ödeme tek bir giriş ve tek bir çıkış noktasına sahiptir: ödeme niyeti oluşturulur, sonuç tek bir yerde değerlendirilir. Modülün değeri kaç sağlayıcıyı desteklediğinde değil, kaç farklı anormal senaryoyu tek bir kod yoluyla karşıladığındadır.

Gateway Soyutlaması: Neden Her Sağlayıcı Aynı Arayüze Bakmalı?

Soyutlama şu demek: sistemin geri kalanı hangi sağlayıcıyla çalıştığını bilmez. Ortada bir sözleşme vardır ve her sağlayıcı o sözleşmeyi uygular. Sözleşmenin dört fiili yeterlidir; ödeme başlat, sonucu doğrula, iade et, işlemi sorgula. Sipariş servisi yalnızca bu dört fiili çağırır. Böylece yeni bir sağlayıcı eklemek, yeni bir sınıf yazıp ayarlara bir satır koymak demektir; mevcut sipariş kodunda tek karakter değişmez. Soyutlamanın ikinci faydası testtir: sahte bir sağlayıcı yazıp tüm anormal senaryoları gerçek para harcamadan deneyebilirsin. Üçüncü faydası ise pazarlık gücü. Komisyon oranları değiştiğinde ya da bir sağlayıcı hesabını kapattığında geçiş maliyetin sıfıra yakınsa masaya güçlü oturursun. Pratikte bir e-pin satış yazılımı kurarken ilk günden en az iki sağlayıcı eklemek en sağlıklısıdır; tek sağlayıcıyla yazılan soyutlama neredeyse her zaman o sağlayıcıya göre şekillenmiş, sahte bir soyutlama olur.

Sipariş Durum Makinesi: Para Geldi Demek Teslim Edildi Demek Değildir

Ödeme mimarisinin kalbi burada atıyor. İki durumlu bir sistem kuran herkes ("beklemede" ve "tamamlandı") kaçınılmaz olarak duvara çarpar, çünkü gerçek hayatta paranın geldiği an ile kodun müşteriye ulaştığı an arasında bir boşluk vardır ve o boşlukta tedarikçi kesintisi, stok bitmesi, sahtekarlık kontrolü gibi olaylar yaşanır. "Ödendi" ile "Tamamlandı" ayrı iki durum olmalı ve aralarında "Teslim ediliyor" adımı bulunmalı. Bu ayrım sayesinde bir sorun çıktığında müşterinin parasının alındığını ama teslimatın beklemede olduğunu net biçimde raporlayabilirsin; "beklemede" yığınının içinde parası alınmışla alınmamışı ayırt edemediğin karmaşadan kurtulursun. İkinci kural: durum geçişleri tek yönlü ve kayıtlı olmalı. Her geçiş için zaman, tetikleyen kaynak ve gerekçe saklanmalı. Bir müşteri üç hafta sonra "ben bunu almadım" dediğinde elinde saniye saniye geçiş geçmişi olması, tartışmayı bitiren şeydir. Bu yüzden olgun bir e-pin scripti sipariş tablosunun yanında ayrı bir durum günlüğü tutar.

Callback mi Sorgulama mı? Otorite Kim?

Bu sorunun cevabı tek cümleyle verilir: otorite her zaman sağlayıcıya yapılan doğrulama sorgusudur, callback ise sadece bir tetikleyicidir. Nedeni basit. Callback ağ üzerinden gelir; gelmeyebilir, gecikebilir, iki kez gelebilir, hatta taklit edilebilir. Buna karşılık senin sağlayıcıya kendi sipariş referansınla sorduğun "bu işlemin durumu nedir" sorusunun cevabı manipüle edilemez. Doğru akış şöyle: callback geldiğinde imzasını doğrula, sonra sağlayıcıya sor, cevaba göre durumu değiştir. Callback hiç gelmezse ne olur? Tam da bu yüzden zamanlanmış bir toplayıcı işin olmalı; "ödeme bekleniyor" durumunda belirli süredir takılı kalmış siparişleri tarayıp her biri için aynı sorguyu çalıştırmalı. Bu iki mekanizma birlikte çalıştığında kayıp sipariş kavramı ortadan kalkar. Ayrıca müşterinin dönüş sayfasına hiç bakmamak gerekir; dönüş sayfası kullanıcıya bilgi vermek içindir, karar vermek için değil. Tarayıcıdan gelen bir parametreye bakarak sipariş tamamlayan bir e-pin satış scripti, adres çubuğunu düzenleyebilen herkese kapıyı açmış olur.

3D Secure, İade ve Ters İbraz: Modülün Görmediği Üç Kapı

Ödeme modülü genellikle "başarılı ödeme" yolu için yazılır ve geri dönüş yolları sonradan elle idare edilir. Oysa dijital ürün satan bir işletmede geri dönüş yolları en hassas alandır, çünkü teslim edilen kod geri alınamaz. 3D Secure tarafında kritik detay, doğrulama ekranında müşterinin kaybolduğu senaryoyu bir hata değil normal bir akış olarak modellemektir; sipariş "ödeme bekleniyor" durumunda kalır, toplayıcı iş sonucu öğrenir ve gerekirse teslimatı tamamlar. İade tarafında ise modülün sağlayıcıya iade çağrısı yapabilmesi şarttır; panelden elle iade yapmak, sistemdeki kaydın gerçekle ayrışmasına yol açar. Ters ibrazda ise her şey tek bir alana bağlıdır: sağlayıcı işlem kimliğini sipariş satırına yazdıysan, bankadan gelen itirazı saniyeler içinde siparişe, müşteriye, teslim edilen koda ve tedarikçi maliyetine bağlayabilirsin. Yazmadıysan tutarla tarih eşleştirmeye çalışır, aynı tutarda üç sipariş bulur ve hangisi olduğunu asla kesin bilemezsin. Dolayısıyla bu alan, e-pin yazılımı tarafında opsiyonel bir kolaylık değil zorunlu bir muhasebe köprüsüdür.

Çoklu Sağlayıcı ve Yönlendirme: Komisyonu Mimariyle Düşürmek

Soyutlama kurulduğunda ortaya güzel bir imkan çıkar: aynı anda birden fazla sağlayıcıyla çalışmak ve her siparişi en uygun kanala yönlendirmek. Küçük tutarlı siparişleri sabit ücreti düşük kanala, yüksek tutarlıları oran avantajı olan kanala gönderebilirsin. Bir sağlayıcı arıza verdiğinde diğerine otomatik düşerek satış kaybını engelleyebilirsin. Bayi ve toptancı ödemelerini havale/EFT ve cüzdan bakiyesiyle yürütüp kart komisyonunu tamamen devre dışı bırakabilirsin. Burada dikkat edilecek nokta, cüzdan bakiyesinin de tam bir ödeme yöntemi gibi modellenmesi: bakiyeyi doğrudan artırıp azaltmak yerine hareket kayıtları yazmak, bakiyeyi bu hareketlerin toplamından türetmek gerekir. Aksi halde bir hata sonrası bakiyenin doğru olup olmadığını hiçbir zaman ispatlayamazsın. Bu disiplin kurulduğunda dijital ürün satış yazılımı tarafında ödeme modülü bir maliyet kalemi olmaktan çıkıp kâr marjını doğrudan etkileyen bir kaldıraca dönüşür.

Ödeme modülü, işletmenin para ile temas ettiği tek yüzeydir; oradaki her mimari kısayol ileride müşteri şikayeti, kayıp sipariş veya muhasebe açığı olarak geri döner. Durum makinesinin sipariş ekranında nasıl göründüğünü, doğrulama sorgusunun log satırlarını ve sağlayıcı ekleme akışını incelemek istersen canlı demo üzerinden gez; sonra özellik listesini ve lisans paketlerini karşılaştırabilirsin.