A tarefa
Infraestrutura de pagamento é difícil de vender em uma tela só. Quem decide é um provedor de pagamento ou uma fintech, e antes de escrever para alguém eles querem saber o que o gateway cobre, se serve para o caso deles e como começa a integração.
Então quem explica é a própria página. Dividimos o produto em blocos e cada bloco tem uma função: o que o gateway faz, para quem serve, como integrar. Não há o que fotografar em infraestrutura de pagamento, então toda imagem da página é render 3D nosso.
O que construímos
A primeira tela do site de um gateway de pagamento
A página abre com a oferta em palavras simples: pagamentos com a sua marca. Abaixo, um parágrafo diz o que é o gateway e o que ele tira das mãos do cliente.
Ao lado do título há um objeto 3D com um cartão mostrando um pagamento aprovado. Um botão leva para baixo na página, e tudo que é preciso para decidir está nela mesma, então não dá para se perder.
O que o gateway faz, bloco a bloco
O bloco seguinte lista o que a plataforma cobre: uma integração para muitos adquirentes, regras de roteamento e tokens de cartão, meios de pagamento locais, uma API REST e uma página de pagamento hospedada pelo cliente. Abaixo ficam as bandeiras dos cartões, então a cobertura aparece sem precisar de tabela.
Depois, nove cards curtos passam por adquirência, meios locais, roteamento, checagens de risco, o painel do lojista, white label, o lado do desenvolvedor, a integração inicial e onde a plataforma roda. Cada card tem duas linhas, então um provedor de pagamento percorre o produto inteiro em um minuto.
Para quem serve um gateway white-label
Quatro públicos ganham um card cada: lojistas que recebem pagamentos no exterior, negócios de alto risco que dividem o volume entre adquirentes, fintechs que colocam o pagamento dentro do próprio produto e provedores que revendem o gateway com a própria marca.
O bloco abaixo conta quem constrói e mantém a plataforma, com nomes e contatos. Em um produto assim isso pesa tanto quanto a lista de recursos, porque o comprador escolhe um fornecedor, não só um software.
Gráficos 3D próprios no lugar de banco de imagens
A página inteira roda sobre imagens que fizemos: objetos em wireframe nos destaques, cenas isométricas ao lado dos blocos de recursos e dentro dos cards de casos de uso.
Todas compartilham a mesma paleta e a mesma luz, então o site se lê como uma peça só, e não como um conjunto de imagens achadas por aí. E cada imagem da página pertence ao cliente.
Por dentro do projeto
Abaixo está o que foi medido na página no ar: com que velocidade ela abre, o que um buscador e um mensageiro leem dela e o que acontece depois que alguém envia o formulário.
Velocidade
Velocidade de abertura, medida
O Lighthouse dá à página 97 de 100 em desempenho no celular e 100 no computador.
Gráficos vetoriais com carga tardia
Das 58 imagens da página, 43 são vetoriais e ficam nítidas em qualquer tela.
Como ela se comporta no celular
Em uma tela de 390 pixels a página cabe na largura e não há rolagem lateral.
Busca e prévias
O que um buscador lê
Na parte de SEO do Lighthouse a página tira 100 de 100 no celular e no computador.
O link abre como um card
Um link do site colado em um chat abre como um card com imagem, título e descrição.
Confiabilidade
Os dois formulários barram robôs
Os dois formulários de contato ficam atrás do Cloudflare Turnstile.
Nada segue o visitante
A auditoria não encontrou na página nenhum contador, pixel de anúncio ou gerenciador de tags.
A conexão é criptografada
Um acesso por http comum é redirecionado para https, e o navegador é instruído a usar https pelos próximos dois anos.
No celular
O que saiu disso
- Um produto B2B complexo explicado em uma página
- O contato fica a dois cliques de qualquer ponto da página
- Toda imagem é render 3D nosso, sem banco de imagens
A primeira conversa agora é da página. O provedor lê o que o gateway cobre, encontra o próprio caso entre os quatro, vê quem mantém a plataforma e escreve dali mesmo. Ninguém precisa mais explicar o básico em uma call.
