Aynı Ödeme Bildirimi Neden Birden Fazla Kez Gelebilir?
Bir e-ticaret sitesinde ödeme süreci, müşterinin gördüğü “Ödeme Başarılı” ekranından ibaret değildir.
Ödeme sağlayıcısı sonucu ayrıca sunucular arasında gerçekleşen bir callback veya webhook bildirimiyle e-ticaret yazılımına iletebilir.
Burada önemli bir ayrım vardır:
Aynı callback'in iki kez gelmesi, müşterinin kartından iki kez para çekildiği anlamına gelmez.
Asıl risk, e-ticaret yazılımının aynı başarılı ödeme olayını ikinci kez yeni bir işlemmiş gibi değerlendirmesidir.
Örneğin ilk bildirim sonrasında sistem:
Sipariş → Ödeme → Fatura → Hizmet Aktivasyonu
zincirini tamamlamış olabilir.
Aynı bildirim tekrar geldiğinde yeterli kontrol yoksa sipariş, ödeme veya hizmet hazırlama süreçleri yeniden çalışabilir.
IHASHOP'ta Ele Aldığımız Gerçek Problem
IHASHOP ödeme altyapısını geliştirirken yalnızca “ödeme başarılı mı?” sorusuna odaklanmadık.
Asıl sorumuz şuydu:
Aynı ödeme olayı sisteme birden fazla kez ulaşırsa sonuç değişecek mi?
Hedefimiz, aynı olayın kaç kez gelirse gelsin yalnızca bir kez ticari sonuç üretmesiydi.
Bu nedenle aşağıdaki zincirin tamamını kontrol ettik:
Sepet → Sipariş → Fatura → Ödeme → Hizmet Hazırlığı
Yalnızca ikinci bir ödeme kaydını değil;
- aynı sepetten ikinci sipariş oluşmasını,
- aynı siparişin tekrar ödenmiş gibi işlenmesini,
- aynı callback'in yeniden finalizasyon yapmasını,
- manuel ödemenin ikinci kez onaylanmasını,
- aynı hizmet hazırlama görevlerinin tekrar oluşturulmasını
engelleyecek kontroller uyguladık.
Idempotency Nedir?
Bu yaklaşımın temelinde idempotency bulunur.
Basitçe ifade edersek:
Aynı işlem tekrar çalıştırıldığında sistemde yeni veya mükerrer bir sonuç oluşmuyorsa işlem idempotent davranıyor demektir.
Ödeme sistemindeki beklenen davranış şöyledir:
İlk bildirim:
Ödeme başarılı → sipariş güncellendi.
Aynı bildirim tekrar geldiğinde:
Bu ödeme zaten işlendi → yeni işlem oluşturma.
Temel prensip:
Aynı ödeme olayı sisteme kaç kez ulaşırsa ulaşsın, aynı ticari işlem yalnızca bir kez sonuç üretmelidir.
1. Aynı Sepetten İkinci Sipariş Oluşmasını Önledik
Duplicate işlem riski ödeme sağlayıcısından önce bile başlayabilir.
Kullanıcı ödeme butonuna iki kez basabilir, sayfayı yenileyebilir veya tarayıcı aynı isteği yeniden gönderebilir.
Bu nedenle IHASHOP'ta siparişe dönüştürülen bir sepetin aynı dönüşüm sürecine tekrar alınmaması gerekir.
Böylece aynı alışveriş niyetinden ikinci bir sipariş oluşmasının önüne geçilir.
2. Sipariş, Fatura ve Ödeme Bütünlüğünü Koruduk
Ödeme sistemlerinde yalnızca duplicate kayıt değil, yarım kalan işlemler de risk oluşturur.
Örneğin sipariş oluşup fatura oluşmazsa veya ödeme kaydı tamamlanmadan süreç kesilirse ticari kayıtlar birbirinden kopabilir.
Bu nedenle ilgili işlemleri kontrollü bir işlem zinciri içerisinde yürütmek önemlidir.
Amaç:
Ya işlem bütün olarak tamamlanmalı ya da sistem yarım ticari kayıt bırakmamalıdır.
Ödeme güvenliğinde yalnızca “para alındı mı?” değil, sipariş, fatura ve ödeme kayıtları birbiriyle tutarlı mı? sorusu da önemlidir.
3. Ödenmiş Siparişi İkinci Kez İşlemiyoruz
Duplicate callback'e karşı en önemli kontrollerden biri mevcut ödeme durumudur.
Bir sipariş zaten başarıyla paid durumuna geçmişse aynı ödeme bildiriminin yeniden gelmesi yeni bir ticari işlem değildir.
Bu nedenle sistem önce mevcut durumu kontrol eder.
Sipariş zaten ödenmişse:
- yeni ödeme oluşturulmaz,
- sipariş yeniden işlenmez,
- ödeme tekrar finalize edilmez,
- hizmet aktivasyonu ikinci kez başlatılmaz.
Bu erken kontrol, mükerrer işlemlere karşı en temel koruma katmanlarından biridir.
4. Koruma Ödeme Kaydıyla Sınırlı Değil
Duplicate ödeme riskinde yalnızca payment kaydını korumak yeterli değildir.
Başarılı ödeme sonrasında;
- lisans aktivasyonu,
- domain işlemleri,
- hosting hazırlığı,
- tema veya modül hakkı,
- sipariş teslimat görevleri
gibi başka operasyonlar da başlayabilir.
İkinci ödeme kaydını engellesek bile bu operasyonlar tekrar tetikleniyorsa sistem hâlâ mükerrer sonuç üretebilir.
Bu nedenle IHASHOP'ta duplicate korumasını ödeme katmanından hizmet hazırlama süreçlerine kadar devam ettirdik.
5. Manuel Ödemelerde de Aynı Kural Geçerli
Banka havalesi gibi manuel onay gerektiren ödeme yöntemlerinde de aynı risk vardır.
Bir ödeme admin tarafından onaylandıktan sonra aynı onay işleminin tekrar çalıştırılması ikinci bir hizmet aktivasyonu oluşturmamalıdır.
Bu nedenle temel kural ödeme yönteminden bağımsızdır:
Bir ödeme ister otomatik callback ile ister manuel onayla kesinleşsin, aynı ticari olay ikinci kez sonuç üretmemelidir.
Neden Sadece “Ödeme Başarılı” Sayfasına Güvenilmez?
Müşterinin ödeme sonrasında gördüğü başarı sayfası kullanıcı deneyiminin bir parçasıdır, ancak tek başına ödeme otoritesi olmamalıdır.
Çünkü kullanıcı:
- tarayıcıyı kapatabilir,
- bağlantısını kaybedebilir,
- yönlendirmeyi tamamlayamayabilir,
- başarı sayfasını tekrar açabilir.
Bu nedenle ödeme durumu mümkün olduğunca ödeme sağlayıcısından gelen doğrulanmış sunucu bildirimi ve sistemdeki gerçek ödeme durumu üzerinden kesinleştirilmelidir.
Bunun Mağaza Sahibi İçin Önemi Nedir?
Bu teknik kontroller müşterinin doğrudan gördüğü özellikler değildir. Ancak etkileri doğrudan işletmeye yansır.
Sağlam bir ödeme yaşam döngüsü;
- doğru sipariş durumu,
- tutarlı fatura kayıtları,
- mükerrer hizmet aktivasyonlarının önlenmesi,
- gereksiz müşteri bildirimlerinin azaltılması,
- daha temiz muhasebe kayıtları,
- daha az destek talebi
anlamına gelir.
Bu nedenle idempotency yalnızca geliştiriciler için teknik bir kavram değildir.
Güvenilir ödeme ve sipariş yönetiminin temel parçalarından biridir.
IHASHOP'ta Ödeme Güvenliğine Yaklaşımımız
IHASHOP'ta ödeme güvenliğini tek bir kontrol olarak ele almıyoruz.
Ödeme yaşam döngüsünün farklı noktalarında;
- aynı sepetin ikinci kez siparişe dönüşmesini,
- sipariş, fatura ve ödeme kayıtlarının birbirinden kopmasını,
- tamamlanmış ödemenin tekrar işlenmesini,
- duplicate callback'in ikinci ticari işlem üretmesini,
- manuel onayın tekrar çalışmasını,
- hizmet hazırlama görevlerinin mükerrer oluşmasını
engelleyecek kontroller uyguluyoruz.
Amaç çok basit:
Sistem tekrar eden istekler karşısında tahmin edilebilir ve güvenli davranmalıdır.
E-Ticaret Yazılımınızı Seçerken Şu Soruları Sorun
Ödeme altyapısını değerlendirirken yalnızca hangi ödeme kuruluşlarının desteklendiğine bakmak yeterli değildir.
Şunları da sorun:
- Aynı callback iki kez gelirse ne oluyor?
- Aynı sipariş için ikinci ödeme kaydı oluşabiliyor mu?
- Kullanıcı ödeme butonuna iki kez basarsa ne oluyor?
- Ödenmiş sipariş yeniden işlenebiliyor mu?
- Hizmet aktivasyonu ikinci kez tetiklenebiliyor mu?
- Sipariş, ödeme ve fatura kayıtları birbiriyle tutarlı mı?
Bu sorular, ödeme altyapısının gerçek kalitesi hakkında oldukça önemli ipuçları verir.
Sonuç
E-ticarette ödeme güvenliği yalnızca kart bilgilerinin korunması değildir.
Ödeme başarılı olduktan sonra sistemin aynı olaya nasıl tepki verdiği de en az ödeme ekranı kadar önemlidir.
IHASHOP ödeme altyapısında temel prensibimiz şudur:
Aynı ödeme olayı sisteme kaç kez ulaşırsa ulaşsın, aynı ticari işlem yalnızca bir kez sonuç üretmelidir.
Sepetten siparişe, ödeme finalizasyonundan hizmet hazırlığına kadar uygulanan idempotency ve bütünlük kontrolleri, daha güvenilir bir ödeme deneyiminin temelini oluşturur.