Histórico de Mensagens

Pessoal, virei cliente da Efi e no geral eu amo o software de vocês, já fiz a integração de PIX no meu SaaS e ela ja está funcionado em produção. Mas hoje finalizando a integração com cartão no frontend (estou migrando da stripe) tive uma surpresa desagradável: Me deparei com o erro do print. Segue em texto:
"Falha ao conectar ao script FingerPrint. Verifique seu navegador ou extensão."

Estou tentando usar a função getPaymentToken() na qual gera essa exceção.

Eu uso o Brave, a maioria dos meus clientes usam navegadores com bloqueador de anúncio. Isso não pode ocorrer, imagina como vai ficar minha conversão? Vou perder clientes por causa do navegador?

Vocês pretendem corrigir? Se sim, tem alguma data prevista? Existe algum workaround que podemos fazer para solucionar esse problema?

Oi, @devluxca. Bom dia! Tudo bem?
Que bom saber que você está gostando da nossa solução, e que que a integração do PIX no seu SaaS já está rodando em produção!

Sobre o payment token, entendemos sua preocupação e queremos esclarecer alguns pontos.

A geração do payment_token precisa ser feita no front-end por uma questão de segurança. Isso impede que os dados do cartão do cliente trafeguem entre o front e o back, reduzindo riscos e protegendo as informações sensíveis.

Sobre o erro que você mencionou, o processo de fingerprint coleta algumas informações do navegador e do pagador para prevenir fraudes e garantir mais segurança nas transações. Normalmente, os navegadores não bloqueiam esse processo. Mas, navegadores como o Brave e extensões que impedem rastreamento podem bloquear essa coleta de dados, gerando essa exceção.

No momento, o melhor solução é orientar seus clientes a desativarem essa configuração para que tudo funcione corretamente. A gente sabe que isso pode afetar a conversão, mas já estamos estudando formas de minimizar esse impacto no futuro.

Se precisar de mais detalhes ou tiver qualquer dúvida, conte com a gente!

Uma possibilidade é uma splash page que detecta esse tipo de configuração ou componente e avisa o cliente.

Pode ser um caminho temporário, você tem algum código de exemplo para identificação? Assim posso bloquear o uso do cartão e permitir apenas o Pix.

Fala @guilherme_efi , realmente é muito frustrante isso. Eu não consigo chegar no meu Lead e pedir pra ele desativar do browser dele por exemplo… eu nem tenho contato com esse novo cliente. E não consigo pedir pra ele modificar o browser para conseguir pagar, imagina a frustração dele.

Não pq na Efí nós só transacionamos Pix. A gente seguiu uma idéia similar em outro serviço nosso que também precisava de suporte a Javascript.

Certo, de qualquer forma obrigado pela ideia, vou ver uma forma de implementar ou provavelmente vou usar outro Gateway para processamento de cartões.

O que posso te dizer da minha experiência de cliente de gateways é não se fixar em usar o mesmo para todos os métodos de pagamento. Seja pelo serviço, seja pelo custo...

... agora, esses problemas de browser x anti-fraude em cartão de crédito mudam só de intensidade e frequência, mas acontecem em todas os gateways. É intrínseco ao meio de pagamento cartão de crédito, e a solução para eles é o Pix.

Obrigado por compartilhar a sua expêriencia! Estou elaborando soluções multigateways nas próximas implementações. Esses problemas de browser eu não tive com a Stripe, meu único problema com eles é a demora para liberar os pagamentos. Eu preciso de antecipações para ter caixa. Mas enfim, obrigado mais uma vez, vou ver formas de contornar esses problemas.

Mas você usa via link de pagamento ou transparente ? Isso muda a incidência de problemas. Dependendo do gateway para pior ou para melhor, mas é diferente.

Sobre antecipações, isso é sempre um jogo de risco. Pq o adquirente só recebe em D+30... para antecipar ele na verdade está fazendo uma operação de crédito acreditando que irá receber depois. Eu não colocaria um serviço dependendo de antecipar cartão...

Usamos sempre transparente, acredito que o link de pagamento quebra o "flow" do lead. Interessante o ponto que comentou sobre antecipação, não sabia que ao antecipar o gateway estaria fazendo uma operação de crédito, mas faz sentido! Cogitamos muito o mercado pago para cartão pois eles tem recebimento de imediato por uma taxa maior, mas agora faz sentido... Único problema que tivemos com mercado pago é não ter tokenização de cartões para uso posterior. Nosso SaaS cobra o cliente após exceder os limites do plano escolhido, então essa feature é essencial para evitar inadimplências.

O problema de browsers com transparente é que o componente de tokenização dos dados de cartão pode vir de um domínio diferente da página ou enviar informações para um domínio diferente da página. Por isso que em alguns gateways o link funciona melhor.

Com cartão, o ótimo é inimigo do bom. O ideal em cada ponto pode dar um agregado que tem problemas, como você notou na prática.