Toquenização de cartões e fluxos PAN-safe

1) Porquê toquenizar e o que é PAN-safe

• minimizar o CSI PCI (e o custo de controle),
• reduzir o risco de fuga,
• melhorar a permissão (substituições automáticas, COF, one-click),
• simplificar a rotação multi-PSP e os cancelamentos de novo.

O fluxo PAN-safe é um cenário personalizado e servidor onde o PAN só aparece dentro de um perímetro de confiança isolado (valt/TSP/PSP iframe) e nunca passa pelo seu becand/logs/pneus de eventos em aberto.

2) Tipos de token e ciclo de vida

2. 1 Vault-tokens (privados)

Gerados pela sua valt de token ou por um prestador de cofre de terceiros.
São ligados ao PAN, mas a correspondência reversível é armazenada apenas em valtas (HSM).
São usados para roteiros para qualquer PSP/Acawyer (flexibilidade).
Além disso, independência dos esquemas; Menos: Você precisa do seu próprio compliant-valt.

2. 2 Rede-tokens (esquemas; Visa/Mastercard/AmEx TSP)

São lançados através do TSP; muitas vezes acompanhados de devica-/merchant-binding e criptograma.
Melhoram a permissão: acima de approval rate, menos frod-falls positivo.
Suportam a atualização automática ao transferir o cartão.
Menos: suporte PSP/processador e cobertura de mercado.

2. 3 Descartáveis (single-use) e reutilizáveis (COF)

Single-use: para cancelamento/inicialização ESCA descartável.
COF (Card-on-Fights): para assinaturas, retroescavadeiras, pagamentos repetidos.

2. 4 Ciclo de vida

1. Inicialização: a frente não recebe campos de pagamento do seu domínio (campo de hospedagem/iframe TSP/PSP).
2. Tokenização: PAN → token (vault ou network), produção de criptograma (se necessário).
3. Armazenamento: token e metadados (BIN, esquema, prazo, domínio-binding).
4. Uso: permissão/capchur/retrai por token.
5. Rotação/atualização: update automático (network), card updater (vault/PSP).
6. Revogação/remoção: a pedido do usuário (GDPR/DSR) ou política de retenção.

3) Pattern de arquitetura PAN-safe

3. 1 Camada de cliente (web/mobile)

Hosted fields/ iFrame SDK de PSP/TSP: PAN é introduzido fora do seu DOM.
Seu frontand recebe apenas o token + atributos não ritíticos (últimos 4 dígitos, BIN-meta).
O SCA/3DS começa pelo provedor; os seus servidores recebem o resultado/veredicto.

3. 2 Serviços «Payments Orquestrador»

Não vê PAN; a operar em Tóquio.
Implementa: routing (primary/segundary PSP), idempotency keys, retries/backoff, smart-routing (por BIN/regiões/conversão).
Mantém as regras de config e as provas de health PSP (SLI/SLO).
É capaz de detokenize-proxy (apenas como «serviço-passarela» dentro de um perímetro de confiança para uma valta).

3. 3 Tocen-valt (se o seu)

HSM-Backand, criptografia compatível FIPS.
Isolamento de rede/segmentação, AAA (MFA/least privege), revistas de auditoria, rotação chave.
API: tocenize (), detokenize (), rotate (), purge () com LCA/Scopes finos.
O suporte ao formato-presenting encrypition (FPE) é opcional se você precisar de armazenamento visualmente «mascarado».

3. 4 Pneu de evento e DWH

Os eventos incluem apenas tokens e metadados seguros.
O link de autorização ↔ capchura/refanda através de payment _ id (não PAN).
Os armazéns BI são proibidos por PAN e CVV.

4) Fluxos (diagramas de texto)

4. 1 COF primário (salvar o cartão)

1. User → Hosted Fields (PSP/TSP iframe) introduz o PAN.
2. O PSP/TSP → devolve o tocen (+ device binding/cryptograma).
3. Front → Backend (Orchestrator): `{token, order_id, context}`.
4. Orquestrador → PSP: 'auth' por token (possível 3DS challenge).
5. PSP → Orchestrator: `auth_result`.
6. Orquestrador → Wallet Service: Salvamos 'tocen' e meta.

O PAN não aparece em nenhum dos seus serviços.

4. 2 Novo cancelamento/assinatura

1. Scheduler/Business → Orchestrator: `charge(token, amount)`.
2. Orchestrator → PSP: `capture/auth`.
3. PSP → Orquestrador: resultado + arn/rrn.
4. Orchestrator → Ledger/Reconciliation.

4. 3 Failover и smart-routing

Regra: 'IF PSP _ A. degraded OR BIN in {X} THEN PSP_B ELSE PSP_A`.
Para os rede-tokens, certifique-se de que ambos os PSP suportam sua adoção; senão, mantenha a referência binária (rede + vault).

5) 3DS e SCA no circuito PAN safe

O 3DS2 é lançado a partir do hosted SDK; seus servidores aceitam alias estatais (frictionless, challenge, failure).
Vincule o veredicto 3DS ao payment _ id; armazenem artefatos transacionais (ARES, Cres refs) sem PAN.
Para recarregamentos (MIT/recurring/unscheduled COF): marca corretamente as bandeiras de transação (tipo MIT, CIT reference inicial).

6) Segurança, complacência e política de dados

Cúmulo PCI DSS: frente sem PAN, becand sem PAN ⇒ avaliação simplificada (SAQ-A/variações). Se houver uma valt/detonação própria - caixote superior (SAQ-D).
HSM/rotação chave: rotações periódicas de chaves mestre, dual control, split knowledge.
GDPR/DSR: Remover o token e os metadados associados a pedido do usuário (o PAN permanece desconhecido).
Logi/trailer: Camuflagens rígidas, detectores de vazamento (DLP), saneamento durante a serialização de erros.
Segmentação: valt no segmento selecionado; acesso: apenas por mTLS e tocadores (STS).

7) Integração com PSP/Acavaiers

7. 1 Conjunto mínimo de recursos PSP para safe PAN

Hosted fields/SDK com torneamento.
Adoção de network tocens (se possível) e/ou exportação de vault-tokens.
Card updater, marcação COF, bandeiras MIT.
3DS server + orquestra SCA.
Webhooks com entrega e assinatura idempotent.

7. 2 Multi-PSP Arquitetura

Abstração de «conector» no Orquestrador (unificação de campos).
Tabela de balanças/prioridades + health-pings.
Tabela de políticas BIN (esquema, região, produto, risco-mapeamento).
PSP de reserva para rotas críticas (fallback SLA).

8) Atualização dos cartões e durabilidade dos tokens

Rede tokens: Atualização automática de transferência (melhor para LTV).
Vault tokens: use o card updater (via PSP/3rd-party).
Monitorar prazos de vencimento, notação ao usuário, retais suaves (exponential backoff + jitter).
Vincular o COF a um account-id, e não ao usuário PII, para um simples reaproveitamento.

9) Retraias, erros e idempotency

Idempotency-key = хеш(merchant_id, account_id, order_id, attempt_n).
Categoria de erros: hard (decline código permanente) vs soft (timeout, network, risk pending).
Backoff: 1m → 10m → 1h → 24h com limite superior e cancelamento com hard-decline.
Deduplicar webhooks: guarde event _ id e transições estatutárias (state machine).

10) Reconciliação e finanças

Faça o Ledger de pagamento sem PAN: 'payment _ id', 'psp _ txn _ id', 'arn/rrn', 'token _ id', estatais.
O rect diário de arquivo de PSP/Acaveyer; somas, comissões, charjbacks.
Pipas individuais para refunds/voids/chargebacks; concordância com o bilhete/contabilidade.
KPI PSP/países/BIN.

11) Métricas e alvos (KPI)

Segurança/Complacência

% dos serviços que nunca veem PAN (objetivo: 100%).
PCI scope level (abaixo - melhor).

Negócios

Approval Rate (AR) por tipo de token (network vs vault).
COF retence rate, proporção de métodos atualizados automaticamente.
D + 0/D + 1 divergências de reconsilação (objetivo: → 0).

Técnica

Hora de toquenização p95.
Proporção de transações via fallback PSP.
Para detonação (objetivo: minimizar, apenas dentro da valta).

12) Frequentes anti-pattern

Logar PAN/CVV em exceções.
Formulários de cliente sem campos hosted.
Enviar o PAN através do seu pneu de API «temporariamente».
Misturar tocantes de domínios diferentes sem uma política explícita (risk).
Falta de cartão de rotação (todos os pagamentos «em um PSP»).
Armazenamento de artefatos 3DS com PII em excesso.

13) Plano de implementação (por passo)

1. Frontend: integrar hosted fields/SDK, remover formulários de pagamento próprios.
2. Escolha PSP/TSP: Confirmando suporte à rede tocens, 3DS2, webhooks, card updater.
3. Orquestrador: camada de abstração sobre PSP, regras de routing, idempotency, retrias.
4. Valt (opcional): Selecionamos managed-vault ou construímos o nosso (HSM, LCA, rotações).
5. Dados/eventos: proibição do PAN no pneu e no DWH; implantar o DLP-gate em CI/CD.
6. Complacência: atualizar área PCI, procedimentos, registros de auditoria, testes de disfarce.
7. Observabilidade: métricas AR/LSR/latency PSP, alertas de degradação, frascos.
8. Economia: A/B teste rede vs vault tokens de AR/frod/custo, otimização de flow.

14) Folha de cheque PAN-safe

• Digitar PAN apenas em iframe/hosted fields.
• Beckend nunca aceita PAN/CVV.
• Os tokens são criptografados no armazenamento, as chaves no HSM, a rotação está ativada.
• 3DS2 e SCA são marcados corretamente (CIT/MIT/COF).
• Routagem Multi-PSP e failover testados.
• O card updater (network/PSP) está ativado.
• Logs/trens/dampas - sem PAN (máscaras/sanitários).
• Reconciliação e marceback-pipline sem PAN.
• As políticas GDPR/remoção de tokens foram implementadas.
• Métricas e alertas cobrem a qualidade do token flow.

15) Glossário breve

PAN: Número do cartão.
Token (vault/network): substituto de PAN seguro.
TSP: Tocen Service Provider (serviço de token de rede).
COF/MIT/CIT: armazenamento de cartão/iniciativa merchant/iniciativa do cliente.
HSM: módulo de segurança de hardware.
SCA/3DS2: forte autenticação/protocolo de autenticação por cartão.

16) Resumos

O torneamento é uma técnica básica para reduzir os riscos PCI, aumentar o rate approval e fazer roteiros flexíveis de pagamento no iGaming. Combine a rede tocens (com conversão e atualizações automáticas) com vault tocens (controlando e independentemente), construa um flow PAN-safe com campo hosted, orquestrador, controle de chaves e observação transparente da permissão à reconciação. Isso dará segurança, escala e monetização previsível.