Fintex platformalari va to‘lov infratuzilmasi: ishlab chiqish va ekspluatatsiya tajribasi

To‘lov tizimlari va fintex platformalari — bu oddiy veb-servis emas. Bu yerda kod xatosi, sekin so‘rov yoki noto‘g‘ri ishlangan tarmoq uzilishi to‘g‘ridan-to‘g‘ri pul harakatiga, balanslarga va foydalanuvchi ishonchiga ta’sir qiladi. Bitta ikki marta yechib olingan to‘lov yoki yo‘qolgan tranzaksiya — bu nafaqat texnik incident, balki moliyaviy va huquqiy mas’uliyat. Shu sababli fintex loyihalarini “tezroq ishga tushiramiz, keyin tuzatamiz” yondashuvi bilan qurib bo‘lmaydi. Quyida OneDev jamoasining to‘lov infratuzilmasini ishlab chiqish va ekspluatatsiya qilish bo‘yicha amaliy tajribasini ulashamiz: arxitektura qarorlari, tipik xatolar va biznes uchun muhim mezonlar.

Nega to‘lov platformasi alohida toifa

Ko‘pchilik veb-ilovalarda “eventual consistency” (ma’lumotlar bir necha soniyada moslashishi) maqbul holat hisoblanadi. To‘lovlarda esa har bir operatsiyaning holati har lahzada aniq bo‘lishi shart: pul yechildimi, hisobga o‘tdimi, yoki muallaqmi (pending). Foydalanuvchi “To‘lash” tugmasini bossa-yu, javob kelmasa — bu noaniqlik yuzaga keladi va aynan shu noaniqlik fintexdagi eng katta xatarlar manbai.

To‘lov platformasini farqlovchi bir nechta xususiyat bor:

• Idempotentlik majburiy. Bir xil so‘rov ikki marta kelsa (tarmoq qayta urinishi, foydalanuvchi tugmani ikki marta bosishi), tizim bir martagina pul harakatini bajarishi kerak.
• Audit izi to‘liq. Har bir status o‘zgarishi, har bir tashqi chaqiruv jurnalga yozilishi va keyinchalik tiklash mumkin bo‘lishi shart.
• Tashqi bog‘liqliklar nazoratdan tashqarida. Bank, protsessing markazi yoki to‘lov shlyuzi sizdan mustaqil ishlaydi — ular sekinlashadi, vaqtincha o‘chadi, formatni o‘zgartiradi.
• Regulyatsiya va hisobot. Markaziy bank talablari, soliq hisoboti, ma’lumotlarni saqlash muddati — bularning hammasi arxitekturaga ta’sir qiladi.

Arxitektura asoslari: pulni “haqiqat manbasi”da saqlash

To‘g‘ri qurilgan to‘lov tizimida pul holati hech qachon faqat ilova xotirasida yoki UI’da yashamaydi. Yagona haqiqat manbasi (single source of truth) — bu tranzaksiyalar jurnali (ledger). Biz odatda ikki yozuvli (double-entry) prinsipidan foydalanamiz: har bir pul harakati kamida ikki yozuv hosil qiladi — qayerdan chiqdi va qayerga kirdi. Bu buxgalteriya prinsipi xatolarni avtomatik aniqlashga imkon beradi, chunki yig‘indi har doim nolga teng bo‘lishi kerak.

Balansni ledger’dan hosil qilish kerak, aksincha emas. Ya’ni foydalanuvchi balansi — bu uning barcha tranzaksiyalari yig‘indisi, mustaqil saqlanadigan “raqam” emas. Bu yondashuv bitta jiddiy muammoni hal qiladi: agar balans alohida ustun sifatida yangilanib borsa, har qanday parallel so‘rov yoki uzilish uni jurnaldan ajratib qo‘yishi mumkin va keyin qaysi raqam to‘g‘riligini aniqlash deyarli imkonsiz bo‘ladi.

Idempotentlik va tranzaksiya holatlari

Fintexdagi eng ko‘p uchraydigan ishlab chiqish xatosi — idempotentlikni e’tiborsiz qoldirish. Mijoz “to‘lov” so‘rovini yuboradi, tarmoq sekinlashadi, mijoz qayta yuboradi — natijada ikkita bir xil to‘lov. To‘g‘ri yechim: har bir to‘lov so‘roviga mijoz tomonidan generatsiya qilingan noyob kalit (idempotency key) biriktiriladi va server bu kalit bo‘yicha takroriy so‘rovni aniqlab, oldingi natijani qaytaradi — yangi operatsiya yaratmaydi.

Tranzaksiya holatlari aniq belgilangan davlat mashinasi (state machine) sifatida modellashtirilishi kerak: created → pending → authorized → captured → settled yoki failed / reversed / refunded. Har bir o‘tish faqat ruxsat etilgan yo‘nalishda bo‘ladi. “pending” holati alohida e’tibor talab qiladi — bu eng xavfli holat, chunki bu yerda pul “qayerdadir” yo‘lda. Aynan pending tranzaksiyalar uchun avtomatik solishtirish (reconciliation) mexanizmi bo‘lishi shart.

Tashqi to‘lov shlyuzlari bilan integratsiya

O‘zbekistonda fintex loyihalari odatda mahalliy to‘lov tizimlari (Click, Payme, Uzum va boshqalar) hamda bank protsessing markazlari bilan ishlaydi. Har bir shlyuzning o‘z protokoli, o‘z webhook formati va o‘z xatolik mantig‘i bor. Bu yerda bir nechta amaliy qoidalar muhim:

• Webhook’larni tasdiqlash. Kelayotgan har bir bildirishnoma imzo (signature) yoki maxfiy kalit bilan tekshirilishi shart. Tasdiqlanmagan webhook — bu soxta to‘lov hodisasini in’ektsiya qilish yo‘li.
• Webhook idempotent bo‘lishi kerak. Shlyuzlar bir xil bildirishnomani bir necha marta yuborishi normal holat — tizim buni nazarda tutib qurilishi kerak.
• Timeout va qayta urinish siyosati. Tashqi chaqiruvga aniq timeout qo‘yiladi, qayta urinishlar esa eksponensial kechikish bilan amalga oshiriladi va albatta idempotency kaliti bilan.
• Solishtirish (reconciliation). Kun oxirida yoki belgilangan davriylikda shlyuz tomonidagi tranzaksiyalar ro‘yxati o‘z ledger’ingiz bilan avtomatik solishtirilishi kerak. Farqlar — bu darhol tekshiriladigan signal.

Amaliyotda webhook’ga to‘liq ishonib bo‘lmaydi: u kechikishi yoki umuman kelmasligi mumkin. Shuning uchun har doim ikki manba bo‘lishi kerak — webhook (push) va status-so‘rov (pull). To‘lov holati ushbu ikki manbaning kombinatsiyasidan aniqlanadi.

Xavfsizlik va maxfiy ma’lumotlar

To‘lov tizimlarida xavfsizlik “qo‘shimcha funksiya” emas, balki poydevor. Karta ma’lumotlarini o‘z serveringizda saqlamaslik (PCI DSS doirasini qisqartirish uchun tokenizatsiya), maxfiy kalitlarni kodga yoki git remote URL’ga vshit qilmaslik, barcha pul operatsiyalarini server tomonida tekshirish — bularning hammasi minimal talab. Mijoz tomonidagi (frontend) hech qanday narxni yoki summani server qayta tekshirmasdan qabul qilmasligi kerak.

Maxfiy ma’lumotlar (API kalitlar, sertifikatlar, .env) alohida himoyalangan joyda saqlanadi, jurnal fayllariga karta raqami yoki to‘liq token hech qachon yozilmaydi. Audit jurnali esa, aksincha, har bir muhim harakat — kim, qachon, qaysi summani o‘zgartirgani — saqlanishi shart, chunki bu nafaqat xavfsizlik, balki regulyator talabidir.

Ekspluatatsiya: monitoring, alert va incidentlar

To‘lov tizimini ishga tushirish — bu yo‘lning yarmi. Asosiy ish — uni barqaror ushlab turish. Bu yerda monitoring oddiy “server tirikmi” tekshiruvidan ancha chuqurroq bo‘lishi kerak. Biz biznes-metrikalarni kuzatishni tavsiya qilamiz:

• Muvaffaqiyatli to‘lovlar ulushi (success rate) — keskin pasayish darhol signal.
• “pending” holatda osilib qolgan tranzaksiyalar soni va ularning yoshi.
• Shlyuz javob vaqti va xatolik darajasi har bir provayder bo‘yicha alohida.
• Reconciliation’dagi nomuvofiqliklar — nol bo‘lishi kutiladi, har qanday farq tekshiriladi.

Muhim nuqta: agregatlangan metrikalar muammoni yashirishi mumkin. Agar siz faqat “umumiy to‘lovlar soni”ni kuzatsangiz, bitta provayderning to‘liq o‘chib qolishi boshqalar fonida sezilmay qolishi mumkin. Shuning uchun har bir kritik oqim uchun alohida “tiriklik” probasi bo‘lishi kerak — masalan, “oxirgi N daqiqada ushbu provayder orqali biror to‘lov o‘tdimi”.

Ma’lumotlar bazasi va barqarorlik bo‘yicha amaliy maslahatlar

Pulga aloqador yozuvlarda ma’lumot turlari ham ahamiyatga ega. Summalarni floating-point (o‘nlik kasr) sifatida saqlash — klassik xato; har doim butun son (eng kichik birlik, masalan tiyin) yoki maxsus decimal tur ishlatiladi. Vaqt belgilarini saqlashda esa tashqi tizim aytgan vaqt (u xato bo‘lishi mumkin) va sizning server qabul qilgan vaqt — ikkalasi ham yozilishi kerak, chunki filtrlash va hisobotda server vaqti ishonchliroq.

Ma’lumotlar bazasiga yozishda atomarlik kafolatlanishi kerak: ledger yozuvi, status o‘zgarishi va bog‘liq operatsiyalar bitta tranzaksiya ichida bajariladi yoki umuman bajarilmaydi. Yarim bajarilgan holat fintexda ruxsat etilmaydi.