Gateway não é checkout: dois produtos, dois inimigos

Um checkout bem desenhado pode destruir um gateway. Parece exagero. As duas coisas movimentam o mesmo dinheiro, aparecem próximas no diagrama de arquitetura e, em muitas fintechs, são construídas pelo mesmo time. É justamente aí que começa a confusão.

Checkout e gateway podem participar da mesma transação, mas são produtos desenhados para usuários, momentos e problemas diferentes. No checkout, você tenta impedir que alguém desista de pagar. No gateway, você tenta impedir que alguém precise adivinhar o que aconteceu com o pagamento. Um pede redução de esforço. O outro pede aumento de explicabilidade. Misturar essas duas réguas produz dois tipos de produto ruim: o checkout que parece formulário bancário e o gateway bonito demais para ser útil.

O inimigo do checkout é a desistência

A Baymard Institute mantém uma meta-análise de 50 estudos de e-commerce e calcula uma média documentada de 70,22% de abandono de carrinho. Esse número não deve ser usado como meta para qualquer checkout, muito menos para SaaS ou pagamentos B2B. Mas mostra uma característica importante daquele momento: intenção de compra ainda pode desaparecer antes da confirmação.

Cada exigência precisa justificar sua presença: um campo adicional, uma dúvida sobre preço, um cadastro inesperado, um estado de carregamento ambíguo, um erro sem próximo passo, um método de pagamento que falha. Por isso, no checkout, grande parte do trabalho de design é reduzir a distância entre:

quero pagar

e

pagamento confirmado.

Isso não significa esconder informação. Significa evitar que o usuário processe informação que não ajuda a concluir aquela decisão.

O inimigo do gateway é a ambiguidade

Quem integra ou opera um gateway está em outro contexto. Ele não quer apenas que o pagamento funcione. Quer entender como funciona, por que falhou e como reproduzir o comportamento. No State of the API Report 2025, da Postman, documentação inconsistente aparece como o blocker de colaboração mais citado pelos respondentes, com 55%. Isso diz bastante sobre produtos de infraestrutura.

Quando uma API devolve:

payment_failed

payment_failed

payment_failed

o sistema comunicou que algo deu errado. Ainda não explicou quase nada. Foi o emissor? Antifraude? Validação? Timeout? Credencial? Saldo? Configuração? Erro interno? Pode tentar novamente? A transação chegou a ser criada?

Para quem opera infraestrutura, reduzir todas essas possibilidades a uma mensagem simples não diminui complexidade. Só esconde a complexidade no lugar errado.

No checkout, menos pode ajudar. No gateway, detalhe pode ser a interface

Essa é a diferença que mais produz decisões ruins. Um time olha para um painel cheio de informação e pensa:

precisamos simplificar.

Talvez precise. Mas simplificar não significa necessariamente remover. Imagine uma tabela de transações usada por operações financeiras. Ela contém:

• identificador;

• valor;

• método;

• adquirente;

• status;

• código de resposta;

• horário;

• número de tentativas;

• liquidação;

• taxa.

Para alguém comprando, isso seria absurdo. Para quem está tentando entender por que R$ 37 mil não conciliam, talvez seja exatamente a informação necessária.

O trabalho de UI passa a ser outro: alinhamento que permita comparar linhas, números tabulares, filtros que realmente correspondam à operação, estados excepcionais facilmente identificáveis, colunas reorganizáveis quando fizer sentido, detalhe acessível sem perder o contexto da lista. Densidade não é automaticamente sujeira. Quando a tarefa é profissional e comparativa, informação também é ferramenta.

O exemplo de código é interface

Essa é uma das coisas mais fáceis de esquecer em produto de infraestrutura. O desenvolvedor pode passar poucos minutos no dashboard e horas na documentação. Ele lê endpoint, parâmetro, payload, response, webhook, erro, exemplo. E copia.

Um exemplo de código bem construído participa da experiência tanto quanto um componente desenhado no Figma. Talvez mais. Se a documentação ensina:

const payment = await createPayment(data)

const payment = await createPayment(data)

const payment = await createPayment(data)

mas omite timeout, idempotência, retry e tratamento de erro relevantes para aquela integração, existe uma chance de o cliente implementar exatamente a versão simplificada que você mostrou. Depois essa decisão sobrevive em produção.

Um exemplo de código não é apenas documentação do produto. Em produto de infraestrutura, ele é uma interface de implementação. Isso muda o cuidado com que deveria ser desenhado.

A primeira transação bem-sucedida é um momento de ativação

Em um produto tradicional, onboarding costuma ser pensado como uma sequência dentro da interface. Num gateway, parte importante desse onboarding acontece fora do painel: criar credenciais, encontrar a documentação certa, configurar ambiente, enviar uma requisição, receber resposta, configurar webhook, simular um erro, confirmar que o estado esperado chegou. É aí que o desenvolvedor começa a confiar na infraestrutura.

Por isso, uma métrica interessante não é apenas:

criou uma conta.

Pode ser: quanto tempo e quantas tentativas foram necessárias até a primeira transação de teste concluída corretamente? E depois: quanto trabalho foi necessário para sair do sandbox e processar a primeira operação real? Esse tempo reúne documentação, API, credenciais, ambiente, mensagens de erro e suporte. O onboarding do gateway está espalhado por todos eles.

Checkout e gateway têm usuários em estados diferentes

No checkout, normalmente existe uma pessoa tentando terminar algo. Ela já escolheu um produto, plano ou compra e quer avançar. No gateway, pode existir um desenvolvedor avaliando uma integração, uma pessoa de operações investigando uma falha ou alguém do financeiro conciliando recebíveis. Isso muda a pergunta que cada interface precisa responder.

No checkout

O que preciso fazer agora?

Na documentação

Como isso funciona?

No painel operacional

O que aconteceu?

Na conciliação

Por que esses números não fecham?

Numa investigação

Qual foi a sequência de eventos desta transação?

Tentar responder todas com a mesma heurística de “interface simples” é que produz problemas. Simplicidade depende da tarefa.

O erro também precisa ser desenhado para públicos diferentes

Imagine uma tentativa de cartão recusada pelo emissor. No checkout, mostrar ao comprador um código interno como:

issuer_response: 51

issuer_response: 51

issuer_response: 51

não ajuda. A interface pode precisar traduzir aquilo para algo acionável, respeitando o nível de informação realmente disponível:

Este cartão não pôde ser autorizado. Tente outro cartão ou outro método de pagamento.

Agora imagine a mesma transação no painel do gateway. Ali, apagar completamente o retorno original pode ser um erro. Quem está investigando talvez precise de:

• código recebido;

• origem da resposta;

• timestamp;

• ID da tentativa;

• adquirente ou processador envolvido;

• histórico de retentativas;

• payloads ou logs disponíveis conforme permissão;

• sequência de mudanças de estado.

O mesmo evento precisa gerar representações diferentes. O que no checkout precisa ser traduzido, no gateway muitas vezes precisa ser preservado. Essa talvez seja a diferença mais importante entre os dois produtos.

Estado técnico e estado percebido também são coisas diferentes

Pagamentos raramente têm apenas “deu certo” ou “deu errado”. Pode existir autorizado, capturado, processando, pendente, negado, estornado, cancelado, liquidado, em disputa. A nomenclatura exata depende da infraestrutura.

No checkout, o comprador talvez não precise conhecer toda essa máquina de estados. Ele precisa saber o que aconteceu com a compra e qual ação tomar. No gateway, colapsar estados distintos pode tornar investigação e operação muito mais difíceis. Esse é um dos lugares onde “simplificar” exige cuidado. Você pode simplificar a apresentação sem destruir a distinção do domínio.

O painel do gateway é usado quando alguma coisa saiu do esperado

Essa é outra diferença importante. A integração pode acontecer num período concentrado, mas o produto de infraestrutura continua sendo usado depois. Só que muitas vezes o painel ganha importância justamente em situações excepcionais. Uma transação não liquidou. O webhook não chegou. O valor está diferente. Um cliente reclamou. A conciliação não fechou. Existe uma disputa. Alguém precisa encontrar uma operação de quatro meses atrás.

Nesses momentos, a interface não está competindo por conversão. Está competindo contra tempo operacional. Quantos sistemas precisam ser abertos para entender o caso? Quantos identificadores precisam ser copiados? É possível reconstruir a sequência de eventos? O filtro permite chegar à transação certa? A mensagem de erro preservou contexto? Aqui, alguns minutos economizados por investigação podem valer muito mais do que alguns segundos economizados numa interação cotidiana.

O problema inverso também existe

Times acostumados com infraestrutura podem levar sua lógica para o checkout. Do ponto de vista interno, talvez seja ótimo coletar tudo antes da tentativa de pagamento: CPF, CNPJ, endereço, telefone, e-mail confirmado, dados fiscais, metadados, consentimentos. Tudo pode ter alguma função no sistema. Mas isso não responde uma pergunta de produto: em que momento cada informação precisa ser pedida?

Um dado pode ser necessário para a operação e ainda estar sendo solicitado cedo demais. O comprador não deveria precisar compreender a estrutura de dados do gateway para pagar. É o mesmo erro, na direção oposta. No painel, o produto esconde complexidade que o especialista precisava enxergar. No checkout, expõe complexidade que o comprador não precisava conhecer.

Quando checkout e gateway vivem na mesma empresa

É aqui que a discussão fica mais interessante. Uma fintech pode oferecer checkout para o comprador, API para o desenvolvedor, painel para o lojista, conciliação para o financeiro e ferramentas para risco e suporte. A mesma transação atravessa todos esses produtos, mas cada usuário observa uma parte diferente dela.

Foi uma questão presente, por exemplo, em produtos como Zouti, plataforma de checkout e gateway voltada a criadores digitais, e SyncPay, ecossistema de pagamentos para negócios digitais. São produtos em que a mesma marca precisa servir experiências muito diferentes: quem paga, quem integra e quem opera.

A marca é a mesma. A infraestrutura é compartilhada. A confiança acumulada também. Mas a régua de interface não pode ser única. O comprador precisa concluir, o desenvolvedor precisa integrar, operações precisa investigar, financeiro precisa reconciliar, suporte precisa explicar. Isso deveria aparecer desde a arquitetura de informação.

Uma transação, várias representações

Talvez essa seja uma forma melhor de pensar produtos de pagamento. Não existem simplesmente “várias telas da mesma transação”. Existem várias representações da transação para trabalhos diferentes.

Para o comprador:

Pagamento confirmado.

Para o desenvolvedor:

{
  "status": "captured",
  "payment_id": "...",
  "created_at": "..."
}

{
  "status": "captured",
  "payment_id": "...",
  "created_at": "..."
}

{
  "status": "captured",
  "payment_id": "...",
  "created_at": "..."
}

Para operações, a timeline completa. Para financeiro, valor bruto, taxa, líquido e liquidação. Para suporte, estado atual e informação suficiente para orientar o cliente.

A infraestrutura pode ter uma fonte comum. A interface não precisa expor a mesma quantidade de informação para todos. Esse é um problema de Product Design, não apenas de frontend.

Como saber qual heurística aplicar

Existe uma pergunta útil: qual é o custo de o usuário parar aqui?

Se alguém está tentando pagar e interrompe o fluxo, pode existir uma venda perdida. Reduza esforço, dúvida e exigência desnecessária. Se alguém está tentando integrar e interrompe porque não entende o comportamento da API, existe uma integração atrasada. Reduza ambiguidade. Se alguém está investigando uma transação e não encontra a informação necessária, existe custo operacional. Aumente encontrabilidade e contexto. Se alguém está conciliando milhares de registros, talvez precise justamente de mais densidade e capacidade de comparação.

Não existe uma única régua de “boa UX”. Existe uma tarefa.

Os dois produtos precisam parecer simples por razões diferentes

Checkout simples é aquele em que pouco fica entre intenção e pagamento. Gateway simples é aquele em que a complexidade necessária está organizada o suficiente para ser compreendida. Um reduz decisões. O outro torna decisões técnicas possíveis. Um traduz. O outro preserva. Um tenta evitar abandono. O outro tenta evitar ambiguidade.

É por isso que gateway não é checkout. E por isso a frase “precisamos simplificar a experiência de pagamentos” não é suficiente para começar um projeto. A pergunta seguinte precisa ser: simplificar para quem, fazendo o quê? Porque a mesma mudança que ajuda o comprador pode atrapalhar o operador. E a mesma granularidade que salva uma investigação pode destruir a experiência de quem só queria pagar. Confundir os dois produtos não deixa apenas a interface pior. Deixa a operação mais cara.

Sobre o lado em que a intenção precisa virar pagamento, vale continuar por Checkout: onde o usuário desiste de pagar.

Fontes

Baymard Institute. Cart Abandonment Rate Statistics, atualizado em 22 de setembro de 2025. A meta-análise reúne 50 estudos de e-commerce e calcula uma média documentada de abandono de carrinho de 70,22%. O número é utilizado neste artigo apenas como contexto para comportamento em e-commerce, e não como benchmark esperado para qualquer checkout.

Postman. State of the API Report 2025. O relatório aponta que 93% dos times pesquisados enfrentam algum dos blockers de colaboração avaliados. Documentação inconsistente foi o item mais citado, por 55% dos respondentes, reforçando a importância de informação confiável e encontrável em produtos baseados em APIs.