{"section":"known-issues","requestedLocale":"es","requestedSlug":"error-con-el-codigo-de-retorno-355-en-el-proceso-de-cancelacion-con-erederest-y-erede-v2","locale":"es","slug":"error-con-el-codigo-de-retorno-355-en-el-proceso-de-cancelacion-con-erederest-y-erede-v2","path":"docs/es/known-issues/Payments/error-con-el-codigo-de-retorno-355-en-el-proceso-de-cancelacion-con-erederest-y-erede-v2.md","branch":"main","content":">ℹ️ Este problema conocido ha sido traducido automáticamente del inglés.\n\n## Sumario\n\nLos conectores heredados, ERedeRest y E-Rede V2, inician las cancelaciones enviando una solicitud al proveedor y esperan recibir un «returnCode»: «359» que indique que la cancelación se ha realizado correctamente. Cualquier otro código es interpretado por nuestra pasarela como un estado indefinido, lo que provoca que la transacción se quede bloqueada en un estado de cancelación. Aunque, en algunos casos, la solicitud de reembolso o cancelación se haya realizado correctamente. Esto provocaba intentos repetidos de cancelación, incluso cuando el proveedor ya había procesado la cancelación.\n\n## Simulación\n\nNo se puede simular, ya que dependemos de la respuesta del proveedor.\n\n## Workaround\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».\n\nEs posible que esto no funcione en transacciones con varios pagos, dependiendo de la coherencia del estado de sus liquidaciones."}