To‘lov shlyuzlari va fintech arxitekturasi

To‘lov shlyuzi nima va nima uchun u shunchaki “tugma” emas

Ko‘pchilik to‘lov shlyuzini (payment gateway) oddiy oraliq sifatida tasavvur qiladi: foydalanuvchi “To‘lash” tugmasini bosadi, pul bankka ketadi, ekranda “Muvaffaqiyatli” chiqadi. Amalda esa shlyuz — bu sizning tizimingiz, bank yoki to‘lov tashkiloti (Payme, Click, Uzum, Octo va boshqalar), kartochka protsessingi va bir nechta tashqi xizmatlar kesishadigan nuqta. Aynan shu kesishuvda pul oqimi, xavfsizlik, integratsiyalar va yuklama bir vaqtning o‘zida uchrashadi.

Buning oqibati shuki, fintech tizimidagi eng qimmat xatolar deyarli har doim to‘lov qatlamida yuz beradi. Funksional xatoni keyin tuzatish mumkin, ammo ikki marta yechib olingan pul, yo‘qolgan tranzaksiya yoki uzilib qolgan holatdagi buyurtma — bu to‘g‘ridan-to‘g‘ri mijoz ishonchi va pul yo‘qotishdir. Shu sababli to‘lov arxitekturasiga “feature” emas, balki alohida tizimosti sifatida qarash kerak.

Oddiy modeldan boshlanadigan xatolik

Ko‘p loyihalar bir xil yo‘ldan boradi: to‘lovni sinxron qabul qilamiz, javobni kutamiz, javob “OK” bo‘lsa buyurtmani yopamiz. Bu model demo va birinchi mijozlar uchun ishlaydi, lekin u bitta jiddiy taxminga asoslanadi — to‘lov tashkiloti har doim tez va aniq javob beradi, deb.

Realda esa tarmoq uziladi, tashqi servis sekinlashadi, foydalanuvchi to‘lovdan keyin brauzerni yopadi, callback kechikadi yoki ikki marta keladi. Sinxron “so‘rov-javob” modeli bu holatlarni ko‘tara olmaydi. Natijada klassik muammolar paydo bo‘ladi:

• Osilib qolgan tranzaksiyalar: pul bankda yechilgan, ammo sizning tizimingizda buyurtma hali ham “kutilmoqda” holatida.
• Ikki marta to‘lov: foydalanuvchi sahifani yangiladi yoki tugmani ikki marta bosdi, idempotentlik yo‘qligi sababli ikkita to‘lov yaratildi.
• Holatlar nomuvofiqligi: bank “muvaffaqiyatli” deydi, sizning bazangizda esa “xatolik” — chunki callback yetib kelmadi.

To‘g‘ri arxitekturaning asosi: holat mashinasi va idempotentlik

Ishonchli to‘lov tizimi to‘lovni bitta hodisa emas, balki aniq holatlar ketma-ketligi sifatida modellashtiradi. Har bir tranzaksiya o‘zining holat mashinasiga (state machine) ega bo‘ladi: created → pending → authorized → paid → refunded / failed / cancelled. Bu holatlar o‘rtasidagi o‘tishlar qat'iy belgilanadi va orqaga qaytarib bo‘lmaydigan tarzda yoziladi.

Ikkinchi tayanch ustun — idempotentlik. Har bir to‘lov so‘rovi unikal kalitga (idempotency key) ega bo‘lishi kerak. Agar bir xil kalit bilan so‘rov takror kelsa, tizim yangi to‘lov yaratmaydi, balki mavjudining holatini qaytaradi. Bu callback’larning takrorlanishi, tarmoq qayta urinishlari va foydalanuvchi qo‘sh bosishlari paytida pulning ikki marta yechilishidan himoya qiladi.

Uchinchi element — har bir o‘zgarishni o‘zgarmas jurnalga (audit log / ledger) yozish. Pul harakati hech qachon faqat bitta ustunni yangilash bo‘lmasligi kerak; u qo‘shimcha yozuv (append-only) sifatida saqlanishi lozim, shunda har qanday vaziyatda “pul qayerdan kelib, qayerga ketdi” degan savolga aniq javob beriladi.

Asinxron oqim: webhook va reconciliation

Zamonaviy to‘lov arxitekturasi asinxron. Foydalanuvchini darhol “to‘lov qabul qilindi, tekshirilmoqda” holatiga o‘tkazasiz, asl tasdiqni esa server tomondagi webhook orqali olasiz. Bu yondashuv tashqi servisning kechikishini foydalanuvchi tajribasidan ajratib turadi.

Ammo webhook’ning o‘zi ham kafolat emas — u kechikishi, takrorlanishi yoki umuman yetib kelmasligi mumkin. Shu sababli ishonchli tizimda har doim ikkita mexanizm birga ishlaydi:

• Webhook (push): to‘lov tashkiloti holat o‘zgarganda darhol xabar yuboradi. Imzo (signature) bilan tekshiriladi, idempotent qayta ishlanadi.
• Reconciliation (pull): tizim muntazam ravishda (masalan, har bir necha daqiqada va kun oxirida) “pending” holatdagi to‘lovlar bo‘yicha tashkilotdan haqiqiy holatni so‘rab oladi va o‘z bazasi bilan solishtiradi.

Reconciliation — bu xavfsizlik to‘ri. Aynan u yo‘qolgan webhook’lar, osilib qolgan to‘lovlar va “bankda bor, bizda yo‘q” holatlarini avtomatik aniqlab tuzatadi. Uni keyinga qoldirib bo‘lmaydi: u tizimning birinchi versiyasidan boshlab bo‘lishi kerak.

Bir nechta provayder va abstraksiya qatlami

O‘zbekistonda biznes kamdan-kam bitta to‘lov usuli bilan cheklanadi: odatda Payme, Click, Uzum va kartochka protsessingi bir vaqtda kerak bo‘ladi. Agar har bir provayder logikasi to‘g‘ridan-to‘g‘ri biznes-kodga aralashtirilsa, tizim tez orada qo‘llab-quvvatlab bo‘lmaydigan holatga keladi.

To‘g‘ri yechim — yagona ichki abstraksiya qatlami (payment adapter). Biznes-mantiq “to‘lov yarat”, “holatni tekshir”, “qaytarib ber” degan umumiy interfeys bilan ishlaydi, har bir provayderning o‘ziga xosligi esa alohida adapter ichida yashiriladi. Bu yangi provayder qo‘shishni soddalashtiradi va bitta provayder ishlamay qolganda tizimning qolgan qismini himoya qiladi.

Xavfsizlik va muvofiqlik

To‘lov qatlami — hujum uchun eng jozibali nishon. Shu sababli xavfsizlik bir nechta darajada ta'minlanishi kerak. Karta ma'lumotlarini hech qachon o‘z serveringizda saqlamaslik (PCI DSS yukini provayderga o‘tkazish), barcha webhook’larni imzo orqali tekshirish, summalarni har doim server tomonida hisoblash (mijoz yuborgan summaga ishonmaslik) — bular muhokama qilinmaydigan minimal talablar.

Bundan tashqari, to‘lov endpoint’lariga so‘rovlar chastotasini cheklash (rate limiting), shubhali naqshlarni aniqlash (anti-fraud) va barcha pul harakatlarini izlanadigan jurnal sifatida saqlash kerak. O‘zbekiston regulyatsiyasi va soliq talablarini hisobga olganda, har bir tranzaksiyaning to‘liq audit izi bo‘lishi nafaqat texnik, balki yuridik zaruratdir.

Yuklama va ishonchlilik

To‘lov oqimi tizimning eng yuqori yuklamaga ega va eng kam toqatli qismidir. Aksiya yoki ish haqi kunlarida tranzaksiyalar soni keskin oshadi. Arxitektura buni hisobga olishi kerak: og‘ir operatsiyalarni navbatga (message queue) chiqarish, webhook’larni asinxron qayta ishlash, ma'lumotlar bazasiga yozuvlarni optimallashtirish va tashqi provayder sekinlashganda butun tizim qulab tushmasligi uchun timeout va circuit breaker mexanizmlarini qo‘yish.

Eng muhimi — kuzatuvchanlik (observability). Siz “bugun nechta to‘lov pending’da osilib qoldi”, “qaysi provayder javob bermayapti”, “reconciliation qancha nomuvofiqlik topdi” degan savollarga har soniyada javob bera olishingiz kerak. Monitoring va ogohlantirishlarsiz to‘lov tizimi qora quti bo‘lib qoladi va muammoni faqat mijoz shikoyat qilganda bilib olasiz — bu esa allaqachon kech.