Introdução
O formato de um pagamento
Um lojista que integra a InfraIO Pay lida com quatro peças em movimento:
Sessão de checkout
Você cria uma sessão no servidor com os itens da venda e os totais. A
resposta traz um session_key (cst_…) e uma checkout_url. As sessões
têm TTL (padrão de 30 min) e são de uso único.
Página de checkout hospedada
Você carrega o nosso SDK no navegador e abre a sessão — popup, redirect ou iframe embutido. O comprador escolhe uma combinação rede × ativo (USDT na Polygon, ETH na Base, …), vê um endereço de depósito gerado + QR e envia os fundos pela carteira dele.
Confirmação do pagamento
O payment-service observa a rede em questão buscando transferências de
entrada que combinem com o endereço de depósito da sessão. Quando o
pagamento atinge a quantidade configurada de confirmações (por exemplo,
12 na Ethereum mainnet, 5 na Polygon — veja Redes e ativos),
o PaymentIntent associado vai para SETTLED e o Order pai vai para PAID.
Webhook
A gente envia um POST assinado com o evento payment.settled para a URL
de webhook que você registrou. O seu servidor verifica a assinatura,
faz o join com o seu próprio pedido via external_ref e cumpre a entrega.
O modelo de dados em um diagrama
CheckoutSession ← 1:1 → Order ← 1:N → PaymentIntent
(com TTL) (permanente) (um por tentativa de pagamento)Você pensa em Orders para a entrega, cria Sessions para receber o pagamento e o sistema gerencia os PaymentIntents nos bastidores para retentativas / seleção de rede.
O que a gente cuida vs. o que você cuida
| A InfraIO Pay cuida | Você cuida |
|---|---|
| UI hospedada do checkout (endereço de depósito, QR, seletor de ativo) | Catálogo + criação do Order no seu banco |
| Monitoramento da rede + lógica de confirmações em 8 redes EVM | Receiver de webhook + verificação de assinatura |
| Checkout multi-ativo (USDT, USDC, ETH/BNB/POL/MNT nativos por rede) | Mapear o nosso order_id ↔ o ID do seu pedido via external_ref |
| Contabilidade de reembolsos (máquina de estados, dashboard, API) | Assinar + transmitir a tx de reembolso on-chain |
| Chaves de modo de teste + webhooks de teste isolados | Abastecer carteiras de testnet a partir de torneiras (faucets) |
A gente não retém custódia dos fundos do lojista. As transferências do comprador para o lojista acontecem diretamente on-chain; a gente é a camada de indexação + reconciliação que avisa quando a transferência foi confirmada.
Modo de teste vs. modo live
Toda conta começa em modo de teste. As chaves de teste têm o prefixo
pk_test_ / sk_test_. As chaves live (pk_live_ / sk_live_) ficam
condicionadas a:
- KYB concluído
- Atestado de carteira de tesouraria (você assina uma mensagem provando que controla a carteira de destino em cada rede em que quer receber)
A mesma URL base da API atende aos dois — o ambiente é determinado pelo prefixo da chave, não pela URL. O modo de teste roda contra testnets reais (Sepolia, Base Sepolia, BSC Testnet, etc.) — não existe rede fictícia. Para acionar um pagamento de teste você precisa de fundos reais de testnet, vindos de uma torneira.
O que a InfraIO Pay não é
- Não é um custodiante. Os fundos vão do comprador para a carteira do lojista on-chain, direto. A gente nunca retém saldo.
- Não é um provedor de carteira. Os clientes trazem a própria carteira; o checkout hospedado tem uma opção embutida de WalletConnect, mas nenhuma custódia nativa.
- Não é uma rampa fiat. Os compradores pagam no ativo cripto que têm; a gente não converte.
- Não é um gateway para Tron ou Solana hoje. EVM em primeiro lugar. Veja Redes e ativos para a matriz atual.
Próximos passos
- Início rápido — copie e cole a sua primeira integração em ~10 minutos.
- Conceitos → Sessões — o modelo de dados em profundidade.
- SDK → JavaScript — o único SDK publicado hoje.