{"section":"known-issues","requestedLocale":"es","requestedSlug":"las-transacciones-siguen-bloqueadas-en-autorizadas-a-pesar-de-que-el-conector-las-ha-aprobado","locale":"es","slug":"las-transacciones-siguen-bloqueadas-en-autorizadas-a-pesar-de-que-el-conector-las-ha-aprobado","path":"docs/es/known-issues/Payments/las-transacciones-siguen-bloqueadas-en-autorizadas-a-pesar-de-que-el-conector-las-ha-aprobado.md","branch":"main","content":">ℹ️ Este problema conocido ha sido traducido automáticamente del inglés.\n\n## Sumario\n\nEn algunos casos, el Transaction Worker no logra que la transacción pase al estado esperado, incluso después de recibir una respuesta positiva (200 OK) del conector. Como resultado, las transacciones pueden quedarse bloqueadas en _Authorized_ y los pedidos correspondientes permanecen en _«Pago pendiente»_. Este comportamiento puede producirse cuando el conector devuelve correctamente una respuesta de aprobación, pero el proceso interno que actualiza el estado de la transacción no se ejecuta correctamente.\n\nEste problema corresponde al escenario: _«Silencio tras la autorización»_, en el que se identificaron cinco causas raíz distintas que compartían el mismo síntoma superficial pero diferentes mecanismos de fallo. Las otras causas son:\n\n- Bucle de reintentos antifraude de ClearSale debido a `NullReferenceException` en el conector. Ticket n.º 1059028\n- Bucle de reintentos antifraude de ClearSale debido a `address.number=null`. Ticket n.º 496298\n- Pago atascado en el estado `Recibido` tras la autorización, sin estado visible en la interfaz de usuario. Ticket n.º 1411012.\n- Regresión de estado «Aprobado» → «Autorizado» causada por una llamada de retorno secundaria del conector, resuelta junto con este KI.\n\n## Simulación\n\nNo es posible simularlo.\n\n## Workaround\n\nAbre un ticket para el equipo de soporte técnico del producto."}