Repetições e backoff em pagamentos

Repetições e backoff em pagamentos

1) Porquê as repetições

Conversão: falhas suaves (timeouts, erros 3DS, falhas de rede) são frequentemente restauradas com a repetição de + 2-7 p.p. para Auth Rate.
Sustentabilidade: falhas locais do PSP/ACS/banco são suavizadas por retais com rotas alternativas.
Experiência do jogador: repetições corretamente construídas escondem o «ruído» da infraestrutura sem cancelamentos duplos.

2) Princípios básicos

1. Idempotidade no nível «payment intent» (PI): uma operação = uma 'idempotency _ key'; qualquer reaproximação não altera a fortuna monetária.

• Hard decline (por exemplo, 'Do not honorário', sob a política rígida do emissor, 'Insufficient funds') → normalmente não é retrátil imediatamente.
• Soft decline/técnico (timeout, 'Issuer unavailable', 'Try again') → retrai permitido.
• 3. Backoff + limitação de tentativas: aumentamos exponencialmente o atraso, adicionamos um jitter e não ultrapassamos os limites (normalmente 2-3 tentativas).
• 4. Roda em retrai não é apenas uma «repetição do mesmo PSP», mas também uma mudança de PSP/MID/3DS/método.
• 5. Observabilidade: cada hop é captado em Rota Journal (PSP, reason, latency, modo 3DS, fee, resultado).

3) Classificação de erros para a decisão de retrações

4) Estratégia Backoff (prática)

4. 1 Backoff exponencial com jitter (recomendado)

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

Jitter: 'delay = rand (0, delay _ n)' - reduz «estampadas» quando muitas solicitações são repetidas simultaneamente.
Parâmetros típicos: 'base = 200-500 ms', 'max _ delay = 5-10 s', 'n≤2 -3'.

4. 2 Backoff linear

Simples, mas pior com a «agitação» online. Inferior ao + jitter exponencial.

4. 3 Política de Tempo-Outs

Cliente timeout (seu) ≤ PSP SLA (por exemplo, 3-5 c), ou o risco de duplicação/partilha aumenta.
Selecione o tempo de espera do webhook/confirm: se a confirmação não tiver chegado → compensação de compensação (ledger/PSP).

5) Idempotidade e proteção contra suplentes

Payment Intent (PI) armazena status, soma, método, 'idempotency _ key', histórico de rotas.
Cada hop e retry usam a mesma chave.
As transações compensatórias são «recepcile-pull' (approve no PSP e você tem timeout),» recordle-pull' + ajustar o ledger.
Exclua a nova permissão quando o webhook voltar a ser entregue: verifique se o PSP reference é exclusivo.

6) 3DS/SCA e repetições

Soft decline após frictionless → retrai com challenge.
ACS timeout/unavailable → backoff exponencial, então um canal alternativo (open banking/APM) ou outro PSP.
Com a degradação em massa do ACS - circuito-breaker, crescimento do 'challenge rate', limite de tempo de soma.

7) Repetições para APM/open banking

• Retrações limitadas: verifique a idempotidade do lado do provedor e estatais em webhook 'ax adiados.
• Com status incerto, polling com backoff e cruzamentos rigorosos.
• Vales/dinheiro: Os retais não são aplicados como «transação online», mas existem controles de prazo de pagamento e «status refresh».

8) Payouts (conclusões): repetições e filas

Falha técnica do banco/PSP → queued payouts com backoff-dren.
KYT/velocity fail → não retrabalhado, traduzido em verificação manual.
Priorizar a fila VIP/pequenos valores/idade da candidatura; deadline SLA e escalação automática.
Roteiros alternativos (RTP/FPS/SEPA Point/Pix) no segundo passo de retalho.

9) Circuito-breaker e retrai

Local (PSP/MID/BIN): Com o aumento de erros, → paramos as retraias nesta rota e mudamos para a rota alternativa.
Global (método/região): degradação do sistema → desativamos o método, oferecemos APM/open banking.
Half-open: Devolvemos parte do tráfego (1-5%) para verificar a recuperação antes da devolução total.

10) Pseudocode estratégia de retrações

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 orientações de destino

Incorporal Approvals from Retries: + 2-7 p.p. para conversão básica.
Avg Retry Attempts per Approved Tx: 1. 2–1. 5 (mantenha abaixo de 1. 7).
Retry Success Rate (soft/tech): ≥ 25–40%.
Duplicate Rate: 0 com idempotação correta.
P95 Latency (considerando os retais): <7 com a resposta final.
Payout SLA: ≥ 70% de cheques leves, atrasos <limite de destino.

12) Playbooks incidentes

A. Timeouts em massa em PSP-A

1. Abrir breaker local para PSP-A.
2. Redistribuir retraí para PSP-B/APM.
3. Backoff exponencial com jitter, limite de 2 a 3 tentativas.

4. Canário half-open em 10-15 minutos

B. Degradação ACS/3DS

1. Um detetive de crescimento de 'soft decline', timeouts.
2. Aumentar o challenge rate; parte do tráfego → open banking.
3. Adiar cheques pesados, incluir limites de velocidade.

C. Atrasos de payouts

1. Transferência para fila, priorização de quantias VIP/pequenas.
2. Reut para rails alternativos (RTP/FPS/SEPA Point/Pix).
3. Comunicação aos jogadores + escalação automática.

13) Observabilidade e dados

Route Journal: PSP/MID, BIN/issuer, reason, latency, 3DS-режим, retry chain, итог, fee.
Dashboards: Auth Rate (em bancos), Retry Sucess, Avg Attempts, Decline Mix, p95 latency, Payout Queue Depth.
Alerts: spikes em códigos reason, aumento de tentativas/latency, cheias de filas de conclusões.

14) Folhas de cheque de implementação

Arquitetura/dados

• Payment Intent + `idempotency_key` на все hops.
• Config matriz de código reason: retryable vs não-retryable.
• Webhooks assinados, dedução por PSP reference.

Backoff/regras

• Backoff exponencial com jitter; limite de tentativas e tempo de janela.
• Smart retry: mudança de 3DS/MID/PSP/método; distinção para cartões vs APM/open banking.
• Circuito-breakers (local/global), half-open-canários.

Ledger/comprimidos

• Transações compensatórias em estados suspensos.
• T + 0/T + 1 comprovação: PSP ↔ banco ↔ candeeiro monetário.
• Política de tempo e SLA em confirm/webhook.

Operações/Complaens

• RG/sanções/PEP/idade - antes dos retais.
• KYT/velocity на payouts; Regras para o ciúme manual.
• Runbooks e RACI para incidentes/escalações.

15) Economia e risco

Considere o rate efetivo considerando fias 3DS, FX, valor de charjback, retrai-overhead.
Limite severamente os retais pelos segmentos high-risk para não impulsionar a exposure e as reservas.

16) Resultado

As repetições funcionam quando são controladas: idempotidade, matriz clara de código reason, backoff exponencial com jitter, limitação de tentativas e conexão com o roteiro (mudança PSP/3DS/método). Adicione o circuito-breaker, as filas para payouts e os cruzamentos fortes - e você vai elevar a conversão de forma estável sem criar dublês ou «buracos» de caixa.