Anatomia de um checkout que converte

O checkout é a única página do seu site em que todo visitante já decidiu pagar. Ele não precisa convencer ninguém. O trabalho dele é não atrapalhar: responder às dúvidas antes que apareçam, receber o pagamento e dizer com clareza o que aconteceu.

Você não vai encontrar números de conversão aqui: não medimos nenhum em que confiaríamos. O que segue é raciocínio, junto com as decisões que tomamos ao construir o checkout hospedado da KrokoPay. Use como uma lista para discutir, não como verdade pronta.

As três primeiras perguntas de quem vai pagar são quanto, pelo quê e para quem. Responda no topo: o nome de quem vende, uma linha descrevendo o item e o valor, escrito do jeito que o comprador lê. Quem está no Brasil espera R$ 1.234,50; um leitor em inglês está acostumado com R$1,234.50. A moeda é a mesma; muda só a forma de escrever.

E depois não mexa nesse total. Se o botão e o cabeçalho discordam, o comprador para para entender o porquê. Quando algo muda o total por um bom motivo, explique ao lado do valor, não numa nota de rodapé.

No nosso checkout, o resumo do pedido mostra o vendedor, o item e o total, e o botão repete o mesmo valor: Pagar R$ 189,00, e não só Pagar. Em telas estreitas, os detalhes do pedido se recolhem atrás de um botão, mas o item e o total continuam à vista.

Cada campo é uma pergunta, e cada pergunta é uma chance de hesitar. Antes de incluir um, anote quem vai ler a resposta e quando. Se ninguém souber, o campo sai.

Os campos que sobram devem trabalhar a favor de quem preenche. Abra o teclado certo (inputmode="numeric" para os dígitos do cartão), use as dicas de preenchimento automático (autocomplete="cc-number", "email") e formate enquanto a pessoa digita. Descubra a bandeira em vez de perguntar e confira o dígito verificador antes de enviar: assim um erro de digitação é pego na própria página, em vez de voltar como recusa.

Pix e cartão não são versões da mesma coisa. No Pix, o comprador sai para o app do banco, confirma e volta; no cartão, preenche um formulário e tem a resposta na hora. Abas idênticas escondem o que a pessoa precisa saber: o que acontece depois do clique.

• Pix: "Pague com o QR Code ou com o Pix Copia e Cola no app do seu banco." A página mostra o código, a contagem regressiva até ele expirar e um estado de espera que se atualiza sozinho.
• Cartão: "Pague com cartão de crédito." O formulário aparece ali mesmo, e a resposta sai na mesma página.

Uma linha embaixo de cada opção basta. Se você aceita um método só, não mostre escolha: quando um link de pagamento é configurado assim, o nosso checkout já exibe direto o único método. Pergunta com uma resposta possível é ruído.

"Falha no pagamento" talvez seja a frase mais cara da página. Ela deixa a dúvida no ar: fui cobrado ou não? Quase toda recusa traz um motivo, e quase todo motivo tem um próximo passo óbvio. Diga os dois, sem culpar ninguém e sem vazar mensagem de erro interna.

Toda tela de recusa do nosso checkout também diz, numa linha própria, que nada foi cobrado, respondendo à pergunta que o comprador está nervoso demais para fazer. Do seu lado, a tentativa chega como um evento charge.failed com o mesmo failure_code, e o suporte vê exatamente o que o comprador viu.

Checkout é uma máquina de estados que o comprador enxerga. O caminho feliz está no protótipo; o resto ganha uma caixa de erro genérica. Liste todos e dê a cada um a sua frase e a sua saída.

• Aguardando pagamento: o código Pix, a contagem regressiva e o aviso de que a página se atualiza sozinha.
• Processando: o botão mantém a largura, mostra um indicador e não pode ser apertado duas vezes.
• Pago: comprovante com valor, método, data e um identificador que o comprador possa informar ao suporte.
• Expirado: o código Pix venceu, nenhum pagamento foi feito, e um botão gera um código novo para o mesmo pedido.
• Recusado: o motivo, "nada foi cobrado" e o próximo passo.
• Indisponível: o vendedor desativou o link. Diga isso e mostre como falar com ele.

Os que todo mundo esquece são expirado e indisponível: um link mandado meses atrás num grupo vai ser aberto muito depois de você desativá-lo, e merece uma frase clara, não um 404. E quando alguém reabre um link que já pagou, mostre o comprovante, não um segundo formulário. Pagar duas vezes sem querer é o pior resultado que um checkout pode produzir.

Muita gente vai abrir o seu checkout no mesmo celular com que vai pagar. É difícil escanear um QR Code com o aparelho que o exibe, então o Copia e Cola precisa do mesmo destaque, com um botão de copiar do tamanho do polegar e uma alternativa para quando a cópia é bloqueada.

• Áreas de toque de no mínimo 44px, bem espaçadas.
• Nada de rolagem horizontal em 360px, e rótulos que quebram linha em vez de serem cortados.
• Campos com fonte de 16px ou mais, para o navegador do celular não dar zoom ao focar.

O comprador confia no que consegue conferir, não em fileiras de cadeados: de quem é o nome na página, o que está pagando e quem recebe o dinheiro. O nosso checkout mostra a marca e a razão social do vendedor, e pede a quem paga com Pix que confira se o recebedor no app do banco é o mesmo.

Um checkout ganha confiança sendo previsível: o mesmo valor em todas as telas, nenhuma surpresa e uma resposta clara no final.

Não exiba selos de certificações que você não tem, nem invente urgência. Contagem regressiva faz sentido num código Pix, que expira de verdade; numa página de produto, é pressão.

1. Em cinco segundos, o comprador sabe quem vende, o que está comprando e quanto vai pagar?
2. O valor no botão é igual ao valor no resumo?
3. Cada método de pagamento diz, numa linha, o que acontece em seguida?
4. Toda recusa traz um motivo, um próximo passo e "nada foi cobrado"?
5. Links expirados, indisponíveis e já pagos têm cada um a sua tela?
6. A página funciona em 360px, com rótulos longos, usando só o polegar?

Você pode passar por tudo isso na demonstração do checkout ou ver como a página hospedada entra na sua integração na documentação do checkout. No servidor, combine com chaves de idempotência e um consumidor de webhooks que aguente duplicatas, assunto do artigo Webhooks sem surpresas.