Cascadura ao nível dos provedores

1) O que é cascata e porquê em iGaming

• AR↑/ DR↓: contornar os emissores «caprichosos», escolher o melhor PSP para um determinado BIN/geo/método.
• Custo: IC + +/markup mais baixo em parte da cesta, minimização da fia de fixe em micro-bilhete.
• Sustentabilidade: failover em incidentes, degradações 3DS, queda de corredores de pagamento.
• Complacência: Cumprimento de geopolítica, sanções, proibições locais e licenças.

2) Pattern Cascavel

1. Sequencial (sequential)

PSP _ A → (soft-decline/falha técnica) → PSP _ B → PSP _ C.
É usada uma «janela estreita» de retrações para não criar suplementos/riscos de múltiplos fundos.

2. Paralelo (split-traffic/multi-arm)

Distribuição de fluxo (%/regras) entre vários PSP para benchmark, treinamento de regras e redução de falhas correlacionadas.

3. Sticky BIN / Sticky GEO

Memorizar o «melhor» PSP para uma faixa de BIN/emissor/geo específica.

4. Method-aware / Feature-aware

Provedores de cartões diferentes, A2A, carteiras, métodos locais; consideração de especificidades 3DS-rails, DCC/FX-comportamento, tocenização.

5. Limit-aware / SLA-aware

Registro de limites de provedores, reservas, incidentes SLA, cut-off e atrasos funding.

3) Motor decisivo (rulas-engine): sinais de entrada

Sinais de cartas BIN/IIN, brand, debit/credit, comercial/premium, country of issuer.
Geo e complacência: país do jogador (IP/GPS/SIM/KYC), sanções, licenças.
Transação: valor (menor units), moeda, canal (web/app), risco-screen.
Histórico de provedores: AR/DR. por BIN/geo/método nos últimos 15-60 min, proporção de soft-decline, 3DS-pass-rate.
Custo: IC + +/markup/fix, FX spread, rolling reserve%.
Limitações: provedor de rate-limit, maintenance/incidentes, capas de circulação diurna.

Saída: lista prioritária de rotas '[(PSP, MID, require _ 3DS, retry _ window _ ms, max _ attempts)]'.

4) Retraias, Idempotidade e segurança

Idempotency-key para tentativa (user _ id + order _ id + nonce), comum a todos os provedores em cascata.
Retrai apenas em soft-decline (rede/3DS/timeout/insufficient funds), nunca com códigos «rígidos» (stolen, do not honra novamente e etc).
Anti-dooling: O status de 'AUTORIZED '/' CAPTURED' fecha a cascata; todos os outros ramos são cancelados.
Janelas: 1 retrai ≤ 2-5 segundos, orçamento total ≤ 15-30 segundos, considerando UX.
Política 3DS: possivelmente step-up no segundo/terceiro ramo, se o primeiro caiu sem 3DS.

5) 3DS, liability shift и AR

A seleção de 'frictionless '/' challenge' depende do risco e suporte PSP (delegated auth, TRE, whitelisting).
Em «severos» geo/emissores - compulsório 3DS em parte da cesta.
Rastree a liability shift através dos provedores: onde é mais frequentemente alcançado - para onde transportar o BIN's arriscado.

6) Custo: IC++, blended, fias e FX

Para cada PSP, leia o efetivo take-rate = interchange + scheme + markup + fixed + FX-slippage.

• `Score = w1AR_live + w2(−Cost_bps) + w3(SLA_health) + w4(FX_quality) +...`
• Micro-bilhete: Peso de fias de fix superior → preferido por provedores de fix baixo.
• Contabilize separadamente a reserva% e funding T + N - afeta o flow de dinheiro.

7) Incidentes, cut-off e rotação

Health-fid: Estágios PSP/corredores (auth API, 3DS ACS, payout rails).
Auto-failover: rerute instantâneo quando AR/health cai abaixo do limite.
Cut-off-aware: Antes de fechar o setlment, evite partital-capture em PSP com T + N. desconfortável.
Throttling: Para não «queimar» o limite do provedor, espalhe o tráfego.

8) Modelo mínimo de dados

sql
-- Providers and MIDs
CREATE TABLE ref. providers (
provider TEXT PRIMARY KEY, model TEXT, pricing_model TEXT, fx_policy TEXT, reserve_pct NUMERIC, meta JSONB
);
CREATE TABLE ref. mids (
mid TEXT PRIMARY KEY, provider TEXT REFERENCES ref. providers, country TEXT, method TEXT, descriptor TEXT, meta JSONB
);

-- Cascade Rules/Profiles
CREATE TABLE ref. cascade_profiles (
profile_id BIGSERIAL PRIMARY KEY, name TEXT, version TEXT, enabled BOOLEAN, meta JSONB
);
CREATE TABLE ref. cascade_rules (
rule_id BIGSERIAL PRIMARY KEY, profile_id BIGINT REFERENCES ref. cascade_profiles,
geo TEXT, bin_from TEXT, bin_to TEXT, method TEXT,
provider TEXT, mid TEXT, require_3ds BOOLEAN, priority INT,
retry_on_soft JSONB, max_attempts INT, ttl_seconds INT, enabled BOOLEAN, meta JSONB
);

-- Online Provider Performance Metrics (Sliding Window)
CREATE TABLE live. provider_stats_15m (
provider TEXT, method TEXT, geo TEXT, bin6 TEXT,
approvals INT, declines INT, soft_declines INT, three_ds_pass INT,
avg_latency_ms INT, updated_at TIMESTAMP
);

-- Transactions with idempotency and selected route
CREATE TABLE payments. auth_attempts (
attempt_id BIGSERIAL PRIMARY KEY, idempotency_key TEXT, step INT,
provider TEXT, mid TEXT, require_3ds BOOLEAN, status TEXT, decline_code TEXT,
amount_minor BIGINT, currency TEXT, bin TEXT, geo TEXT,
started_at TIMESTAMP, finished_at TIMESTAMP, meta JSONB
);

9) Modelos de análise SQL

9. 1. Classificação de provedores online (AR e soft-decline share)

sql
SELECT provider, method, geo,
SUM(approvals) AS appr,
SUM(declines) AS decl,
ROUND(100. 0 SUM(approvals) / NULLIF(SUM(approvals+declines),0), 2) AS ar_pct,
ROUND(100. 0 SUM(soft_declines) / NULLIF(SUM(declines),0), 2) AS soft_share_pct
FROM live. provider_stats_15m
WHERE updated_at > now() - INTERVAL '20 minutes'
GROUP BY 1,2,3
ORDER BY ar_pct DESC, soft_share_pct DESC;

9. 2. Efeito cascata em pedidos (step-conversion)

sql
WITH s AS (
SELECT idempotency_key,
MAX(step) AS steps,
BOOL_OR(status='APPROVED') AS approved
FROM payments. auth_attempts
WHERE started_at BETWEEN:from AND:to
GROUP BY 1
)
SELECT steps,
COUNT() AS orders,
100. 0 SUM(approved::int) / NULLIF(COUNT(),0) AS conv_pct
FROM s
GROUP BY 1
ORDER BY 1;

9. 3. Sticky BIN: melhor provedor de BIN6

sql
SELECT bin6,
provider,
ROUND(100. 0 SUM(approved)::NUMERIC / NULLIF(COUNT(),0), 2) AS ar_pct
FROM (
SELECT LEFT(bin,6) AS bin6, provider, (status='APPROVED') AS approved
FROM payments. auth_attempts
WHERE started_at BETWEEN:from AND:to
) t
GROUP BY 1,2
QUALIFY ROW_NUMBER() OVER (PARTITION BY bin6 ORDER BY ar_pct DESC) = 1;

9. 4. Custo do provedor (all-in take-rate)

sql
SELECT provider,
SUM(amount_reporting) AS volume_rep,
SUM(interchange_amt + scheme_amt + markup_amt + auth_amt + refund_amt + cb_amt + gateway_amt + fx_spread_amt) AS fees_rep,
100. 0 SUM(interchange_amt + scheme_amt + markup_amt + auth_amt + refund_amt + cb_amt + gateway_amt + fx_spread_amt)
/ NULLIF(SUM(amount_reporting),0) AS take_rate_pct
FROM finance. settlement_fees
JOIN dw. transactions_flat USING (provider)
WHERE period_start_at >=:from AND period_end_at <:to
GROUP BY 1
ORDER BY take_rate_pct;

10) KPI e dashboards

AR/DR. por provedores e BIN/geo/método (janelas online de 15/60 min e day-to-data).
Step-conversion: proporção de aprovações no ramo 1, 2, 3.
Take-Rate% e FX-slippage por provedor/MID.
3DS pass-rate e uma proporção de liability shift.
Health/SLA: latency, timeouts, erro rate, incidentes.
Reserve & Funding: reserve% e T + N hit-rate por provedores.

11) Alertas e liminares

Roting Degradation: queda do AR do provedor selecionado> Y bps em 10 a 30 minutos.
Soft-decline surfe: o crescimento da fatia de soft-decline → permitir um ramo adicional de cascata.
3DS Anataly: queda 3DS pass-rate> X% para um emissor/cluster BIN específico.
Take-Rate Spike: crescimento all-in valor> limiar bps.
Health Down: SLA breach (latency/error) — авто-failover.
Policy Drift: tentativas sem idempotency _ key/sem perfil cascata - P1.

12) Testes AB e treinamento de regras

Multi-arm bandit ou split-traffic fixo para novas rotas.
Explore/Explorer: parte do tráfego é mantido para «treinamento» sticky BIN.
Horizontes de avaliação online (15/60 min) para incidentes e semana/mês para o custo.
Guardrails: mínimo AR/max take-rate para parar a experiência.

13) Complaens e casos «extremos»

Respeitar sanções/licenças/geoblocks: alguns provedores não podem atender países/métodos individuais.
Same-method/Return-to-nature: a cascata não deve quebrar a política de retorno.
Tokenization/PCI: um único esquema de token entre PSP (rede tocens/vault).
Marcebacks: Regue por qual ramo a capture passou - para displays.

14) Best pratices (curta)

1. Retrate apenas soft-decline, com uma única idempotency _ key.
2. Mantenha a telemetria viva AR/3DS/soft-decline e health provedores.
3. Construa a função de preço da rota (AR vs Costa vs SLA vs FX).
4. Use sticky BIN e testes AB; versionalize os perfis de cascata.
5. Seja cut-off-aware: Não produza partial-capture ao final do dia.
6. Tenha playbooks failover: queda PSP/ACS/corredor de pagamento.
7. Divida dados e responsabilidades: quem mantém o PAN, quem mantém o display.
8. Conduza o reserve-ledger pelos provedores: lançamentos e cancelamentos.

15) Folha de cheque de implementação

• Cartão de provedores/MID, pricking (IC + +/blended), políticas FX, reservas, T + N.
• Rulas-engine: perfis, regras, soft-codes, políticas 3DS, limites.
• Roteador: Idempotação, Retrações, temporizações, sticky BIN.
• Telemetria: métricas live AR/DR./3DS/latency/health; Alertas.
• Gerenciamento de incidentes e playbooks failover.
• ETL para fees/FX/reserve; vitrines take-rate e step-conversion.
• Procedimentos de testes AB e guard.
• Documentação: limitações de compliance, restituições de same-method, responsabilidade.

Currículo

A cascata ao nível dos provedores não é «experimentar outro PSP», mas disciplina: métricas vivas, rulas-engine inteligente, idematicidade rigorosa, táticas 3DS corretas, contabilidade de custo/FX/reservas e cenários failover prontos. Essa arquitetura aumenta o AR, reduz o all-in take-rate e torna o circuito de pagamento resistente a falhas e restrições regulatórias.