Fintech launch öncesi yakaladığım 7 sessiz payment bug'ı

Fintech bug'ları diğer bug'lardan daha pahalı. Bozuk bir signup formu utanç verici. Bozuk bir checkout butonu kayıp gelir. Ama kullanıcıdan sessizce iki kez para alan, yetkisiz transfer geçmesine izin veren veya EUR→USD çevirmede sessizce decimal düşüren bir bug — bu regülasyon olayı, müşteri güveni çöküşü ve potansiyel 6 haneli iade operasyonu demek.

Son 3 yılda Avrupa, Türkiye ve ABD'deki fintech, e-ticaret ve marketplace'lerin payment akışlarını denetledim. Bunlar sürekli karşıma çıkan 7 bug — code review'u geçen, internal QA'ı geçen ve yine de production'a sızan türler.

Önümüzdeki 90 gün içinde fintech ürünü launch ediyorsan, bunu her kurucunun kullanmasını istediğim pre-launch checklist olarak gör.

(Müşteri gizliliği için aşağıdaki her örnek anonimleştirildi ve spesifikler değiştirildi.)

Bug #1 — Stripe webhook race condition

Ne olur: Kullanıcı "Öde"ye tıklar. Stripe charge'ı başarıyla işler. Stripe backend'ine payment_intent.succeeded webhook'unu fırlatır. Backend sipariş'i "paid" işaretler. Ama Stripe kullanıcıyı success URL'ine de geri gönderir — ve o handler da sipariş'i "paid" işaretlemeye çalışır. Zamanlamaya göre, duplicate side-effect'ler ortaya çıkar: iki kez gönderilmiş confirmation email, iki kez düşmüş envanter, iki kez eklenmiş puan.

Neden kaçar: Staging'de Stripe test modu olayları race'i yeniden üretemeyecek kadar hızlı veya yavaş fırlatır. Her şey dev'de çalışır. Production'da, gerçek latency ile fırlar.

Test case: Webhook endpoint'inde 2-3 saniyelik gecikme simüle et. Duplicate side-effect'leri izle. Fix: her side-effect handler'ında idempotency key.

Bug #2 — 3DS redirect loop

Ne olur: Kullanıcı mobil tarayıcıda. "Öde"ye dokunur. 3D Secure challenge yeni sekmede açılır (veya daha kötüsü, iframe'de). Doğrular, geri döner — ve orijinal sekme sonsuz loading spinner'ı gösterir çünkü return URL, pencere focus kazandıktan sonra fırladı ve state'in temizlenmişti.

Neden kaçar: Staging'deki desktop Chrome'da akış mükemmel çalışır. Bug sadece gerçek mobil Safari'de ortaya çıkar — iframe handling ve sekme state farklıdır.

Test case: Her payment akışını gerçek iPhone'da Safari ile tamamla, desktop emülatör değil. Her seferinde challenge zorlayan 3DS test kartları kullan.

Bug #3 — Currency conversion'da decimal rounding

Ne olur: EUR'da charge ediyorsun ama backend internal olarak USD saklıyor. price * 1.0847 conversion'u 43.5094819... gibi float oluşturur. 2 decimal'e truncate edip 43.50 saklarsın. Sonra kullanıcıyı refund ettiğinde, 43.50 USD iade edersin → EUR'a geri çevir → kullanıcı €40.09 alır €40.10 yerine. 1 cent kayıp. Yılda 50.000 iade ile çarp.

Neden kaçar: Unit test'ler $100.00 gibi yuvarlak sayı kullanır. Bug sadece dağınık gerçek dünya tutarlarıyla ortaya çıkar.

Test case: Her currency conversion'da €43.57, £22.03, $19.99 gibi tutarlarla test et. Charge ve refund miktarı arasındaki herhangi bir sapma bug'dır.

Bug #4 — Kısmi 2FA bypass

Ne olur: Login akışı email + şifre + 2FA ister. Kullanıcı email ve şifre girer. Backend *kısmi oturum* oluşturur (sadece bir flag), 2FA beklenirken. Kullanıcı sekmeyi terk eder. Saldırgan kullanıcının cookie'sini bir şekilde ele geçirir (XSS, cihaz paylaşımı, cookie hırsızlığı). Saldırgan kısmi oturum cookie'si ile 2FA ekranına düşer — ama belirli bir API endpoint'i, mesela /api/profile, sadece kısmi oturum flag'ini kontrol eder ve tam profil verisini döner.

Neden kaçar: 2FA ekranı güvenlidir. Geliştirici "kısmi oturumun arkasında başka ne var?" diye düşünmedi.

Test case: Tüm API endpoint'lerini listele. Her biri için kısmi oturum cookie'si ile test et. Tam 2FA bitmeden gerçek veri döndüren herhangi bir endpoint critical bug.

Bug #5 — Sessiz kart depolama downgrade'i

Ne olur: Kullanıcı recurring billing için kart ekler. Frontend'in tokenization için Stripe'a gönderir — ama bir geliştirici error handling eklemiş: fail olursa, kartı backend'ine "geçici" olarak post edip sonra tekrar denemek üzere. Şimdi PCI DSS kapsamı olmadan ham kart verisi saklıyorsun — leak = felaket.

Neden kaçar: Code path sadece tokenization fail'lerinde çalışır, test'te nadir. Log'larda her şey compliant görünür.

Test case: Stripe tokenization'ı fail olmaya zorla (geçersiz API key, network block, Stripe test error kartları). Tüm giden network request'leri izle. Hiçbir şey ham kart verisiyle browser'dan PCI-uyumlu tokenizer'a gitmeden çıkmamalı.

Bug #6 — Webhook replay zafiyeti

Ne olur: Stripe webhook endpoint'in signature header'ını doğrulamıyor. Endpoint URL'ini bulan saldırgan (kolay — çoğu zaman frontend bundle log'larında veya eski email'lerde var) herhangi bir tutar ve müşteri ID'si ile sahte payment_intent.succeeded olayı POST edebilir. Backend'in gerçekte ödenmemiş bir siparişi "paid" işaretler.

Neden kaçar: Her şey meşru webhook olayları için çalışır çünkü Stripe onları imzalar. Doğrulama kodu sadece unutulmuş.

Test case: Geçerli signature olmadan hazırlanmış webhook payload'u POST et. Backend kabul edip "ödeme"yi işlerse critical bug. Tüm webhook endpoint'leri imzasız istekler için 403 dönmeli.

Bug #7 — Timezone kaynaklı duplicate charge

Ne olur: Billing sistemin UTC üzerinde çalışır. İstanbul'da (UTC+3) kullanıcı gece 11'de signup olur, UTC 20:00 demek. Billing günlük UTC gece yarısı çalışır. İlk charge: ertesi gün İstanbul saati 04:00'da. Ama kullanıcıya "deneme 7 gün sonra bitiyor" mesajı 11pm dedi. Deneme hâlâ aktif gören kullanıcı ürünü kullanır. Sonra 7. günün UTC gece yarısında charge edilir. Sonra 7. günün İstanbul 11pm'inde (ki UTC ertesi gün 20:00) "deneme bitti" job'ı tekrar çalışır ve ikinci kez charge eder.

Neden kaçar: Ekibin tamamı aynı timezone'da ve drift'i hiç fark etmez. Unit test'ler referans timezone olmadan new Date() kullanır.

Test case: 5+ farklı timezone'da (UTC-8, UTC-3, UTC+0, UTC+3, UTC+9) test kullanıcıları oluştur. Tam billing yaşam döngüsünü çalıştır. Kullanıcının algıladığı zaman çizelgesi ve gerçekten charge edildiği şey arasındaki herhangi bir fark bug.

7 bug'ın arkasındaki ders

Bu listedeki her bug'ın üç ortak özelliği var:

1. Kod dev'de çalışıyor. Sadece production koşullarında kırılıyor — latency, gerçek cihazlar, gerçek veri, gerçek timezone'lar. 2. Code review yakalamazdı. Tek tek satırlar doğru görünüyor. Bug sistemler arasındaki etkileşimde yaşıyor. 3. Regülasyon sonuçları bug'ın kendisinden daha kötü. Her biri, production'da, çalıştığım bir şirkette ya PCI olayı, ya veri ihlali bildirimi ya da toplu iade operasyonu tetiklemiş.

Fintech QA'ın jenerik QA'dan farkı bu. Butonun çalışıp çalışmadığını test etmiyorsun. Para hesabı sistemler yalan söylediğinde, network'ler geciktiğinde ve kullanıcılar beklenmedik şeyler yaptığında ayakta kalıyor mu, onu test ediyorsun.

Testopius'ta Fintech QA Audit özellikle bu failure mode'ları kapsar — payment akışları, 2FA/KYC, webhook güvenliği, decimal rounding, timezone edge-case'leri. Önümüzdeki 90 gün içinde launch planlıyorsan, bunları go-live sonrasına değil, öncesine yakalamak daha ucuz.