• Buenos días José,

    He visto entradas similares en el foro pero ninguna con este caso en concreto, al menos no la he encontrado.

    El cliente inicia una petición a las 12:57:59, esta la cancela (supuestamente) y empieza otra petición a las 13:08:10. Redsys notifica a las 13:08:56 que el pago está hecho y a las 13:09:13 manda una nueva comunicación cancelando el pedido con el error 9997 (Por lo que hemos visto en la documentación “Con una misma tarjeta hay varios pagos en “vuelo” en el momento que se finaliza uno el resto se deniegan con este código. Esta restricción se realiza por seguridad.”).

    Parece que Redsys manda la notificación de la primera petición, después de la segunda, y cancela el pedido aunque el pago sí está hecho en el banco.

    ?Este comportamiento es habitual? ?Cómo podemos prevenirlo en el futuro?

    Espero tu respuesta, muchas gracias!

Viewing 8 replies - 1 through 8 (of 8 total)
  • Me está sucediendo algo muy parecido
    (diría que lo mismo)
    en dos o tres ocasiones por notificación de redsys el pedido aparece como cancelado
    pero no no obtengo mas información (acabo de activar el log del plugin para comprobar si detecto algo mas)
    alguna pista sobre este comportamiento?

    captura del mensaje
    https://postimg.cc/62mBtjRq

    gracias

    A mi también me está sucediendo algo similar. Pedidos con hasta 2 denegaciones y luego confirmación de pago:

    https://postimg.cc/Vr2w7tQF

    Fijaos en las horas de registro de los eventos. Primero hay dos pagos denegados y unos minutos después de acepta.

    Pero las notificaciones de pedido Cancelado a Wocommerce llegan … en orden inverso !?. Parece que las notificaciones desde no llegan obligatoriamente en orden y se cancelan pedidos que ya estaban Procesando.

    ?Se podria a?adir una opcion para ignorar los errores 9997 si el pedido ya se ha confirmado como pagado?

    https://postimg.cc/zbK2rHH7

    Me ocurre exactamente lo mismo. La primera vez detectado sobre el 20 de diciembre de 2021 y se ha replicado posteriormente en varias ocasiones hasta el día de hoy.
    Ejemplo:

    – Primer intento de pago a las 23:41:38 del 10/01/2022 denegado por timeout:
    ——————————————-
    Fecha y hora: 10/01/2022 23:52:15
    Tipo notificación: HTTP
    Modo de comunicación: Síncrona
    Resultado operación: 9997
    Cod. respuesta servidor: Correcto (200)
    ——————————————-

    – Segundo intento de pago correcto, enviado a las 23:44:44 del 10/01/2022:
    ——————————————-
    Fecha y hora: 10/01/2022 23:45:29
    Tipo notificación: HTTP
    Modo de comunicación: Síncrona
    Resultado operación: 0000
    Cod. respuesta servidor: Correcto (200)
    ——————————————-

    – Y en woocommerce, en primera instancia procesa como correcto el pedido:
    ——————————————-
    Notificación HTTP recibida – pago completado
    10 de enero de 2022 a las 23:45 Borrar nota
    ——————————————-

    – Pero se cancela posteriormente cuando recibe la denegación por timeout:
    ——————————————-
    Pedido cancelado por Redsys
    10 de enero de 2022 a las 23:52 Borrar nota
    ——————————————-

    Gracias.

    Hola a todos:
    A mi también me sucede lo mismo:
    Hay un intento de pago fallido y a los pocos minutos el cliente hace otro intento con éxito. El sistema recibe el pago con éxito y acepta el pedido y después recibe el pago sin éxito y lo cancela.
    Hablando con REDSYS me dice que el plugin sólo toma el código del pedido y no el código completo del pedido de Redsys que es diferente.

    Esperaremos a ver que dice el desarrollador.

    Por si sirve de algo, comento una forma de replicar este error y que los clientes pueden hacer perfectamente.

    1. a?ade algún producto al carrito y finaliza el pedido hasta llegar a la pasarela de pago.
    2. introduce una tarjeta correctamente y cuando salga la cuenta atrás para verificarla, no la verifiques.
    3. rápidamente accede a tu cuenta desde otro dispositivo (creo que tienes 7 min) y verás que tu carrito sigue ahí.
    4. finaliza la compra desde ese nuevo dispositivo, esta vez verificando la tarjeta. En este paso tu pedido pasará al estado procesando
    5. por último, espera a que termine el tiempo en el primer dispositivo. Ahora el estado pasará de procesando a cancelado aunque el pedido está pagado.

    Eso es todo, un saludo ??

    Plugin Author Jose Conti

    (@jconti)

    Hola @jrstarenlared @oldlastman @adriwabi @jmmendez @jesuslorenzo @cantbutron,

    El tema de varios pedidos en vuelo, es por lo que comentáis precisamente. Es por que se va a pagar, se abandona cerrando navegador/pesta?a, y se intenta de nuevo dejando el contador de la PSD2 en marcha. Hasya queno pasen los 7 minutos (creo recordar que es), puede saltar este error.

    Si no salta (que es un error del propio Redsys), sucede lo que ha explicado @cantbutron, que se marca como cancelado tras ser marcado como pagado.

    Mirando lo que ha explicado @cantbutron, veo lo que debe suceder.

    – Va a pagar
    – Lo avandona
    – Lo intenta de nuevo y paga de forma correcta
    – Redsys envía la notificación de pagado y se marcar como pagado.
    – Pasa el tiempo del primer intento, y manda notificación del que el pàgo a fallado.
    – Se marca como cancelado.

    Tendré que poner un check conforme si el pedido ya ha sido marcado como pagado o no.

    Esto viene de que cada pedido en Redsys debe ser una numeración diferente, y lo que hace el plugin es a?adir unos números aleatorios delante. Luego, cuando se realiza la notificación, mi plugin limpia los primeros números y se fija en exclusiva en el numero de pedido real en Woo.

    Lo del orden inverso que comenta @adriwabi, mira que tengas que sean las notifciaciones síncronas. Puede que las tengas asíncronas y por eso baila un poco el tema de cuando notifica.

    Me pongo a ello.

    Saludos

    Plugin Author Jose Conti

    (@jconti)

    Hola @jrstarenlared @oldlastman @adriwabi @jmmendez @jesuslorenzo @cantbutron,

    He libeado la 3.0.5

    Esta versión a?ade un check en el endpoint de notificaciones, de forma que cuando Redsys notifica, antes de hacer nada mira si el pedido ya está pagado o no. Si no está pagado, seguirá el transcurso normal de todo, pero si está ya pagado, para el proceso. De esta forma, si existe algún proceso avandonado en Redsys a la espera de autorización y el cliente intenta un nuevo pagar antes de que finalice el anterior, pagándolo de forma correcta, cuando Redsys notifique que el anterior ha sido avandonado, no hará caso al estar ya pagado.

    El tema de los pagos en vuelo no se puede hacer nada, ya que es el mismo usuario que intenta varios pagos y Redsys detecta que hay dos, tres o los que sea, por lo que lanza el error.

    Pero esto que he a?adido al código, como mínimo no se cancelarán pedidos.

    Saludos

    • This reply was modified 2 years, 10 months ago by Jose Conti.

    Buenas,
    Hemos actualizado el plugin, pero aún así creemos que no se ha resuelto del todo. Un primer intento de pago con respuesta “Sin Finalizar 9999” y un segundo pago “autorizado” con una diferencia de 8 minutos entre los intentos, el único estado del pedido en WooCommerce es: “El pedido sin pagar ha sido cancelado – se ha alcanzado el limite de tiempo. El estado del pedido cambió de Pendiente de pago a Cancelado” sin pasar por el estado “procesando” como ocurría anteriormente.
    Es como si recibiese el estado del primer intento de pago. Nos está suponiendo un conflicto con los clientes porque recibimos el pago y el pedido está cancelado, sin descontar los productos y cuando nos avisan ya no queda stock.
    Gracias.

Viewing 8 replies - 1 through 8 (of 8 total)
  • The topic ‘Pedido cancelado por Redsys después del pago’ is closed to new replies.