Ödənişlərdə təkrar və backoff

Ödənişlərdə təkrar və backoff

1) Niyə təkrar lazımdır

Çevirmə: yumşaq nasazlıqlar (timeouts, 3DS səhvləri, şəbəkə nasazlıqları) tez-tez təkrarlandıqda bərpa olunur: Auth Rate-ə + 2-7 pp.
Sabitlik: PSP/ACS/bankın lokal nasazlıqları alternativ marşrutlar ilə retrajlarla hamarlanır.
Oyunçunun təcrübəsi: düzgün qurulmuş təkrarlar infrastrukturun «səs-küyünü» iki dəfə silinmədən gizlədir.

2) Əsas prinsiplər

1. «payment intent» (PI) səviyyəsində idempotentlik: bir əməliyyat = bir 'idempotency _ key'; hər hansı bir təkrar müraciət pul vəziyyətini dəyişdirmir.

• Hard decline (məsələn, 'Do not honor' emitentin sərt siyasəti ilə, 'Insufficient funds') → adətən dərhal retraim deyil.
• Soft decline/texniki (timeout, 'Issuer unavailable', 'Try again') → icazə retraj.
• 3. Backoff + cəhd məhdudiyyəti: gecikməni eksponensial olaraq artırırıq, jitter əlavə edirik və limitləri aşmırıq (adətən 2-3 cəhd).
• 4. Retraj yalnız «eyni PSP-nin təkrarlanması» deyil, həm də PSP/MID/3DS rejimi/metodunun dəyişdirilməsidir.
• 5. Müşahidə: Hər bir hop Route Journal-da qeyd olunur (PSP, reason, latency, 3DS rejimi, fee, nəticə).

3) Retraj qərarı üçün səhvlərin təsnifatı

4) Backoff strategiyaları (təcrübə)

4. 1 Jitter ilə eksponensial backoff (tövsiyə olunur)

База: `delay_n = min(base 2^n, max_delay)`

Jitter: 'delay = rand (0, delay_n)' - bir çox sorğu eyni anda təkrarlandıqda «stampedləri» azaldır.
Tipik parametrlər: 'base = 200-500 ms', 'max _ delay = 5-10 s', 'n ≤ 2-3'.

4. 2 Xətti backoff

Sadə, lakin şəbəkədə «həyəcan» ilə daha pis. Eksponensial + jitterdən aşağı.

4. 3 Zaman aşma siyasəti

Client timeout (sizin) ≤ PSP SLA (məsələn, 3-5 s), əks halda dublikat/donma riski artır.
Ayrıca webhook/confirm gözləmə vaxtını təyin edin: təsdiq gəlməzsə → kompensasiya yoxlama (ledger/PSP).

5) İdempotentlik və dubl qorunması

Payment Intent (PI) statusunu, məbləğini, metodunu, 'idempotency _ key', marşrutların tarixçəsini saxlayır.
Hər hop və retry eyni açar istifadə edir.
Kompensasiya əməliyyatları: (PSP-də approve, sizdə isə vaxt var) - «reconcile-pull» + ledcerin tənzimlənməsi.
Webhook-un təkrar çatdırılması zamanı təkrar icazəni istisna edin: 'transaction _ id '/' PSP reference' unikallığını yoxlayın.

6) 3DS/SCA və təkrar

challenge ilə frictionless → retray sonra Soft decline.
ACS timeout/unavailable → eksponensial backoff, sonra alternativ kanal (açıq banking/APM) və ya digər PSP.
ACS kütləvi deqradasiyasında - circuit-breaker, artım 'challenge rate', məbləğlər üzrə müvəqqəti limitlər.

7) APM/open banking üçün təkrar

• Retrajlar məhduddur: provayder tərəfində idempotentliyi və gecikmiş webhook 'ax statuslarını yoxlayın.
• Qeyri-müəyyən statusda - backoff və ciddi yoxlamalar ilə polling.
• Vauçer/nağd pul: retrajlar «onlayn əməliyyatlar» kimi tətbiq edilmir, lakin ödəniş müddətinə nəzarət və «status refresh» qüvvədədir.

8) Payouts (nəticələr): təkrar və növbələr

backoff drenaj ilə bank/PSP → queued payouts texniki uğursuzluq.
KYT/velocity fail → retraim deyil, əl yoxlama tərcümə.
Növbənin prioritetləşdirilməsi: VIP/kiçik məbləğlər/ərizə müddəti; SLA və avto eskalasiya müddəti.
Alternativ relslər (RTP/FPS/SEPA Instant/Pix) retrajın ikinci addımındadır.

9) Circuit-breaker və retras

Yerli (PSP/MID/BIN): səhvlər baş verdikdə → bu marşrutda retrayları dayandırırıq, alternativə keçirik.
Qlobal (metod/region): sistemli deqradasiya → metodu söndürmək, APM/açıq banking təklif.
Half-open: Tam geri qayıtmadan əvvəl bərpanı yoxlamaq üçün trafikin bir hissəsini (1-5%) geri qaytarırıq.

10) Retraj strategiyasının psevdokodu

python def pay_with_retries(pi):
ensure_idempotency(pi.key)
if not compliance_pass(pi): return REJECT

routes = rank_candidates(pi) # по вероятности approve, fee, health attempts = 0 for route in routes:
policy3ds = select_3ds(pi, route)
res = call_psp(route, pi, policy3ds, pi.key, timeout=3.0)
log_attempt(pi, route, res)

if res.approved: return APPROVED

if is_soft_decline(res) or is_transient_error(res):
while attempts < MAX_ATTEMPTS and not breaker_open(route):
delay = backoff_with_jitter(base=0.3, attempt=attempts, cap=8.0)
sleep(delay)
policy3ds = maybe_toggle_3ds(policy3ds, res)
res = call_psp(route, pi, policy3ds, pi.key, timeout=3.0)
log_attempt(pi, route, res)
attempts += 1 if res.approved: return APPROVED if is_hard_decline(res): break перейти к следующему маршруту (PSP-B/APM/open banking)
return DECLINED

11) KPI və hədəf göstəriciləri

Incremental Approvals from Retries: + 2-7 p.p. baza konversiyasına.
Avg Retry Attempts per Approved Tx: 1. 2–1. 5 (aşağıda saxlayın 1. 7).
Retry Success Rate (soft/tech): ≥ 25–40%.
Duplicate Rate: 0 düzgün idempotentlik ilə.
P95 Latency (retrajlar nəzərə alınmaqla): <7 son cavabdan əvvəl.
Payout SLA (instant share): ≥ 70% yüngül çeklər, gecikmə <hədəf həddi.

12) Hadisə pleybukları

A. PSP-A-da kütləvi timeouts

1. PSP-A üçün lokal breaker açın.
2. PSP-B/APM-də retrajları yenidən paylayın.
3. Jitter ilə eksponensial backoff, 2-3 cəhd limiti.
4. half-open kanareyka 10-15 dəqiqə sonra.

B. Deqradasiya ACS/3DS

1. Boy detekti 'soft decline', timeouts.
2. challenge rate artırmaq; trafikin bir hissəsi → open banking.
3. Ağır çekləri təxirə salın, velocity limitlərini daxil edin.

C. payouts üçün gecikmələr

1. Növbəyə köçürmə, VIP/kiçik məbləğlərin prioritetləşdirilməsi.
2. Alternativ rails (RTP/FPS/SEPA Instant/Pix).
3. Oyunçulara ünsiyyət + avto eskalasiya.

13) Müşahidə və məlumatlar

Route Journal: PSP/MID, BIN/issuer, reason, latency, 3DS-режим, retry chain, итог, fee.
Daşbordlar: Auth Rate (banklar üzrə), Retry Success, Avg Attempts, Decline Mix, p95 latency, Payout Queue Depth.
Alertlər: reason kodları ilə spikes, artan cəhdlər/latency, nəticələr növbələrinin aşması.

14) Giriş yoxlama vərəqləri

Memarlıq/Məlumatlar

• Payment Intent + `idempotency_key` на все hops.
• -matris reason kodları: retryable vs non-retryable.
• Imzalı webhooks, PSP reference tərəfindən duplication.

Backoff/Qaydalar

• Jitter ilə eksponensial backoff; cəhd limiti və pəncərə vaxtı.
• Smart retry: 3DS/MID/PSP/metodu dəyişdirmək; kartlar üçün fərq vs APM/open banking.
• Circuit-breakers (yerli/qlobal), half-open-kanaryalar.

Ledger/Yoxlama

• «dayandırılmış» statuslarda kompensasiya əməliyyatları.
• T + 0/T + 1 yoxlanılması: PSP, bank, pul legger.
• Confirm/webhook time-out və SLA siyasəti.

Əməliyyatlar/komplayens

• RG/sanksiyalar/PEP/yaş - retras qədər.
• KYT/velocity на payouts; əl ağlama qaydaları.
• Hadisələr/eskalasiyalar üçün Runbooks və RACI.

15) İqtisadiyyat və risk

3DS-fii, FX, Çarjbek-dəyər, retray-overhead nəzərə alaraq effective rate hesab.
Chargeback exposure və ehtiyatları dağıtmamaq üçün yüksək riskli seqmentlərdə retrayları ciddi şəkildə məhdudlaşdırın.

16) Yekun

Təkrar idarə olunduqda işləyir: idempotentlik, aydın reason-kod matrisi, jitter ilə eksponensial backoff, cəhdlərin məhdudlaşdırılması və marşrutlaşdırma ilə əlaqə (PSP/3DS/metodun dəyişdirilməsi). Circuit-breaker, payouts üçün növbələr və güclü uyğunlaşmalar əlavə edin - və siz dubl və kassa «dəlikləri» yaratmadan çevirməni stabil şəkildə artıracaqsınız.