{"section":"known-issues","requestedLocale":"es","requestedSlug":"la-devolucion-de-llamada-con-estado-aprobado-no-se-tiene-en-cuenta-para-continuar-con-la-transaccion","locale":"es","slug":"la-devolucion-de-llamada-con-estado-aprobado-no-se-tiene-en-cuenta-para-continuar-con-la-transaccion","path":"docs/es/known-issues/Payments/la-devolucion-de-llamada-con-estado-aprobado-no-se-tiene-en-cuenta-para-continuar-con-la-transaccion.md","branch":"main","content":"## Sumario\n\n>ℹ️ Este problema conocido ha sido traducido automáticamente del inglés.\n\n\nAunque la pasarela recibe correctamente el callback indicando que el estado del pago es aprobado, la transacción no progresa a `authorized` y luego a `approved`. Se envía una solicitud de autorización posterior, y como el retorno es `undefined`, la transacción permanece en el estado `authorizing` hasta que se agota el número de reintentos.\n\n\n##\n\n## Simulación\n\n\nPara que se produzca este problema, la pasarela debe reintentar en el mismo momento en que recibió la llamada de retorno. No es sencillo reproducir este comportamiento, ya que acertar exactamente con la misma marca de tiempo es bastante difícil.\n\n\n\n\n## Workaround\n\n\nHay dos acciones que el socio puede tomar:\n\n1. 1. Si se aprueba el pago, responder a las llamadas posteriores de solicitud de autorización de la pasarela con este estado en lugar de indefinido.\n2. 2. Aumentar el número de reintentos (`delayToCancel`) para que la pasarela realice más intentos."}