Ödeme sistemi nasıl tasarlanır? Sahadan backend rehberi

Idempotency, aynı istek bir kez de gelse on kez de gelse sistemde bıraktığı etkinin aynı kalmasıdır. Ödeme API'lerinde bir adım fazlası gerekir: ikinci istek, ilk isteğin cevabını da almalı. Tekrarı yalnızca reddeden bir sistem parayı korur ama kullanıcıyı korumaz; parası çekilen kullanıcı ekranda "işlem başarısız" görür.

Tekrar yalnızca çift tıklamadan gelmez: istemci, gateway, mesaj kuyruğu ve arka plan işleri de aynı ödemeyi yeniden gönderir. Yazıda kilidin neden yetmediğini, idempotency key ile saklanan cevabı, consumer tarafındaki tekrarı ve bankadan hiç cevap gelmediğinde ödemeyi hangi durumda tutacağını anlatıyorum.

Sunucuda idempotency'yi kursan bile istemci her tıklamada yeni bir anahtar üretiyorsa hiçbir şey korunmaz: iki tıklama, iki anahtar, iki ödeme. Kısa cevap: anahtar butona basışta değil, ödeme niyeti oluştuğu anda, yani ödeme ekranı açılırken üretilir.

Tutarın ya da taksidin ekranda değişebildiği akışlarda anahtar snapshot anında doğar; aynı anahtarla farklı gövde gelirse sunucu 422 döner. Sayfa yenilemesine karşı korumayı anahtara yüklemek yerine ekran açılırken siparişin ödenip ödenmediğini sormak daha sağlam. Yazıda bunun koddaki hali ve ağ sekmesinden nasıl fark edileceği var.

Ödeme kaydedildi, sıra bildirimde ya da bir sonraki adımda. Bu yan etkiyi isteğin içinde yaparsan kullanıcı mail sunucusunu bekler; hata verirse ya işlemi boşuna başarısız sayarsın ya da sessizce kaybedersin. Outbox pattern, yapılacak işi iş verisiyle aynı transaction'da bir tabloya yazmak ve ayrı bir süreçle oradan işlemektir; ikisi ya birlikte kaydedilir ya hiç.

Yazıda outbox'ı broker'ın önünde bir ara durak olarak değil, RabbitMQ yokken kuyruğun kendisi olarak kullanmayı anlatıyorum: EF Core tablosu ve BackgroundService ile. Tablo kuyruğa dönüşünce kuyruğun dertleri de gelir: aynı satırı iki işçinin alması, başarısız işler ve sonucu belirsiz kalan para çıkışı gibi hiç tekrar denenmemesi gereken işler.

Kart numarasını her endpoint'te regex'le maskelemek yaygın yöntem; çağırmayı unutan tek bir endpoint numarayı log'a açık düşürür. Log maskeleme, hassas değeri log'a yazılmadan önce okunamaz hale getirmektir; kartta genelde ilk 6 ve son 4 hane kalır. Sorun maskelemenin kendisi değil, birinin hatırlamasına bağlı olması.

Önerim varsayılanı tersine çevirmek: kart numarası string olarak dolaşmasın, ToString'i her zaman maskeli dönen kendi tipini taşısın; açık değer yalnızca bankaya giden istekte, adıyla çağrılan bir metotla alınsın. .NET'in Redaction aracı iyi bir katman ama tek başına yetmiyor; regex'in doğru yeri, entegrasyon testinde bütün log çıktısını tarayan son kontrol.

IDOR, giriş yapmış bir kullanıcının istekteki id'yi değiştirerek başkasının kaydına erişebilmesidir. Token geçerli, [Authorize] yerinde, rol kontrolü geçiyor; ama kimse "bu kart bu kişiye mi ait" diye sormuyor. Kimlik doğrulama "kimsin" der, aitlik "bu senin mi" diye sorar; ikisi ayrı kontroldür ve ikisinin de geçmesi gerekir.

Herkes id'yi kontrol etmesi gerektiğini bilir; asıl soru bu kontrolü, yarın yeni bir endpoint yazan birinin unutamayacağı yere nasıl koyacağın. Yazıda kaynağın sahibini entity'nin kendisine söyleten yapıyı, token'da taşınan hiyerarşik aitliği, body'deki sahip id'sine neden güvenilmeyeceğini ve 403 ile 404 arasındaki seçimi anlatıyorum.