{"section":"known-issues","requestedLocale":"pt","requestedSlug":"erro-no-processo-de-cancelamento-o-erederest-e-o-erede-v2-so-permitem-o-cancelamento-quando-o-returncode-e-359","locale":"pt","slug":"erro-no-processo-de-cancelamento-o-erederest-e-o-erede-v2-so-permitem-o-cancelamento-quando-o-returncode-e-359","path":"docs/pt/known-issues/Payments/erro-no-processo-de-cancelamento-o-erederest-e-o-erede-v2-so-permitem-o-cancelamento-quando-o-returncode-e-359.md","branch":"main","content":"## Sumário\n\n>ℹ️ Este problema conhecido foi traduzido automaticamente do inglês.\n\n\nOs conectores legados, ERedeRest e E-Rede V2, iniciam os cancelamentos enviando uma solicitação ao provedor e esperam um \"returnCode\": \"359\" indicando um cancelamento bem-sucedido. Qualquer outro código é interpretado pelo nosso gateway como um status indefinido, fazendo com que a transação fique presa em um estado de cancelamento. Mesmo que, em alguns casos, a solicitação de reembolso/cancelamento seja bem-sucedida. Isso levou a repetidas tentativas de cancelamento, mesmo quando o cancelamento já havia sido processado pelo provedor.\n\n## Simulação\n\n\nNão pode ser simulado, pois dependemos da resposta do provedor.\n\n\n\n## Workaround\n\n\nSe o pagamento no lado do provedor já tiver sido cancelado\n\n    \\{\"returnCode\": \"355\", \"returnMessage\": \"Transação já cancelada.\"\\}\n\nA equipe de suporte ao produto tem a opção de utilizar uma API interna, \"`force-cancel-status`\", para atualizar o status do pagamento e da transação para \"cancelado\"."}