Conhece de verdade as diferenças entre Stripe e Redsys e seus perigos

Quero deixar muito claro que hoje em dia Stripe e Redsys são idênticos em muitos aspectos, incluindo o poder pagar diretamente do checkout sem abandonar o site como podem provar em minha loja de exemplo mediante InSite, e embora muita gente continuamente afirme que Stripe é melhor para os pagamentos já que há maior finalização de pagamento, não é verdade. Bom, pontuemos, é verdade se se fala a partir do desconhecimento real de como funciona Redsys (realmente a PSD2) e Stripe, já que com Redsys podemos igualar a mesma baixa taxa de abandono que existe em Stripe no pagamento (que é muito reduzida) e até reduzi-la (sim, reduzi-la), só que é preciso conhecer a possibilidade e o que isso significa para o comércio. E não, não tem nada a ver com “a tecnologia superior” de Stripe, como muitas pessoas repetem constantemente como se fosse um mantra.

Mas para entender tudo isso é preciso começar do princípio. No final de 2018 começou a ser aplicada de forma progressiva a nova normativa PSD2. Em setembro de 2019 entrou em vigor e quem o solicitava podia começar a utilizá-la em seus terminais, e em 31 de dezembro de 2020 foi de cumprimento obrigatório, embora em alguns casos foram ativando ao longo de 2021 o fluxo PSD2 nos terminais por solicitações de empresas que não lhes “tinha dado tempo” para adequar seu código. Coloco entre aspas porque tiveram quase 3 anos para fazê-lo, então mais do que não terem tido tempo, foi descaso (segundo minha forma de ver). Eu estive adequando meu plugin premium de Redsys ao longo de 4 meses, sem muitas pressas, conseguindo liberar uma versão beta dando já suporte à PSD2 em setembro de 2020 para ter feedback de usuários antes que fosse obrigatório 4 meses antes de entrar em uso de forma obrigatória. De fato, nesse momento ajudei muitas empresas a adequar o código de seus sites feitos sob medida à PSD2 e assessorei várias empresas conhecidas de desenvolvimento, já que a verdade é que não é simples e era mais fácil recorrer a alguém que já tinha estado “lutando” para aplicar a nova normativa, do que começar do zero buscando informações.

Em que consiste exatamente a PSD2? É basicamente uma dupla autenticação de compra. Até a implementação da PSD2, a autenticação consistia no CVV/CVC e em alguns casos no envio de um SMS se solicitavas ao banco que o ativasse (algum banco o ativava mesmo que não o solicitasse), muita gente não sabia ou não queria ativar “por comodidade”. Após a entrada em vigor da PSD2, essa segunda autenticação, que por regra geral consiste em autorizar a operação através do aplicativo do banco, era obrigatória na Europa. Isso aumentou enormemente a segurança, mas também a complicação no pagamento para muitas pessoas, tanto que alguns ainda hoje em dia não o finalizam por não saberem como fazê-lo, ou por exemplo porque não têm o celular à mão.

E aqui começa o ponto importante, então grava isso a fogo para que tenhas muito em conta e claro. Essa segurança é bidirecional. O que quer dizer? Que dá segurança tanto ao cliente que compra em um comércio com seu cartão, como ao comércio de que quem compra é realmente o dono do cartão e está garantido pelo sistema bancário, ou seja, que quem compra tem segurança de que ao ter a dupla autenticação o comércio não vai poder utilizar seu cartão para realizar cobranças indevidas, e o comércio sabe que se lhe pagaram o pedido ele vai cobrar porque o sistema bancário lhe garantiu que a pessoa que comprou é a dona do cartão, portanto em caso de roubo de cartão (por exemplo), você vai cobrar igual se essa operação foi autenticada.

Começas a ver um pouco por onde vão os tiros? Aí está basicamente a diferença entre Stripe e Redsys. Stripe pede muitas menos autenticações (na prática quase nulas) e Redsys solicita por padrão autenticar praticamente em todas as operações. Isso é o que provoca que haja muito mais finalizações de pagamento em Stripe do que em Redsys. Mas como pode ser isso se a PSD2 obriga à autenticação? E o que acontece com todas essas operações não autenticadas em Stripe? Suponho que você tenha se feito essas duas perguntas, e se não as fez deveria tê-las feito com tudo que te expliquei até este momento.

Dentro da diretiva PSD2 existem as isenções, que são conhecidas como SCA (Strong Consumer Authentication ou autenticação reforçada dos consumidores). Há vários SCA, mas há três em particular importantes neste âmbito.  Uma é o MIT, que não se aplica neste caso já que este é exclusivo de assinaturas. Os que devemos conhecer e ter em conta são o LWV e o TRA.

O LWV é um SCA que se aplica quando o pedido é de baixo custo. Ou seja, quando o valor é menor que 30€ pode ser enviado na solicitação de cobrança e não será solicitada a autenticação. Stripe o aplica diretamente se o pedido entra dentro da faixa de preço e em Redsys é preciso solicitá-lo para que o ativem e enviar o SCA no momento da cobrança de um pedido se for o caso. Transladado para o mundo offline, é quando você paga em um comércio físico com o cartão, e pelo valor da compra não solicita o pin para pagar, obviamente isso já não se nota tanto se você paga com celular através de NFC, porque sempre solicita a impressão digital por segurança de acesso ao método de pagamento, no mínimo com o aplicativo que eu utilizo (CaixaBank).

O TAR, que é o “perigoso”, é como o LWV, mas com a diferença que é para valores muito mais altos. TRA significa (Transaction Risk Analysis). A aplicação máxima do SCA TRA costuma depender do banco no caso de Redsys, mas por regra geral são muito relutantes em ativá-lo/aceitá-lo para valores superiores a 250€. Se te ativam TRA em Redsys, você poderá solicitar que se aplique e Redsys realizará uma avaliação se o envia ou não ao emissor, mas tenha em mente que o risco será assumido por vocês (como já explicarei um pouco mais tarde). Stripe o tem ativo diretamente e com valores até 500€. O que fará Stripe é realizar uma análise de risco, e se não vê nada significativo enviará TRA ao emissor do cartão para a solicitação de pagamento com o que não será realizada a autenticação (se o emissor do cliente o aceitar). Na captura do seguinte quadro que você pode encontrar aqui, você pode ver como aplicam a análise de risco para enviar ou não TRA.

Isso anterior pode parecer muito interessante e que um pense, ¡Ah, fantástico, envio sempre TRA! É um pensamento que pode vir muito rápido à cabeça, não é? Menos solicitação de autenticações, mais conversões, mais vendas ¡Fantástico! «Agora entendo por que com Stripe não há tanto abandono no pagamento, porque muito poucos devem se autenticar».

Sim, teriam razão em que o motivo é esse, envia LWV ou TRA em quase a totalidade das transações, e isso faz com que não se solicite em praticamente nenhum caso autenticação, se o emissor/banco do cliente o aceita, porque igual o emissor/banco não aceitar o TRA por qualquer motivo e solicita autenticação. E como comentei anteriormente, você pode solicitar a Redsys que o ativem. O LWV praticamente seria imediato, e o TRA pode demorar um pouco mais. Mas cuidado, te informarão de que consequências tem que te ativem esses SCA e talvez você já não veja como uma boa ideia porque o conhecimento é poder, sobretudo de decisão.

Se aprofundarmos mais nos SCA, o ente que envia o SCA (seja o comércio ou o banco), seja LWV ou TRA, deve se responsabilizar em caso de fraude/roubo. Se aprofundarmos em PSD2/SCA, podemos ver que quem deve se responsabilizar em caso de fraude, deve ser quem envia a conformidade de TRA (nesta entrada da Adyen explicam muito bem tudo) Podemos ver que quase no final, coloca isso:

2. Transações de baixo risco – TRA (Transaction Risk Analysis)

Os bancos emissores podem considerar certas transações como de baixo risco. Para isso, se baseiam nos níveis de fraude média do emissor, do adquirente o de ambos ao mesmo tempo. Nesses casos, a isenção pode ser pedida tanto pelo comércio quanto pelo banco emissor.

A responsabilidade em caso de contracargo recairá sobre o emissor se foi este quem pediu a isenção ou sobre o comércio se foi o que a pediu.

O mais importante é o último parágrafo. Então já tens uma pista do que te vai dizer seu banco. Podem ativar LWV ou TRA no terminal para solicitar não autenticar a operação, mas se esse cartão foi roubado (por exemplo) e o banco emissor aceita o TRA, você vai ficar sem o produto (se já o enviou) e sem o dinheiro, porque vai ter que devolver. Se há autenticação, embora a pessoa tenha roubado o cartão e seu celular e tenham comprado em seu site, ninguém vai poder reclamar nada de você. Você continua com o dinheiro porque é um problema do dono do cartão e do banco emissor, já se esclarecerão entre eles quem é o culpado daquela cobrança, o banco por não anular rápido o cartão a tempo, ou o dono do cartão por não ter denunciado imediatamente o roubo. Mas com certeza você não é.

E agora você estará pensando, «Ah, pois é Stripe quem envia TRA, que se apresse!». E seria o lógico neste caso porque está enviando sem que você saiba nada, mas esta é a única parte pantanosa de tudo isso. Pois não, está enviando TRA em seu nome sem que você tenha conhecimento disso e sem conhecer as consequências que tem em pedidos de até 500€, e em caso de fraude vai passar o problema para você abrindo uma disputa, ou seja, está fazendo com que as pessoas não autentiquem sem explicar as consequências disso aos comerciantes, mas se houver algum problema, que o comércio arque com isso sem que tenha solicitado assumir esse risco. Por isso digo que é a parte pantanosa de tudo isso. Ou seja, se você tiver a desgraça de que uma máfia de roubo/clonagem de cartões passa pelo seu site e compra através de diferentes usuários e cartões produtos com um valor por exemplo de 10.000€, que não te aconteça nada com Stripe, porque terá enviado TRA, não se terão autenticado, e te passarão o problema através de disputa quando aparecerem todas as denúncias de que os cartões haviam sido roubados ou clonados e que as compras não haviam sido autenticadas. Mas não só você vai ter que devolver o dinheiro, também será aplicada uma tarifa pelo que se denomina contracargo, ou seja, que não só você vai ficar sem o dinheiro e o produto, vai ter que pagar por isso. No caso de Stripe, por disputa que perder será a dia de hoje 15€ (pense que dentro desses 10.000€ podem haver centenas de pedidos diferentes) + 20€ por cada retorno de dinheiro (o mesmo, podem ser centenas de clientes/pedidos), e não sei se há um % do valor de sanção. Mas só com os 15€ + os 20€ por transação/cliente, faça contas. Igual você paga mais com todos esses encargos, que os 10.000€ que já te haviam estafado, sem contar a perda do gênero/produtos.

Todo isso é um alegato contra Stripe? Não, só te conto o que eles não contam, para que um dia não tenhas uma surpresa muito desagradável. Agora como mínimo sabes como é o tabuleiro de jogo, e podes decidir com todos os dados em mãos.

Stripe tem coisas boas em comparação com Redsys, como a facilidade de contratação, o painel de gestão de transações, faturamento, etc. Que pode ser um valor acrescentado que vos incline ao seu uso. Mas em contrapartida Redsys tem muita segurança e tarifas muito baixas.

Nestes momentos igual você está pensando, «A mim nunca me aconteceu nada assim», até que um bom dia pode acontecer e você se encontra em uma situação semelhante à anterior. Mas agora já não poderá dizer que não se esperava ou não conhecia, mas se ainda assim está disposto a aceitar o risco de TRA e em muito menor medida LWV, em Redsys pode tê-lo igual e com comissões muito mais baixas das que aplica Stripe (e ainda mais após o aumento que realizaram), e através do meu plugin de Redsys para WooCommerce poderá solicitar LWV e TRA (se estiver disposto a assumir o risco) a Redsys (se te os ativaram no terminal) e também ter o formulário do cartão de crédito no checkout sem abandonar a web, que também se pode com Redsys como poderão comprovar em minha loja de exemplo.

Pode ser muito interessante a ativação de LWV no terminal para que todos os pagamentos menores de 30€ não se autentiquem, mas é preciso ter cuidado com TRA. Sem dúvida, o envio de TRA, que como comento você pode fazê-lo também com Redsys, aumentará quase com certeza suas vendas ao não solicitar tanto a autenticação, mas também aumentará muito a possibilidade de você ser estafado.

Já tens de verdade toda a informação de como funciona a PSD2. Acho que não vais encontrar muitas entradas tão claras como esta em relação ao funcionamento e riscos que existem com os SCA. Nesses momentos, sabendo tudo o que sabes após ler a entrada, você pode tomar de verdade uma decisão do que quer para conseguir um fim tendo em conta as consequências. Agora você pode avaliar como vai enfocar sua forma de pagamento, mais autenticações ao não utilizar nenhum tipo de SCA para viver tranquilo, aplicar LWV tendo um equilíbrio entre segurança e risco baixo ao ser de valores reduzidos, ou utilizará TRA maximizando as vendas ao reduzir as autenticações mas também maximizando riscos.

Como você pode ver, com Redsys também pode reduzir ao mínimo as autenticações e maximizar vendas por não abandono de pagamento como em Stripe graças a que solicite e te ativem os SCA LWV e TRA, mas a decisão de aceitar o risco em Redsys é sua, e em Stripe vem imposta e com o desconhecimento da maioria dos comerciantes dos riscos que estão assumindo. E o pior é que a maioria interpreta como que com Stripe se têm mais vendas porque tem melhor tecnologia.

Por favor deixe este campo em branco

¡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.