Sign in
Introdução/Referências

Referências

Códigos de rede, mapeamentos moeda-rede e valores de status de pagamento usados em toda a API da 2328.io.

Esta página lista todos os valores de referência utilizados nas requisições e respostas da API.

Códigos de rede

Estes códigos são utilizados sempre que houver um campo network:

CódigoRede
TRX-TRC20Tron TRC-20
BSC-BEP20BNB Smart Chain
ETH-ERC20Ethereum (ERC-20)
BASEBase
AVAX-CAvalanche C-Chain
POL-MATICPolygon (Matic)
TONTON
BTCBitcoin
LTCLitecoin
DASHDash
SOLSolana
DOGEDogecoin
ZECZcash
XRPXRP Ledger
XMRMonero

Mapeamento moeda-rede

Cada moeda está disponível apenas em um subconjunto de redes. Use esta tabela para escolher uma combinação válida:

MoedaRedes permitidas
USDTTRX-TRC20, BSC-BEP20, ETH-ERC20, BASE, AVAX-C, POL-MATIC, TON, SOL
USDCBSC-BEP20, ETH-ERC20, BASE, AVAX-C, POL-MATIC, SOL
BTCBTC
ETHETH-ERC20, BASE
BNBBSC-BEP20
TRXTRX-TRC20
LTCLTC
DASHDASH
GRAMTON
AVAXAVAX-C
POLPOL-MATIC
SOLSOL
DOGEDOGE
ZECZEC
XRPXRP
XMRXMR

GRAM é o código de ativo canônico para a moeda nativa TON. As APIs de pagamento, carteira estática e criação de pagamento atualmente aceitam a entrada legada TON e a normalizam para GRAM; as integrações devem armazenar e manipular o valor canônico retornado pela API. O ativo nativo da Polygon é POL, enquanto seu código de rede é POL-MATIC. Nunca envie MATIC como código de rede.

As direções habilitadas são configuração operacional e podem mudar independentemente deste catálogo. Consulte /v1/directions antes de apresentar opções; trate esta tabela como o mapa de códigos válido, não como garantia de que todos os pares estejam atualmente habilitados.

Status de pagamento

O campo payment_status em pagamentos e o filtro de /v1/payment/list aceita os seguintes valores:

StatusDescrição
pendingCriado, aguardando inicialização
checkAguardando pagamento do cliente
paidPago com sucesso
underpaid_checkPago a menor (pode ser complementado)
underpaidPago a menor
overpaidPago a maior (creditado)
cancelCancelado / expirado
aml_lockTransação bloqueada por AML

Ao monitorar um pagamento bem-sucedido, você deve tratar tanto paid quanto overpaid como estados de sucesso e creditar o pedido do cliente.

Política de gerenciamento de status

StatusCumprir pedido?Continuar esperando?Ação operacional
pending / checkNãoSim, até o vencimentoExibir estado pendente e reconciliar normalmente.
underpaid_checkNão por padrãoSim, o complemento pode chegarArmazenar cada txid de forma idempotente e mostrar o fluxo de trabalho de pagamento restante.
paidSim, uma vezNãoCumprir atomicamente a partir do evento verificado.
overpaidSim, uma vezNãoCumprir e reter quantias excedentes/realizadas de acordo com a política do comerciante.
underpaidEspecífico por produtoNãoAplicar política explícita de pagamento parcial/revisão manual.
cancelNãoNãoMarcar como expirado/cancelado, mas escalar qualquer evidência posterior na blockchain.
aml_lockNãoNenhum cumprimento automáticoRevisão de conformidade/suporte; não liberar valor automaticamente.

Os status descrevem a visão da plataforma sobre o pagamento. Eles não substituem seu estado local de cumprimento. Armazene ambos para que um pedido reembolsado, revisado manualmente ou já cumprido não seja corrompido por um webhook mais antigo.

O filtro de solicitação /v1/payment/list atualmente aceita pending, check, paid, underpaid_check, underpaid, overpaid e cancel. Ele não aceita aml_lock como filtro, mesmo que um pagamento bloqueado por AML possa ser devolvido por outros endpoints de pagamento.

Status de saque

O campo status em /v1/payout e /v1/payout/status/{uuid} assume um destes valores:

StatusDescrição
pendingCriado, aguardando processamento
completedConcluído com sucesso — txid está definido
failedErro de envio — veja error_type
cancelledCancelado

Tipos de erro de saque

Quando um saque tem status = failed, o campo error_type descreve o motivo:

CódigoDescrição
aml_riskSaque bloqueado pelas verificações de risco AML (endereço do destinatário sinalizado como de alto risco)