{"section":"known-issues","requestedLocale":"es","requestedSlug":"error-en-el-proceso-de-cancelacion-erederest-y-erede-v2-solo-permiten-la-cancelacion-cuando-el-returncode-es-359","locale":"es","slug":"error-en-el-proceso-de-cancelacion-erederest-y-erede-v2-solo-permiten-la-cancelacion-cuando-el-returncode-es-359","path":"docs/es/known-issues/Payments/error-en-el-proceso-de-cancelacion-erederest-y-erede-v2-solo-permiten-la-cancelacion-cuando-el-returncode-es-359.md","branch":"main","content":"## Sumario\n\n>ℹ️ Este problema conocido ha sido traducido automáticamente del inglés.\n\n\nLos conectores heredados, ERedeRest y E-Rede V2, inician las cancelaciones enviando una petición al proveedor y esperan un \"returnCode\": \"359\" indicando una cancelación exitosa. Cualquier otro código es interpretado por nuestra pasarela como un estado indefinido, provocando que la transacción se quede atascada en un estado de cancelación. Aunque en algunos casos, la solicitud de reembolso/cancelación se realiza correctamente. Esto provocaba repetidos intentos de cancelación, incluso cuando la cancelación ya había sido procesada por el proveedor.\n\n\n##\n\n## Simulación\n\n\nNo se puede simular ya que dependemos de la respuesta del proveedor.\n\n\n\n## Workaround\n\n\nSi el pago por parte del proveedor ya está cancelado\n\n    \\{\"returnCode\": \"355\", \"returnMessage\": \"Transacción ya cancelada.\"\\}\n\nEl equipo de soporte del producto tiene la opción de utilizar una API interna, `force-cancel-status`, para actualizar el estado del pago y de la transacción a `cancelado`."}