Skip to main content
Cada transferencia genera un registro de auditoría completo. Esta página describe los datos disponibles para reportes, reconciliación y cumplimiento.

​
Qué datos se registran por transferencia

​
Ciclo de vida del estado de la transferencia

​
TED OUT

Diagrama de máquina de estado TED OUT
  • Cliente confirmado (CREATED) — el cliente confirmó la transferencia, ahora en cola para envío
  • Enviada a la red bancaria (PENDING) — mensaje enviado a JD Consultores, esperando reconocimiento
  • Procesamiento bancario (PROCESSING) — JD aceptó la transferencia y la enruta
  • Liquidada (COMPLETED) — transferencia liquidada con éxito en el banco de destino
  • Rechazada (REJECTED) — JD devolvió un error de negocio (por ejemplo, datos de cuenta inválidos)
  • Fallida (FAILED) — falla técnica (timeout o indisponibilidad del servicio)
  • Cancelada (CANCELLED) — el cliente canceló antes de que se enviara la transferencia

​
TED IN

Diagrama de máquina de estado TED IN
  • Transferencia detectada (RECEIVED) — mensaje entrante persistido, pendiente de procesamiento interno
  • Destinatario validado (PROCESSING) — el sistema acredita la cuenta del destinatario
  • Monto acreditado (COMPLETED) — cuenta del destinatario acreditada con éxito
El banco remitente puede revertir una transferencia entrante ya liquidada. Para gestionar estos chargebacks, TED IN admite una transición COMPLETED → FAILED.

​
P2P

Diagrama de máquina de estado P2P
  • Confirmada (CREATED) — transferencia iniciada entre cuentas internas
  • Procesando (PROCESSING) — transacción de Midaz en progreso
  • Liquidada (COMPLETED) — ambas cuentas actualizadas con éxito
  • Fallida (FAILED) — error de procesamiento
  • Cancelada (CANCELLED) — cancelada antes de que comenzara el procesamiento

​
Revisión de tarifa antes de la confirmación (solo TED OUT)

Para TED OUT, los clientes pasan por un flujo de dos pasos: Diagrama de ciclo de vida de PaymentInitiation
  • Pendiente de confirmación — el plugin calculó y presentó la tarifa. El cliente aún no la ha confirmado
  • Procesada — el cliente confirmó y el plugin creó la transferencia
  • Expirada — transcurrieron 24 horas sin confirmación
Los clientes pueden revisar el costo total (monto + tarifa) antes de confirmar la transferencia.

​
Historial de estados

El plugin registra cada transición de estado con una marca de tiempo, el estado anterior, el nuevo estado y un motivo para errores y cancelaciones. Esto te da un registro de auditoría completo de cada transferencia — quién cambió qué y cuándo. El campo changedBy registra el actor que hizo la transición — por ejemplo, un proceso del sistema o un worker de reconciliación. Puede estar vacío.

​
Campos de reconciliación

Use estos campos para relacionar los registros de transferencia con sus extractos bancarios:

​
Retención de datos

No elimines los registros de transferencia. El plugin nunca los elimina ni los caduca, así que tú controlas su retención. Consérvalos, junto con los de auditoría, durante al menos 5 años, conforme a los requisitos de conservación de registros del BACEN.

​
Consulta de sus datos

Use Listar Transferencias para consultar transferencias con los siguientes filtros:
  • Por rango de fechas — filtre por createdAt o completedAt
  • Por tipo — TED OUT, TED IN o P2P
  • Por estado — por ejemplo, solo transferencias COMPLETED para reconciliación, o FAILED para investigación

​
Para desarrolladores

​
Almacenamiento

El plugin almacena los datos de transferencia en PostgreSQL. El campo recipientDetails usa JSONB. Este campo contiene las diferentes estructuras de datos para los destinatarios de TED OUT, TED IN y P2P. El campo recipientAccountId referencia una cuenta de Midaz cuando el destinatario es interno. Cada tenant tiene su propia base de datos, y la organización es el filtro principal dentro de un tenant. El plugin mantiene los siguientes índices para los patrones de consulta comunes:
  • (midaz_organization_id, created_at) para listados paginados.
  • (midaz_organization_id, status, created_at) para filtros basados en estado.
  • (control_number, date) (único) para búsquedas de reconciliación de JD.
La tabla de auditoría transfer_status_history usa un índice para flujos de auditoría e investigación:
  • (transfer_id, changed_at DESC) para el historial a nivel de transferencia.

​
Deduplicación de TED IN entrante

Antes de procesar una transferencia TED IN, el plugin almacena el mensaje JD sin procesar en la tabla JDIncomingMessage. Esto permite que el plugin recupere las transferencias entrantes si el servicio falla durante el procesamiento. Para prevenir el procesamiento duplicado, la tabla aplica una restricción única en sequenceNumber (el NumCabSeq de JD). Si JD reentrega el mismo mensaje, el plugin lo identifica automáticamente como duplicado y lo ignora.

​
Relaciones entre entidades

El modelo de dominio de TED sigue estas relaciones:
  • Cada Transfer pertenece a una única organización y puede tener múltiples registros de TransferStatusHistory.
  • Las transferencias TED OUT pueden originarse desde una PaymentInitiation en el flujo de transferencia de dos pasos.
  • Cada JDIncomingMessage puede crear como máximo un Transfer de tipo TED_IN.
Diagrama de relación entre entidades