{"section":"known-issues","requestedLocale":"pt","requestedSlug":"transacoes-presas-em-autorizado-ou-autorizacao-pendente-apos-a-aprovacao","locale":"pt","slug":"transacoes-presas-em-autorizado-ou-autorizacao-pendente-apos-a-aprovacao","path":"docs/pt/known-issues/Payments/transacoes-presas-em-autorizado-ou-autorizacao-pendente-apos-a-aprovacao.md","branch":"main","content":">ℹ️ Este problema conhecido foi traduzido automaticamente do inglês.\n\n## Sumário\n\n\nAs transações podem permanecer presas em Autorizado ou Autorização pendente mesmo depois que todos os pagamentos forem autorizados com sucesso, impedindo o faturamento e a progressão normal do pedido. O sintoma visível é que a transação não avança para Approved (Aprovado) apesar de as aprovações terem ocorrido, muitas vezes acompanhadas de registros `TransactionWorkFlowChangeStatus` duplicados ou conflitantes.\nA documentação oficial explica os diferentes estados da transação com mais detalhes: Fluxo de transações em pagamentos.\n\nEntretanto, nas transações afetadas por esse problema, observamos dois tipos de comportamentos inesperados:\n\n1. **Após todos os pagamentos terem sido aprovados (autorizados) e a transação já ter passado para o status _Approved_, um novo evento de status de transição, `TransactionWorkFlowChangeStatus`, é acionado. Esse evento atualiza incorretamente o status de volta para _Authorized_. Embora outro evento `TransactionWorkFlowChangeStatus - Approved` ocorra em seguida, a atualização do status final não é registrada corretamente na transação. Como resultado, a transação permanece presa no estado _Authorized_, impedindo que o pedido ou a transação avance conforme o esperado.\n2.\n\n**Parada na autorização pendente:** Às vezes, a transação fica presa no status _Pending Authorization_, mesmo quando todos os pagamentos já foram autorizados.\n\n\n\nEsses problemas podem ser identificados com frequência por registros `TransactionWorkFlowChangeStatus` duplicados ou conflitantes, como _Approved_ seguido de _Authorized_, ou pela ausência total do evento _Approved_ final, o que leva a um estado de transação inconsistente ou congelado.\n\nPara evitar esse problema, é importante saber que o VTEX Payment Gateway usa um modelo de dados na memória, confirmando as alterações no banco de dados somente após a conclusão de cada solicitação. Por isso, os conectores de pagamento devem evitar fazer solicitações POST (como `/additional-data`, `/retry` ou `/callback`) durante o processamento da autorização, pois os dados esperados podem ainda não ter sido persistidos, causando deadlocks ou inconsistências.\nOs conectores não devem chamar o Gateway de volta durante o mesmo fluxo que ele iniciou, nem presumir que os dados estejam imediatamente disponíveis no banco de dados. Em vez disso, eles devem usar solicitações GET para recuperar informações sobre transações ou pagamentos, aguardar a conclusão do processo de autorização antes de enviar retornos de chamada e tratar o processamento adicional de forma assíncrona após a conclusão da solicitação inicial.\nAo seguir esse padrão, evitando chamadas de API circulares, solicitações simultâneas e callbacks sobrepostos, os conectores garantem uma integração estável e evitam problemas de consistência ou bloqueio de dados.\n\n#\r\n## Simulação\n\n\r\n## Workaround"}