Receber online: o que acontece entre o toque do cliente e o dinheiro ser seu

Um cliente toca em Pagar na sua página de encomendas e vê um visto verde. Por trás desse visto, quatro ou cinco coisas tiveram de correr bem, e uma delas decide se o dinheiro é mesmo seu ou se tem apenas autorização para o cobrar. A maioria das discussões com um prestador de pagamentos começa porque um restaurante assumiu que era a mesma coisa.

O gateway recolhe primeiro o consentimento, depois o dinheiro

Todas as redes de cartões dividem um pagamento em dois momentos:

1. Autorização — o banco emissor confirma que o dinheiro existe e reserva-o.
2. Captura — o comerciante diz «cobra agora», e o dinheiro move-se.

Alguns gateways juntam os dois passos por si. Outros não, e entregam-lhe uma encomenda aprovada, com fundos e inteiramente por cobrar até que a reclame. O PayPal funciona da segunda forma: um cliente que aprova na página do PayPal consentiu pagar-lhe, e nada saiu da conta dele até haver captura. A Stripe Checkout, na configuração habitual, faz ambas as coisas por si.

Isto importa por uma razão muito prática. Se o seu sistema marcar uma encomenda como paga assim que o cliente é reencaminhado de volta, mais cedo ou mais tarde servirá comida contra autorizações que nunca foram capturadas — e saberá disso ao fim do mês, pelo banco, não pelo POS.

A regra é, pois, simples e vale a pena impô-la a qualquer fornecedor: uma venda está paga quando o dinheiro se moveu, não quando o cliente voltou.

Quatro vias, e para que serve honestamente cada uma

A Fawry é a exceção útil: não aceita cartão nenhum. Emite um código, o cliente paga-o num quiosque ou numa farmácia, e a confirmação chega-lhe depois. Num mercado onde grande parte das pessoas não tem cartão, isso não é um plano B — é a estrada principal.

O dinheiro e o terminal do seu balcão continuam a ser outras duas vias, sem gateway algum. São registados no POS e conciliados com a gaveta no fecho do turno.

É a sua moeda que escolhe o gateway, não a preferência

Esta é a parte que surpreende, por isso digamo-lo claramente: um prestador liquida numa lista fixa de moedas, e se a sua não estiver lá, nenhuma configuração resolve.

A Paymob e a Fawry liquidam em libras egípcias. São a resposta certa no Cairo e irrelevantes em Madrid. A Stripe chega a quase todo o lado. O PayPal chega a boa parte do mundo mas não aceita libras egípcias de todo, nem riais, nem dirhams — por isso um restaurante egípcio com a carta em EGP não pode pôr o PayPal por trás do seu pagamento, por muito que queira.

Um bom sistema diz-lho na configuração, não na primeira encomenda falhada. A um restaurante que factura em euros não deviam sequer ser oferecidas as vias egípcias; a um que factura em libras não devia ser permitido configurar em surdina um prestador que recusará a primeira transação.

Se opera em mais do que um país, defina os preços de cada estabelecimento na sua própria moeda e deixe cada um levar o seu prestador. O que nos leva ao erro seguinte.

As chaves de uma sucursal não são as da sede

As credenciais de um prestador pertencem a uma conta de comerciante, e uma conta de comerciante liquida numa conta bancária, numa moeda.

Por isso, quando um grupo tem uma sucursal noutro país, essa sucursal não pode herdar as credenciais da sede — não por decisão de política, mas por aritmética. Essas chaves encaminhariam os seus clientes para um processador incapaz de receber o seu dinheiro.

A organização sensata: uma sucursal que factura na mesma moeda herda as definições e não precisa de configuração separada. Uma que factura noutra mantém credenciais, endereço de retorno e liquidação próprios. Pergunte a qualquer fornecedor como resolve isto antes de abrir o segundo país, não depois.

O webhook é a confirmação

Quando um cliente acaba de pagar acontecem duas coisas independentes:

• o navegador dele é reencaminhado para a sua página, e
• o prestador envia ao seu servidor uma notificação assinada com o que se passou.

Só a segunda é de confiança. Um reencaminhamento pode ser interrompido por uma ligação caída, um separador fechado, uma bateria esgotada ou um cliente que simplesmente carregou em retroceder — e em todos esses casos o dinheiro pode muito bem ter-se movido. Pior: um reencaminhamento é um URL, e um URL pode ser escrito à mão.

A notificação assinada — o webhook — é o prestador a dizer ao seu servidor, de servidor para servidor e com uma assinatura que verifica, que o pagamento se liquidou. É esse o evento que deve marcar a encomenda como paga, libertar o talão para a cozinha e aparecer na receita do dia.

Duas consequências práticas:

• O seu endereço de retorno tem de ser alcançável a partir da Internet. Um webhook é um pedido de entrada. Não funciona contra um portátil no WiFi de um café, e é por isso que um teste que passa na máquina de um programador pode falhar em produção.
• O prestador enviará o mesmo evento duas vezes. As redes perdem confirmações e qualquer prestador sério repete. Ter isto em conta é o que evita que uma encomenda fique registada como dois pagamentos.

Os reembolsos voltam pela mesma via

Um reembolso não é uma transferência de volta — é uma instrução à via original para reverter uma cobrança específica. Isso significa que só pode reembolsar pelo prestador que recebeu, e normalmente precisa da referência da captura, não da encomenda.

Daí decorrem duas coisas. Primeiro, um reembolso em dinheiro e um por gateway são operações diferentes e devem parecer diferentes nos seus relatórios, porque uma esvazia uma gaveta e a outra ajusta uma liquidação bancária. Segundo, um reembolso parcial tem de ficar ligado à cobrança que reverte, ou a sua conciliação nunca fechará.

O que faz mesmo perder a encomenda

Na prática, o pagamento online falha por razões aborrecidas, não exóticas:

• O valor está certo e a moeda não. O prestador recusa e o cliente vê um erro inexplicado.
• O URL de retorno é uma ligação de aplicação, não um endereço web. Alguns prestadores só aceitam endereços https vulgares e rejeitam o resto — a encomenda nem sequer chega a ser criada.
• Ninguém configurou o webhook. Os pagamentos correm bem, os clientes são debitados, e nada no restaurante sabe disso. É a avaria mais comum, e é silenciosa.
• As chaves de teste nunca foram trocadas pelas reais. Tudo funciona lindamente e nunca chega dinheiro.

Nenhum destes é um problema engenhoso. São problemas de lista de verificação, e é precisamente por isso que deviam estar numa — e por isso um teste de ligação que chame mesmo o prestador, em vez de se limitar a guardar as suas chaves, merece o seu lugar no ecrã de definições.

Em resumo

Ofereça as vias que os seus clientes usam mesmo, defina os preços de cada estabelecimento na moeda em que é liquidado, deixe o webhook — não o reencaminhamento — decidir quando uma encomenda está paga, e teste com chaves reais antes de dizer a alguém que a página está aberta. O resto é configuração.