Repetiții și backoff în plăți

Repetiții și backoff în plăți

1) De ce sunt necesare reluări

Conversia: eșecurile moi (timeout-uri, erori 3DS, eșecuri de rețea) sunt adesea recuperate la repetare: + 2-7 pp la Rata Auth.
Robustețe: falimentele locale PSP/ACS/bancare sunt netezite de retras cu rute alternative.
Experiența jucătorului: reluările construite corect ascund „zgomotul” infrastructurii fără taxe duble.

2) Principii de bază

1. Idempotența la nivelul „intenției de plată” (PI): o operațiune = o 'idempotency _ key'; orice recurs nu modifică condiția monetară.

• Declin dur (ex. „Nu onorați” cu o politică strictă a emitenților, „Fonduri insuficiente”) → de obicei nu retraiem imediat.
• Soft declin/tehnic (timeout, „Emitent indisponibil”, „Încercați din nou”) → retray permis.
• 3. Backoff + încercări limită: crește exponențial întârzierea, adăugați jitter și nu depășiți limitele (de obicei 2-3 încercări).
• 4. Bundle routing: retray nu este doar o „repetare a aceluiași PSP”, ci și o modificare a modului/metodei PSP/MID/3DS.
• 5. Observabilitate: fiecare hop este înregistrat în Route Journal (PSP, motiv, latență, mod 3DS, taxă, rezultat).

3) Clasificarea erorilor pentru decizia de retragere

4) Strategii de backoff (practică)

4. 1 Backoff exponențial cu jitter (recomandat)

База: 'delay _ n = min (base 2 ^ n, max_delay)'

Jitter: 'delay = rand (0, delay_n)' - reduce ștampilele atunci când multe cereri se repetă simultan.
Parametrii tipici sunt 'base = 200-500 ms', 'max _ delay = 5-10', 'n≤2 -3'.

4. 2 Backoff liniar

Simplu, dar mai rău cu „neliniște” pe rețea. Inferior exponential + jitter.

4. 3 Politica de timeout

Timeout client (a ta) ≤ PSP SLA (de exemplu, 3-5 s), în caz contrar riscul de duplicate/înghețări crește.
Setați separat timpul de așteptare pentru webhook/confirmați: dacă confirmarea nu vine → reconcilierea compensatorie (registru/PSP).

5) Idemptence și protecție împotriva ia

Intenția de plată (PI) stochează statutul, suma, metoda, 'idempotency _ key', istoricul traseului.
Fiecare hop și încercați din nou să utilizați aceeași cheie.
Compensarea tranzacțiilor: când nu se sincronizează (aprobați în PSP și aveți un timeout) - „reconciliere-tragere” + ajustare registru.
Excludeți re-autorizarea atunci când re-livrați webhook-ul: verificați "tranzacție _ id'/" referință PSP" pentru unicitate.

6) 3DS/SCA și repetiții

Declin moale după frictionless → retray cu provocare.
ACS timeout/indisponibil → backoff exponențial, apoi un canal alternativ (open banking/APM) sau un alt PSP.
Cu degradarea în masă a ACS - întrerupător de circuit, creșterea „rata de provocare”, limitele de timp ale sumelor.

7) Reps pentru APM/open banking

• Retraiele sunt limitate: verificați idempotența pe partea furnizorului și statusurile în webhook 'ax întârziat.
• Cu un statut nedeterminat - sondaje cu backoff și reconcilieri stricte.
• Vouchere/numerar: Retroadele nu se aplică în cazul unei „tranzacții online”, ci se aplică controlul datei scadente și „reîmprospătarea stării”.

8) Plăți: reluări și cozi

Eșec tehnic bancar/PSP → plăți în coadă cu scurgere backoff.
KYT/viteza eșuează → nu retraiem, transferul la verificarea manuală.
Prioritizarea cozii: VIP/cantități mici/vârsta aplicației; SLA și termene de auto-escaladare.
Șine alternative (RTP/FPS/SEPA Instant/Pix) în al doilea pas retras.

9) Circuit-breaker și retrai

Local (pe PSP/MID/BIN): atunci când erorile spike, → opriți retraiele pe această rută, treceți la una alternativă.
Global (per metodă/regiune): degradarea sistemică → dezactiva metoda, oferim APM/open banking.
Jumătate deschis: returnați o parte din trafic (1-5%) pentru a verifica recuperarea înainte de returnarea completă.

10) Pseudocodul strategiei de retray

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-uri și obiective

Aprobări incrementale de la Retries: + 2-7 pp la conversia de bază.
Încercări Avg Retry per Aprobat Tx: 1. 2–1. 5 (a se păstra sub 1. 7).
Rata de succes (soft/tech): ≥ 25-40%.
Rată duplicat: 0 cu idempotență corectă.
P95 Latenţă (inclusiv retribuţii): <7 s până la răspunsul final.
Plata SLA (cota instantanee): ≥ 70% din verificări ușoare, întârziate <pragul țintă.

12) Registrele de redare incidente

A. Timeout-uri de masă pe PSP-A

1. Întrerupător local deschis pentru PSP-A.
2. Realocați retroactivele la PSP-B/APM.
3. Backoff exponențial cu jitter, limitați încercările 2-3.
4. Canar pe jumătate deschis după 10-15 minute.

B. Degradarea ACS/3DS

1. Detectarea prin creștere „declin moale”, timeout.
2. Creșterea ratei de provocare; o parte a traficului → open banking.
3. Pune deoparte controale grele, porniți limitele de viteză.

C. Întârzieri plăți

1. Transferați la coadă, prioritizarea sumelor VIP/mici.
2. Rerout la șine alternative (RTP/FPS/SEPA Instant/Pix).
3. Comunicare către jucători + auto-escaladare.

13) Observabilitate și date

Route Journal: PSP/MID, BIN/emitent, motiv, latență, 3DS-режим, încercați din nou lanțul, итог, taxa.
Tablouri de bord: Rata Auth (pe bancă), Succesul Retry, Încercări Avg, Mix Declin, latență p95, Adâncimea cozii de plată.
Alerte: vârfuri după codurile de motive, creșterea încercărilor/latenței, depășirea cozilor de ieșire.

14) Liste de verificare a implementării

Arhitectură/Date

• Intenție de plată + 'idempotency _ key' на все hamei.
• Matricea de configurare a codului: retrizabilă vs neretrizabilă.
• Semnate webhook-uri, eliminarea duplicatelor prin referință PSP.

Backoff/reguli

• Backoff exponențial cu jitter; limita de încercări și timp fereastră.
• Smart retry: schimbare 3DS/MID/PSP/method; distincţie pentru cardurile APM/open banking.
• Întrerupătoare de circuit (locale/globale), semi-deschise-canare.

Registru/reconcilieri

• Compensarea tranzacțiilor cu statut „suspendat”.
• T + 0/T + 1 reconciliere: PSP ↔ banca ↔ registru de bani.
• Timeout și politica SLA pe confirma/webhook.

Operațiuni/Conformitate

• RG/sancțiuni/PEP/vârstă - înainte de retroacere.
• KYT/viteză на plăți; reguli de revizuire manuală.
• Runbooks și RACI pentru incidente/escaladări.

15) Economie și risc

Luați în considerare rata efectivă luând în considerare 3DS-phia, FX, valoarea de încărcare, retraiul deasupra capului.
Hard limită retroactive la segmente cu risc ridicat, astfel încât să nu overclock expunere chargeback și rezerve.

16) Linia de jos

Repetițiile funcționează atunci când sunt controlabile: idempotență, o matrice clară a codurilor rațiunii, backoff exponențial cu jitter, restricție de încercare și un pachet cu rutare (schimbare PSP/3DS/method). Adăugați întrerupător de circuit, cozi de plăți și reconcilieri puternice - și ridicați în mod constant conversia fără a crea dureri și găuri de numerar.