CASO DE USO

Valide payouts de remessas LATAM antes do rail de pagamento

Uma remessa USD -> BRL que sai com Pix key malformada termina em reverse, ticket de suporte e cliente irritado. O rail de pagamento (Stripe, dLocal, Mercado Pago, PSP local) recebe a instrucao, tenta processar, e a transferencia falha — na melhor hipotese — ou cai em limbo, na pior. Validar formato do Pix/CBU/CLABE antes da instrucao ao rail elimina essa classe inteira de falhas.

Entrar na lista de espera Ler documentacao

O PROBLEMA

Reverses de cross-border tem custo desproporcional

Um payout revertido por formato custa taxas do rail, ticket de suporte, ciclo de FX cancelado e as vezes explicacao ao cliente final. Detectar o erro no client antes de iniciar o rail e ordens de magnitude mais barato.

Tres rails distintos por pais, tres formatos-chave

AR usa CBU (22 digitos, checksum). BR usa Pix (chave pode ser CPF, CNPJ, email, telefone ou UUID aleatorio). MX usa CLABE (18 digitos, Luhn-like). Uma integracao cross-border para LATAM precisa validar tres formatos diferentes antes de cada payout — cada um com seu algoritmo.

Tax ID pre-flight para compliance

Muitos rails LATAM exigem tax ID do beneficiario no request (CPF para Pix, CUIT para CBU). Se o tax ID vem malformado, o rail rejeita a instrucao. Pre-validar tax ID + conta evita o reverse downstream.

Suporte sobre payouts falhos nao escala

Cada payout revertido gera um ticket: o cliente final pergunta por que nao recebeu o dinheiro, o time de suporte precisa diagnosticar (formato vs. conta inexistente vs. titular errado), explicar e tentar de novo. Em volume, consome horas de suporte por semana.

POR QUE AS SOLUCOES PADRAO NAO SAO SUFICIENTES

Por que validar so no rail chega tarde

Confiar na validacao do rail

O rail (Stripe, dLocal, Mercado Pago) valida formato — mas so quando recebe o request. Voce ja iniciou FX, bloqueou fundos, gerou um transaction ID. Reverter custa tempo e dinheiro.

Regex por pais no client

Um regex para CBU pega comprimento mas nao checksum. Uma Pix key tipo email passa qualquer regex mas pode ser um email invalido. CLABE tem Luhn-like que regex nao calcula.

Revisao manual de operations

Alguns times incluem revisao manual de payouts grandes. Nao escala e nao se aplica a payouts pequenos que falham em volume.

COMO O NORMADATA AJUDA

Como o Normadata ajuda

Chame verify/bank antes de montar o request ao rail. Pix, CBU, CLABE: uma API, mesma estrutura de resposta. Se valid=false, o payout fica em pending ate corrigir.

Complemente com verify/tax-id se o rail exige tax ID do beneficiario (frequente em BR/AR/MX). O gate combinado (conta valida + tax ID valido) elimina reverses estruturais.

O campo normalized da resposta e o que voce envia ao rail — a forma canonical do Pix key, CBU ou CLABE que o rail espera, independentemente de como veio formatado.

VEJA EM ACAO

Veja em acao

# Validate Brazilian Pix key (CPF format) before USD->BRL remittance
$ curl -X POST api.normadata.io/v1/verify/bank \
  -H "X-API-Key: nd_a8f3b2c1d4e5f6g7h8i9j0k1l2m3n4o5" \
  -d '{"country":"BR","type":"pix","value":"111.444.777-35"}'

{
  "valid": true,
  "normalized": "11144477735",
  "identifier": {
    "type": "PIX_KEY",
    "category": "bank_account"
  }
}

# Same gate covers CLABE (MX), CBU (AR), Pix (BR)
# Skip the FX + rail leg if format is bad — no reverse, no support ticket

LIMITACOES

O que o Normadata nao faz aqui

—O Normadata nao processa o rail de pagamento, nao faz FX, nao e PSP. Validamos o dado antes de voce chamar o rail.

—O Normadata nao confirma que a conta existe ou pertence ao titular nomeado. Nao fazemos confirmacao de titularidade bancaria, nao consultamos o Banco Central, nao validamos AML.

Ver limitacoes completas

PERGUNTAS FREQUENTES

Perguntas frequentes

Funciona com Stripe, Mercado Pago ou dLocal como rail?

Sim, o Normadata e agnostico ao rail. Voce chama antes de montar o request ao rail (seja Stripe Connect, dLocal payouts, Mercado Pago marketplace, ou PSP local). A resposta diz se o dado e estruturalmente valido.

Confirma que a conta pertence ao titular nomeado?

Nao. Validamos que o formato do Pix/CBU/CLABE esteja estruturalmente correto. Confirmacao de titularidade bancaria e outra camada, tipicamente feita pelo banco ou por servico especifico de account verification, nao pelo Normadata.

Ver validadores →

See endpoint in docs →

Integre o Normadata no seu stack

Acesso antecipado. Entre na lista e daremos acesso à API.

Entrar na lista de espera Ler documentacao