Trading platforması üçün depozit sistemi hazırlanması istifadəçinin vəsait yatırma sorğusundan hesab balansında istifadə oluna bilən vəsaitin yaranmasına qədər olan bütün maliyyə nəzarət zəncirinin qurulmasıdır. Etibarlı həll “provider uğurlu cavab qaytardı” məlumatına əsasən balansı dərhal artırmır. O, daxili depozit qeydi yaradır, provayderin imzalı callback-ini yoxlayır, təkrar hadisələri təhlükəsiz qəbul edir, uyğunluq və risk qaydalarını tətbiq edir, sonra isə ledger vasitəsilə wallet kreditini atomik şəkildə yazır.

Bu yanaşma broker, kripto birjası, prop-trading məhsulu və ya çoxvalyutalı wallet üçün vacibdir. Depozit axını düzgün modelləşdirilməzsə, ikiqat kredit, yanlış istifadəçiyə vəsait yazılması, valyuta fərqləri, “pending” ödənişlərin itməsi və provayder hesabatı ilə daxili qalıqlar arasında uyğunsuzluq yaranır. POLADO FinTech və trading sistemləri xidməti çərçivəsində bu cür inteqrasiyaları məhsul, back-office və audit tələbləri ilə birlikdə layihələndirir.

Depozit niyə sadəcə “ödə və balansı artır” əməliyyatı deyil?

İstifadəçi tətbiqdə məbləği və valyutanı seçdikdə sistem əvvəlcə payment intent və ya daxili deposit transaction yaratmalıdır. Bu qeyd istifadəçi hesabı, wallet, tələb edilən valyuta, gözlənilən məbləğ, provayder, ödəmə metodu, FX qaydası, son istifadə vaxtı və ilkin statusu saxlayır. Sonrakı bütün hadisələr həmin daxili qeyd ilə əlaqələndirilir.

Provayderin hosted checkout səhifəsindən brauzerin geri qayıtması yalnız istifadəçi təcrübəsi üçündür; maliyyə həqiqəti deyil. İstifadəçi səhifəni bağlaya, geri dönüş URL-i gecikə və ya dəyişdirilə bilər. Kredit qərarı provayderdən server-to-server gələn, imzası yoxlanılmış callback və zəruri hallarda provayder API-si ilə əlavə status sorğusu əsasında verilməlidir.

Tövsiyə edilən depozit status modeli

  • created — istifadəçi depozit niyyətini yaradıb, lakin ödəniş sessiyası hələ formalaşmayıb.
  • awaiting_payment — checkout, bank rekvizitləri və ya on-chain ünvan göstərilib; sistem ödənişi gözləyir.
  • provider_processing — provayder vəsaiti qəbul edib, lakin yekun nəticə hələ məlum deyil.
  • received — provayderin etibarlı hadisəsi məbləğin daxil olduğunu təsdiqləyib; kredit qaydaları hələ tamamlanmayıb.
  • under_review — məbləğ, istifadəçi, ölkə, risk siqnalı və ya uyğunluq qaydasına görə əməliyyat növbəyə düşüb.
  • credited — wallet ledger-də kredit yazılıb və vəsait məhsul qaydalarına uyğun istifadə oluna bilər.
  • failed, expired, reversed, refunded — mənfi və ya geri çevrilmiş nəticələr ayrıca terminal vəziyyətlərdir.

Bu statuslar provayderin öz terminlərini kor-koranə təkrarlamamalıdır. Provayder statusu ayrıca saxlanmalı, daxili status isə məhsulun maliyyə qərarını ifadə etməlidir. Beləliklə, iki fərqli provayderin hadisələrini eyni əməliyyat və audit dili ilə idarə etmək mümkün olur.

Provider callback-lərini necə etibarlı qəbul etməli?

Payment provider webhook handling ayrıca təhlükəsizlik sərhədidir. Endpoint yalnız TLS üzərindən işləməli, provayderin imzasını xam request body əsasında yoxlamalı, timestamp toleransını tətbiq etməli və hadisə identifikatorunu saxlamalıdır. İmza doğrulanmadan gələn payload heç vaxt wallet kreditinə, status dəyişikliyinə və ya əməliyyat qeydinə təsir etməməlidir.

Callback emalı sürətli olmalıdır: hadisəni qəbul et, imzanı yoxla, dəyişməz raw payload və metadata-nı saxla, sonra emalı növbəyə ötür. Provayderlər timeout olduqda eyni hadisəni yenidən göndərə bilər; buna görə “200 OK” cavabı kreditin mütləq tamamlandığı anlamına gəlmir. O, yalnız sistemin hadisəni qəbul etdiyini göstərir.

İdempotency iki səviyyədə lazımdır

  • İstifadəçi sorğusu: mobil və ya web client hər “deposit yarat” əməliyyatına idempotency key göndərməlidir. Şəbəkə retry-si eyni checkout sessiyasını və ya iki payment intent yaratmamalıdır.
  • Provayder hadisəsi: provider event ID üçün unikal məhdudiyyət olmalıdır. Eyni callback on dəfə gəlsə belə, bir dəfə emal edilməlidir.
  • Wallet krediti: deposit transaction ID və kredit növü üçün unikal ledger posting qaydası olmalıdır. Event təkrarı və paralel worker-lər ikinci balans yazısı yarada bilməməlidir.

Burada yalnız tətbiq kodunda “əgər artıq kredit edilibsə” yoxlaması kifayət deyil. Məlumat bazası səviyyəsində unikal indekslər, tranzaksiya sərhədləri və lazım olduqda row lock istifadə edilməlidir. OWASP biznes məntiqi üzrə tövsiyələrində xarici, təkrarlanmayan əməliyyatlar üçün idempotency key və tranzaksiyalı nəticə yazısını açıq şəkildə tövsiyə edir.

Wallet kreditini kontrollu maliyyə əməliyyatına çevirin

Provider “paid” statusu birbaşa users.balance += amount əmrinə çevrilməməlidir. Kredit xidməti daxili deposit transaction-ı, əlaqəli istifadəçini, wallet valyutasını, provayder transaction ID-sini, qəbul edilən məbləği və kredit üçün bütün precondition-ları yenidən yoxlamalıdır. Sonra immutable double-entry ledger-də yazı yaradılmalıdır: məsələn, “provider clearing” və ya “funds receivable” hesabının debeti, istifadəçinin müştəri vəsaiti öhdəliyinin krediti.

Əgər məhsul mövcud vəsait, bonus vəsaiti, marja üçün uyğun vəsait və bloklanmış vəsait arasında fərq qoyursa, depozit krediti hansı balans vedrəsinə yazılacağını açıq müəyyən etməlidir. Bu qayda sonradan withdrawal, marja və hesabat modullarında eyni şəkildə istifadə edilməlidir. Ledger arxitekturası ilə bağlı daha geniş yanaşma üçün dəyişməz double-entry ledger arxitekturasına baxın.

Valyuta, hesab və məbləğ xəritələnməsi

“100” təkbaşına maliyyə məlumatı deyil. Sistem minimum olaraq məbləği, ISO valyutasını, provider settlement currency-ni, wallet currency-ni, FX məzənnəsinin mənbəyini, məzənnə vaxtını, fee-nin kim tərəfindən qarşılandığını və yuvarlaqlaşdırma qaydasını saxlamalıdır. Provider EUR qəbul edib istifadəçi USD trading wallet-ına kredit alırsa, kredit məbləği hansı anda hesablanır, FX spread harada yazılır və sonradan mübahisə zamanı hansı dəlil göstərilir — bunlar inteqrasiyadan əvvəl müəyyən edilməlidir.

Bank transfer, kart, open banking, lokal ödəniş metodu və kripto transferi eyni adapter interfeysinə uyğunlaşdırıla bilər, lakin onların yekunluq xüsusiyyətləri fərqlidir. Məsələn, bəzi metodlarda gecikmiş reversal və ya chargeback ehtimalı var. Buna görə “credited” statusu ilə “tam geri dönməz” statusu məhsulunuz üçün eyni məna daşımaya bilər.

Manual review növbəsi və back-office nə etməlidir?

Avtomatlaşdırma bütün hallarda avtomatik kredit demək deyil. Məbləğ limiti, ilk depozit, hesab sahibinin adı ilə uyğunsuzluq, təkrarlanan provider reference, ölkə və ya device risk siqnalı, yüksək riskli ödəniş metodu kimi qaydalar əməliyyatı under_review vəziyyətinə yönəldə bilər. Reviewer yalnız əməliyyatı təsdiqləməməli, qərarın səbəbini, sübutları, istifadə olunan qaydanı və kimin nə vaxt qərar verdiyini görməlidir.

Back-office-də ən azı axtarış, filtrləmə, provider event timeline, raw callback-a məhdud giriş, user/KYC vəziyyəti, linked wallet posting-ləri, iki nəfərli təsdiq tələb edən düzəlişlər və export edilə bilən audit log olmalıdır. KYC prosesinin statusları depozit qərarlarından ayrıdır, amma düzgün inteqrasiya edilməlidir; bunun üçün trading platforması üçün KYC onboarding yanaşmasından istifadə oluna bilər.

Gündəlik reconciliation: sistemin həqiqətən işlədiyini necə sübut etməli?

Reconciliation yalnız maliyyə komandasının ay sonu işi deyil. Gündəlik avtomatik uzlaşdırma provayder settlement fayllarını və ya API hesabatını daxili deposit transaction-lar, provider event-ləri, ledger posting-ləri və bank/PSP clearing hesabları ilə müqayisə etməlidir. Məqsəd “provider qəbul edib, sistem kredit etməyib”, “sistem kredit edib, provider ödənişi təsdiqləmir”, “məbləğ və ya valyuta fərqlidir” kimi istisnaları tez tapmaqdır.

  • Hər provider transaction ID daxili depozitə ən çox bir dəfə bağlanır.
  • Hər credited depozitin bir və yalnız bir uyğun ledger posting-i var.
  • Settlement məbləği gross amount, provider fee, reversal və net payout hissələrinə ayrılır.
  • Uyğunlaşmayan sətirlər owner, prioritet, səbəb kodu və həll tarixi ilə exception queue-yə düşür.
  • Manual adjustment heç vaxt ilkin qeydi dəyişmir; ayrıca səbəbli və təsdiqli kompensasiya yazısı yaradır.

Provider inteqrasiyasından əvvəl veriləcək arxitektura sualları

  1. Hansı ölkələr, hüquqi şəxslər, valyutalar və payment method-lar ilk buraxılışa daxildir?
  2. Hansı provayder hadisəsi kredit üçün kifayətdir və hansı hallarda status API ilə yenidən yoxlanmalıdır?
  3. İstifadəçi wallet-ı, trading account-u və provider customer reference-i necə xəritələnəcək?
  4. Pending, failed, expired, reversed, chargeback və refund hallarında istifadəçi ekranı və əməliyyat komandası nə görəcək?
  5. Hansı limit, KYC, AML və risk siqnalları manual review yaradır?
  6. Hansı halda vəsait trading üçün aktiv, withdrawal üçün məhdud və ya tam bloklu olacaq?
  7. Provider downtime, gecikmiş callback və duplicate event üçün retry, alert və runbook nədir?
  8. Gündəlik reconciliation-u kim izləyəcək və istisnanı kim, hansı səlahiyyətlə bağlayacaq?

Kart məlumatını öz sisteminizdən keçirməmək, provayderin host etdiyi payment page və tokenləşdirilmiş inteqrasiya istifadə etmək adətən kart məlumatı riskini azaltmağa kömək edir; lakin bu, təşkilatın PCI DSS üzrə tətbiq olunan öhdəliklərini avtomatik aradan qaldırmır. Konkret scope və hüquqi/compliance tələbləri seçilən axın, ölkə və tərəfdaş müqavilələrinə görə ayrıca qiymətləndirilməlidir.

POLADO ilə depozit axınını necə planlamaq olar?

POLADO depozit sistemini sadəcə gateway SDK inteqrasiyası kimi deyil, transaction state machine, provider adapter-ləri, wallet ledger, back-office, audit, monitoring və reconciliation birlikdə olan FinTech capability kimi hazırlayır. Yeni broker məhsulu, mövcud platformada payment layer-in yenilənməsi və ya çoxprovayderli wallet üçün scope-u real əməliyyat ssenarilərindən başlayaraq müəyyənləşdirə bilərik. Əgər komandanız acquisition və funding həcmini artırmazdan əvvəl depozit nəzarətlərini yoxlamaq istəyirsə, konsultasiya üçün POLADO ilə əlaqə saxlayın.