Transacciones
La API de Transacciones devuelve registros de libro creados después de confirmar pagos exitosos. Úsala para conciliar pagos, auditar saldos y respaldar integraciones basadas en webhooks.
Resumen
Cada solicitud de pago confirmada produce un registro de transacción. Las transacciones incluyen montos brutos y netos, metadatos de activo y red, direcciones de origen y destino, y hashes de transacción on-chain opcionales.
Las transacciones están limitadas a la entidad autenticada:
- Claves API a nivel de cuenta — transacciones solo de esa cuenta
- Claves API a nivel de organización — todas las transacciones de la organización, o una sola cuenta cuando se proporciona
accountID
Autenticación
Todas las solicitudes requieren ambos encabezados:
Authorization: Bearer <access_token>x-fluxis-api-key: <your_api_key>
Listar transacciones
Code
Parámetros de consulta
| Parámetro | Requerido | Descripción |
|---|---|---|
page | Sí | Número de página (mínimo 1) |
page_size | Sí | Elementos por página (5–100) |
accountID | No | Filtrar a una cuenta específica (solo claves de organización). Debe pertenecer a tu organización |
Desfase de Swagger: La referencia OpenAPI puede documentar parámetros de consulta limit y offset y una respuesta de array plano. El manejador en vivo usa page y page_size y devuelve un sobre paginado con data, total, page, page_size y total_pages. Sigue esta página y el comportamiento del manejador — no tipos swagger obsoletos.
Ejemplo
Code
Para claves de organización limitadas a una cuenta:
Code
Forma de la respuesta
Code
Campos opcionales como account_external_id, unique_asset_id, network y transaction_hash usan omitempty y pueden estar ausentes según el tipo de transacción y la etapa de procesamiento.
Tipos de transacción
| Tipo | Descripción |
|---|---|
payment_in | Pago entrante de cliente |
payment_out | Pago saliente |
deposit | Depósito |
withdraw | Retiro |
refund | Reembolso |
adjustment | Ajuste manual |
swap | Intercambio de activos |
dry_run | Registro de prueba / vista previa |
La mayoría de integraciones de comercio interactúan principalmente con registros payment_in creados cuando las solicitudes de pago alcanzan confirmed.
Estados de transacción
| Estado | Descripción |
|---|---|
preview | Estado de vista previa |
pending | Esperando procesamiento |
created | Registro creado |
processing | En progreso |
completed | Completado exitosamente |
failed | Fallido |
error | Estado de error |
expired | Expirado |
Relación con solicitudes de pago
Code
- Los webhooks se disparan en
processing,completed,underpaidyoverpaid— consulta Eventos de webhook. - Tras la confirmación, aparece una transacción de libro en
GET /v1/transactions. - Haz polling de transacciones como respaldo si se pierde un webhook.
Patrón de conciliación
Combina webhooks (tiempo real) con polling periódico de transacciones (red de seguridad). Empareja por payment_request_id vía tu external_reference_id o correlacionando montos, marcas de tiempo y hashes de transacción.
Flujo recomendado:
- Almacena IDs de solicitud de pago cuando creas sesiones de checkout
- Actualiza el estado del pedido desde webhooks
payment_request - Nightly (o bajo demanda), recorre
GET /v1/transactionsy concilia brechas
Documentación relacionada
- Solicitudes de pago — ciclo de vida de estados
- Eventos de webhook — actualizaciones de estado en tiempo real
- Verificación de firma de webhook — verificación HMAC para entregas de webhook
- Liquidaciones y consolidación — cómo se mueven los fondos tras la confirmación
- Guía de integración API — Paso 7 conciliación