Solución al problema de los pedidos en WooCommerce con Redsys y HTTPS

Con la cantidad de datos personales que, cada vez con más frecuencia, solemos aportar en las páginas web que vamos visitando a lo largo del día, y muy especialmente en las tiendas online –donde se suele incluir, además, información económica o bancaria muy sensible–, es normal que la seguridad se haya convertido en uno de los principales problemas a solventar por parte de proveedores de servicios de Internet (hostings, plataformas de pago, servidores en la nube, proveedores de correo electrónico, etc) y empresas dedicadas a la lucha contra la ciberdelincuencia.

Hackers o ladrones de datos los ha habido siempre, pero hasta hace unos años la mayor parte de la navegación en Internet se basaba en visitas a páginas con contenido meramente unidireccional, en el que el usuario apenas dejaba un rastro pequeño, del que había poco que rascar.

Si algún adolescente superdotado era capaz de robar listas y contraseñas de emails personales, el daño tampoco era catastrófico. Más problema podían dar los virus o troyanos que se propagaban en los disquetes de 3 ¼ de antaño, que los ciberataques.

Hoy en día, sin embargo, el malware ideado para hacerse con cuentas bancarias o secretos empresariales es más importante que nunca, ya que el adolescente cerebrito fue sustituido hace tiempo por bandas organizadas cuya misión es hacerse con miles o millones de euros/dólares desde el otro lado de la pantalla de sus ordenadores.

Y los más vulnerables en este sentido son los de siempre, los usuarios domésticos que escriben sus números de tarjeta, entre otras cosas, en los formularios de registros de webs y tiendas online porque necesitan hacerse con la última figura de Star Wars que ha salido a la venta (por darle un toque friki a todo esto, si me permitís).

Por el contrario, y para contrarrestar las retorcidas ideas del villano de turno, la ciberseguridad llegó para hacernos la vida más tranquila y, desde hace años, es un campo especialmente productivo que siempre está concibiendo técnicas de control y prevención. Y si hablamos de prevención en la World Wide Web, una de las armas más importantes que se utilizan actualmente y que ofrece resultados comprobados es el cifrado de datos.

Qué es HTTPS y para qué lo necesitas en tu tienda online

Llegados a este punto, y a estas alturas de la película, ya tendrías que saber de qué se trata cuando alguien te habla de “certificado SSL” o HTPPS, ¿no es así? Ah, bueno, parece que veo algún brazo en alto en el fondo… y aquí a la derecha creo que también hay alguien que no sabe qué diablos es esto de cifrados, certificados y demás. No pasa nada, tranquilos, que para eso está, entre otras cosas, este blog y Antonio Cantero me permite que os lo cuente, antes de entrar en materia práctica.

La explicación rápida y más visual es la siguiente: ¿os suena el candadito verde en la barra de direcciones del navegador (de escritorio o móvil) cuando visitáis una página web?

Perfecto, pues sabed entonces que estáis navegando a través de HTTPS (o http Seguro) y que podréis hacerlo con seguridad en esa web y, si os piden algún dato personal a modo de formulario porque queréis inscribiros en un curso o pagar por un producto, vuestra información personal va a viajar, hasta el servidor de la página, protegida por una encriptación especial que impedirá que cualquiera ajeno a la web visitada y vuestro ordenador se pueda hacer con estos datos y descifrarlos.

¿Y qué hay que hacer para poder navegar mediante el protocolo HTTPS en vuestras webs? Sencillo, instalar un certificado SSL que atestigüe que, efectivamente, la página cuenta con un protocolo de navegación segura.

Hasta hace no mucho, estos certificados han sido siempre de pago, con costes que iban desde unos pocos euros hasta una fortuna, según el nivel de seguridad que ofrecían.

A pesar de todo, incluso los certificados más económicos eran una buena opción para convertir la web en un lugar relativamente seguro. Pero precisamente por tratarse de productos de pago y de que todavía no hay una percepción plena de que la seguridad online es importante, la implantación del HTTPS no se ha popularizado en demasía. Hasta hace poco…

Instalando y configurando un certificado SSL para tu tienda WooCommerce con Let’s Encrypt

(Nota: si ya tienes instalado el certificado y lo que buscas es solucionar los errores de notificaciones de Redsys, puedes pasar directamente al siguiente apartado)

A finales de 2015, la Fundación Linux decidió dar un paso enorme para la Humanidad y ofrecer, de forma gratuita, un certificado SSL a todo aquél que necesitara instalarlo en su servicio online. Como ellos mismos dicen «Let’s Encrypt es una autoridad certificadora gratis, automatizada y abierta, realizada para el beneficio público»

Hablando en plata: que si ya no pones SSL a tu web es porque no quieres o te da igual comprometer la seguridad de tus visitantes. Una pena, porque por cada página que no tiene instalado SSL, un gatito morirá. Y nosotros adoramos a los gatitos.

Actualmente, casi todos los servicios de hosting, al menos los que conozco, ofrecen la posibilidad de instalar Let’s Encrypt desde el panel de control del servidor, con lo que os invito a consultarlo con vuestros proveedores.

VER HOSTING WOOCOMMERCE DE SITEGROUND

Seguramente se trate de una activación mediante un botón y poco más. Si no es así, habladlo con ellos para que os indiquen el modo de hacerlo.

Tras instalar el certificado, hay que decirle a WordPress y WooCommerce que a partir de ahora todas las urls de la tienda van a funcionar con HTTPS. Y puedes hacerlo de 2 formas:

OPCIÓN 1 – Sin plugins adicionales

En primer lugar, id a los “Ajustes” de WordPress y en el menú “General” indicadle que, a partir de ahora, lo vuestro es la ciberseguridad, y que por tanto hay que acceder a vuestra web a partir de https, así:

Seguidamente, habría que acudir al archivo .htaccess, que se encuentra en la carpeta raíz de nuestra web, accesible a través de un servicio de ftp, e incluir las siguientes líneas de código, que lo que harán es decirle a WordPress que haga una redirección desde la antigua http a la nueva https. De este modo:

 RewriteEngine On RewriteCond %{SERVER_PORT} 80 RewriteRule ^(.*)$ https://www.tudominio.com/$1 [R,L] 

Donde pone “tudominio.com” debes de escribir el nombre de dominio de tu web. (Tranquilos, que hay una solución menos peligrosa, que os cuento enseguida).

Finalmente, y para que no haya problemas a la hora de hacer login en vuestro panel de WordPress, deberéis añadir las siguientes líneas al archivo wp-config.php (justo antes de la que dice “That’s all, stop editing!”), que también se encuentra en la carpeta raíz vía ftp:

define('FORCE_SSL_LOGIN', true); define('FORCE_SSL_ADMIN', true);

OPCIÓN 2 – Usando un plugin

Si no tenéis ganas de toquetear código ni archivos que no conozcáis y provocar, quizás, un estropicio, hay un método alternativo que consiste en instalar un plugin muy útil llamado «Really Simple SSL» y que deberéis configurar del siguiente modo:

Si tenéis acceso a Google Search Console y a Google Analytics, es importante, asimismo, que modifiquéis los parámetros para que ahora comiencen a rastrear la web con la nueva propiedad. ¿Os he dicho, además, que el SSL ayuda al SEO de vuestra página web? ¿A qué esperáis, entonces, a instalar un certificado?

¡Listo! Ya tienes tu web bajo el protocolo HTTPS funcionando, tus visitantes se encontrarán más seguros bajo su paraguas, y tú estarás tranquilo porque has salvado a un gatito.

Solución al problema de los pedidos en WooCommerce pagados con Redsys

Bien, llegados a este punto es posible que ya supieras toda la teoría, la práctica y que lo que andabas buscando al entrar en este post no lo hayas encontrado. Hasta ahora. Así que discúlpame si lo anterior te ha aburrido o era información redundante en tu cabeza.

En realidad, esta entrada se fraguó en un principio como una ayuda para todos aquellos que, teniendo instalado WooCommerce y el TPV Virtual de Redsys, tenían problemas con los pedidos en el backend de la tienda online (los pedidos se pagan, pero no se reflejan como pedidos “Procesando”, sino como “En espera”).

Pero al final, me salió mi vena periodística y decidí hacer un poco de historia y ofrecer una pequeñísima guía a todos aquellos que llegaran aquí y no supieran nada de certificados ni de instalaciones de éstos.

Por lo tanto, si hemos conseguido ayudar a esta gente, nos damos por satisfechos por partida doble.

Ok, pero os preguntaréis “¿me va a decir este tío de una vez cómo arreglar lo de los pedidos?”. Ea, vamos allá. Como decía, tras la instalación del certificado Let’s Encrypt en nuestra tienda online, la navegación se hacía, por fin, segura y los datos os llegaban encriptados, con lo que supone de confianza hacia vuestra clientela.

Sin embargo, muchos de vosotros, usuarios del TPV Virtual de Redsys, habréis comprobado que los pedidos realizados mediante este método de pago no se llegan a trasladar al backend como consumados.

Ya sabemos que los pedidos pagados al momento (ya sea por tarjeta bancaria, Paypal o Stripe) se notifican como “Procesando” de modo que vosotros, como propietarios de la tienda, conocéis en todo momento el estado de los mismos en el menú de gestión (independientemente de que se consulte el pago en el módulo de administración del TPV).

Al contrario, y aquí radica el problema, estos pedidos no se etiquetan como “Procesando” sino que se establecen como “En espera”, con la consiguiente confusión que puede provocar esta etiqueta, utilizada para los pedidos realizados pero no pagados (habitualmente porque se han efectuado mediante el método de transferencia). De forma adicional, los emails de confirmación de la transacción (los que envía Redsys) no se envían.

¿Y quién es el culpable de esta situación? Pues ni más ni menos que la propia Redsys.

Reconocido también por ellos, todo hay que decirlo, ocurre que la pasarela de pagos (la más extendida entre los proveedores de este servicio en España, dato importante y, por lo tanto, lo que más nos sorprende en este caso) no soporta SNI, que es la forma más común, hoy en día, de instalar los certificados SSL, como hace Let’s Encrypt.

No hace falta profundizar en qué es SNI, pero digamos de forma rápida que permite instalar los certificados sin contratar una IP dedicada.

Consecuentemente, y al no aceptarlo, Redsys (que requiere de una validación con IP dedicada) no va a notificar a nadie (ni a WordPress/WooCommerce ni a vosotros mediante el email) de que se ha realizado un pago como resultado de un pedido. Evidentemente, esta es una situación indeseable ya que tendríamos que estar cada dos por tres comprobando manualmente el pago y pasando las notificaciones de los pedidos de “En espera” a “Procesando”.

Señores de Redsys, ya que habíamos salvado a tantos gatitos, vienen ustedes y nos hacen desear que un león les haga una visita, a ver si así se ponen las pilas de una vez y arreglen esta situación. Mientras este deseado momento llega, somos nosotros los que vamos a tener que solucionar el inconveniente.

Para ello, lo que vamos a hacer es decirle a Redsys que las comunicaciones del banco hacia nuestra web, una vez efectuado el pago por parte del cliente, se hagan por http.

Tranquilos, esta operación no va a comprometer la seguridad de la web, ya que la información va a seguir circulando de forma cifrada y, además, la introducción de los datos de la tarjeta bancaria siempre tiene lugar en la página del banco, que es, asimismo, cifrada mediante su propio certificado SSL.

Hablamos de una comunicación puntual que sólo va a tener lugar en la trastienda, en el backoffice, entre el TPV y nosotros. Lo que vamos a conseguir es que una vez que la operación bancaria se haya efectuado, Redsys utilizará el antiguo protocolo, informando así a WooCommerce de que el pedido puede etiquetarse como “Procesando” y permitiendo el envío del email de confirmación de la transacción.

Lo bueno de todo esto es que si usas un plugin de gestión de la pasarela, seguramente éste contenga la opción para corregir esta deficiencia. En el caso del plugin que yo utilizo, el de modulosdepago, sólo hay que marcar la opción “marque esta opción si usa HTTPS y Redsys no reconoce su certificado”; por su parte, el plugin de Codection aparece como la elección desplegable “No, usar la respuesta estándar por HTTP” de la opción “Forzar respuesta por HTTP”.

Acto seguido, es necesario hacer una cosa importante: eliminad cualquier redirección de .htaccess.

Mientras sigáis manteniendo el código que tuvimos que introducir al instalar el certificado, el error se seguirá reproduciendo. Por lo tanto, a borrarlo.

En este sentido, si tenéis muchos enlaces apuntando a vuestra web, no estaría de más que los cambiarais con el https delante, para no tener demasiados problemas con los buscadores.

Unas consideraciones finales

1 – Si configuraste la instalación de Let’s Encrypt mediante el plugin Really Simple SSL, asegúrate de marcar la casilla “Dejar de modificar el archivo .htaccess”.

Te lo aseguro, estuve toda una mañana con la cabeza a punto de estallarme porque aunque borraba a mano el código de redirección, éste volvía a aparecer y las pruebas que hacía seguían siendo erróneas. No me di cuenta de que la solución estaba a un solo click pasadas unas cuantas horas 🙁

2 – Hay un plugin que, no obstante, no ofrece la posibilidad de forzar la comunicación por http en lugar de por https… ¿Adivináis cuál? ¡Claro, el propio de Redsys! Qué ilusos fuimos si creímos que nuestros amigos iban a ponernos las cosas fáciles… Bueno, tranquilos, que también hay solución a este desaguisado.

En primer lugar, desactivar la opción de “Forzar pago seguro” en los ajustes de Finalizar Compra de WooCommerce. Y, seguidamente, deberemos de hacer lo siguiente en el archivo wc-redsys.php (si usas una versión antigua del plugin, deberéis buscarlo en el archivo class-wc-redsys.php):

Localiza la siguiente línea de código:

//Callback $urltienda = $this -> notify_url;

y sustituidla por esta:

$urltienda = str_replace('https://', 'http://', $this -> notify_url);

Recordad: este paso es necesario sólo si usáis el plugin de Redsys.

3 – Por último, y para rematar la faena, es posible que, a pesar de todo lo dicho hasta ahora, siga sin solucionarse esta pesadilla. A un conocido le pasó y, según me contaba, es posible que se debiera a características particulares del tema que usaba o vete tú a saber. Por eso, lo que hizo como última alternativa fue implementar una exclusión a las redirecciones del .htaccess.

Se fijó, desde el panel del TPV, a qué dirección mandaba Redsys las notificaciones, y esa es la dirección que excluyó. Es decir, de esta forma se le está diciendo que se redirija siempre a la versión HTTPS salvo si la petición incluye la cadena wc-api=WC_redsys [NC]. En concreto, la línea que añadió antes de la redirección fue esta:

RewriteCond %{QUERY_STRING} !wc-api=WC_redsys [NC]

quedando la redirección así:

RewriteEngine On RewriteCond %{SERVER_PORT} 80 RewriteCond %{QUERY_STRING} !wc-api=WC_redsys [NC] RewriteRule ^(.*)$ https://tudireccion.com/$1 [R=301,L]

A partir de ahora, vuestros problemas con Let’s Encrypt y Redsys en WooCommerce, esperamos, deberían de haberse solucionado. Ya es posible tener una tienda online segura y, además recibir las notificaciones de los pedidos de forma correcta.