Quiero dejar muy claro que hoy en día Stripe y Redsys son idénticos en muchos aspectos, incluido el poder pagar directamente desde el checkout sin abandonar el sitio como podéis probar en mi tienda de ejemplo mediante InSite, y aunque mucha gente continuamente afirme que Stripe es mejor para los pagos ya que hay mayor finalización de pago, no es cierto. Bueno, puntualicemos, es cierto si se habla desde el desconocimiento real de cómo funciona Redsys (realmente la PSD2) y Stripe, ya que con Redsys podemos igualar la misma baja tasa de abandono que existe en Stripe en el pago (que es muy reducida) e incluso reducirla (sí, reducirla), sólo que hay que conocer la posibilidad y lo que significa esto para el comercio. Y no, no tiene nada que ver con l«a tecnología superior» de Stripe, como muchas personas repiten constantemente como si fuera un mantra.

Pero para entender todo esto hay que comenzar desde el principio. A finales de 2018 se comenzó a aplicar de forma progresiva la nueva normativa PSD2. En septiembre de 2019 entró en vigor y quien lo solicitaba podía comenzar a utilizarla en sus terminales, y el 31 de diciembre de 2020 fue de obligado cumplimiento, aunque en algunos casos fueron activando a lo largo de 2021 el flujo PSD2 en los terminales por solicitudes de empresas que no les «había dado tiempo» a adecuar su código. Lo entrecomillo porque habían tenido casi 3 años para hacerlo, así que más que no hubieran tenido tiempo, había sido dejadez (según mi forma de verlo). Yo estuve adecuando mi plugin premium de Redsys a lo largo de 4 meses, sin muchas prisas, consiguiendo liberar una versión beta dando ya soporte a la PSD2 en septiembre de 2020 para tener feedback de usuarios antes de que fuera obligatorio 4 meses antes de que entrara en uso de forma obligatoria. De hecho en ese momento ayudé a muchas empresas a adecuar el código de sus sitios hechos a medida a la PSD2 y asesoré a varias empresas conocidas de desarrollo, ya que la verdad es que no es sencillo y era más fácil acudir a alguien que ya había estado «peleándose» para aplicar la nueva normativa, que no comenzar de cero buscando información.

¿En qué consiste exactamente la PSD2? Es básicamente una doble autenticación de compra. Hasta la puesta en marcha de la PSD2, la autenticación consistía en el CVV/CVC y en algunos casos en el envío de un SMS si solicitabas en el banco que te lo activaran (algún banco te lo activaba aunque no lo solicitaras), mucha gente no lo sabía o no lo quería activar «por comodidad». Tras la entrada en vigor de la PSD2, esa segunda autenticación, que por regla general consiste en autorizar la operación a través de la aplicación del banco, era obligatoria en Europa. Esto aumentó enormemente la seguridad, pero también la complicación en el pago para muchas personas, tanto que algunos aún hoy en día no lo finalizan por no saberlo hacer, o por ejemplo porque no tienen el móvil a mano.

Y aquí comienza el punto importante, así que grábatelo a fuego para que lo tengas muy en cuenta y claro. Esta seguridad es bidireccional ¿Qué quiere decir? Que da seguridad tanto al cliente que compra en un comercio con su tarjeta, como al comercio de que quién compra es realmente el dueño de la tarjeta y está garantizado por el sistema bancario, es decir, que el que compra tiene seguridad de que al tener la doble autenticación el comercio no va a poder utilizar su tarjeta para realizarle cobros indebidos, y el comercio sabe que si le han pagado el pedido lo va a cobrar porque el sistema bancario le ha garantizado que la persona que ha comprado es la dueña de la tarjeta, por lo que en caso de robo de tarjeta (por ejemplo), vas a cobrar igual si esa operación ha sido autenticada.

¿Comienzas a ver un poco por dónde van los tiros? Ahí está básicamente la diferencia entre Stripe y Redsys. Stripe pide muchísimas menos autenticaciones (en la práctica casi nulas) y Redsys solicita por defecto autenticar prácticamente en todas las operaciones. Eso es lo que provoca que haya muchas más finalizaciones de pago en Stripe que en Redsys. Pero ¿Cómo puede ser esto si la PSD2 obliga a la autenticación? ¿Y qué sucede con todas esas operaciones no autenticadas en Stripe? Supongo que te habrás hecho estas dos preguntas, y si no te las has hecho deberías habértelas hecho con todo lo que te he explicado hasta este momento.

Dentro de la directiva PSD2 existen las exenciones, que son conocidas como SCA (Strong Consumer Authentication o autenticación reforzada de los consumidores). Hay varios SCA, pero hay tres en particular importantes en este ámbito.  Una es el MIT, que no aplica en este caso ya que este es exclusivo de suscripciones. Los que debemos conocer y tener en cuenta es el LWV y el TRA.

El LWV es un SCA que se aplica cuando el pedido es de bajo coste. Es decir, cuando el importe es menor a 30€ se puede enviar en la solicitud de cobro y no se solicitará la autenticación. Stripe lo aplica directamente si el pedido entra dentro del rango de precio y en Redsys hay que solicitarlo para que lo activen y enviar el SCA en el momento del cobro de un pedido si procede. Trasladado al mundo offline, es cuando pagas en un comercio físico con la tarjeta, y por el valor de la compra no te solicita el pin para pagar, obviamente esto ya no se nota tanto si pagáis con móvil a través NFC, porque siempre solicita la huella por seguridad de acceso al método de pago, cómo mínimo con la aplicación que yo utilizo (CaixaBank).

El TAR, que es el «peligroso», es como el LWV, pero con la diferencia que es para importes mucho más alto. TRA significa (Transaction Risk Analysis). La aplicación máxima del SCA TRA suele depender del banco en el caso de Redsys, pero por regla general son muy reacios a activarlo/aceptarlo para importes superiores a 250€. Si te activan TRA en Redsys, tu podrás solicitar que se aplique y Redsys realizará una valoración si lo envía o no al emisor, pero tened en cuenta que el riesgo lo asumiréis vosotros (como ya explicaré el un poco más tarde). Stripe lo tiene activo directamente y con importes hasta 500€. Lo que hará Stripe es realizar un análisis de riesgo, y si no ve nada significativo enviará TRA al emisor de la tarjeta para la solicitud de pago con lo que no se realizará la autenticación (si el emisor del cliente lo acepta). En la captura del siguiente cuadro que puedes encontrar aquí, puedes ver como aplican el análisis de riesgo para enviar o no TRA.

Esto anterior puede parecer muy interesante y que uno piense, ¡Ah, fantástico, envío siempre TRA! Es un pensamiento que puede venir muy rápido a la cabeza ¿verdad? Menos solicitud de autenticaciones, más conversiones, más ventas ¡Fantástico! «Ahora entiendo por qué con Stripe no hay tanto abandono en el pago, porque muy pocos se deben autenticar».

Si, tendríais razón en que el motivo es ese, envía LWV o TRA en casi la totalidad de las transacciones, y eso hace que no se solicite en prácticamente ningún caso autenticación, si el emisor/banco del cliente lo acepta, porque igual el emisor/banco no aceptar el TRA por cualquier motivo y solicita autenticación. Y cómo he comentado anteriormente, podéis solicitar a Redsys que os lo activen. El LWV prácticamente sería inmediato, y el TRA puede que tarden un poco más. Pero ojo, te informarán de qué consecuencias tiene que te activen estos SCA y a lo mejor ya no lo ves como una buena idea porque el conocimiento es poder, sobre todo de decisión.

Si profundizamos más en los SCA, el ente que envía el SCA (ya sea el comercio o el banco), sea LWV o TRA, debe hacerse cargo en caso de estafa/robo. Si profundizamos en PSD2/SCA, podemos ver que quien se debe hacer cargo en caso de fraude, ha de ser el que envía conformidad de TRA (en esta entrada de Adyen explican muy bien todo) Podemos ver que casi al final, pone esto:

2. Transacciones de bajo riesgo – TRA (Transaction Risk Analysis)

Los bancos emisores pueden considerar ciertas transacciones como de bajo riesgo. Para ello, se basan en los niveles de fraude medio del emisor, del adquiriente o de ambos al mismo tiempo. En estos casos, la exención puede pedirla tanto el comercio como el banco emisor.

La responsabilidad en caso de contra cargo recaerá sobre el emisor si fue este quien pidió la exención o sobre el comercio si fue el que la pidió.

Lo más importante es el último párrafo. Así que ya tienes una pista de lo que te va a decir tu banco. Te pueden activar LWV o TRA en el terminal para solicitar no autenticar la operación, pero si esa tarjeta ha sido robada (por ejemplo) y el banco emisor acepta el TRA, te vas a quedar sin el producto (si ya lo has enviado) y sin el dinero, porque lo vas a tener que devolver. Si hay autenticación, aunque a la persona le hayan robado la tarjeta y su móvil y hayan comprado en tu sitio, nadie va a poder reclamarte nada. Continuas con el dinero porque es un problema del dueño de la tarjeta y del banco emisor, ya se aclararán entre ellos quien es el culpable de ese cargo, el banco por no anular rápido la tarjeta a tiempo, o el dueño de la tarjeta por no haber denunciado de inmediato el robo. Pero seguro que tú no lo eres.

Y ahora estarás pensando, «Ah, pues es Stripe el que envía TRA, ¡Que espabile!». Y sería lo lógico en este caso porque lo está enviando si que tu sepas nada, pero esta es la única parte pantanosa de todo esto. Pues no, está enviando TRA en tu nombre sin que tengas conocimiento de ello y sin conocer las consecuencias que tiene en pedidos de hasta 500€, y en caso de estafa te va a pasar el problema a ti abriendo una disputa, es decir, está haciendo que la gente no autentique sin explicar las consecuencias de ello a los comerciantes, pero si hay algún problema, que se lo coma el comercio sin que haya solicitado asumir ese riesgo. Por eso digo que es la parte pantanosa de todo esto. Es decir, si tienes la desgracia que una mafia de robo/clonación de tarjetas pasa por tu web y te compra mediante diferentes usuarios y tarjetas productos con un valor por ejemplo de 10.000€, que no te pase nada con Stripe, porque habrá enviado TRA, no se habrán autenticado, y te pasarán el marrón mediante disputa cuando aparezcan todas las denuncias de que las tarjetas habían sido robadas o clonadas y que las compras no habían sido autenticadas. Pero no sólo vas a tener que devolver el dinero, también se va a aplicar una tarifa por lo que se denomina contracargo, es decir, que no solo vas a quedarte sin el dinero y el producto, vas a tener que pagar por ello. En el caso de Stripe, por disputa que pierdas serán a día de hoy 15€ (piensa que dentro de esos 10.000€ pueden haber cientos de pedidos diferentes) + 20€ por cada retorno de dinero (lo mismo, pueden ser cientos de clientes/pedidos), y no se si hay un % del valor de sanción. Pero solo con los 15€ + los 20€ por transacción/cliente, haz números. Igual pagas más con todos estos cargos, que los 10.000€ que ya te habían estafado, sin contar la pérdida del genero/productos.

¿Todo esto es un alegato en contra de Stripe? No, solo te cuento lo que ellos no cuenta, para que un día no tengas una sorpresa muy desagradable. Ahora como mínimo sabes como es el tablero de juego, y puedes decidir con todos los datos en la mano.

Stripe tiene cosas buenas en comparación con Redsys, como la facilidad de contratación, el panel de gestión de transacciones, facturación, etc. Que puede ser un valor añadido que os incline a su uso. Pero en contrapartida Redsys tiene mucha seguridad y tarifas muy bajas.

En estos momentos igual estás pensando, «A mí nunca me ha sucedido nada así», hasta que un buen día puede suceder y te encuentras en una situación semejante a la anterior. Pero ahora ya no podrás decir que no te lo esperabas o no conocías, pero si aun así estás dispuesto a aceptar el riesgo de TRA y en mucha menor medida LWV, en Redsys puedes tenerlo igual y con unas comisiones muchísimo más bajas de las que aplica Stripe (y aún más tras la subida que realizaron), y mediante mi plugin de Redsys para WooCommerce podrás solicitar LWV y TRA (si estás dispuesto a asumir el riesgo) a Redsys (si te los han activado en el terminal) y también tener el formulario de la tarjeta de crédito en el checkout sin abandonar la web, que también se puede con Redsys como podréis comprobar en mi tienda de ejemplo.

Puede ser muy interesante la activación de LWV en el terminal para que todos los pagos menores de 30€ no se autentiquen, pero hay que tener cuidado con TRA. Sin dudarlo, el enviar TRA, que como comento puedes hacerlo también con Redsys, aumentará casi seguro tus ventas al no solicitar tanto la autenticación, pero también aumentará mucho la posibilidad que te estafen.

Ya tienes de verdad toda la información de cómo funciona la PSD2. Creo que no vas a encontrar muchas entradas tan claras como esta en cuanto al funcionamiento y riesgos que existen con los SCA. En esos momentos, sabiendo todo lo que sabes tras leer la entrada puedes tomar de verdad una decisión de lo que quieres para conseguir un fin teniendo en cuenta las consecuencias. Ahora puedes valorar como vas a enfocar tu forma de pago, más autenticaciones al no utilizar ningún tipo de SCA para vivir tranquilo, aplicar LWV teniendo un balanceo entre seguridad y riesgo bajo al ser de importes reducidos, o utilizarás TRA maximizando las ventas al reducir las autenticaciones pero también maximizando riesgos.

Cómo puedes ver, con Redsys también puedes reducir al mínimo las autenticaciones y maximizar ventas por no abandono de pago como en Stripe gracias a que solicites y te activen los SCA LWV y TRA, pero la decisión de aceptar el riego en Redsys es tuya, y en Stripe viene impuesta y con el desconocimiento de la mayoría de los comerciantes de los riesgos que están asumiendo. Y lo peor es que la mayoría lo interpreta como que con Stripe se tienen más ventas porque tiene mejor tecnología.

Por favor, deja este campo vacío

¡No te pierdas las novedades!

Dirección de correo electrónico *

Acepto apuntarme a la lista de correo para estar al día de todas las novedades.

¡No hacemos spam! y te puedes dar de baja cuando quieras

Revisa tu bandeja de entrada o la carpeta de spam para confirmar tu suscripción.