{"section":"known-issues","requestedLocale":"es","requestedSlug":"transacciones-bloqueadas-en-autorizacion-pendiente-tras-su-aprobacion","locale":"es","slug":"transacciones-bloqueadas-en-autorizacion-pendiente-tras-su-aprobacion","path":"docs/es/known-issues/Payments/transacciones-bloqueadas-en-autorizacion-pendiente-tras-su-aprobacion.md","branch":"main","content":">ℹ️ Este problema conocido ha sido traducido automáticamente del inglés.\n\n## Sumario\n\nLas transacciones pueden permanecer bloqueadas en **Autorización pendiente** incluso después de que todos los pagos se hayan autorizado correctamente, lo que impide la facturación y el progreso normal del pedido. El síntoma visible es que la transacción no avanza a Aprobada a pesar de que se han producido aprobaciones, lo que a menudo va acompañado de registros duplicados o conflictivos de TransactionWorkFlowChangeStatus. La documentación oficial explica los diferentes estados de las transacciones con más detalle: Flujo de transacciones en los pagos.\n\nLa transacción se queda atascada en el estado **Pendiente de autorización**, incluso cuando todos los pagos ya han sido autorizados. Estos problemas a menudo pueden identificarse por registros duplicados o conflictivos de TransactionWorkFlowChangeStatus, como Aprobado seguido de **Pendiente de autorización**, o la ausencia total del evento final Aprobado, lo que conduce a un estado de transacción inconsistente o congelado.\n\nPara evitar este problema, es importante saber que la pasarela de pago VTEX utiliza un modelo de datos en memoria, que solo confirma los cambios en la base de datos una vez completada cada solicitud. Por este motivo, los conectores de pago deben evitar realizar solicitudes POST (como /additional-data, /retry o /callback) durante el procesamiento de la autorización, ya que es posible que los datos esperados aún no se hayan conservado, lo que provocaría bloqueos o incoherencias.\nLos conectores no deben volver a llamar a la pasarela durante el mismo flujo que iniciaron, ni dar por sentado que los datos están disponibles inmediatamente en la base de datos. En su lugar, deben utilizar solicitudes GET para recuperar la información de la transacción o del pago, esperar a que finalice el proceso de autorización antes de enviar las devoluciones de llamada y gestionar el procesamiento adicional de forma asíncrona una vez completada la solicitud inicial.\nSiguiendo este patrón, evitando llamadas API circulares, solicitudes concurrentes y devoluciones de llamada superpuestas, los conectores garantizan una integración estable y evitan problemas de coherencia o bloqueo de datos.\n\n## Simulación\n\nNo es posible simularlo.\n\n## Workaround\n\nAbra un ticket para el equipo de soporte técnico %0A"}