Rotação de pagamentos e failover

Rotação de pagamentos e failover

1) Por que é necessário

Conversão: a escolha correta do canal/PSP pelo BIN/banco/geo/risco aumenta o Auth Rate de 5-15 p.p

Custo: escolha dinâmica por «sucesso x comissão» reduz o rate efetivo em 10-30 bps.
Sustentabilidade: isolamento das baixas PSP/3DS/bancos; Continuar recebendo e pagando em casos de falhas parciais.
Complaens/RG: Implementação flexível de limites, geo-limitações, auto-exclusões e regras de sanções diretamente no roteiro.

2) Arquitetura de destino (camadas)

1. Checkout Layer - Localização de moedas/métodos, APM discovery, 3DS UX.
2. Payment Orquestrator (Rule Engine) - Routing, smart retry, idempotação, circuito-breaker.
3. Risk/KYT Engine - device/behavior, sanções/RER, velocity, limites RG, política 3DS.
4. Compliance Hub - KYC, provedores de sanções, afordability/limites, auditorias.
5. Wallet & Ledgers - Ledgers em dinheiro e jogos, bónus-passivos, multivaltos.
6. Reconciação & Reporting - T + 0/T + 1 cruzamento, reason codes, registros fiscais.
7. Observabilidade & Segurança - métricas/logs/pistas, alertas, RBAC, segmentação PCI.
8. Data/ML - mapeamento de risco, previsão de conversão por bancos/métodos.

3) Modelo de dados e idempotação

Payment Intent (PI): um único objeto para depósito/pagamento com campos: amount, currency, method, geo, BIN, risk _ score, rg _ limits, road _ history, idempotency _ key, status.
Idempotidade: Cada hop (PSP-A → PSP-B) é executado com uma idempotency _ key; A repetição de chamadas não altera o estado do candeeiro.
Rota Journal: registro de rotas e respostas (PSP id, reason code, latency, flow 3DS, fee), necessário para A/B e treinamento de modelos.

4) Algoritmo de rotação (referência)

4. 1 Recepção (Aquiring)

1. Pré-score: GEO, BIN/IIN, banco emissor, dispositivo, cheque, risco-screen, status RG.
2. Filtros de complacência: sanções/RER, geo-blocos, idade/auto-exclusão.
3. Regras de Custo/Sucesso: score = w1·AuthRate + w2 (- Fee) + w3 bloomberg Health - penalties.
4. Política 3DS: TRA/whitelisting/step-up sobre risco, seleção de challenge vs frictionless.
5. Escolha de rota PSP-A → → PSP-B → método alternativo (APM/open banking).
6. Smart Retry: mudança de modo 3DS, MID, mcc/fallback, tempo-becoff por reason codes (05/51/62 ≠ 91/96).
7. Post-processing: gravação no Road Journal, atualização da balança.

4. 2 Pagamentos (Payouts)

1. Priorização: Velocidade (momento/near-momento) ↔ custo ↔ disponibilidade.
2. KYT/AML/RG: velocity, pattern «abraçado», limites, fonte de fundos, listas de exceções.
3. Roteiro: card-to-card OCT/RTP/Faster Payments/SEPA Point/Pix/UPI.
4. Failover: queued payouts quando o banco/PSP não está disponível, fila drain periódica.
5. Confirmation: webhooks com assinatura que compensam transações em divergências.

5) Failover-pattern

5. 1 Circuit-breaker

Local (PSP): Ativa com error_rate↑, latency↑, spike in declins (issuer-especificic).
Global (por método): em uma falha da indústria (por exemplo, ACS/3DS em um grande banco).
Estados: Closed → Open → Half-open; os horários e liminares são definidos por segmentos GEO/BIN.

5. 2 Active-Active vs Active-Passive

Ativo-ativo: métodos PSP/paralelos; equilíbrio de acordo com as regras/valor; melhor RTO/RPO.
Atividade-Passive: Economizar em comissões/suporte, mas mais longo que RTO; adequado para GEO/técnicas secundárias.

5. 3 Degradation Modes

Desativar métodos high-risk, traduzir parte do tráfego para open banking/APM.
Compulsório 3DS challenge-all para BIN-ov/bancos «em chamas».
Limite temporário de montante/frequência (RG + risco).

6) Trabalhar com 3DS/SCA (dinâmico)

Frictionless padrão para baixo risco/cheques menores, challenge para high-risk.
As exceções PSD2 são LVA, MOTO, MIT - no orquestrador, não no aplicativo.
Fallback: Quando o ACS é degradado, aumenta o rate challenge ou desloca temporariamente o tráfego para um método alternativo (open banking).
KPI: challenge rate, frictionless share, post-3DS approvals.

7) Integração com antifrode/KYT/RG

Antes de o roteiro é um padrão (device, comportamento, proxy/VPN, risco BIN, histórico).
No roteiro, selecione 3DS/canal/PSP por risk _ score.
Antes do pagamento, KYT/velocity/anti-arb (win→withdraw rápido, múltiplos cartões, dispositivos relacionados).
Os limites RG e a auto-exclusão são regras «rígidas» para parar ao nível do orquestrador.

8) Observabilidade e dados

Métricas em tempo real: auth _ rate, decline _ reason mix, p95 latency, PSP health, 3DS sucess, payout time, queue depth.
Alerts: liminares para bancos/métodos, pente-pente com páginas de status externo.
A/B & Lerning: Atualização da balança de rotação baseada em conversão/custo; grupos de controle sem retrações para calibrar.

9) KPI e orientações de destino

Auth Rate (mapas): EU 85-92%, US 80-88%, LATAM 70-85% (sem orquestra - borda inferior).
p95 latency auth API: < 3 c; webhooks: < 60 c.
Share of Point Payouts: ≥ 70% dos cheques «leves».
Roting Efficiency (valor de conversão): + 5-10% para baseline por trimestre após a sintonia.
Circuito-break RTO: <2 min para alternar; RPO: 0 (idempotidade).
Chargeback rate: < 0. 5% por count (depende do produto/GEO).

10) Playbooks incidentes (parafuso)

10. 1 Seleções em massa por banco emissor

1. Confirmar spike por BIN/issuer.
2. Abrir o circuito local-breaker → redistribuir para alt-PSP/método.
3. Aumentar o challenge rate para BIN afetado, incluir smart retry.
4. Comunicação em canais estatais; RCA com dados de reason codes.

10. 2 Queda 3DS/ACS

1. Detecção de crescimento timeouts/» soft decline».
2. Transferir parte do tráfego para open banking/APM; incluir «challenge-all» onde o ACS estiver vivo.
3. Reduzir o cheque de risco (limite de soma/velocidade), aumentar o monitoramento.

10. 3 Instabilidade PSP

1. O health-alert → open breaker funcionou.
2. Transferência para PSP/MID de reserva; a proibição de métodos «pesados» de alta latência.
3. Restauração através de half-open com canários (1% a 5% do tráfego), seguida de gradation.

10. 4 Atrasos nos pagamentos

1. Transferência para queued payouts com prioridades (VIP, limite de valor).
2. Mudar a parte para caminhos alternativos (RTP/FPS/SEPA Point/Pix).
3. Notificações transparentes aos jogadores; escalações manuais> X relógio.

11) SLA e âncoras contratuais (o que exigir do PSP)

Disponibilidade: ≥ 99. 95% de admissão; p95 latency < 3 c; webhooks < 60 c.
Incidentes: TTA ≤ 15 min, caminho contornado (fallback MID/APM), RCA ≤ 5 dias.
Dados: reason codes crus, detalhamento sobre bancos, devolução de tokens ≤ 10 dias após a saída.
Finanças: limitação de reservas/holdback, fees transparentes (ativado 3DS/rede tocens), cap em aumentos FX.
Segurança: PCI-AOC, assinaturas webhooks, key rotation, SOC 2/ISO 27001 (preferencialmente).

12) Patternos regionais

EC/UK: PSD2/SCA; cartões + open banking (SEPA Point/FPS). Orquestra 3DS forte, TRA e whitelisting.
EUA: cartões + ACH; prioridade de pagamento instantâneo (push-to-card, RTP). Os circuitos Charjback são obrigatórios.
LATAM: Pix (BR), SPEI (MX), PSE (CO); APM-heavy; foco de risco e documento-KYC.
Turquia/CA: transferências locais/carteiras; Caminho de sanção/AML reforçado, limites de soma/velocidade.
Ásia/Índia: UPI/e-carteiras; regras velocity rigorosas; rotação por bancos emissores.

13) Folhas de cheque de implementação

Arquitetura/dados

• Payment Intent + idempotidade para todos os hops.
• Road Journal, reason codes crus, webhooks com assinatura.
• Separação de dinheiro/jogos; transações compensatórias.

Rotação/regras

• Rule-engine por GEO/BIN/issuer/risco/custo.
• Smart retry com tempo-becoff e mudança 3DS/MID.
• Circuito-breakers locais e globais; canary-retorno.

Risco/Complacência

• Integração risk/KYT/RG antes e depois do roteiro.
• Sanções/RER, idade/auto-exclusão - como filtros «rígidos».
• Limites de velocity/soma; registro de soluções.

Observabilidade/SLA

• Dashboard por Auth Rate, latency, decline mix, payout time.
• Alertas a liminares; runbooks para incidentes.
• SLA no contrato, QBR e multas por violações.

14) Pseudocode de estratégia (para comando)

on PaymentRequest(PI):
ensureIdempotency(PI.key)
risk = RiskEngine.score(PI)
if not ComplianceHub.pass(PI, risk): reject()

candidates = RouteCatalog.filter(PI.geo, PI.method, PI.bin, risk)
for route in rankBy(Score(AuthRate, Fee, Health, Risk), candidates):
res = PSP.call(route, PI, policy=ThreeDS.select(risk))
log(RouteJournal, route, res)
if res.approved: return approve(PI)
if isRetryable(res.reason): continue with SmartRetryAdjustments()
return decline(PI)

15) Economia e otimização A/B

Считайте effective rate = (Fees + 3DS + FX + chargeback cost − interchange rebates) / Approved Volume.
A/B: no mínimo 10k transações/ramo, 2-4 semanas; fique com os bancos/métodos.
Otimize o peso AuthRate vs Fee por GEO/sazonalidade; controlem a «distorção» em trilhos caros, mas de conversão.

16) O que é importante lembrar

Orquestrador + regras + dados - coração da estabilidade de pagamento e conversão.
Idempotidade/Payment Intent exclui duplo cancelamento e simplifica failover.
O circuito-breakers e o retorno canary permitem uma rápida estabilização sem «balanços».
SLA contratual e dados transparentes em PSP não são uma opção, mas uma exigência.
Roteiros regionais (open banking, RTP, Pix/UPI) são muitas vezes melhores que os cartões de velocidade/custo - leve em conta no roteiro.