Ödəniş zəncirləri və prioritetləşdirmə

1) Ödəniş zənciri anlayışı

Ödəniş zənciri (payout chain) - orkestrator göndərmə ('sent') və ya qəbul ('settled') təsdiqini alana qədər ardıcıl olaraq ödəniş etməyə çalışdığı relslərin/provayderlərin nizamlı siyahısı.
Məqsəd müəyyən edilmiş məhdudiyyətlər zamanı pula qədər vaxtı minimuma endirməkdir: KYC/AML, limitlər, likvidlik, dəyər, katofflar, geo/valyuta, profil riski.

• Primary rail (seqment üçün üstünlük rels).
• Fallbacks (alternativlər SLA/dəyəri/mövcudluğu).
• Rules (keçid şərtləri) və Constraints (sərt qadağalar/limitlər).
• Sağlamlıq siqnalları (approve/settle/latency/səhvlər) və Liquidity (balans/prefanding).

2) Relslərin prioritetləşdirilməsi meyarları

1. SLA/sürət: min/saat/bank günləri; mövcudluğu 24/7 (RTP/FPS/Pix) qarşı D + N (ACH/SEPA).
2. Qiymət: fix +%, FX marjası, provayder haqları; daxili cost-model.
3. Likvidlik: Provayder/korschetdən mövcud qalıq, prefandinq tələbləri.
4. Uyğunluq: valyuta/alıcı ölkə, rekvizitlərin formatı (IBAN/CLABE/Routing/Sort/PIX-açar).
5. Limitlər: per-txn/daily/weekly provayderdə və alıcıda (bank/pul kisəsi).
6. Risk/KOS: müştəri səviyyəsi, SoF/SoW, sanksiyalar/RER, velocity, yeni benefisiar.
7. Etibarlılıq: cari nasazlıq, gecikmə, geri dönüş metrikası (reject/return).
8. Cat-off və təqvimlər: yerli bayramlar, cut-off bank; TZ göndərici/alıcı.
9. Məhsulun üstünlükləri: VIP/affiliates/jackpotlar - ayrı-ayrı profillər.

3) Orkestr matrisi (məntiq nümunəsi)

≤ €1k, EU, Tam KYC → SEPA Instant → (folback) SEPA SCT → (cut-off sonra) növbəti BD.
≤ £250k, Böyük Britaniya, 24/7, VIP → FPS (primary), gecikmələr zamanı> P95 - 2 nömrəli provayderə keçid.
US ≤ $5k → RTP; bank alıcını dəstəkləmirsə - Same Day ACH; pəncərə bağlandıqda - ACH Next Day.
BR → Pix (primary); risk/bank limitləri ilə → Pix aşağı treshchold və ya e-wallet payout.
Kart (qlobal) → Push-to-Card (OCT) sürətli, lakin bahalı və məhdud göndərişlər üçün.
Cross-border → yerli e-wallet (var) → ümumi rüsumlar və ETA hesablanması ilə başqa SWIFT.

Bütün ədədi eşiklər və siyahılar kodda deyil, konfiqurasiyada.

4) Zəncir orkestratorunun arxitekturası

• Decision Engine (policy) - rels və folbeklərin seçilməsi qaydalarını (deklarativ siyasətlər, versiyalaşdırma) tətbiq edir.
• Payout Orchestrator — state machine: `requested → queued → processing → sent/failed → settled/returned`.
• Liquidity/Treasury - provayderlərin balansları, prefandinq, avto-rebalance, provayder/gün limitləri.
• Calendar/Scheduler - cut-off, ölkə/valyuta bayramları, batch göndərmə yuvaları.
• Provider Adapter Layer - API unifikasiyası, mappinq status kodları, idempotentlik.
• Reconciliation - reyestrlərin/çıxarışların avtomatik yoxlanılması, UTR/ARN/Trace yüklənməsi.
• Compliance - KYC/AML/sanksiyalar/SoF/SoW və case-menecment.

• İdempotentlik ('requestId'), hadisə dedupu, DLQ/retrailer c backoff/jitter.
• Observability: trass, orkestr hadisələri, per-provayder zamanlayıcılar.

5) Folbek, deqradasiya və «boz» ssenarilər

Time-based fallback: əgər 'processing' həddi keçibsə (məsələn, 90-cı percentil) - növbəti relsə keçin (icazə verilsə, ilk cəhd/void ləğv edilsin).
Health-based: 'reject/return' böyüdükdə və ya approve düşdükdə - provayderin dəresi.
Liquidity-based: prefanding çatışmazlığı → müvəqqəti sürətli relslər gizlətmək, yavaş təklif.
Risk-based: yüksək risk - fast-rails qadağası, məcburi hold/step-up.
Grey window: axşamlar/bayramlar → ən yaxın pəncərəyə avtomatik planlaşdırma; UI dürüst ETA.

6) Relslərin qiyməti və reytinqi

• `eff_cost = fixed_fee + percent_fee amount + FX_margin + failure_cost fail_prob + support_cost`.

• `score = w_slaSLA + w_cost(1/eff_cost) + w_reliabilitysuccess_rate − w_riskrisk_score − w_opsoperational_load`.
• Tərəzi - konfiqurasiyalı; seqmentlərə görə müqayisə edin (geo/məbləğ/VIP).

7) Likvidlik və prefandinq

Sürətli relslər əvvəlcədən ödəniş tələb edir: minimumları provayderlərin hesablarında saxlayın.
Auto-rebalance: cüzdan/banklar arasında eşik qaydaları.
Circuit-breakers: <eşik qalığı - zəncirdə metodun avtomatik çıxarılması.
Cashbook: vəd edilmiş ödənişlərin mühasibatlığını faktiki debetlərdən ayırın; kassa boşluğuna nəzarət.

8) Planlaşdırma: batchi, katoff və təqvimlər

Batching SWIFT/ACH/SEPA SCT dəyərini azaldır, lakin gecikməni artırır - məbləği/prioriteti tənzimləyin.
Off-off aware: sorğu off-off sonra gəldi - dərhal növbəti BD ETA göstərin.
Holiday API: regional bayramları saxlayın; cross-TZ üçün alıcının yerli vaxtını göstərin.

9) Zəncirlərdə risk və KYC

Yeni benefisiar/böyük məbləğ → cool-off + step-up, tez rails qadağa.
Eşik məbləğləri → SoF/SoW tələbi; tədarükə qədər - «yavaş» rels.
Geo/sanksiyalar/RER → sərt deny, alternativ marşrutlar yoxdur.
Velocity: N ödənişlər/gün/həftə; → zəncirdə downgrade rels aşmaq.

10) Statuslar və artefaktlar

• `requested → queued → processing → sent(UTR/ARN) → settled | failed | returned | on_hold | canceled`.
• Храните: `payoutId`, `beneficiaryId`, `rail`, `provider`, `amount/currency`, `fees`, `ETA`, `UTR/ARN/Trace`, reason-codes, `attempts[]`.

11) Yoxlama və jurnallaşdırma

Daily auto-recon: reyestrlərin yüklənməsi, 'payoutId/UTR/amount/date' matçı.
Full-recon: periodik nəzarət (reyestrlər/çıxarışlar/GL).
Alertlər: «reyestrsiz uğur», «aging processing», «double send», «provayderin sükutu».

12) UX və kommunikasiya

ETA-nın ray və seçim səbəbi ilə göstərilməsi («daha sürətli/daha ucuz/cut-off sonra»).
UTR/ARN/Trace ilə şəffaf statuslar.
Folback üçün - açıq bildiriş: "gecikmə/likvidlik səbəbindən {rail} -ə keçib; yeni ETA"....
VIP üçün - «sürətləndirmək» seçimi (digər rels/komissiya).
Yeni alıcılar üçün - hold/step-up xəbərdarlığı.

13) KPI и SLO

On-time rate (vəd edilmiş ETA-dan əvvəl gəlmiş ödənişlərin% -i).
Median/P95/provayderləri/geo.
Reject/Return rate və səbəblərin paylanması.
Fallback rate və SLA/dəyəri onun təsiri.
Liquidity uptime (sürətli relslərin mövcud vaxtı).
Cost per payout və FX payı.
Support load (biletlər/1k ödənişlər) və nəticələr üzrə NPS.

14) Check-list başlanğıc zəncirlər

1. Rels kataloqu: ölkələr/valyutalar/limitlər/komissiyalar/ETA/cut-off/bayramlar.
2. Policy Engine: deklarativ prioritetləşdirmə qaydaları + explain-həll səbəbləri.
3. Provayderlərin sağlamlığı: metriklər, sağlamlıq testləri, avtomobil reytinqi.
4. Treasury: prefanding, provayder limitləri, avto-rebalance.
5. İdempotentlik və DLQ: dubl/təkrarlama qorunması, təhlükəsiz retrajlar.
6. Webhooks/HMAC: imzaların yoxlanılması, zaman aşımları, çatdırılma təkrarlanması.
7. Recon: daily + full, rasinxronlarda alertlər.
8. UX: ETA, statuslar, UTR/ARN, folbek/hold səbəblərinin mətnləri.
9. KYC/AML: yeni benefisiarlar/böyük məbləğlər step-up, SoF/SoW prosedurları.
10. Test dəsti: uğur/uğursuzluq/geri dönüş, vaxt/likvidlik, cut-off/tətil, provayder deqradasiyası.

15) Mini psevdocode həlledicisi

rail_list = rank_by(score(amount, geo, kyc, risk, sla, cost, liquidity, health))
for rail in rail_list:
if violates_constraints(rail, geo, kyc, sanctions, limits): continue if not has_liquidity(rail): continue attempt = send_payout(rail)
if attempt. status in {SENT, SETTLED}: return success(attempt)
if is_retryable(attempt): continue return fail_with_reason(best_reason_collected)

Xülasə

Ödəniş zəncirləri sürət, qiymət, risk və əməliyyat hazırlığı arasında ağıllı marşrutlaşdırmadır. Qaydaları və metrikləri konfiqada saxlayın, likvidlik və provayderlərin sağlamlığı nəzərə alınmaqla skorinq funksiyasına əsaslanaraq qərar verin, idempotentlik, folbek və dürüst ETA təmin edin. Beləliklə, xərcləri və gəlirləri azaldır, SLA və istifadəçilərin etibarını saxlayırsınız - xüsusilə iGaming və cross-border kimi həssas seqmentlərdə.