> ## Documentation Index
> Fetch the complete documentation index at: https://docs.lerian.studio/llms.txt
> Use this file to discover all available pages before exploring further.

# Recibir (TED IN)

> Recibe transferencias TED automáticamente — el plugin consulta SPB, valida las Cuentas destinatarias y acredita los fondos sin intervención manual.

TED IN permite a tu institución recibir transferencias de cualquier banco brasileño de forma automática. Tu equipo no realiza ninguna acción — el plugin detecta, valida y acredita cada transferencia. Cuando un cliente de otro banco envía un TED a tu institución, los fondos llegan a la cuenta del destinatario en minutos.

## Cómo funciona

***

1. Un cliente de otro banco inicia una transferencia TED hacia una de las cuentas de tu institución
2. Cada 60 segundos (valor por defecto `JD_POLL_INTERVAL_SECONDS`), el plugin consulta la red JD SPB en busca de transferencias entrantes nuevas
3. El plugin busca la cuenta del destinatario en tu CRM por el número de documento incluido en el mensaje de transferencia
4. El plugin acredita la cuenta del destinatario automáticamente, menos la tarifa de cashin si configuraste una

<img src="https://mintcdn.com/lerian-49cb71fc/ZrZBZTM4DWnrahSd/images/es/d2/ted-how-it-works-ted-in.svg?fit=max&auto=format&n=ZrZBZTM4DWnrahSd&q=85&s=709deb1d6f9f90912f33ff011c34ea53" alt="Diagrama de flujo TED IN" width="1171" height="426" data-path="images/es/d2/ted-how-it-works-ted-in.svg" />

## Cronograma de detección y procesamiento

***

Las etapas a continuación muestran qué ocurre después de que el banco de origen envía la transferencia:

| Etapa        | Qué ocurre                                                                                       |
| ------------ | ------------------------------------------------------------------------------------------------ |
| Envío        | El banco de origen envía la transferencia a la red SPB                                           |
| Detección    | El plugin obtiene la transferencia en su siguiente ciclo de polling. El estado pasa a `RECEIVED` |
| Validación   | El plugin confirma la cuenta del destinatario. El estado pasa a `PROCESSING`                     |
| Crédito      | El plugin acredita la cuenta del destinatario. El estado pasa a `COMPLETED`                      |
| Notificación | El plugin envía el webhook a tu sistema                                                          |

**Tiempo típico:** El crédito se completa dentro de un ciclo de polling. Con el intervalo de polling por defecto de 60 segundos, los fondos llegan en aproximadamente un minuto.

## Estados de transferencia

***

| Estado       | Qué significa para el destinatario                                                                                      |
| ------------ | ----------------------------------------------------------------------------------------------------------------------- |
| `RECEIVED`   | El plugin detectó la transferencia en la red y comenzó a procesarla                                                     |
| `PROCESSING` | El plugin confirmó la cuenta del destinatario y aplica el crédito                                                       |
| `COMPLETED`  | Los fondos llegaron a la cuenta del destinatario                                                                        |
| `FAILED`     | El plugin no pudo aplicar el crédito (por ejemplo, un rechazo de Midaz), o un chargeback revirtió un crédito completado |

## Tarifa de recepción (cashin)

***

Tu organización puede cobrar una tarifa sobre las transferencias entrantes. Cuando la habilitas, el plugin deduce la tarifa del monto antes de acreditar al destinatario. El destinatario recibe el monto neto. Tú defines el monto y la configuración de la tarifa por organización a través del Fees Engine.

Fórmula: `monto acreditado = monto de transferencia − tarifa`

Ejemplo: una transferencia de R$1.000,00 con una tarifa de R$2,50 acredita R\$997,50 en la cuenta del destinatario. Esto es lo opuesto a TED OUT, donde el plugin suma la tarifa al monto y el remitente paga más.

## Qué ocurre cuando no se encuentra un destinatario

***

Si el plugin no puede asociar el número de documento de la transferencia entrante a una cuenta en tu CRM, devuelve la transferencia al banco de origen automáticamente. El cliente remitente recupera su dinero. Tu equipo no realiza ninguna acción, y ningún fondo queda sin contabilizar.

El plugin registra el mensaje entrante como una transferencia entrante no entregable en el almacén `undeliverable_incoming_transfers`. Luego despacha una devolução (devolución STR0010) al banco de origen. Esta ruta no crea un registro de transferencia acreditada con estado `FAILED`.

## Consultar transferencias recibidas

***

Usa el endpoint [List Transfers](/es/reference/midaz/plugins/ted/list-transfers) para recuperar todas las transferencias entrantes. Filtra por `type=TED_IN` para ver solo las transferencias recibidas.

**Endpoint:** GET /v1/transfers

**Respuesta (campos clave):**

```json theme={null}
{
  "items": [
    {
      "transferId": "019c96a0-ab20-7def-a1b2-1f2a3b4c5d6e",
      "type": "TED_IN",
      "status": "COMPLETED",
      "amount": 5000.00,
      "feeAmount": 0.00,
      "totalAmount": 5000.00,
      "createdAt": "2026-01-21T10:15:00-03:00",
      "updatedAt": "2026-01-21T10:15:30-03:00"
    }
  ],
  "pagination": {
    "limit": 50,
    "offset": 0,
    "returned": 1,
    "totalCount": 150,
    "hasNextPage": true
  }
}
```

Para opciones completas de parámetros de consulta, consulta la referencia [List Transfers](/es/reference/midaz/plugins/ted/list-transfers).

## Endpoints operativos

***

Tres endpoints de operador controlan el bucle de polling de TED IN. Están dirigidos a scripts y runbooks, no al tráfico de usuario final.

| Endpoint                           | Propósito                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                          |
| ---------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `POST /v1/transfers/ted-in/poll`   | Dispara manualmente el poller de JD que normalmente se ejecuta en un cron de 60s. Úsalo tras una ventana de incidente o para validar la conectividad con JD. La ruta es tenant-scoped pero no requiere `X-Organization-Id`, porque resuelve el tenant desde el contexto autenticado. Requiere `X-Idempotency` para reintentos seguros. Un reintento con la misma clave reproduce la respuesta en caché en lugar de leer nuevamente la cola destructiva de JD.                                                                                                                                                                                                                                                                                                                                                                      |
| `POST /v1/transfers/ted-in/replay` | Reprocesa filas de backlog TED IN persistidas y no procesadas que el plugin ya obtuvo de JD. Esta ruta no lee JD nuevamente. Requiere `X-Organization-Id` para el alcance de organización Midaz y `X-Idempotency` para reintentos seguros. El tenant se sigue resolviendo desde el contexto autenticado.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                           |
| `POST /v1/transfers/ted-in/resume` | Limpia el latch de recepción fail-closed y rearma un poller que la auto-recuperación no puede revivir — un hijo multi-tenant que entró en panic o un poller single-tenant que superó el tope de reintentos. Tiene mayor privilegio que `/poll` porque reabre el consumo destructivo de JD. El resume nunca omite la protección del money-path: si el latch actual aún no tiene una brecha de reconciliación duradera, la solicitud se rechaza con `409`. Verifica primero las brechas pendientes con [List TED IN Reconciliation Gaps](/es/reference/midaz/plugins/ted/list-ted-in-reconciliation-gaps) y, opcionalmente, envía `{ "acknowledge": true, "note": "..." }` para marcar la brecha como resuelta en la misma llamada. Un poller sano y sin latch devuelve `resumed: false` — la ruta es un no-op idempotente y seguro. |

Para el body de la solicitud, la respuesta, los códigos de estado y los códigos de error, consulta la [especificación OpenAPI de TED](/es/openapi/v3-current/ted.yaml) (operaciones `triggerTEDInPoller`, `replayTEDInPoller` y `resumeTEDInPoller`).

## Tres caminos distintos de dead-letter

***

El plugin usa tres almacenes de fallas separados. No son intercambiables, y debes monitorear cada uno de forma independiente:

<Note>
  * **JD parse failures** — el plugin las almacena en `jd_incoming_parse_failures`. El mensaje llegó desde JD, pero el plugin no pudo interpretarlo (XML mal formado, tipo de mensaje desconocido). Este almacén requiere triaje manual.
  * **Transferencias entrantes no entregables** — el plugin las almacena en `undeliverable_incoming_transfers`. El parseo fue exitoso, pero el plugin no pudo aplicar el crédito (por ejemplo, no encontró la cuenta del destinatario). Esta ruta puede disparar una devolución automática al banco de origen.
  * **Webhook DLQ** — la cola de reintentos para entregas de webhook salientes fallidas, en `/v1/webhooks/dlq`. No se relaciona con la ingesta de TED IN. Este es el canal de eventos saliente hacia los clientes integradores.
</Note>

## Webhooks

***

Configura un webhook para recibir notificaciones en tiempo real cuando lleguen transferencias. El evento `transfer_incoming.completed` se activa en cuanto el plugin acredita una transferencia. Consulta [Webhooks](/es/rails/ted/jd/ted-webhooks) para detalles de configuración y del payload del evento.

## Conciliación

***

Para la conciliación contable y financiera, cada registro de transferencia incluye estos campos:

| Campo           | Uso                                                                                          |
| --------------- | -------------------------------------------------------------------------------------------- |
| `controlNumber` | Número de control JD SPB — único por transferencia, usado para la conciliación interbancaria |
| `transferId`    | Identificador interno de Lerian                                                              |
| `createdAt`     | Marca de tiempo de cuando el plugin detectó la transferencia                                 |
| `completedAt`   | Marca de tiempo de cuando el plugin acreditó los fondos                                      |

El plugin conserva los registros de transferencia para conciliación y auditoría.

## Garantías de procesamiento

***

El plugin se asegura de no perder ninguna transferencia y de no acreditar ninguna dos veces:

* **Sin créditos duplicados** — cada mensaje de transferencia lleva un número de secuencia único. El plugin rechaza cualquier intento de procesar el mismo mensaje dos veces.
* **Reintento automático en caso de falla** — el plugin reintenta los errores transitorios (como una interrupción momentánea del servicio) con retroceso exponencial antes de registrar cualquier estado de falla.
* **Cola de mensajes no procesables** — si el plugin no puede procesar una transferencia después de todos los reintentos, mueve la transferencia a una cola de mensajes no procesables para revisión manual. El plugin nunca descarta una transferencia de forma silenciosa.
