Dijital Ürün Satış Yazılımında Ödeme Başarısız Olduğunda Siparişe Ne Oluyor? Kimsenin Konuşmadığı O Sessiz Kayıp Noktasını Açıklıyoruz

Satıcıların büyük kısmı başarısız ödemeyi bir son olarak görür: para geçmedi, sipariş olmadı, konu kapandı. Panelde bir yerde "başarısız" yazan bir satır durur, kimse ona bakmaz. Oysa o satırın arkasında rezerve edilmiş bir stok, yarı yolda kalmış bir müşteri, belki de birkaç saniye sonra gelip "bu işlem aslında başarılı" diyen bir banka bildirimi vardır. Başarısız ödeme bir son değil, en kırılgan ara durum.

Bu yazıda ödeme akışının çöktüğü anda siparişin hangi duruma düşmesi gerektiğini, stok rezervasyonunun ne kadar süre tutulacağını, geç gelen bildirimlerin neden çift teslimat ürettiğini ve müşteri ekranında ne yazması gerektiğini teknik ama uygulanabilir biçimde ele alıyoruz. Kendi e-pin satış scripti kurulumunda bu kontrollerden birkaçının eksik olduğunu göreceksin; iyi haber şu ki hepsi kapatılabilir.

"Ödeme başarısız" aslında tek bir durum değil

Tek bir hata etiketinin altına en az beş ayrı senaryo sıkıştırılıyor ve bunların hiçbiri aynı davranışı hak etmiyor. Kartın limiti yetmediyse müşteri başka kartla hemen tekrar deneyebilir; sipariş yaşatılmalı. Banka riskli işlem diyerek reddettiyse tekrar deneme büyük olasılıkla yine reddedilecek; sipariş kapatılıp kullanıcı alternatif yönteme yönlendirilmeli. Kullanıcı 3D ekranını kapattıysa ödeme hiç başlamamış gibi davranılmalı. Sağlayıcı zaman aşımına düştüyse işlemin gerçekte ne olduğu bilinmiyor demektir ve bu en tehlikeli hâldir.

Beşinci senaryo ise en pahalısı: ödeme başarılı ama teslimat başarısız. Para alındı, stokta uygun kod bulunamadı veya tedarikçi API'si cevap vermedi. Bu durumda sipariş ne "başarısız" ne "tamamlandı" olabilir; kendi başına bir durum ister. Bunları tek etiketle yönetmeye kalkan bir dijital ürün satış yazılımı, ay sonunda muhasebe ile teslimat kayıtlarının uyuşmadığı bir yığın bırakır geride.

Siparişi ödeme öncesi oluşturmak mı, sonra mı?

Bu tercih, başarısız ödeme davranışının tamamını belirler. Siparişi ödemeden sonra oluşturan kurgular basit görünür ama başarısız denemeler hakkında hiçbir veri bırakmaz; kaç kişinin ödeme adımında düştüğünü, hangi kartın reddedildiğini, hangi ürünü almak istediğini bilemezsin. Terk edilmiş sepet kurtarma, hata analizi, dolandırıcılık tespiti gibi her şey kör kalır.

Doğru yaklaşım siparişi ödeme öncesinde taslak olarak açmaktır. Taslak sipariş stok rezerve eder, ödeme girişimlerini kendi altında biriktirir ve süresi doldurulduğunda otomatik temizlenir. Böylece tek bir sipariş kaydına bağlı üç dört ödeme denemesi görürsün: ilki limitten reddedildi, ikincisi başka kartla başarılı. Bu geçmiş hem destek ekibinin işini kolaylaştırır hem de kullanıcının yeni bir sipariş numarası almadan devam etmesini sağlar. Sağlam bir e-pin scripti mimarisinde sipariş ile ödeme girişimi ayrı iki tablo olmalı; tek tabloya sıkıştırılan her kurgu ilk çoklu denemede kirlenir.

Stok rezervasyonu: e-pin stoğunu kim, ne kadar süre tutar?

Dijital stok sanıldığı gibi sınırsız değil. Elindeki kod havuzu sonlu ve bir kodun iki kişiye satılması geri dönüşü olmayan bir hata. Bu yüzden ödeme adımına giren kullanıcı için stoktan somut bir kod ayrılmalı. Ancak bu ayırma süresiz olamaz; aksi halde ödemeyi terk eden onlarca kullanıcı stoğu kilitler ve vitrin "tükendi" gösterirken depoda kod durur. Buna hayalet tükenme denir ve kampanya dönemlerinde ciroyu doğrudan keser.

İşleyen kurgu üç parçalı. Birincisi rezervasyona süre koymak: on beş ile otuz dakika arası yeterlidir. İkincisi süresi geçen rezervasyonları toplayan bir zamanlanmış görev çalıştırmak; bu görev çalışmıyorsa rezervasyon mantığı hiç yoksa daha kötüdür. Üçüncüsü rezervasyonu kodun kendisine değil kod havuzundaki bir yuvaya bağlamak, böylece teslimat anına kadar hangi kodun gideceği kesinleşmez ve kod, ödeme tamamlanmadan hiçbir yere yazılmaz. Bu detay, başarısız ödemelerde sızan kod vakalarının neredeyse tamamını ortadan kaldırır.

Bildirim geç geldiğinde ne olur? Idempotency meselesi

Ödeme sağlayıcıları sonucu iki kanaldan bildirir: kullanıcının tarayıcısıyla dönen sayfa ve sunucudan sunucuya gelen bildirim. Bu ikisi sıraları karışarak, tekrarlanarak ve bazen dakikalar sonra gelir. Buradaki altın kural nettir: otorite sunucu bildirimidir, tarayıcı dönüşü yalnızca kullanıcıya ekran göstermek içindir. Tarayıcı dönüşüne bakıp teslimat yapan bir kurgu, adres satırıyla oynayan birine bedava kod verir.

İkinci kural mükerrerliğe dayanıklılık. Aynı bildirim üç kez gelebilir; sistem birinci gelişte siparişi tamamlamalı, ikinci ve üçüncüde hiçbir şey yapmamalı. Bu, her ödeme girişimine eşsiz bir referans vermek ve durum geçişlerini veritabanı kilidi altında tek yönlü yapmakla sağlanır. "Tamamlandı" durumundaki bir sipariş bir daha teslimat tetiklemez, e-posta göndermez, stok düşmez. Bir de tersi vardır: sipariş zaman aşımıyla "reddedildi" yazılmışken beş dakika sonra başarılı bildirimi gelir. Bu durumda sipariş otomatik tamamlanmamalı, incelemede durumuna alınıp operatöre bildirilmeli; para alınmış ama ürün verilmemiş bir kayıt asla sessizce kapanmamalı.

Müşteri ekranında ne yazmalı? Belirsizliğin dönüşüm maliyeti

Teknik tarafı düzgün kurup ekranda "İşlem başarısız" yazan tek satırla kalmak, kazandığın her şeyi geri vermektir. İlk denemesi başarısız olan kullanıcıların önemli bir kısmı ikinci denemede ödüyor; onları kaybetmenin sebebi genelde kartı değil, ne yapacağını bilmemesi. Mesaj üç şeyi söylemeli: ne olduğu, paranın durumu, sıradaki adım. "Bankan işlemi onaylamadı. Hesabından para çekilmedi. Başka bir kartla deneyebilir veya havale ile ödeyebilirsin."

Zaman aşımı senaryosunda dil tamamen değişmeli. Orada yanlış bilgi vermek en büyük risk, çünkü para gerçekten çekilmiş olabilir. "İşlemin doğrulanıyor, sonucu birkaç dakika içinde e-posta ile bildireceğiz" demek ve o süre boyunca tekrar ödeme düğmesini kilitlemek doğru davranıştır. Aksi halde endişelenen kullanıcı üst üste dener, üç kez çekim yapılır ve elinde üç ayrı iade süreci olan bir müşteri hizmetleri kâbusu bulursun. Bu akışların nasıl kurgulandığını özellik listesinde görebilir, hangi durumda hangi bildirimin gittiğini kendi ihtiyacına göre ayarlayabilirsin.

Sipariş durum makinesini nasıl denetlersin?

Durumları listelemek yetmez, aralarındaki izinli geçişleri de yazmak gerekir. Taslaktan ödeme bekleniyora, oradan tamamlandıya veya reddedildiye geçilebilir; ama tamamlandıdan taslağa dönüş olamaz. Bu geçiş haritası kodda tek bir yerde tanımlanmalı ve her durum değişikliği oradan geçmelidir. Panelde elle durum değiştirme yetkisi varsa, o da aynı haritaya uymalı; operatörün iki tıkla imkânsız bir duruma atlayabildiği bir sistem raporlarını bozar.

Yanına bir de değişmez günlük koy: her geçişin zamanı, sebebi, tetikleyicisi ve sağlayıcıdan gelen ham cevap saklanmalı. Bir kullanıcı üç ay sonra "param gitti ürün gelmedi" dediğinde bu günlük olmadan tartışmayı kazanamazsın. Haftalık denetim sorgun da basit olmalı: ödemesi alınmış ama teslimatı olmayan siparişler, teslimatı yapılmış ama ödemesi doğrulanmamış siparişler ve süresi geçmiş rezervasyonlar. Bu üç listenin boş olması, sistemin sağlıklı çalıştığının en somut kanıtı. Paket seçimini yaparken bu denetim ekranlarının hazır gelip gelmediğini sormak, sonradan geliştirici maliyetiyle uğraşmaktan iyidir.

Başarısız ödeme, doğru kurgulandığında kayıp değil ikinci şans; yanlış kurgulandığında ise hem stoğunu kilitleyen hem müşterini kaçıran hem de muhasebeni bozan üç katlı bir sorun. Taslak siparişi aç, rezervasyona süre koy, otoriteyi sunucu bildirimine ver, mükerrerliğe dayanıklı ol ve haftalık üç denetim listesini boş tut. Bu davranışların tamamının tek bir kurulumda nasıl birleştiğini görmek istersen canlı demo içinde bilerek başarısız bir ödeme denemesi yapıp siparişin hangi duruma düştüğünü, hangi bildirimin gittiğini ve stoğun ne zaman serbest kaldığını adım adım izleyebilirsin.