Bakiye neden hesaplanan bir değer olmalı?
Bakiye, kullanıcı tablosunda güncellenen bir kolon değil; değişmez hareket kayıtlarının toplamı olarak hesaplanan bir değerdir. Kolon yaklaşımında eşzamanlı iki işlem birbirini ezebilir, hatalı bir güncelleme geri alınamaz ve "bu bakiye neden bu?" sorusunun cevabı bulunamaz. Hareket temelli defterde her değişikliğin bir kaynağı, tarihi ve karşı kaydı vardır.
Çift kayıtlı defterin pratik karşılığı
Her işlem en az iki satır üretir ve satırların toplamı sıfırdır: bir hesap borçlanırken diğeri alacaklanır. Bir cüzdan yüklemesinde kullanıcının cüzdan hesabı artarken, karşı tarafta banka/tahsilat hesabı artar. Bu yapı üç şeyi doğrudan sağlar:
- Sistem genelinde toplamın sıfır olması, bir tutarın "yoktan var olmasını" engeller.
- Her bakiye, kendisini oluşturan hareketlere kadar geri izlenebilir.
- Düzeltme, kaydı silmek yerine ters kayıt (storno) ile yapılır; geçmiş bozulmaz.
Performans için dönemsel bakiye özetleri tutulabilir; ancak özet, hareketlerden yeniden üretilebilir olmalıdır.
Para birimini kayan noktalı sayıyla tutmayın
Tutarlar tam sayı olarak, en küçük para biriminde (kuruş) veya sabit ondalıklı bir tipte saklanmalıdır. Kayan noktalı sayılar yuvarlama farkı üretir ve bu fark mutabakatta günler süren aramalara dönüşür. Ayrıca her tutarın yanında para birimi kodu saklanmalı; farklı para birimlerinin toplanması veri modeli seviyesinde engellenmelidir.
Yuvarlama kuralı da tek bir yerde tanımlanmalıdır: hangi adımda, hangi yöne, kaç basamak. Komisyon ve vergi hesaplarında yuvarlamanın sırası sonucu değiştirir.
İşlem tekrarı ve durum makinesi
Ödeme işlemleri belirli bir durum akışını izler: başlatıldı → yetkilendirildi → tahsil edildi → (iade / ters ibraz). Her geçiş, izin verilen önceki durumlarla birlikte tanımlanmalı ve geçersiz geçişler reddedilmelidir. Tekrarlanan isteklerin yeni işlem üretmemesi için işlem anahtarı kullanılır; bu konuyu API entegrasyonu rehberinde ayrıntılı ele alıyoruz.
Mutabakat: sistem kaydı ile sağlayıcı kaydı
Günlük mutabakat, sizin defterinizle ödeme sağlayıcısının/bankanın dosyasını karşılaştırır. Üç fark türü ayrı ele alınır:
- Sizde var, onlarda yok: çoğunlukla yanıtı kaybolmuş ama tamamlanmamış işlem.
- Onlarda var, sizde yok: kaçan bildirim; telafi için periyodik sorgulama gerekir.
- İkisinde de var, tutar farklı: komisyon, yuvarlama veya para birimi dönüşümü kaynaklı.
Mutabakat çıktısı otomatik kapanmayan kalemleri bir kuyruğa düşürmeli ve bu kuyruğun yaşı izlenmelidir. Tahsilat verisinin haftalık nakit tahminine nasıl bağlandığını nakit akışı rehberinde anlatıyoruz.
Kart verisi ve kapsam daraltma
En etkili güvenlik kararı, kart verisini hiç saklamamaktır. Ödeme sağlayıcısının barındırdığı alan veya cihaz üzerinde tokenizasyon kullanıldığında, hassas kart verisi sizin sisteminizden geçmez ve uyum kapsamı belirgin biçimde daralır. Bu bir sertifikasyon iddiası değil, mimari bir tercihtir; kapsamın nihai değerlendirmesi ilgili standardın gereklilikleri ve denetim süreciyle yapılır.
Kayıt ve izlenebilirlik
Finansal sistemlerde kayıt (log) bir ek özellik değil, işlevin parçasıdır. Kimin hangi işlemi hangi yetkiyle yaptığı, hangi değerin nereden neye değiştiği ve bu değişikliğin hangi talebe dayandığı saklanmalıdır. Kayıtlar değiştirilemez şekilde tutulmalı ve saklama süresi yazılı olmalıdır.
Sık sorulan sorular
Bakiye sorgusu hareket toplamıyla yapılırsa yavaşlamaz mı?
Yavaşlamaması için dönemsel kapanış bakiyeleri tutulur ve sorgu, son kapanıştan itibaren gelen hareketleri ekler. Böylece hem hız hem izlenebilirlik korunur.
Bir işlemi silmek gerekirse ne yapılır?
Silinmez. Ters kayıt oluşturulur ve orijinal kayıtla ilişkilendirilir. Finansal kayıtlarda geçmişi değiştirmek, denetlenebilirliği ortadan kaldırır.
Çoklu para birimi desteği ne zaman eklenmeli?
Veri modeline en baştan eklenmelidir: her tutarın yanında para birimi ve kur kaydı bulunmalıdır. Sonradan eklemek, mevcut tüm hareketlerin geriye dönük yorumlanmasını gerektirir.