Vender pelo WhatsApp no Brasil tem um ponto de fuga clássico: a conversa vai bem, o cliente decide comprar — e aí alguém digita uma chave Pix, manda um print e pede para o cliente enviar o comprovante.
Funciona. Também é onde a venda esfria, onde o valor sai errado e onde ninguém sabe dizer, no fim do dia, quais pedidos foram pagos.
A Meta documenta uma Payments API específica para o Brasil, que resolve boa parte disso. Vale entender o que ela faz de fato, porque tem uma linha na documentação que muda o planejamento de quem for usá-la — e ela quase nunca aparece nos textos sobre o assunto.
Os meios de pagamento documentados
Para o Brasil, a documentação lista cinco caminhos:
- Códigos Pix dinâmicos
- Links de pagamento
- Boleto
- Pagamento com cartão em um clique, fora do aplicativo
- Template de detalhes do pedido
Ou seja: não é só Pix, e não é só cartão. Boleto está lá — o que importa bastante para quem vende para empresa e para público que ainda paga assim.
O fluxo, passo a passo
1. O cliente conversa e escolhe. Atendimento normal, humano ou com IA. Nada de especial aqui — e é justamente o ponto: o pagamento entra no meio da conversa que já estava acontecendo.
2. A empresa envia o pedido. É uma mensagem de order_details, que existe em versão completa — com os produtos item a item — e em versão simplificada, mostrando só o total. Dois detalhes importantes dessa mensagem:
- ela precisa carregar um
reference_idúnico, criado pela empresa, que acompanha o pedido do começo ao fim; - ela aceita um prazo de expiração. Passado o horário definido, o botão de pagar é desabilitado no aplicativo do cliente.
Esse segundo ponto é mais útil do que parece: resolve a promoção com validade e evita o clássico do cliente pagar, três semanas depois, um preço que não existe mais.
3. O cliente paga. No caso do Pix, a documentação descreve o comportamento com todas as letras: o cliente muda para o aplicativo do banco e usa a função Pix copia e cola. Não é um pagamento que acontece inteiro dentro do WhatsApp — é um pedido que sai de lá pronto para ser pago, e volta.
4. A empresa é notificada. Chega uma notificação de mudança de status de pagamento por webhook. Se o seu webhook estiver caindo, você não fica sabendo — e essa é mais uma razão para monitorá-lo, assunto de webhook falhou: mensagens perdidas.
5. A empresa atualiza o pedido. Com mensagens de order_status, que a documentação descreve serem enviadas “seja com base na notificação de mudança de status de pagamento do WhatsApp, seja com base nos processos internos” da empresa.
Os seis status possíveis:
| Status | O que significa |
|---|---|
pending |
pedido pendente, ainda não processado |
processing |
a empresa está atendendo o pedido |
partially_shipped |
parte dos produtos foi enviada |
shipped |
todos os produtos foram enviados |
completed |
pedido concluído, nada mais é esperado |
canceled |
a empresa quer cancelar o pedido |
Repare que os status cobrem entrega, não só pagamento. Isso torna a mensagem de pedido um trilho de acompanhamento — o cliente vê o pedido evoluir dentro da própria conversa, sem precisar de portal, e-mail ou link de rastreio.
A linha que muda o planejamento
Aqui está a parte que quase ninguém escreve, e que é a mais importante do artigo:
“WhatsApp does NOT support payment reconciliations.”
O WhatsApp não faz conciliação de pagamento. A empresa precisa conciliar com o seu provedor de pagamento (PSP), usando o reference_id do pedido.
Traduzindo para a operação: o WhatsApp é o canal por onde o pedido e o status trafegam. Ele não é o seu sistema financeiro, não garante que o dinheiro entrou e não substitui a checagem no provedor. Se um pagamento for estornado, contestado ou cair com valor divergente, isso se resolve entre você e o seu PSP — e é o reference_id que amarra as duas pontas.
Duas consequências práticas:
O reference_id não é um detalhe técnico. Ele é a chave que liga a conversa ao seu financeiro. Vale gerá-lo a partir do seu sistema de pedidos, e não inventar na hora, ou a conciliação vira trabalho manual.
Alguém precisa fechar o dia. Não existe um relatório mágico dentro do WhatsApp dizendo “hoje entraram 42 pagamentos”. Esse número está no seu provedor, e a integração é o que faz ele aparecer junto da conversa.
Sobre as taxas que circulam
Vale um aviso de precisão, porque este assunto está cheio de número específico.
A documentação técnica descreve fluxo de mensagens, não condições comerciais. Percentuais de taxa, isenções por faixa de valor e acordos com instituições financeiras que circulam em textos sobre o tema não vêm dessa documentação — vêm do provedor de pagamento de cada um, ou de lugar nenhum.
Antes de montar precificação em cima de uma taxa lida num blog, confirme com quem vai processar o seu dinheiro. É a mesma disciplina que vale para as tarifas da própria Meta, que devem ser conferidas no rate card da sua conta, como explicamos em quanto custa a API Oficial.
Onde isso muda o resultado de verdade
Três situações em que o pagamento na conversa deixa de ser conveniência e vira dinheiro:
Carrinho abandonado que volta. O cliente parou na dúvida do frete. Você responde e manda o pedido pronto, com prazo de expiração. Ele paga sem trocar de aplicativo, sem procurar link, sem digitar cartão.
Venda consultiva de ticket alto. Onde hoje existe proposta em PDF, comprovante por foto e três dias de espera, passa a existir um pedido com valor certo e status acompanhável.
Recorrência e segunda via. Boleto e link dentro do canal que o cliente já usa, em vez de e-mail que ninguém abre.
Em todos, o ganho não é o meio de pagamento — é eliminar a troca de canal na hora da decisão. É o momento em que mais se perde venda no WhatsApp.
O que precisa estar pronto antes
Uma lista curta e honesta:
- Estar na API Oficial. Nada disso existe no aplicativo comum.
- Ter um provedor de pagamento e saber como ele expõe status e estorno.
- Ter
reference_idsaindo do seu sistema, não da cabeça de quem atende. - Ter webhook monitorado, porque é por ele que o status chega.
- Ter alguém dono da conciliação. A documentação já avisou que essa parte não é do WhatsApp.
Quem trata os itens 3 e 5 como detalhe descobre o problema no primeiro fechamento de mês.
Onde a gente entra
O AtendeChat é parceiro oficial da Meta e trabalha na API Oficial, que é onde a Payments API existe. Nossa parte é a operação em volta: vários atendentes no mesmo número, fila de distribuição, histórico centralizado, funil em kanban para acompanhar o pedido do orçamento ao pago, relatórios e integração com os seus sistemas — que é exatamente o que faz o reference_id sair do lugar certo e o pedido pago aparecer no seu ERP sem alguém digitando.
Conduzimos com você a verificação de negócio, o registro do número e a aprovação dos templates.
Se hoje a sua venda termina com uma chave Pix digitada na conversa e um print de comprovante, fale com a gente: esse é o pedaço do funil onde mais se perde dinheiro sem ninguém perceber.