{"section":"known-issues","requestedLocale":"en","requestedSlug":"transactions-stuck-in-authorized-or-pending-authorization-after-approval","locale":"en","slug":"transactions-stuck-in-authorized-or-pending-authorization-after-approval","path":"docs/en/known-issues/Payments/transactions-stuck-in-authorized-or-pending-authorization-after-approval.md","branch":"main","content":"## Summary\n\n\nTransactions may remain stuck in Authorized or Pending Authorization even after all payments are successfully authorized, preventing invoicing and normal order progression. The visible symptom is the transaction not advancing to Approved despite approvals having occurred, often accompanied by duplicated or conflicting `TransactionWorkFlowChangeStatus` logs.\nThe official documentation explains the different transaction states in more detail: Transaction Flow in Payments.\n\nHowever, in transactions affected by this problem, we observe two types of unexpected behaviors:\n\n1. **Stuck in Authorized:** After all payments have been approved (authorized) and the transaction has already transitioned to the _Approved_ status, a new transition status event, `TransactionWorkFlowChangeStatus`, is triggered. This event incorrectly updates the status back to _Authorized_. Even though another `TransactionWorkFlowChangeStatus - Approved` event occurs afterward, the final status update is not properly recorded in the transaction. As a result, the transaction remains stuck in the _Authorized_ state, preventing the order or transaction from progressing as expected.\n2.\n\n**Stuck in Pending Authorization:** Sometimes, the transaction gets stuck in the _Pending Authorization_ status, even when all payments have already been authorized.\n\n\n\nThese issues can often be identified by duplicated or conflicting `TransactionWorkFlowChangeStatus` logs, such as _Approved_ followed by _Authorized_, or missing the final _Approved_ event entirely — leading to an inconsistent or frozen transaction state.\n\nTo avoid this issue is important to know that the VTEX Payment Gateway uses an in-memory data model, committing changes to the database only after each request completes. Because of this, payment connectors must avoid making POST requests (such as `/additional-data`, `/retry`, or `/callback`) during authorization processing, as the expected data may not yet be persisted, causing deadlocks or inconsistencies.\nConnectors should not call the Gateway back during the same flow it initiated, nor assume that data is immediately available in the database. Instead, they should use GET requests to retrieve transaction or payment information, wait for the authorization process to finish before sending callbacks, and handle additional processing asynchronously after the initial request completes.\nBy following this pattern, avoiding circular API calls, concurrent requests, and overlapping callbacks, connectors ensure stable integration and prevent data consistency or locking issues.\n\nIn addition to the behavior described above, this parent known issue was later split into two more specific KIs to better delimit the business and technical flows and improve prioritization, as aligned in our internal discussion:\n\n- **[KI] Transactions stuck in Authorized after approval** – Zendesk ticket **1344363**\nhttps://vtexhelp.zendesk.com/agent/tickets/1344363\n- **[KI] Transactions stuck in Pending Authorization after approval** – Zendesk ticket **1344365**\nhttps://vtexhelp.zendesk.com/agent/tickets/1344365\n\nFor up-to-date descriptions, symptoms, impact, metrics, and troubleshooting steps, **always use the child KIs above**.\nThis parent KI is kept only for historical tracking and linkage of older escalations and should **not** be used as the main reference going forward.\n\n\n#### Simulation\n\n\nIt's not possible to simulate.\n\n\n#### Workaround\n\n\nSupport team can call internal APIs to move the transaction forward."}