{"section":"known-issues","requestedLocale":"en","requestedSlug":"transactions-stuck-in-authorized-after-approval","locale":"en","slug":"transactions-stuck-in-authorized-after-approval","path":"docs/en/known-issues/Payments/transactions-stuck-in-authorized-after-approval.md","branch":"main","content":"## Summary\n\n\nTransactions may remain stuck in **Authorized** 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 interactions.\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 unexpected behavior:\nStuck 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.\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\n\n\n#### Simulation\n\n\nIt's not possible to simulate.\n\n\n#### Workaround\n\n\nOpen a ticket for Produtc Support team"}