Skip to Content
ConceitosRedes e ativos

Redes e ativos

A InfraIO Pay é EVM em primeiro lugar e stablecoin em primeiro lugar. Toda rede suportada é configurada no registry networks.json do payment-service; a matriz abaixo espelha o que está vivo em teste e mainnet hoje.

Mainnet

RedeChain IDNativoUSDCUSDTConfirmaçõesPedido mínimo
Ethereum1ETH✓ (ERC-20)✓ (ERC-20)12$5.00
Base8453ETH✓ (ERC-20)—10$1.00
Polygon137POL✓ (ERC-20)✓ (ERC-20)5$1.00
BSC56BNB✓ (18 decimais)✓ (18 decimais)5$1.00
Arbitrum42161ETH✓ (ERC-20)✓ (ERC-20)5$1.00
Optimism10ETH✓ (ERC-20)✓ (ERC-20)5$1.00
ZKsync Era324ETH——5$1.00
Mantle5000MNT——5$1.00

USDC e USDT na BSC usam 18 decimais, não 6 como em todo lugar. Se você está calculando valores no lado do cliente por algum motivo, leve isso em conta — caso contrário os campos de valor do SDK cuidam disso.

“Pedido mínimo” é o piso em USD aplicado no momento de criação do payment-intent. Os padrões enviados hoje são $1.00 mainnet / $0.50 testnet, com a Ethereum subindo para $5 porque o gas da L1 empequena pedidos menores. Operações de admin podem sobrescrever por rede — pedidos abaixo do piso são rejeitados com AMOUNT_BELOW_MINIMUM (HTTP 400), e details.floor_usd carrega o valor configurado real para que o seu FE possa exibir.

Testnet

RedeChain IDNativoConfirmaçõesPedido mínimo
Ethereum Sepolia11155111ETH1$0.50
Base Sepolia84532ETH1$0.50
Polygon Amoy80002POL1$0.50
BNB Smart Chain Testnet97tBNB1$0.50
Arbitrum Sepolia421614ETH1$0.50
OP Sepolia11155420ETH1$0.50
Mantle Sepolia5003MNT1$0.50
ZKsync Sepolia300ETH1$0.50

O modo de teste usa testnets reais, não uma rede fictícia. Para acionar um pagamento de teste você precisa de fundos reais de testnet — pegue numa torneira (por exemplo, sepoliafaucet.com , coinbase.com/faucets ) e envie para o endereço de depósito que a página de checkout gera.

Códigos de moeda usados na API

currency (no body de nível superior e em cada item) é a moeda de exibição do pedido — o que o comprador vê como valor. Hoje a plataforma aceita um único código no momento da criação:

  • "USD" — o único valor para o qual IsSupportedCurrency retorna true no payment-service. Tanto POST /v1/orders quanto POST /b2b/v1/checkout-sessions/quick rejeitam qualquer outra coisa com INVALID_INPUT (“unsupported currency”). A lista divulgada fica em GET /v1/supported/currencies para que o enum do servidor e o seu cliente nunca fiquem dessincronizados.

O ativo on-chain em que o comprador liquida (USDC, USDT, …) não é o campo currency. Ele é escolhido pelo comprador na página de checkout a partir das combinações rede × token que você habilitou na sua config de lojista e volta para você no PaymentIntent + payload do webhook como settlement_token (símbolo + rede). Tokens de gás nativos (ETH, BNB, POL, MNT) são metadado da rede apenas — não são moedas válidas de pagamento.

A rede em si também não é especificada no momento da criação — pelo mesmo motivo: o comprador escolhe a combinação na página de checkout.

Confirmações vs. finalidade

A coluna “Confirmações” acima é o número de blocos que o watcher da rede espera antes de virar um PaymentIntent para SETTLED e disparar payment.settled. Os padrões estão calibrados para dar finalidade probabilística em cada rede em profundidades típicas de reorg:

  • O 12 da mainnet Ethereum é o valor que a maioria das exchanges usa pós-Merge.
  • L2s liquidam mais rápido mas herdam a finalidade da Ethereum eventualmente — a contagem por rede reflete o risco de reorg da própria L2, não da L1.
  • Testnets ficam em 1 conf para manter o loop de desenvolvimento rápido; não extrapole para segurança nível mainnet no seu ambiente de dev.

Se você precisa de confirmações mais rígidas (ou mais soltas) para uma rede específica, a contagem por rede é configurável na conta do lojista — fale com o seu contato de conta.

Habilitando redes para o seu lojista

Por padrão, um novo lojista tem um conjunto permissivo de redes em testnet e um conjunto mais restrito em mainnet. O conjunto de mainnet fica condicionado a:

  1. KYB concluído
  2. Atestado de carteira de tesouraria por rede (você assina uma mensagem provando custódia)

Habilite redes adicionais em Settings → Networks no dashboard do lojista.

Endereços de depósito determinísticos

Endereços de depósito EVM são determinísticos por checkout: a plataforma os deriva antecipadamente a partir de parâmetros internos vinculados ao lojista, ao pedido e ao intent. Você não pré-cria nem financia nada — só recebe o endereço de volta no PaymentIntent e entrega ao comprador.

  • Dois intents do mesmo lojista pegam endereços diferentes — sem colisões entre compradores.
  • O endereço aparece na página de checkout antes de qualquer setup on-chain, então o comprador vê um destino imediatamente.
  • Os compradores nunca pagam gas de setup. Os fundos liquidam direto na tesouraria do lojista, sem um passo separado de sweep que o lojista tenha que acompanhar.

Implicações práticas para integradores:

  • O deposit_address retornado num PaymentIntent é um endereço EVM comum — você pode mostrar como QR code, escanear, enviar de qualquer carteira. Não precisa de suporte especial do lado do cliente.
  • Enviar para o endereço antes que o intent expire liquida o pedido. Enviar depois da expiração é recuperado em best-effort — a plataforma pode re-sweepar depósitos atrasados em alguns casos, mas nunca assuma que fundos atrasados estão seguros.
  • Cada endereço é de uso único por intent. Se um comprador precisa de uma segunda tentativa, crie uma nova sessão de checkout — você recebe um endereço novo.

O que NÃO é suportado hoje

  • Tron / TRC-20. Frequentemente pedido para USDT-TRC20; está no roadmap, não está vivo.
  • Solana / SPL. Está no roadmap.
  • Bitcoin / Lightning. Não está no roadmap.
  • Stablecoins nativas de Layer-1 (USDe, FDUSD, …). Adicione via solicitação no dashboard; basta que a rede subjacente esteja habilitada.

Próximos passos

ReembolsosVisão geral