Case study / Product design
WhalletInfraestrutura de pagamentos desenhada como produto
Pix, cartão e boleto vivem em três lógicas diferentes. O Whallet existe para transformar essas três lógicas em uma superfície só: uma API que o desenvolvedor entende na primeira leitura e um painel em que a operação sabe, a qualquer momento, onde está cada centavo.
- Papel
- Product design e construção
- Natureza
- Produto proprietário
- Superfícies
- API, painel web, plugins
- Métodos
- Pix, cartão, boleto
- Estágio
- Beta público
O desafio
Receber dinheiro no Brasil não é um problema, são três
Cada meio de pagamento tem seu próprio tempo e seu próprio vocabulário. O Pix liquida em segundos. O cartão passa por uma autorização antes de virar dinheiro. O boleto pode levar dias e depende de uma ação que acontece fora do seu produto.
Para quem integra, isso significa três fluxos, três conjuntos de estados e três maneiras de descobrir que algo deu errado. Para quem opera, significa abrir várias telas para responder a uma pergunta simples: essa venda entrou?
- 01
Três tempos diferentes
Instantâneo, autorizado e aguardando. O mesmo botão de pagar produz três histórias distintas.
- 02
Duas audiências no mesmo produto
Quem integra quer previsibilidade técnica. Quem opera quer leitura imediata. As duas precisam da mesma verdade.
- 03
Erro faz parte do fluxo
Recusa, expiração e reembolso não são exceções raras. São estados que precisam de lugar no design.
A tese
Uma infraestrutura de pagamentos, desenhada como produto
A maior parte dos gateways trata a documentação como produto e o painel como consequência. Aqui a ordem foi invertida: definimos um único modelo de pagamento e derivamos dele todas as superfícies.
API, painel, webhooks e plugins não são quatro produtos. São quatro leituras do mesmo objeto.
API REST
Um recurso central, pagamentos, com verbos previsíveis. Criar uma cobrança é uma requisição, não um ritual.
Webhooks
O produto avisa o sistema do cliente quando o estado muda, em vez de exigir que ele fique perguntando.
Plugins
Shopify e WooCommerce para quem não vai escrever código, com o mesmo modelo por trás.
Dev Mode
Sandbox para reproduzir qualquer estado, inclusive os que ninguém quer ver em produção.
Assinaturas
Cobrança recorrente sobre a mesma base, sem um segundo produto correndo em paralelo.
De infraestrutura a experiência
Quatro camadas, um vocabulário
- 01
Liquidação e adquirência
Onde o dinheiro se move de verdade. Invisível para o usuário final, crítico para o produto.
- 02
API e webhooks
A camada que o desenvolvedor toca. Contrato estável, nomes explícitos, conjunto de estados fechado.
- 03
Painel web
Onde a operação entende o negócio. Volume, transações e ticket médio na primeira dobra.
- 04
Checkout do cliente final
Onde a confiança é ganha ou perdida, em poucos segundos.
A decisão de produto foi manter a mesma nomenclatura nas quatro camadas. O status que o desenvolvedor lê no JSON é o status que o operador lê no painel.
Como abordamos
Vocabulário antes de tela
- 01
Mapear os estados do dinheiro
Antes de desenhar tela, listamos todos os estados possíveis de uma cobrança e o que cada um significa para o negócio.
- 02
Fechar um vocabulário único
Um estado, um nome. Sem sinônimos circulando entre API, painel e notificação.
- 03
Desenhar as duas superfícies juntas
Painel e API foram desenhados em paralelo, para que nenhum dos dois herdasse a limitação do outro.
- 04
Sistematizar o que se repetiu
Os padrões que apareceram pela terceira vez viraram componente: pílula de status, linha de transação, cartão de métrica, bloco de código.
Arquitetura da informação
Oito destinos, nenhuma dúvida sobre onde clicar
Oito destinos. A regra que organizou a lista foi separar o que se consulta todo dia do que se configura uma vez.
- 01Visão geralComo o negócio está agora.
- 02TransaçõesO histórico completo, filtrável.
- 03PagamentosA cobrança individual e seu ciclo de vida.
- 04AssinaturasRecorrência, com estados próprios.
- 05ReembolsosDinheiro voltando, como fluxo de primeira classe.
- 06IntegraçõesPlugins e conexões de loja.
- 07DevelopersChaves, webhooks e Dev Mode.
- 08ConfiguraçõesLoja, projeto e time.
O momento do pagamento
Desenhando o momento do pagamento
É o único instante em que essa infraestrutura aparece para o cliente final. Ele precisa responder três perguntas em menos de um segundo: quanto, para quem e deu certo.
R$ 150,00
Pagamento aprovado
Decisões de design
Valor com mais destaque que a marca. Quem paga confere o número primeiro.
Estado com cor e com texto. Cor sozinha não é informação acessível.
Confirmação explícita. O usuário não deveria precisar deduzir que funcionou.
O ciclo de vida de uma cobrança
- 01Pendente
pendingA cobrança existe e espera uma ação de quem paga.
- 02Autorizado
authorizedO cartão reservou o valor, mas o dinheiro ainda não é seu.
- 03Pago
paidLiquidado. É o único estado que fecha a venda.
O painel
Um lugar para entender o que está acontecendo
Três números e uma lista. Volume total, número de transações e ticket médio respondem como vai o negócio. A lista de transações recentes responde o que aconteceu agora.
Todo o resto é secundário por definição e foi empurrado para baixo da dobra.
Visão geral
Volume total
Transações
Ticket médio
Volume de transações
Transações recentes
Hoje- Pagamento via PixPago
- Pagamento via Cartão de créditoAutorizado
- Pagamento via BoletoPendente
- Pagamento via PixReembolsado
Desenvolvedores
Desenhado para desenvolvedores, não só para usuários
Documentação não é anexo. A forma da requisição é parte do design do produto, e é a primeira tela que o desenvolvedor vê.
POST /v1/payments200 OK{
"id": "pay_123456789",
"status": "paid",
"amount": 15000,
"method": "pix",
"created_at": "..."
}payment.paid
- Evento
- payment.paid
- ID
- pay_123456789
- Status
- paid
Nomes que se leem em voz alta
O evento payment.paid não precisa de legenda para ser entendido.
Valor em centavos, inteiro
Dinheiro não admite arredondamento silencioso de ponto flutuante.
Identificador que diz o que é
O prefixo pay_ evita confundir objetos ao ler um log às três da manhã.
Sandbox com os mesmos estados
O Dev Mode reproduz produção, para que o erro apareça no ambiente certo.
De componentes a sistema
O sistema não começou como biblioteca, começou como repetição
Quando o mesmo padrão apareceu pela terceira vez, ele virou componente. O estado de uma cobrança é o exemplo mais claro: um único componente, quatro tons, e o mesmo nome que a API usa.
paidauthorizedpendingrefundedComplexidade para clareza
O que o cliente vê é o que sobrou depois do trabalho
A complexidade real
- Três meios de pagamento
- Vários estados por meio
- Uma integração por canal de venda
- Conciliação feita à mão
A superfície entregue
- Um modelo de pagamento
- Um vocabulário de estados
- Uma integração
- Um painel
A complexidade não desapareceu. Ela foi absorvida pelo produto. Esse é o trabalho.
O resultado
O que existe hoje
Produto no ar
Em beta público, com painel, API e documentação acessíveis em whallet.org.
Uma integração para três métodos
Pix, cartão de crédito e boleto sob o mesmo contrato técnico.
Preço por transação, sem mensalidade
Pix R$ 0,80. Cartão 3,5% mais R$ 0,60. Boleto R$ 2,50. A tabela é a mesma para todos.
Duas superfícies mantidas em paralelo
Quem escreve código e quem opera a loja usam o mesmo modelo, cada um na sua interface.
Uma nota sobre números: este case não publica volume, conversão ou receita. O produto está em beta, e qualquer métrica hoje diria mais sobre o tamanho da amostra do que sobre a qualidade das decisões de design.
O que aprendemos
Quatro coisas que levamos para o próximo produto
Vocabulário é arquitetura
A discussão mais longa do projeto foi sobre o nome de um estado. Foi também a que economizou mais tempo depois.
Documentação é interface
Se o desenvolvedor precisa adivinhar, o produto já falhou antes do primeiro deploy.
Erro merece o mesmo cuidado que sucesso
É no estado de falha que o usuário decide se confia no sistema.
Painel bom não mostra tudo
Mostra o que muda uma decisão. O resto é ruído com gráfico.
Construindo algo complexo?
Infraestrutura, produto técnico, fluxo com muitos estados e duas audiências. É esse o tipo de problema com que a gente trabalha.