Ripetizioni e backoff nei pagamenti

Ripetizioni e backoff nei pagamenti

1) Perché hai bisogno di ripetizioni

Conversione: guasti morbidi (timeouts, errori 3DS, guasti di rete) vengono spesso ripristinati quando si ripete: + 2-7 pp a Auth Rate.
Resilienza: i guasti locali PSP/ACS/banca vengono alleggeriti con rotte alternative.
Esperienza del giocatore: ripetizioni corrette nascondono il rumore dell'infrastruttura senza doppi prelievi.

2) Principi di base

1. Idampotenza a livello «payment intent» (PI): un'operazione = una «idempotency _ key»; qualsiasi conversione non cambia lo stato del denaro.

• Hard decline (ad esempio, "Do not honor'con la rigida politica dell'emittente," Insufficient funds ") di solito non ritraiamo subito.
• Soft decline/tecnica (timeout, «Issuer unavailable», «Try again») è un retrai autorizzato.
• 3. Backoff + limitazione dei tentativi: aumenta esponenzialmente la latenza, aggiunge jitter e non supera i limiti (di solito 2-3 tentativi).
• 4. Routing in raccordo: il retrai non è solo «ripetizione dello stesso PSP», ma anche un cambio PSP/MID/3DS/metodo.
• 5. Osservabilità: ogni hop viene registrato in Route Journal (PSP, reason, latency, 3DS, fee, risultato).

3) Classificazione degli errori per la soluzione retrae

4) Strategie backoff (pratica)

4. 1 Backoff esponenziale con jitter (raccomandato)

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

Jitter: 'delay = rand (0, delay _ n)' - riduce le «stampe» quando molte richieste vengono ripetute contemporaneamente.
Opzioni tipiche: 'base = 200-500 ms', 'max _ delay = 5-10 c', 'n≤2 -3'.

4. 2 Backoff lineare

Semplice, ma peggiore con «agitazione» online. È inferiore al + jitter esponenziale.

4. 3 Politica timeout

Client timeout (il tuo) è un PSP SLA (ad esempio 3-5 c), altrimenti aumenta il rischio di duplicati/dipendenze.
Imposta separatamente il tempo di attesa per webhook/confirm: se la conferma non è arrivata, il → di compensazione (ledger/PSP).

5) Idampotenza e protezione contro le prese

Payment Intent (PI) memorizza lo stato, la somma, il metodo, 'idempotency _ key', la cronologia dei percorsi.
Ogni hop e retry utilizza la stessa chiave.
Le transazioni di compensazione sono «reconcile-pull» (approve in PSP e tu hai timeout) + regolazione del ledger.
Escludi la ripetizione dell'autorizzazione durante la ricomposizione di webhook: controlla unicamente la transizione _ id/PSP reference.

6) 3DS/SCA e ripetizioni

Soft decline dopo frictionless retrai con challenge.
ACS timeout/unavailable è un backoff esponenziale, quindi un canale alternativo (open banking/APM) o un altro PSP.
In caso di deterioramento di massa ACS - circuito-breaker, crescita «challenge rate», limiti di tempo di importo.

7) Ripetizioni per APM/open banking

• I retrai sono limitati: verificare l'idempotenza sul lato provider e gli stati in webhook ritardato'ax.
• Se lo stato è incerto, polling con backoff e incroci rigorosi.
• Voucher/contanti - I retrai non si applicano come «transazione online», ma il controllo della scadenza e «status refresh».

8) Payouts (conclusioni): ripetizioni e code

Guasto tecnico della banca/PSP-queued payouts con drenaggio backoff.
KYT/velocity fail non è un ritraim, tradotto in controllo manuale.
Priorità della coda: VIP/piccoli importi/durata della richiesta; deadline SLA e auto-escalation.
Binari alternativi (RTP/FPS/SEPA Instant/Pix) al secondo passo del retrotreno.

9) Circuito-breaker e retrai

Locale (su PSP/MID/BIN) - Quando si verificano errori, interrompiamo i retrai su questo percorso e passiamo a un altro.
Globale (metodo/regione): degrado di sistema disattivando il metodo, offrendo APM/open banking.
Half-open: restituisce parte del traffico (1-5%) per verificare il ripristino prima della restituzione totale.

10) Pseudo-codice della strategia dei retrai

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 e target

Incorporal Approvals from Retries: + 2-7 p.p. alla conversione di base.
Avg Retry Attempts per Approved Tx: 1. 2–1. 5 (tieni sotto 1. 7).
Retry Success Rate (soft/tech): ≥ 25–40%.
Duplicata Rate: 0 con idampotenza corretta.
P95 Latency (considerando i retrai): <7 dalla risposta finale.
Payout SLA (instant share) - ≥ il 70% degli assegni facili, la soglia di destinazione è scaduta.

12) Playbook incidenti

A. Timeouts di massa su PSP-A

1. Apri breaker locale per PSP-A.
2. Ridistribuire i retrai su PSP-B/APM.
3. Backoff esponenziale con jitter, limite di 2-3 tentativi.

4. Canary half-open tra 10-15 minuti

B. Degrado ACS/3DS

1. Un oggetto di crescita «soft decline», timeouts.
2. Aumentare il challenge rate; una parte del traffico di open banking.
3. Ritardi assegni pesanti, abilita limiti velocity.

C. Ritardi di payouts

1. Traduzione in coda, priorità VIP/piccole somme.
2. Reut per rails alternativi (RTP/FPS/SEPA Instant/Pix).
3. Comunicazione ai giocatori + auto-escalation.

13) Osservabilità e dati

Route Journal: PSP/MID, BIN/issuer, reason, latency, 3DS-режим, retry chain, итог, fee.
Dashboard: Auth Rate (per banche), Retry Success, Avg Attempts, Decline Mix, p95 latency, Payout Queue Depth.
Alert: spikes nei codici reason, aumento dei tentativi/latency, riempimento delle code di conclusioni.

14) Assegni di implementazione

Architettura/dati

• Payment Intent + `idempotency_key` на все hops.
• Matrice config di codice reason: retryable vs no-retryable.
• Firmati webhooks, deduplicazione PSP reference.

Backoff/regole

• Backoff esponenziale con jitter; limite di tentativi e tempo di finestra.
• Smart retry: cambio 3DS/MID/PSP/metodo; differenza per le carte vs APM/open banking.
• Circuiti-breakers (locali/globali), half-open-canary.

Ledger/comprimi

• Transazioni compensative per gli stati'sospesi '.
• T + 0/T + 1 crocifisso: PSP-Banca ha ↔ un ↔ di cassa.
• Timeout e SLA su confirm/webhook.

Operazioni/compilazione

• RG/sanzioni/PEP/età - prima dei retrai.
• KYT/velocity на payouts; le regole della gelosia manuale.
• Runbooks e RACI per incidenti/escalation.

15) Economia e rischi

Leggi effettiva rate con 3DS-fia, FX, charjback-costo, retrai-overhead.
Limitare rigidamente i ritai sui segmenti high-risk per evitare di accelerare le esposure e le riserve di marceback.

16) Totale

Le ripetizioni funzionano quando sono controllate: idampotenza, matrice chiara dei codici reason, backoff esponenziale con jitter, limitazione dei tentativi e collegamento con il routing (cambio PSP/3DS/metodo). Aggiungi circuito-breaker, code per payouts e forti compressioni - e alzerai stabilmente la conversione senza creare scatti o buchi di cassa.