> ## 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. # Cómo funciona Lerian SPI > Cómo funciona Lerian SPI: incorporación de Pix, flujos de envío y recepción (pacs.008 y pacs.002), devoluciones, claves y reivindicaciones de DICT, cobros de BR Code, Pix Automático y MED. Lerian SPI expone la superficie de mensajes de Pix como un conjunto de operaciones tipadas. La mayoría de los flujos conservan su trabajo antes del envío. El despachador de devoluciones solo intenta registrar un `pacs.004` saliente antes de enviarlo. Un fallo de registro no bloquea necesariamente el envío. Las operaciones devuelven un estado aceptado pero no liquidado y concilian contra la respuesta asíncrona de BACEN. ## Incorporación y readiness *** Registras un participante por su ISPB. Un participante indirecto ingresa en `PENDING`. El riel envía su solicitud de registro, y solo la confirmación de BACEN puede activarlo. La acción de activación solo reactiva a un participante ya suspendido. El riel ejecuta el readiness en un orden obligatorio. Aprobar una prueba de conectividad es el requisito previo para un envío. 1. **Sube** un certificado Pix, solo el `.cer` público. El riel rechaza una clave privada subida. 2. Confirma que el riel informa **ready**. 3. Aprueba una **prueba de conectividad**. 4. Ya puedes enviar pagos. La misma superficie de Core también suspende y da de baja a un participante a lo largo de su ciclo de vida. ## Enviar un Pix *** Creas una orden de pago. La plataforma construye el mensaje ISO 20022 de transferencia de crédito (`pacs.008`), conserva la operación y la envía. BACEN devuelve una notificación asíncrona de estado (`pacs.002`). El riel la valida y la aplica, y luego lleva el pago a `completed` o `rejected`. Lees de vuelta un pago por su ID de extremo a extremo, con su historial y una línea de tiempo por operación. ## Recibir un Pix *** El consumidor ICOM recibe mensajes firmados de BACEN y los pasa al ingreso interno autenticado del riel. Para un `pacs.008` entrante, el riel valida el mensaje y registra el Pix como pendiente. El cliente entonces provee la decisión de fondeo para ese Pix ya recibido. Un pago saliente no puede recibir fondeo como dinero entrante. Los participantes listan los Pix que reciben. ## Devolución (devolução) *** Inicias una devolución (`pacs.004`) solo para un Pix liquidado que el riel recibió de BACEN, y luego lees el estado de la devolución. La devolución debita al receptor original y acredita al pagador original. No puedes iniciar una devolución para un Pix que envió tu cliente. La contraparte emite una devolución de ese Pix, y esta llega al riel como un mensaje entrante. Una devolución es la vía de movimiento de dinero de MED, la forma en que los fondos regresan a un pagador por una disputa o un error resuelto. Existen dos superficies de devolución, y el riel registra cuál creó una devolución en lugar de inferirlo después. Una devolución **total** revierte todo el Pix y saca al pago principal de `completed`. Una devolución **parcial** usa el `devolucaoId` que eliges como su clave y nunca mueve al pago principal. Varias devoluciones parciales pueden coexistir para un mismo Pix. Se aplican tres barreras a toda devolución, en ambas superficies: * **El pago principal debe ser un Pix entrante que se haya liquidado.** Solo se puede devolver un pago recibido que llegó a `completed` (o que ya tiene una devolución). * **La ventana de devolución de BACEN.** Una devolución debe solicitarse dentro de los **90 días posteriores a la liquidación del Pix original**. El riel mide la ventana desde el instante de liquidación, nunca desde la creación ni desde la última actualización. Un Pix sin instante de liquidación registrado no queda bloqueado: el riel registra el vacío y reenvía la solicitud. * **El límite de la suma.** Los valores de todas las devoluciones de un Pix no pueden superar el valor propio de ese Pix. El riel lee solo el monto de ese pago y sus propias devoluciones. No calcula ninguna posición entre pagos. Una devolución nace como `EM_PROCESSAMENTO` y llega a `DEVOLVIDO` o `NAO_REALIZADO` solo con la respuesta de BACEN. Una aceptación de transporte no es una conclusión. Una devolución que falla libera el límite que ocupaba. Una devolución total fallida devuelve el pago principal a `completed` sin reiniciar su ventana de 90 días. Solicitas una devolución como `ORIGINAL` (el valor predeterminado cuando no envías ninguna naturaleza) o `RETIRADA`, el tramo de Pix Saque y troco. Las dos naturalezas de MED (fallo operativo y sospecha fundada de fraude) son solo del lado de la respuesta. Se derivan del motivo que el riel coloca en el `pacs.004`, y nunca las solicitas tú. ## Ciclo de vida de las claves de DICT *** Administras las claves de Pix directamente contra el directorio DICT: registrar, listar, buscar, consultar, actualizar y eliminar una clave. También verificas en lote si un conjunto de claves existe. El riel lee las estadísticas de claves de DICT y las estadísticas antifraude de BACEN, tanto por clave como por persona. ## Reclamos de DICT (reivindicação) *** Un reclamo mueve una clave de Pix entre participantes por portabilidad o titularidad. Inicias un reclamo contra un participante, y luego lo mueves a través de su ciclo de vida. El ciclo de vida cubre acuse de recibo, confirmar o rechazar, y completar o cancelar, tanto del lado donante como del reclamante. Cuando `SCHEDULER_ENABLED=true` y `SCHEDULER_CLAIM_DEADLINE_ENABLED=true` están activos a la vez, el riel registra el procesamiento periódico de plazos de reclamo. Intenta avanzar los reclamos según sus ventanas de BACEN, pero un reclamo aún puede requerir atención. ## BR Code y cobros *** Un QR dinámico se resuelve en un cobro persistido, así que primero creas el cobro y luego generas el payload que se resuelve en él. Un QR estático se genera a partir de datos de pago estáticos. No requiere ni apunta a un cobro. * Crea un cobro: **Cob** (inmediato), **CobV** (con vencimiento, con interés y multa), o un **lote** de cobros con vencimiento. * Genera el payload del **QR EMV dinámico**, que se vincula al cobro por su txid o localizador y se resuelve como un JWS firmado. También generas un QR estático, decodificas un payload, lo validas y registras un perfil de receptor (recebedor). ## Pix Automático (recurrente) *** Pix Automático autoriza pagos recurrentes y programados a través de la familia recurrente de ISO 20022: * **Crea** una autorización recurrente (recorrência) o una solicitud de una. * **Solicita la confirmación** del mandato (`pain.009`), **cancélalo** (`pain.011`), o **acéptalo / recházalo** (`pain.012`). * **Programa** una instrucción (`pain.013`) y **acéptala / recházala** (`pain.014`). * **Solicita la cancelación** de una instrucción programada (`camt.055`) y **resuelve** una cancelación recibida (`camt.029`). * **Solicita un reintento de liquidación** (retentativa) cuando un cobro programado falla. ## Disputas de MED *** La superficie de MED (Mecanismo Especial de Devolução) maneja los casos de fraude y error: * **Abre** un caso de MED, **analízalo**, y luego **resuélvelo**, **ciérralo** o **cancélalo** con evidencia adjunta. * Presenta **reportes de infracción**, **solicitudes de devolución**, **marcadores de fraude** y solicitudes de **recuperación de fondos** de DICT, cada uno rastreado a través de su gráfico de ciclo de vida. * Reporta los Pix liquidados internamente mediante el reporte de liquidación de MED 2.0. ## Reportes de la Conta PI *** Solicitas un reporte de cuenta (`camt.060`), y luego lees el saldo (`camt.053`), el extracto (`camt.052`) o el detalle de movimiento (`camt.054`) que devuelve BACEN. Reportes síncronos de solo conteo de volumetria, pagos rechazados, saldo y extracto completan la superficie de reportes, cada uno acotado a su período de referencia.