Fintech Yazılımı

Para hareketi taşıyan uygulamalarda asıl mesele ekran değil, defterdir. Bu platform; ödeme, cüzdan, ön ödemeli bakiye ve tahsilat süreçlerini çift kayıtlı bir defter, idempotent işlem akışı ve açık bir durum makinesi üzerine kurar.

Finansal akış taşıyan sistemlerde en pahalı hatalar şunlardır:

• Bakiyenin tek alanda güncellenmesi. Hareket geçmişi olmadığında fark analizi yapılamaz, denetim izi kaybolur.
• Yanıtsız işlemin başarısız sayılması. Karşı tarafta gerçekleşmiş bir işlem sizde iptal görünür; bu, çift tahsilat ve müşteri itirazının ana kaynağıdır.
• Tekrarlanan isteğin çift kayıt üretmesi. Ağ hatasında istemci isteği yeniden gönderir; idempotency anahtarı yoksa ikinci kayıt oluşur.

Her para hareketi en az iki satır üretir: borç ve alacak. Bakiye, bu satırların toplamıdır; ayrı bir alanda tutulmaz. Böylece "bakiye neden bu?" sorusu her zaman hareket listesiyle yanıtlanabilir.

Her dış çağrı bir idempotency anahtarı taşır. Aynı anahtarla gelen ikinci istek yeni kayıt üretmez, ilk isteğin sonucunu döndürür. Ayrıntısını API entegrasyonunda idempotency rehberinde anlatıyoruz.

İşlem durumları arasında "yanıt alınamadı" ayrı bir durumdur ve otomatik olarak başarısız sayılmaz. Bu kayıtlar, karşı taraftan alınan mutabakat dosyasıyla kapatılır.

• Defter: hesap planı, borç/alacak satırları, dönem kapanışı, çoklu para birimi.
• Ödeme: sanal POS, taksit, kısmi iade, iade referansı, 3D akışı.
• Cüzdan / ön ödemeli bakiye: yükleme, harcama, blokaj, iade ve bakiye limiti.
• Mutabakat: banka ve ödeme kuruluşu dosyalarının eşleştirilmesi, fark listesi.
• Komisyon ve kesinti: komisyon, blokaj ve valör farkının ayrı kalemler olarak kaydı.
• Yetki ve denetim: rol bazlı erişim, veri kapsamı ve silinemez denetim kaydı.

Banka hesap hareketi ve tahsilat kanalları (banka entegrasyonu), sanal POS ve ödeme kuruluşları, e-belge sistemleri, muhasebe ve ERP, kimlik doğrulama servisleri ve kurumsal uygulamalar için API entegrasyon katmanı.

• Hassas alanlarda alan bazlı şifreleme; kart verisi token ile değiştirilir.
• Yetkilendirme rol bazlı yetkinin yanı sıra veri kapsamı ile sınırlandırılır.
• Denetim kaydı ayrı ve değiştirilemez biçimde tutulur.
• Dış servis çağrılarında zaman aşımı, yeniden deneme ve devre kesici (circuit breaker) davranışı tanımlıdır.
• Webhook doğrulaması imza kontrolü ile yapılır; tekrar gönderim (replay) reddedilir.

Uyum kapsamı hakkında: Kart verisi güvenliği ve finansal mevzuat gereklilikleri; işin niteliğine, hangi tarafın hangi veriyi tuttuğuna ve lisans durumuna göre değişir. Bu nedenle uyum kapsamı ve hangi yükümlülüğün kimde olduğu proje başında yazılı olarak tanımlanır. Yazılımın tek başına bir uyum belgesi sağlamadığını baştan söylüyoruz.

• Ön ödemeli bakiye / cüzdan: yükleme, harcama ve iade akışının denetlenebilir defterle izlenmesi.
• Tahsilat platformu: çoklu kanaldan gelen tahsilatın cari hesapla otomatik eşleşmesi.
• Bayi/abonelik tahsilatı: yinelenen ödeme, başarısız çekim yönetimi ve yeniden deneme politikası.
• Pazar yeri ödeme akışı: satıcı hakedişi, komisyon kesintisi ve ödeme günü hesabı.

1. Defter ve kimlik: hesap planı, durum makinesi, idempotency kuralı.
2. Kanal bağlantıları: sanal POS, banka, iade ve kısmi iade akışları.
3. Mutabakat: dosya ayrıştırma, eşleştirme kuralları, fark listesi.
4. Raporlama: komisyon kontrolü, alacak yaşlandırma, nakit projeksiyonu.

Kart verisini sistemde saklıyor musunuz?

Varsayılan tasarım kart verisini saklamamaktır: ödeme kuruluşundan dönen token saklanır. Kart verisinin sistemde tutulması gerektiği durumlarda bu, kapsamı ve sorumluluğu değiştirir ve proje başında ayrıca kararlaştırılır.

"Tam olarak bir kez" işlem garantisi verilebilir mi?

Dağıtık sistemlerde hayır. Gerçekçi hedef, isteğin en az bir kez ulaşması ve alıcının aynı isteği ikinci kez işlememesidir. Bunu idempotency anahtarı ve durum makinesi sağlar.

Mutabakat farkları nasıl sınıflandırılır?

Üç grupta: bizde var onlarda yok (yanıtı kaybolan işlem), onlarda var bizde yok (kaçırılan bildirim), ikisinde de var tutar farklı (komisyon, yuvarlama, kur). Her birinin ayrı çözüm yolu vardır; ayrıntısı banka entegrasyonu rehberinde.

Mevcut muhasebe sistemimizle nasıl çalışır?

Defter, muhasebenin yerine geçmez; muhasebeye aktarılacak fişleri üretir. Aktarım periyodu ve hangi kırılımda fiş üretileceği proje başında tanımlanır.