Fintech platformalar va to‘lov tizimlarini qanday ishlab chiqamiz

Nega fintech boshqa loyihalardan tubdan farq qiladi

Oddiy korporativ sayt yoki ichki CRM ishlab chiqishda xato yuzaga kelsa, uni keyingi relizgacha qoldirish mumkin — foydalanuvchi sahifani qayta yuklaydi va davom etadi. Fintech platformalarida bunday «keyin tuzatamiz» yondashuvi ishlamaydi. Bu yerda har bir tranzaksiya — bu real pul, har bir xato esa to‘g‘ridan-to‘g‘ri moliyaviy yo‘qotish, regulyator oldida huquqiy javobgarlik va eng muhimi — foydalanuvchi ishonchining yo‘qolishidir.

To‘lov tizimi, hamyon (wallet), mikrokredit platformasi yoki bank yechimida xatoning «narxi» o‘nlab barobar yuqori. Ikki marta yechib olingan pul, yo‘qolgan tranzaksiya, noto‘g‘ri balans yoki yetarli himoyalanmagan kartani saqlash — bularning hammasi nafaqat texnik nosozlik, balki biznes uchun reputatsion va moliyaviy halokat. Aynan shuning uchun fintechda arxitektura, xavfsizlik va moliyaviy aniqlik loyihaning oxirida emas, balki birinchi kunidan asos sifatida qo‘yiladi.

Moliyaviy aniqlik: pul bilan «taxminan» bo‘lmaydi

Eng ko‘p uchraydigan va eng qimmat tushadigan xatolardan biri — pul summalarini float yoki double turidagi raqamlar bilan saqlash. Suzuvchi nuqtali raqamlar ikkilik sanoq tizimida o‘nlik kasrlarni aniq ifodalay olmaydi, natijada minglab tranzaksiyalardan keyin balansda tiyin-tiyindan «adashish» yig‘ilib qoladi. Pul bilan ishlaganda summalar butun sonlar (eng kichik birlik — tiyinlarda) yoki maxsus decimal turlarida saqlanishi shart.

Ikkinchi tamoyil — har bir moliyaviy operatsiya o‘zgarmas (immutable) yozuv sifatida saqlanadigan ledger (buxgalteriya daftari) orqali yuritilishi. Balansni shunchaki «ustiga yozish» o‘rniga biz har bir o‘zgarishni alohida yozuv qilib qo‘yamiz, balans esa shu yozuvlardan kelib chiqadi. Bu auditni soddalashtiradi va istalgan vaqtda «bu summa qayerdan keldi?» degan savolga aniq javob berishga imkon yaratadi.

Idempotentlik va tranzaksiyalar yaxlitligi

Tarmoq beqaror — foydalanuvchining interneti uzilishi, mobil ilova so‘rovni qayta jo‘natishi yoki to‘lov shlyuzi javobni kechiktirishi mumkin. Agar tizim bir xil so‘rovni ikki marta qabul qilsa va ikkalasini ham bajarsa, foydalanuvchidan ikki marta pul yechiladi. Aynan shuning uchun har bir to‘lov so‘rovi idempotentlik kaliti (idempotency key) bilan jihozlanadi: bir xil kalit bilan kelgan takroriy so‘rov yangi tranzaksiya yaratmaydi, balki birinchi natijani qaytaradi.

Bundan tashqari, har qanday moliyaviy operatsiya «hammasi yoki hech narsa» tamoyili asosida bajariladi. Masalan, bir hisobdan pul yechib, ikkinchisiga qo‘shish — bu ikkita amal bo‘lib, ular bitta atomik tranzaksiyada bajarilishi kerak. Agar oraliqda tizim qulasa, hech qanday yarim holat qolmasligi shart: yo ikkala amal ham bajariladi, yo hech biri bajarilmaydi. Tashqi to‘lov provayderlari bilan ishlaganda esa biz «ikki fazali» yondashuvni qo‘llaymiz — avval niyatni qayd etamiz, keyin tasdiqlaymiz va doimo provayder bilan holatlarni solishtirib turamiz (reconciliation).

Xavfsizlik va muvofiqlik birinchi kundan

Fintechda xavfsizlik — bu qo‘shimcha funksiya emas, balki poydevor. Karta ma’lumotlarini o‘zingiz saqlashdan iloji boricha qochish kerak: PCI DSS talablariga to‘liq javob berish murakkab va qimmat, shuning uchun aksariyat hollarda to‘lov ma’lumotlari sertifikatlangan provayder yoki token orqali yuritiladi, sizning serveringizda esa faqat token saqlanadi.

Bizning amaliyotimizda quyidagilar majburiy bazaviy talablar hisoblanadi:

• Barcha maxfiy ma’lumotlar — uzatishda (TLS) ham, saqlashda ham shifrlangan holatda;
• Maxfiy ma’lumotlar (parollar, kalitlar, .env) hech qachon kod repozitoriyasida emas, alohida sirlar boshqaruvida saqlanadi;
• Har bir moliyaviy va administrativ amal uchun o‘zgarmas audit jurnali — kim, qachon, nimani o‘zgartirgani;
• Rollarga asoslangan kirish nazorati (RBAC) — har bir foydalanuvchi faqat o‘ziga ruxsat etilgan amallarni bajaradi;
• Pul bilan bog‘liq muhim amallar uchun ikki bosqichli tasdiqlash va firibgarlikka qarshi (anti-fraud) qoidalar.

O‘zbekiston kontekstida muvofiqlik (compliance) alohida e’tibor talab qiladi. Markaziy bank talablari, shaxsiy ma’lumotlarni mahalliy serverlarda saqlash (data localization) qoidalari, milliy to‘lov tizimlari va anti-fraud / AML (jinoiy yo‘l bilan olingan daromadlarni legallashtirishga qarshi) talablari arxitekturaga loyiha boshidanoq kiritilishi kerak. Buni keyin qo‘shib bo‘lmaydi — bu butun ma’lumotlar modelini qayta qurishni talab qiladi.

Kuzatuvchanlik va nosozliklarga chidamlilik

Pul aylanadigan tizimda «nima bo‘layotganini bilmaslik» — bu o‘zi katta risk. Shuning uchun biz har bir tizimga kuzatuvchanlikni (observability) o‘rnatamiz: strukturalangan loglar, metrikalar va tranzaksiyalarni uchidan-uchigacha kuzatish (distributed tracing). Bu muammoni foydalanuvchi shikoyat qilishidan oldin aniqlashga imkon beradi.

Bizning tajribamizda eng xavfli holatlardan biri — tizim «muvaffaqiyatli» deb javob bersa-yu, aslida operatsiya bajarilmagan bo‘lsa. Bunday «yashirin» nosozliklar oylab sezilmasligi mumkin. Shuning uchun monitoring nafaqat «server ishlayaptimi?» degan savolga, balki «tranzaksiyalar haqiqatan yozilayaptimi?», «to‘lov provayderi bilan balanslar mos kelyaptimi?» degan biznes-darajadagi savollarga ham javob berishi kerak.

Biz fintech loyihasini qanday olib boramiz

OneDev’da fintech loyihasi har doim biznes va huquqiy talablarni chuqur tahlil qilishdan boshlanadi: qaysi regulyator talablari amal qiladi, qanday to‘lov oqimlari bo‘ladi, qanday firibgarlik stsenariylari mumkin. Shundan keyingina ma’lumotlar modeli va arxitektura loyihalanadi. Biz qisqartiruvchi yondashuvlardan qochamiz: pul bilan bog‘liq har bir yo‘l avtomatlashtirilgan testlar bilan qoplanadi, integratsiyalar test muhitida sinab ko‘riladi, relizdan oldin esa kritik to‘lov stsenariylari qo‘lda ham tekshiriladi.

Bizning tamoyilimiz oddiy: pul bilan ishlaydigan kod boshqacha standartda yoziladi. Bu yerda «ishlasa bo‘ldi» mezoni yetarli emas — kod aniq, kuzatiladigan, qayta tiklanadigan va auditga tayyor bo‘lishi kerak.