Pix como meio de pagamento de API

Quem vende API no Brasil esbarra numa diferença que quem copia modelo de fora não espera: aqui, uma parte relevante do público não quer — ou não pode — pagar com cartão de crédito.

Pix mudou isso. Mas ele não é "cartão sem a maquininha": tem propriedades diferentes, e elas mudam como você desenha a cobrança.

O que muda em relação ao cartão

A confirmação é quase imediata e definitiva. Não existe a janela de captura, e não existe chargeback. Isso elimina de uma vez a categoria de fraude que mais preocupa quem vende digital: a compra com cartão de terceiro que é contestada semanas depois, quando o serviço já foi entregue.

O custo por transação é menor, o que muda a viabilidade de valores baixos.

Não existe recorrência nativa. É aqui que a maioria dos projetos tropeça. Pix é pagamento avulso: alguém precisa mandar. Não dá para debitar todo mês sozinho como no cartão.

Por que saldo, e não cobrança por uso direta

A ausência de recorrência empurra para uma decisão de arquitetura, e ela acaba sendo melhor por outros motivos.

Se cada pedido gerasse uma cobrança Pix, o cliente teria que abrir o aplicativo do banco, copiar código e confirmar — para cada compra. Numa API isso é inviável: o processo automatizado não tem como fazer isso.

A saída é saldo. O cliente adiciona um valor por Pix e cada pedido debita dali. O pagamento manual acontece uma vez a cada tanto, e o uso corre sozinho.

Isso resolve o problema técnico e traz efeitos colaterais bons:

• A cobrança é instantânea e sempre funciona. Não existe cartão recusado no meio de um processo automatizado.
• O gasto tem teto natural. O cliente não descobre no fim do mês que consumiu mais do que queria.
• A conciliação é simples. Entrada de saldo e débito por pedido, com histórico completo.

E traz um custo: saldo zerado interrompe o serviço. Se o cliente não percebe, o processo dele para. Quem opera precisa avisar antes, não depois.

O detalhe que gera reclamação

Pix confirma em segundos, mas nem sempre. Em fila de compensação ou instabilidade do banco, pode demorar minutos.

O erro comum é a tela dizer "aguardando pagamento" sem prazo e sem explicação. O cliente pagou, o extrato dele mostra a saída, e a sua tela diz que não recebeu. Em dois minutos ele está escrevendo para o suporte.

O que evita quase todo esse atrito:

• diga que a confirmação costuma levar segundos, mas pode demorar;
• atualize a tela sozinho, sem pedir que ele recarregue;
• avise por notificação quando o saldo entrar, para ele não ficar olhando;
• deixe claro que o valor não se perde se ele fechar a página.

Do lado de quem integra

Alguns pontos que economizam retrabalho:

O aviso do gateway é a fonte da verdade, não a tela do cliente. É o webhook do provedor de pagamento que confirma, e ele pode chegar antes de a pessoa voltar para o site.

Trate repetição. O mesmo aviso pode chegar duas vezes. Se o seu código credita a cada aviso, ele credita em dobro. Guarde o identificador da cobrança e ignore o que já processou.

Valide o valor recebido, não só o identificador. Pix permite pagar valor diferente do cobrado em alguns arranjos.

Cobrança tem validade. Código Pix expirado precisa dizer que expirou, com um botão para gerar outro — não um erro genérico.

Estorno é fluxo, não exceção

Como não há chargeback, o estorno passa por você. E ele vai acontecer: pedido que não recebeu SMS, cobrança em duplicidade, cliente que desistiu.

Decida antes o que devolve para o saldo e o que devolve para a conta bancária. Devolver para o saldo é instantâneo e resolve quase todo caso operacional — como um pedido que não recebeu o código. Devolver dinheiro para a conta é mais lento e deve existir para quem quer sair.

O que não pode é a política ser inventada no momento da reclamação. Escreva antes, publique, e siga.

Onde ver isso funcionando

Na AltiviaCloud o saldo entra por Pix e cada pedido debita dali, sem mensalidade e sem cartão. O modelo está descrito na página de preços, e o comportamento de estorno de pedido que não recebe SMS está na documentação de pedidos.