Transações
A API de Transações retorna registros contábeis criados após a confirmação de pagamentos bem-sucedidos. Use-a para conciliar pagamentos, auditar saldos e respaldar integrações baseadas em webhooks.
Visão geral
Cada solicitação de pagamento confirmada produz um registro de transação. Transações incluem valores brutos e líquidos, metadados de ativo e rede, endereços de origem e destino e hashes de transação on-chain opcionais.
Transações estão no escopo da entidade autenticada:
- Chaves de API em nível de conta — transações apenas dessa conta
- Chaves de API em nível de organização — todas as transações da organização, ou uma conta específica quando
accountIDé informado
Autenticação
Todas as requisições exigem ambos os cabeçalhos:
Authorization: Bearer <access_token>x-fluxis-api-key: <your_api_key>
Listar transações
Code
Parâmetros de consulta
| Parâmetro | Obrigatório | Descrição |
|---|---|---|
page | Sim | Número da página (mínimo 1) |
page_size | Sim | Itens por página (5–100) |
accountID | Não | Filtrar por conta específica (apenas chaves de organização). Deve pertencer à sua organização |
Divergência do Swagger: A referência OpenAPI pode documentar parâmetros limit e offset e uma resposta em array simples. O handler em produção usa page e page_size e retorna um envelope paginado com data, total, page, page_size e total_pages. Siga esta página e o comportamento do handler — não tipos swagger desatualizados.
Exemplo
Code
Para chaves de organização limitadas a uma conta:
Code
Formato da resposta
Code
Campos opcionais como account_external_id, unique_asset_id, network e transaction_hash usam omitempty e podem estar ausentes conforme o tipo de transação e a etapa de processamento.
Tipos de transação
| Tipo | Descrição |
|---|---|
payment_in | Pagamento recebido do cliente |
payment_out | Pagamento de saída |
deposit | Depósito |
withdraw | Saque |
refund | Reembolso |
adjustment | Ajuste manual |
swap | Troca de ativos |
dry_run | Registro de teste / pré-visualização |
A maioria das integrações de comerciantes interage principalmente com registros payment_in criados quando solicitações de pagamento atingem confirmed.
Status de transação
| Status | Descrição |
|---|---|
preview | Estado de pré-visualização |
pending | Aguardando processamento |
created | Registro criado |
processing | Em andamento |
completed | Concluído com sucesso |
failed | Falhou |
error | Estado de erro |
expired | Expirado |
Relação com solicitações de pagamento
Code
- Webhooks disparam em
processing,completed,underpaideoverpaid— consulte Eventos de webhook. - Após a confirmação, uma transação contábil aparece em
GET /v1/transactions. - Faça polling de transações como fallback se um webhook for perdido.
Padrão de conciliação
Combine webhooks (tempo real) com polling periódico de transações (rede de segurança). Faça o match por payment_request_id via seu external_reference_id ou correlacionando valores, timestamps e hashes de transação.
Fluxo recomendado:
- Armazene IDs de solicitação de pagamento ao criar sessões de checkout
- Atualize o status do pedido a partir de webhooks
payment_request - Diariamente (ou sob demanda), percorra
GET /v1/transactionse concilie lacunas
Documentação relacionada
- Solicitações de pagamento — ciclo de vida de status
- Eventos de webhook — atualizações de status em tempo real
- Verificação de assinatura de webhook — verificação HMAC para entregas de webhook
- Liquidações e consolidação — como os fundos se movem após a confirmação
- Guia de integração API — Etapa 7 conciliação