{"section":"known-issues","requestedLocale":"es","requestedSlug":"transacciones-atascadas-en-autorizado-o-pendiente-de-autorizacion-tras-la-aprobacion","locale":"es","slug":"transacciones-atascadas-en-autorizado-o-pendiente-de-autorizacion-tras-la-aprobacion","path":"docs/es/known-issues/Payments/transacciones-atascadas-en-autorizado-o-pendiente-de-autorizacion-tras-la-aprobacion.md","branch":"main","content":">ℹ️ Este problema conocido ha sido traducido automáticamente del inglés.\n\n## Sumario\n\n\nLas transacciones pueden permanecer atascadas en Autorizado o Pendiente de Autorización incluso después de que todos los pagos se hayan autorizado correctamente, impidiendo la facturación y la progresión normal del pedido. El síntoma visible es que la transacción no avanza a Aprobado a pesar de que se han producido aprobaciones, a menudo acompañadas de registros de `TransactionWorkFlowChangeStatus` duplicados o conflictivos.\nLa documentación oficial explica con más detalle los distintos estados de las transacciones: Flujo de Transacciones en Pagos.\n\nSin embargo, en las transacciones afectadas por este problema, observamos dos tipos de comportamientos inesperados:\n\n1. **Atasco en Autorizado:** Después de que todos los pagos hayan sido aprobados (autorizados) y la transacción ya haya pasado al estado _Aprobado_, se activa un nuevo evento de estado de transición, `TransactionWorkFlowChangeStatus`. Este evento actualiza incorrectamente el estado a _Autorizado_. Aunque después se produce otro evento `TransactionWorkFlowChangeStatus - Approved`, la actualización final del estado no se registra correctamente en la transacción. Como resultado, la transacción permanece atascada en el estado _Authorized_, impidiendo que la orden o transacción progrese como se esperaba.\n2.\n\n**Atasco en Pendiente de Autorización:** A veces, la transacción se queda atascada en el estado _Pendiente de Autorización_, incluso cuando todos los pagos ya han sido autorizados.\n\n\n\nEstos problemas suelen identificarse por registros de `TransactionWorkFlowChangeStatus` duplicados o contradictorios, como _Approved_ seguido de _Authorized_, o por la ausencia total del evento final _Approved_, lo que da lugar a un estado de transacción incoherente o congelado.\n\nPara evitar este problema, es importante saber que la pasarela de pago VTEX utiliza un modelo de datos en memoria, comprometiendo los cambios en la base de datos sólo después de que se complete cada solicitud. Debido a esto, los conectores de pago deben evitar realizar solicitudes POST (como `/additional-data`, `/retry`, o `/callback`) durante el procesamiento de la autorización, ya que los datos esperados pueden no estar todavía almacenados, causando bloqueos o inconsistencias.\nLos conectores no deben volver a llamar a la pasarela durante el mismo flujo que inició, ni suponer que los datos están disponibles inmediatamente en la base de datos. En su lugar, deben utilizar solicitudes GET para recuperar información sobre transacciones o pagos, esperar a que finalice el proceso de autorización antes de enviar devoluciones de llamada y gestionar el procesamiento adicional de forma asíncrona una vez finalizada la solicitud inicial.\nSiguiendo este patrón, y evitando las llamadas circulares a la API, las solicitudes concurrentes y las devoluciones de llamada solapadas, los conectores garantizan una integración estable y evitan problemas de coherencia o bloqueo de datos.\n\n##\n\n#### Simulación\n\n## Workaround"}