Coñece de verdade as diferencias entre Stripe e Redsys e os seus perigos

Quero deixar moi claro que hoxe en día Stripe e Redsys son idénticos en moitos aspectos, incluído o poder pagar directamente desde o checkout sen abandonar o sitio como podedes probar en a miña tenda de exemplo mediante InSite, e aínda que moita xente continuamente afirme que Stripe é mellor para os pagos xa que hai maior finalización de pago, non é certo. Ben, puntualicemos, é certo se se fala desde o descoñecemento real de como funciona Redsys (realmente a PSD2) e Stripe, xa que con Redsys podemos igualar a mesma baixa taxa de abandono que existe en Stripe no pago (que é moi reducida) e incluso reducilas (si, reducilas), só que hai que coñecer a posibilidade e o que significa isto para o comercio. E non, non ten nada que ver coa “tecnoloxía superior” de Stripe, como moitas persoas repiten constantemente como se fose un mantra.

Pero para entender todo isto hai que comezar desde o principio. A finais de 2018 comezouse a aplicar de forma progresiva a nova normativa PSD2. En setembro de 2019 entrou en vigor e quen o solicitaba podía comezar a utilizala nos seus terminais, e o 31 de decembro de 2020 foi de obrigado cumprimento, aínda que en algúns casos foron activando ao longo de 2021 o fluxo PSD2 nos terminais por solicitudes de empresas que non lles “había dado tempo” a adecuar o seu código. O entrecomillo porque tiveran case 3 anos para facelo, así que máis que non tiveran tempo, había sido deixadez (segundo a miña forma de velo). Eu estiven adecuando o meu plugin premium de Redsys ao longo de 4 meses, sen moitas présas, conseguindo liberar unha versión beta dando xa soporte á PSD2 en setembro de 2020 para ter feedback de usuarios antes de que fose obrigatorio 4 meses antes de que entrase en uso de forma obrigatoria. De feito, nese momento axudei a moitas empresas a adecuar o código dos seus sitios feitos a medida á PSD2 e aseseorei a varias empresas coñecidas de desenvolvemento, xa que a verdade é que non é sinxelo e era máis fácil acudir a alguén que xa estivese “peleándose” para aplicar a nova normativa, que non comezar de cero buscando información.

¿En que consiste exactamente a PSD2? É basicamente unha dobre autenticación de compra. Ata a posta en marcha da PSD2, a autenticación consistía no CVV/CVC e en algúns casos no envío dun SMS se solicitabas no banco que te o activaran (algún banco te o activaba aínda que non o solicitaras), moita xente non o sabía ou non o quería activar “por comodidade”. Tras a entrada en vigor da PSD2, esa segunda autenticación, que por regra xeral consiste en autorizar a operación a través da aplicación do banco, era obrigatoria en Europa. Isto aumentou enormemente a seguridade, pero tamén a complicación no pago para moitas persoas, tanto que algúns aínda hoxe en día non o finalizan por non saber facelo, ou por exemplo porque non teñen o móbil á man.

E aquí comeza o punto importante, así que grábatelo a fogo para que o teñas moi en conta e claro. Esta seguridade é bidireccional ¿Que quere dicir? Que dá seguridade tanto ao cliente que compra nun comercio coa súa tarxeta, como ao comercio de que quen compra é realmente o dono da tarxeta e está garantido polo sistema bancario, é dicir, que o que compra ten seguridade de que ao ter a dobre autenticación o comercio non vai poder utilizar a súa tarxeta para realizar cobros indebidos, e o comercio sabe que se lle pagaron o pedido o vai cobrar porque o sistema bancario garantiu que a persoa que comprou é a propietaria da tarxeta, polo que en caso de roubo de tarxeta (por exemplo), vas a cobrar igual se esa operación foi autenticada.

¿Comezas a ver un pouco por onde van os tiros? Alí está basicamente a diferencia entre Stripe e Redsys. Stripe pide moitísimas menos autenticacións (na práctica case nulas) e Redsys solicita por defecto autenticar practicamente en todas as operacións. Iso é o que provoca que haxa moitas máis finalizacións de pago en Stripe que en Redsys. Pero ¿Como pode ser isto se a PSD2 obriga á autenticación? ¿E que sucede con todas esas operacións non autenticadas en Stripe? Supoño que te habrás feito estas dúas preguntas, e se non te as fixeches deberías facelo con todo o que che expliquei ata este momento.

Dentro da directiva PSD2 existen as exencións, que son coñecidas como SCA (Strong Consumer Authentication ou autenticación reforzada dos consumidores). Hai varios SCA, pero hai tres en particular importantes neste ámbito.  Unha é o MIT, que non aplica neste caso xa que este é exclusivo de subscricións. Os que debemos coñecer e ter en conta son o LWV e o TRA.

O LWV é un SCA que se aplica cando o pedido é de baixo custo. É dicir, cando o importe é menor a 30€ pódese enviar na solicitude de cobro e non se solicitará a autenticación. Stripe aplícao directamente se o pedido entra dentro do rango de prezo e en Redsys hai que solicitalo para que o activen e enviar o SCA no momento do cobro dun pedido se procede. Trasladado ao mundo offline, é cando pagas nun comercio físico coa tarxeta, e polo valor da compra non te solicita o pin para pagar, obviamente isto xa non se nota tanto se pagades cun móbil a través de NFC, porque sempre solicita a pegada por seguridade de acceso ao método de pago, como mínimo coa aplicación que eu utilizo (CaixaBank).

O TAR, que é o “perigoso”, é como o LWV, pero coa diferenza que é para importes moito máis altos. TRA significa (Transaction Risk Analysis). A aplicación máxima do SCA TRA sol normalmente depender do banco no caso de Redsys, pero por regra xeral son moi reacios a activalo/aceptalo para importes superiores a 250€. Se te activan TRA en Redsys, poderás solicitar que se aplique e Redsys realizará unha valoración se o envía ou non ao emisor, pero tede en conta que o risco o asumirás vós (como xa explicaréi un pouco máis tarde). Stripe téneo activo directamente e con importes ata 500€. O que fará Stripe é realizar un análisis de risco, e se non ve nada significativo enviará TRA ao emisor da tarxeta para a solicitude de pago co que non se realizará a autenticación (se o emisor do cliente o acepta). Na captura do seguinte cadro que podes encontrar aquí, podes ver como aplican o análisis de risco para enviar ou non TRA.

Esto anterior pode parecer moi interesante e que un pense, ¡Ah, fantástico, envío sempre TRA! É un pensamento que pode vir moi rápido á cabeza ¿verdade? Menos solicitude de autenticacións, máis conversións, máis vendas ¡Fantástico! «Agora entendo por que con Stripe non hai tanto abandono no pago, porque moi poucos se deben autenticar».

Si, teríades razón en que o motivo é ese, envía LWV ou TRA en case a totalidade das transaccións, e iso fai que non se solicite en practicamente ningún caso autenticación, se o emisor/banco do cliente o acepta, porque igual o emisor/banco non acepta o TRA por calquera motivo e solicita autenticación. E como comentei anteriormente, podedes solicitar a Redsys que vos o activen. O LWV practicamente sería inmediato, e o TRA pode que tarden un pouco máis. Pero ollo, informarache de que consecuencias ten que te activen estes SCA e a mellor xa non o ves como unha boa idea porque o coñecemento é poder, sobre todo de decisión.

Se profundizamos máis nos SCA, o ente que envía o SCA (xa sexa o comercio ou o banco), sexa LWV ou TRA, debe facerse cargo en caso de estafa/roubo. Se profundizamos en PSD2/SCA, podemos ver que quen se debe facer cargo en caso de fraude, ten que ser quen envía conformidade de TRA (en esta entrada de Adyen explican moi ben todo) Podemos ver que case ao final, pon isto:

2. Transaccións de baixo risco – TRA (Transaction Risk Analysis)

Os bancos emisores poden considerar certas transaccións como de baixo risco. Para iso, baséanse nos niveis de fraude medio do emisor, do adquirente o de ambos ao mesmo tempo. Nestes casos, a exención pode pedila tanto o comercio como o banco emisor.

A responsabilidade en caso de contracargo recaerá sobre o emisor se foi este quen pediu a exención ou sobre o comercio se foi o que a pediu.

O máis importante é o último parágrafo. Así que xa tes unha pista do que che vai a dicir o teu banco. Pódense activar LWV ou TRA no terminal para solicitar non autenticar a operación, pero se esa tarxeta foi roubada (por exemplo) e o banco emisor acepta o TRA, vas a quedar sen o produto (se xa o enviaste) e sen o diñeiro, porque o vas a ter que devolver. Se hai autenticación, aínda que á persoa lle roubaran a tarxeta e o seu móbil e compraran no teu sitio, ninguén vai poder reclamarche nada. Continúas co diñeiro porque é un problema do dono da tarxeta e do banco emisor, xa se aclararán entre eles quen é o culpable dese cargo, o banco por non anular rápido a tarxeta a tempo, ou o dono da tarxeta por non ter denunciado de inmediato o roubo. Pero seguro que ti non o es.

E agora estarás pensando, «Ah, pois é Stripe o que envía TRA, ¡Que espabile!». E sería o lóxico neste caso porque o está enviando sen que ti saibas nada, pero esta é a única parte pantanosa de todo isto. Pois non, está enviando TRA en teu nome sen que ti teñas coñecemento diso e sen coñecer as consecuencias que ten en pedidos de ata 500€, e en caso de estafa vas a pasar o problema a ti abriendo una disputa, é dicir, está facendo que a xente non autentique sen explicar as consecuencias diso aos comerciantes, pero se hai algún problema, que se o coma o comercio sen que haxa solicitado asumir ese risco. Por iso digo que é a parte pantanosa de todo isto. É dicir, se tes a desgraza de que unha mafia de roubo/clonación de tarxetas pasa pola túa web e che compra mediante diferentes usuarios e tarxetas produtos cun valor por exemplo de 10.000€, que non che pase nada con Stripe, porque terá enviado TRA, non se habrán autenticado, e pasarán o marrón mediante disputa cando aparezan todas as denuncias de que as tarxetas foran roubadas ou clonadas e que as compras non foran autenticadas. Pero non só vas a ter que devolver o diñeiro, tamén se vai a aplicar unha tarifa por o que se denomina contracargo, é dicir, que non só vas a quedarte sen o diñeiro e o produto, vas a ter que pagar por iso. No caso de Stripe, por disputa que perdas serán a día de hoxe 15€ (pensa que dentro deses 10.000€ poden haber centos de pedidos diferentes) + 20€ por cada retorno de diñeiro (o mesmo, poden ser centos de clientes/pedidos), e non sei se hai un % do valor de sanción. Pero só cos 15€ + os 20€ por transacción/cliente, fai números. Igual pagas máis con todos estes cargos, que os 10.000€ que xa che habían estafado, sen contar a perda do xénero/produtos.

¿Todo isto é un alegato en contra de Stripe? Non, só che conto o que eles non contan, para que un día non teñas unha sorpresa moi desagradable. Agora como mínimo sabes como é o taboleiro de xogo, e podes decidir con todos os datos na man.

Stripe ten cousas boas en comparación con Redsys, como a facilidade de contratación, o panel de xestión de transaccións, facturación, etc. Que pode ser un valor engadido que vos incline ao seu uso. Pero en contrapartida Redsys ten moita seguridade e tarifas moi baixas.

Nestes momentos igual estás pensando, «A min nunca me sucedeu nada así», ata que un bo día pode suceder e te atopas nunha situación semellante á anterior. Pero agora xa non poderás dicir que non te o esperabas ou non coñecías, pero se aínda así estás disposto a aceptar o risco de TRA e en moita menor medida LWV, en Redsys podes telo igual e con unhas comisións moito máis baixas das que aplica Stripe (e aínda máis tras a subida que realizaron), e mediante o meu plugin de Redsys para WooCommerce poderás solicitar LWV e TRA (se estás disposto a asumir o risco) a Redsys (se te los activaron no terminal) e tamén ter o formulario da tarxeta de crédito no checkout sen abandonar a web, que tamén se pode con Redsys como podedes comprobar en a miña tenda de exemplo.

Pode ser moi interesante a activación de LWV no terminal para que todos os pagos menores de 30€ non se autentiquen, pero hai que ter coidado con TRA. Sen dúbida, o enviar TRA, que como comento podes facelo tamén con Redsys, aumentará case seguro as túas vendas ao non solicitar tanto a autenticación, pero tamén aumentará moito a posibilidade de que te estafen.

Xa tes de verdade toda a información de como funciona a PSD2. Creo que non vas a atopar moitas entradas tan claras como esta en canto ao funcionamento e riscos que existen cos SCA. Neses momentos, sabendo todo o que sabes tras ler a entrada podes tomar de verdade unha decisión do que queres para conseguir un fin tendo en conta as consecuencias. Agora podes valorar como vas a enfocar a túa forma de pago, máis autenticacións ao non utilizar ningún tipo de SCA para vivir tranquilo, aplicar LWV tendo un balanceo entre seguridade e risco baixo ao ser de importes reducidos, ou utilizarás TRA maximizando as vendas ao reducir as autenticacións pero tamén maximizando riscos.

Como podes ver, con Redsys tamén podes reducir ao mínimo as autenticacións e maximizar vendas por non abandono de pago como en Stripe grazas a que solicites e te activen os SCA LWV e TRA, pero a decisión de aceptar o risco en Redsys é túa, e en Stripe vén imposta e co descoñecemento da maioría dos comerciantes dos riscos que están asumiendo. E o peor é que a maioría o interpreta como que con Stripe se teñen máis vendas porque ten mellor tecnoloxía.

Por favor, deixa este campo baleiro

¡No te pierdas las novedades!

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.