La pasarela de pago RedSys es la que ofrecen los bancos en España como solución por defecto para pagos con tarjeta y no está carente de errores y problemas.
Para empezar, el proceso de configuración es para mear y no echar gota, un horror absoluto, solo para miembros de la secta.
Pero vaya, que no nos vamos a poner estupendos, y si has conseguido acceder al módulo de administración y hacer las primeras pruebas, no siempre el proceso ha terminado ahí, muchas veces ocurren errores en la comunicación entre nuestra tienda online y RedSys, o simplemente no terminan de confirmarse los pedidos, quedándose pendientes, el problema más común con diferencia.
Estas suelen ser las causas más comunes…
Índice de contenidos
Plugins de seguridad
Es bastante habitual que si tienes un plugin de seguridad para WordPress esté bloqueando la comunicación con RedSys, los que suelen generar problemas más comúnmente son estos.
All in One SEO Pack
Aunque no es un plugin de seguridad, una de las utilidades que ofrece AIOSP es el bloqueador de bots maliciosos, y siempre bloquea RedSys, así que desactiva esta utilidad.
iThemes Security
También este fantástico plugin de seguridad puede bloquear la comunicación con RedSys. En este caso hay un par de ajustes que pueden estar bloqueando RedSys.
El primero sería si tienes activa la lista de HackRepair. Si así fuera desactiva esta característica.
Otros ajustes que podrían estar bloqueando a RedSys serían los de bloquear cadenas sospechosas y URLs demasiado largas, en los ajustes del sistema de iThemes.
Una posible solución a este bloqueo, sin desactivar los anteriores ajustes, sería poner las IPs de RedSys en la lista blanca de bloqueo de los ajustes generales de iThemes.
Las IPs a añadir a la lista blanca normalmente serán estas pero confírmalas con el equipo de soporte de RedSys porque pueden haber cambiado:
- 195.76.9.187
- 195.76.9.222
- 195.76.9.182
- 193.16.243.33
Redirecciones HTTPS forzadas
Otro culpable habitual suelen ser las redirecciones HTTPS forzadas, para servir todo tu contenido mediante el cifrado del certificado SSL.
Y esto puede estar forzado de muchas maneras, a saber…
Plugins de SSL … y otros
Todos los plugins de gestión de certificados SSL y muchos de optimización tienen ajustes para forzar que todo tu contenido se cargue mediante HTTPS.
Esto, que a priori es bueno para tu web, pues la hace más segura y evita avisos de sitio no seguro del navegador, casi siempre genera conflictos con RedSys.
Así, por ejemplo, si usas el plugin Really Simple SSL, debes tener activos solamente los siguientes ajustes:
- Solucionador de contenido mixto (sí, no pasa nada si sigues la lista)
- Permitir redirección 301 de .htaccess (no la de WordPress)
- Dejar de modificar el archivo .htaccess
Además, a continuación debes añadir las siguientes líneas, que recomienda José Conti, al archivo .htaccess:
# REDIRECCION CERTIFICADO SSL REDSYS
RewriteEngine on
RewriteCond %{QUERY_STRING} !^wc-api=WC_Gateway_(.*)redsys
RewriteCond %{HTTPS} !=on [NC]
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
# FIN REDIRECCION CERTIFICADO SSL REDSYSCuriosamente, en este aspecto, también iThemes Security podría estar provocando este problema si tienes activos los ajustes de SSL de este plugin de seguridad, que viene precisamente a forzar la carga por HTTPS de tu contenido.
De hecho hay muchos usuarios de iThemes Security que no saben que tiene esa utilidad, con la que ahorrarse un plugin para HTTPS, pero que en este caso concreto, por este problema con RedSys, podría estar interfiriendo.
Así que si usas iThemes Security, lo que te recomiendo, pero estás teniendo problemas de pedidos pendientes de RedSys, también aquí podría estar el problema, y deberías desactivar este módulo.
Y, si como millones de usuarios de SiteGround, utilizas su plugin de optimización SG Optimizer, también el ajuste para corregir contenido inseguro, así que si es tu caso prueba a desactivarlo y ver si era eso lo que dejaba pendientes los pedidos de RedSys, como en el resto de posibles soluciones.
Por supuesto, ni de coña utilices plugins como SSL Insecure Content Fixer o similares.
Códigos de redirección HTTPS
Si, por el contrario, no usas ningún plugin para forzar la carga de tu web por HTTPS sino un código en el archivo .htaccess, búscalo, bórralo y prueba a ver si ya entran correctamente los pedidos desde RedSys.
Un ejemplo de este tipo de códigos sería así:
# BEGIN HTTPS
<IfModule mod_rewrite.c>
RewriteCond %{HTTP:X-Forwarded-Proto} !https
RewriteCond %{HTTPS} off
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
</IfModule>
# END HTTPSCloudFlare
Para finalizar, si utilizas CloudFlare para cargar todos tus estáticos desde esta CDN, también hay un ajuste de SSL que podría ser el culpable.
En la sección denominada SSL/TLS tienes la posibilidad de cambiar el modo de cifrado, que por defecto CloudFlare configura en el modo completo (Full), lo que fuerza que se use el certificado de CloudFlare en vez de el de tu alojamiento.
Siempre, he dicho SIEMPRE, es más recomendable usar el modo flexible de SSL de CloudFlare, y de paso puede que solucione el problema de los pedidos pendientes de RedSys.
¿Te gustó este artículo? ¡Ni te imaginas lo que te estás perdiendo en YouTube!
Hola. Por mi experiencia puedo decir que tanto los CDN como las versiones de PHP han roto las comunicaciones de Redsys con las tiendas.
Son bastantes las llamadas a Redsys tratando que me aconsejaran, y no es por hacerme el listo, no tienen grandes consejos.
Para empezar tardaron meses en actualizar el archivo que vinculaban a la última versión en su web, vinculaba con la anterior. Creías que bajabas la 3 y estaba vinculado a la 2.
Me mandaron el vínculo por privado, me dio muchos fallos, volví al anterior.
Hoy en día su plugin último (por lo menos a mí en varias tiendas) no me funciona más allá del PHP 7.1.
Incluso me recomendaron que comprase un plugin «especializado» ellos mismos, flipas…
Y qué no funciona? En caso de que hagas la compra, el panel de Redsys no informa a la tienda del pago, lo que es realmente divertido, primero mientras lo encuentras y luego para explicarlo al cliente.
Pues he comprado un plugin, no voy a hacer propaganda, pero compré un modulo de pago (es fácil de encontrar) unos 70 o 140 pavos dependiendo funciones, token y suscripciones. Yo he comprado el ilimitado, algo más caro pero rentable a la larga.
Sin problema, tiendas en PHP 7.3 (el 7.4 cuando haga pruebas me da yuyu a lo loco).
Si tenéis problemas con el plugin de Redsys comprobad: CDN (gratuito), SSL Wild card o si PHP más de 7.1
En mi caso, mi ignorancia, me impidió dar con una solución más especializada, encontré una solución simple.
Fernando gracias por la información y la divulgación.
Hola Fernando, muchas gracias por este post que me está salvando la vida.
Es justo lo que me está pasando en cuanto la plataforma Redsys no informa el WooCommerce y me está dando el clásico error de prohibición:
Error (Server returned HTTP response code: 403 for URL: https://kurasanalabs.com/?wc-api=WC_Gateway_redsys)
El pedido se me queda en WC como «pendiente de pago» en lugar de «procesando» con consecuente falta de envío del correo y nadie se entera de que hay un nuevo pedido si no entramos a verlo.
No usando ni el Cloudfare ni ningún plugin de SSL (ya que tenia activado en iThemes el modulo SSL), el único que puede estar afectando es el iThemes en su especifica configuración que vi en otro post tuyo super importante y útil.
Para resolver este problema he configurado lo siguiente en iThemes:
—AJUSTES GLOBALES: En lista de servidores autorizados los de REDSYS 195.76.9.187,195.76.9.222,195.76.9.182,193.16.243.33
—USUARIOS BANEADOS: he dejado activas las opciones: Activa la funcionalidad de lista de bloqueo de HackRepair.com y Activar listas de baneo
—AJUSTES DELSISTEMA: he desactivado tanto Filtrar cadenas de URL largas como Filtrar cadenas de petición sospechosas en la URL
—He dejado inactivo el modulo SSL.
Me surge una duda, debo añadir las líneas, que recomienda José Conti, al archivo .htaccess o con los puntos anteriores es suficiente?
Gracias de antemano.
Me habéis salvado la vida con el código en el htaccess. Me ha solucionado el problema de «pendiente de pago».
Mil gracias!!
Muchas gracias por los consejos… he conseguido solucionar el problema! menos mal 🙂
Buenos días Fernando. He leído tu post y me gustaría conocer tu opinión.
Nada de lo que en él mencionas está en mi proyecto instalado ni en el functions.
Con todo, sigue pasando de vez en cuando.
Desde el 1 de noviembre de 2021 a hoy, 26 de enero de 2022, hemos tenido un 0.6% de error de timeout de Redsys en los pedidos
Mis dos preguntas:
– ¿Crees que es un porcentaje que debemos asumir o crees que debería ser CERO ABSOLUTO?
– ¿Crees que puede ser un problema del hosting donde está alojado el proyecto?
Gracias
Uf, me pides que te de datos que no tengo. Llevo el mantenimiento de varias tiendas y NUNCA hemos tenido un timeout de RedSys ¿significa eso que deba ser lo normal? no lo sé. ¿Podría ser por el hosting? Podría, pero antes miraría que no esté bloqueando conexiones a RedSys desde .htaccess, alguna regla del servidor, la CDN.
Gracias Fernando. En el htacess no tenemos ninguna regla, nuestra me refiero, que pueda ocasionarlo. En todo caso las que escribe el plugin de cache, en este caso fastest cache. Del servidor, hemos estudiado el caso con su servicio de soporte varias veces y no se encuentra nada y de la CDN tampoco puede ser.
De todas las opciones que se me ocurren, no sé si el plugin de cache puede estar interfiriendo en algún momento o si sencillamente debo probar con otro hosting.
Si, en tu opinión, no crees que deba sustituir el plugin de cache, creo que voy a optar por la opción de mover a otro hosting la tienda a ver si ese es el motivo.
Fernando, creo que en alguna ocasión he leído que tú estás en Villalba. si es así pues somos vecinos ya que yo vivo junto al hospital.
Bueno, te agradezco mucho tu respuesta y opinión y, si quieres saber cómo acaba todo esto, dímelo y te lo hago saber para no darte la lata y hacerte gastar el tiempo.
Un saludo y gracias de nuevo.
Independientemente del origen del problema, Fastest Cache me parece con mucho el peor plugin de caché que hay. Prueba mejor con Cache Enabler (para mi el mejor si no tiene caché tu servidor), o incluso WP SuperCache.
Lo de Villalba es cierto, así que cuando quieras tomamos un café o damos un paseo por la Dehesa con los perrillos (ahora tengo un Jack Russell Terrier) y charlamos:)
Gracias Fernando. el WP super cache lo dejé de usar hace como un par de años y ciertamente le cogí el aire al Fastest cache y por lo menos en su versión gratuita me dió la impresión de que el resultado era mejor. Ahora no recuerdo muy bien y tendría que buscar en los apuntes que me hago para recordar el motivo.
Lo que sí se me ha quedado grabado es que cuando veo «Automattic» se me «retuerce el morro».
Tomo nota y, considerando tu experiencia en este asunto, voy a instalarlo de nuevo en un proyecto y a ver la diferencia.
Una última pregunta, para usar el otro que mencionas «Cache Enabler» y según dices, ¿Sólo se puede usar si no tiene caché el servidor?
A nivel personal y sin ánimo de mostrar públicamente nuestro lado personal, seguramente nos habremos cruzado más de una vez en la dehesa y, además, yo también tengo un Jack Russell, jajajajaja qué coincidencia. Voy a intentar localizarte por la gente que pasea por allí y seguramente en poco tiempo nos conoceremos en persona.
Un saludo y te voy contando Fernando.
Cache Enabler es caché de disco, pura y dura, compatible con cualquier caché de servidor. También tengo pendiente probar Surge (https://es.wordpress.org/plugins/surge/) que apunta maneras.
Un abrazo 🙂