Trading platform withdrawal system development zamanı əsas məqsəd pul çıxarışı düyməsini API-yə bağlamaq deyil; hər sorğunu yoxlanıla bilən, təkrar icraya davamlı və əməliyyat komandasının idarə edə bildiyi pul-hərəkəti prosesinə çevirməkdir. Broker, treydinq tətbiqi və ya wallet məhsulu üçün çıxarış axını müştərinin mövcud vəsaitini düzgün hesablamalı, risk və uyğunluq qaydalarını tətbiq etməli, lazımi hallarda insan təsdiqinə yönləndirməli, provayderdən gələn nəticələri qəbul etməli və daxili kitabı xarici hesablaşma ilə müqayisə etməlidir.

Bu yanaşma xüsusilə balansın orderlər, marja, bonuslar, komissiyalar, geri qaytarmalar və əvvəlki çıxarış rezervləri ilə dəyişdiyi platformalarda vacibdir. POLADO FinTech və trading sistemləri xidməti çərçivəsində çıxarış modulunu ledger, back-office, mobil və veb müştəri kabineti ilə birlikdə layihələndirə bilər.

Çıxarış sorğusunu vəziyyət maşını kimi qurun

“Pending” və “paid” kimi iki status kifayət etmir. Hər status biznes mənası, icazəli keçidlər və məsul tərəflə müəyyən edilməlidir. Məsələn:

  • draft — müştəri məbləği və benefisiarı daxil edir, lakin sorğu hələ təqdim olunmayıb;
  • submitted — server sorğunu qəbul edib və idempotency açarı ilə qeyd edib;
  • funds_reserved — çıxarıla bilən məbləğ üçün rezerv yaradılıb;
  • screening — uyğunluq, fraud və ya risk yoxlaması gözlənilir;
  • approval_required — qayda insan yoxlaması tələb edir;
  • approved / rejected / cancelled — daxili qərar yekunlaşıb;
  • provider_submitted — provayderə göndəriş cəhdi qeydə alınıb;
  • provider_pending — provayder nəticəni hələ təsdiqləməyib;
  • paid / failed / returned — xarici nəticə qəbul edilib və daxili maliyyə qeydləri tamamlanıb;
  • investigation — ziddiyyət, gecikmə və ya əl ilə araşdırma tələb olunur.

Keçidlər yalnız server tərəfində yoxlanmalıdır. Məsələn, təsdiqlənməmiş sorğunu “paid” etməyə, rədd olunmuş sorğunu yenidən göndərməyə və ya provayder cavabı gəlmədən rezervi silməyə icazə verilməməlidir. OWASP maliyyə və digər yüksək həssas əməliyyatlarda ardıcıl, server tərəfdən məcbur edilən vəziyyət keçidlərini və yekun icradan əvvəl ayrıca nəzarət qapısını tövsiyə edir. ([cheatsheetseries.owasp.org](https://cheatsheetseries.owasp.org/cheatsheets/Transaction_Authorization_Cheat_Sheet.html?utm_source=openai))

“Balans” deyil, çıxarıla bilən məbləği hesablayın

İstifadəçiyə görünən balans birbaşa çıxarıla bilən balans olmaya bilər. Tipik qayda belə ifadə olunur:

çıxarıla bilən məbləğ = yerləşdirilmiş vəsait + reallaşmış P&L − açıq öhdəliklər − marja rezervi − gözləyən çıxarış rezervləri − bloklanmış məbləğlər − tətbiq edilən komissiyalar.

Dəqiq formula məhsuldan asılıdır, lakin vacib prinsip eynidir: sorğu yaratmaq və rezerv yazmaq atomik əməliyyat olmalıdır. İki paralel sorğu eyni vəsaiti iki dəfə istifadə edə bilməməlidir. Bunun üçün tranzaksiya, sətir kilidi və ya şərtli yeniləmə istifadə olunur; “əvvəl oxu, sonra yaz” modeli kifayət deyil.

Çıxarış yaradılan anda rezerv ayrıca maliyyə hadisəsi kimi qeyd edilir. Ödəniş uğursuz olarsa rezerv nəzarətli qaydada açılır; ödəniş tamamlanarsa rezerv yekun debetə çevrilir. Dəyişdirilməz double-entry ledger bu hadisələri sonradan izah etməyə imkan verir. Ledger prinsipləri üçün ayrıca FinTech ledger arxitekturası materialı faydalıdır.

Risk, uyğunluq və benefisiar nəzarətlərini axına daxil edin

Hər sorğunu avtomatik rədd etmək əvəzinə qayda mühərriki qərarı üç nəticədən birinə yönləndirə bilər: avtomatik davam et, əlavə yoxlama üçün saxla və ya rədd et. Siqnallara KYC statusu, hesab məhdudiyyəti, yeni cihaz, yeni benefisiar, məbləğ limiti, qısa müddətdə təkrarlanan sorğular, hesab valyutası, ölkə və məhsula xas şərtlər daxil ola bilər.

Benefisiar ayrıca obyekt olmalıdır: sahiblik, ödəniş relsi, maskalanmış hesab identifikatoru, doğrulama vəziyyəti, yaradılma tarixi və risk atributları saxlanmalıdır. Müştəri benefisiarı dəyişirsə, mövcud çıxarışın təsdiqi etibarsızlaşmalı və yeni təsdiq tələb olunmalıdır. İstifadəçiyə məbləği, valyutanı, komissiyanı və benefisiarın maskalanmış identifikatorunu açıq göstərən təsdiq ekranı qurun. Bu, istifadəçinin faktiki olaraq hansı əməliyyatı təsdiqlədiyini anlamasına kömək edir.

İnsan təsdiqini nəzarətli edin, sadəcə admin düyməsi yaratmayın

Yüksək məbləğli və ya riskli çıxarışlarda maker-checker modeli tətbiq edin. Sorğunu yaradan və ya ilkin yoxlamanı edən əməkdaş həmin sorğunu yekun təsdiqləməməlidir. Təsdiq növbəsində operator üçün yalnız lazım olan kontekst görünməlidir: müştəri profili, KYC vəziyyəti, mövcud vəsait hesablaması, benefisiar tarixi, əlaqəli siqnallar, əvvəlki çıxarışlar və provayder marşrutu.

Qərar audit izi olmadan dəyişdirilməməlidir. Audit hadisəsində actor, rol, vaxt, əvvəlki və yeni vəziyyət, səbəb kodu, əlavə qeyd və əlaqəli sorğu identifikatorları saxlanmalıdır. Admin rolunun olması hər sorğuya çıxış demək deyil: tenant, region, məhsul və limit üzrə səlahiyyət də yoxlanmalıdır. Back-office ekranları və exception növbələri üçün FinTech back-office development yanaşması bu nəzarətləri məhsul UX-i ilə birləşdirir.

Provayder inteqrasiyasında callback-i həqiqət mənbəyi kimi emal edin

Provayderə sorğu göndərmək ödənişin baş tutduğu demək deyil. Xarici sistem vaxt aşımına düşə, qəbul cavabını itirə, eyni webhook-u bir neçə dəfə göndərə və hadisələri fərqli ardıcıllıqla çatdıra bilər. Buna görə hər çıxarış üçün daxili withdrawal ID, provayder reference ID, provider event ID və idempotency key saxlayın.

Webhook endpoint imzanı yoxlamalı, xam hadisəni təhlükəsiz saxlamalı, event ID əsasında dublikatı aşkar etməli və emalı asinxron növbəyə ötürməlidir. Callback yalnız qanuni vəziyyət keçidi yaradırsa qəbul edilməlidir. Məsələn, artıq paid olan sorğuya köhnə pending hadisəsi gəldikdə tarixçə saxlanıla bilər, amma maliyyə vəziyyəti geri qaytarılmamalıdır. Provayder çağırışının qeyri-müəyyən nəticəsində kor-koranə yenidən göndəriş ikiqat ödəniş yarada bilər; əvvəlcə provayder reference və ya sorğu statusu ilə sorğunu tapmağa çalışın.

Ledger, bildiriş və exception növbəsini birlikdə dizayn edin

Maliyyə nəticəsi UI statusundan deyil, ledger hadisələrindən yaranmalıdır. Məsələn, rezerv zamanı müştərinin available funds hesabından çıxarış rezerv hesabına yazıla, uğurlu payout zamanı rezerv hesabından settlement/clearing hesabına yazıla bilər. Uğursuzluq və ya ləğv isə ayrıca reversal hadisəsi yaradır; köhnə qeydi dəyişmir.

Müştəri bildirişləri də outbox prinsipi ilə işləməlidir. Sorğunun daxili vəziyyəti uğurla commit olunandan sonra “sorğu qəbul edildi”, “əlavə yoxlama tələb olunur”, “ödəniş göndərildi” və ya “uğursuz oldu” mesajı yayımlansın. Bildiriş çatdırılmasa, çıxarışın maliyyə vəziyyəti dəyişməməlidir.

Exception növbəsi əməliyyat komandasının gündəlik iş yeridir. Buraya provayder cavabı gecikən, webhook imzası etibarsız olan, məbləği uyğunsuz gələn, naməlum event alan, reversal gözləyən və ya uzlaşdırmada fərq yaradan sorğular düşür. Operatorda “yenidən cəhd et” düyməsi yox, səbəbli və səlahiyyətli fəaliyyətlər olmalıdır: statusu sorğula, provayderlə uyğunlaşdır, manual review-a yönəlt, eskalasiya et və ya nəzarətli reversal başlat.

Gündəlik uzlaşdırma istehsal sonrası funksiyadır

Uzlaşdırma yalnız maliyyə şöbəsinin export işi deyil. Gündə ən azı daxili çıxarış reyestri, ledger hərəkətləri, provayder payout reyestri və bank/ödəniş relsi hesabatları müqayisə edilməlidir. Uyğunluq açarı provayder reference, məbləğ, valyuta, tarix və mümkün olduqda benefisiar identifikatorudur.

Fərqləri kateqoriyalara ayırın: daxildə var, provayderdə yoxdur; provayderdə var, daxildə yoxdur; məbləğ və ya valyuta fərqi; status fərqi; gecikmiş settlement; təkrarlanan göndəriş ehtimalı. Hər fərq ticket və sahiblik almalıdır. Logların ardıcıl formatda, düzgün zaman sinxronizasiyası ilə və araşdırma üçün kifayət qədər kontekstlə saxlanması həm əməliyyat, həm də təhlükəsizlik baxımından vacibdir. ([cheatsheetseries.owasp.org](https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html?utm_source=openai))

Buraxılışdan əvvəl yoxlama siyahısı

  • Eyni idempotency key ilə təkrar sorğu yalnız bir withdrawal yaradırmı?
  • Paralel çıxarışlar available balance-i mənfiyə endirə bilirmi?
  • Benefisiar və ya məbləğ dəyişdikdə köhnə təsdiq ləğv olunurmu?
  • Rolu olmayan operator təsdiq, rədd və ya reversal edə bilirmi?
  • Eyni, gecikmiş və ardıcıllığı pozulmuş webhook-lar təhlükəsiz emal edilirmi?
  • Provider timeout zamanı sistem ikiqat payout etmədən bərpa oluna bilirmi?
  • Hər maliyyə keçidinin dəyişdirilməz ledger və audit hadisəsi varmı?
  • Gündəlik reconciliation fərqləri görünən, sahibli və izlənən növbəyə düşürmü?

Yeni broker withdrawal management system qurursunuzsa və ya mövcud payout workflow-da manual spreadsheet, qeyri-müəyyən statuslar və reconciliation fərqləri varsa, POLADO ilə konsultasiya planlaşdırın. Arxitekturanı, provider inteqrasiyalarını, back-office rollarını və mərhələli tətbiq planını məhsulunuzun pul-hərəkəti risklərinə uyğun müəyyənləşdirə bilərik.