Gateway de pagamento cripto: aceitar USDT/USDC com KYT e settlement em uma key
Aceitar USDT e USDC é hoje um pedido concreto de lojistas brasileiros que querem receber sem a volatilidade do BTC e com a velocidade de um pagamento instantâneo. Um PSP que faz isso precisa cobrar (invoices e checkout), verificar de onde vem cada pagamento (KYT e sanctions) e liquidar para o lojista. Esta ficha descreve como um gateway cripto reúne cobrança, verificação e settlement sobre nós próprios, com uma key e um saldo em credits.
O desafio
O problema central de um PSP de stablecoin não é gerar o endereço de cobrança, é o que acontece depois que o dinheiro chega. É preciso detectar pagamento a menos e a mais, contar confirmações da rede, verificar se os fundos recebidos não vêm de carteira sancionada ou de origem de alto risco antes de reconhecer a venda, e só então liquidar ao lojista. Se o webhook de confirmação for entregue duas vezes, o sistema não pode creditar a venda em dobro. Amarrar cobrança, KYT e liquidação em fornecedores separados multiplica os pontos onde essa consistência pode quebrar.
- Invoices / checkoutC2
- Transaction screening / KYTC3
- Sanctions check + feedC2
- Mass payout / settlementC2
Checkout hospedado com rastreio de pagamento a menos e a mais
O lojista gera uma invoice e o comprador paga em USDT ou USDC por um checkout hospedado. A plataforma acompanha o endereço e distingue os casos reais do dia a dia: valor pago abaixo do cobrado, valor acima, e a contagem de confirmações da rede antes de considerar o pagamento firme. Isso evita reconhecer como paga uma cobrança que ainda está pendente ou incompleta.
KYT e sanctions decidem o que pode ser liquidado
Sobre os fundos recebidos rodam KYT e screening de sanctions. Só pagamento aprovado segue para settlement: se a origem do USDT/USDC estiver ligada a carteira sancionada ou a exposure de alto risco, o pagamento fica retido para análise em vez de ser liquidado automaticamente ao lojista, o que protege o PSP de assentar dinheiro problemático.
Eventos assinados e idempotentes na liquidação ao lojista
A confirmação e a liquidação disparam eventos assinados, para o lojista verificar a autenticidade, e idempotentes: uma entrega duplicada do mesmo evento não credita a venda duas vezes. O settlement ao lojista consome o mesmo saldo de credits usado no checkout e no KYT, então cobrança, verificação e pagamento vivem em um único fluxo financeiro.
O que a arquitetura entrega
- Cobrança em USDT/USDC, KYT com sanctions e liquidação ao lojista passam a operar em uma key e um saldo, sem três integrações separadas para um único fluxo de venda.
- Apenas pagamentos aprovados são liquidados, porque o screening sobre os fundos recebidos roda antes do settlement e não depois.
- Entrega duplicada de webhook não gera crédito em dobro, já que os eventos de confirmação são assinados e idempotentes.
Perguntas frequentes
Como o gateway lida com o cliente que paga menos ou mais do que o valor da invoice?
O rastreio do checkout compara o valor recebido com o cobrado e marca explicitamente os casos de pagamento a menos e a mais, em vez de aprovar ou rejeitar de forma cega. A contagem de confirmações também é acompanhada, de modo que a invoice só é considerada firme quando o valor e as confirmações fecham segundo as regras que você define.
Se o meu sistema receber o mesmo webhook de confirmação duas vezes, a venda é creditada em dobro?
Não. Os eventos são idempotentes: a segunda entrega do mesmo evento é reconhecida como repetição e não gera novo crédito. Além disso, os eventos são assinados, então o seu backend consegue validar que a notificação veio da plataforma antes de processar a liquidação.
Recarregue, pegue a chave e publique.
Autoatendimento. Pague em cripto ou cartão. Medido por créditos: primitivas pesadas custam mais, as simples são baratas.
Obter chave de API