--- title: "Receber online: o que acontece entre o toque do cliente e o dinheiro ser seu | GoSufra" description: "Um gateway não move dinheiro quando o cliente aprova — alguns só o movem na captura. O que cobrem a Stripe, o PayPal, a Paymob e a Fawry, porque é a sua moeda que escolhe o gateway, e porque o webhook é a única confirmação honesta." url: "https://gosufra.com/pt/blog/receber-online-o-que-acontece-entre/" language: "pt" source: "https://gosufra.com" --- # Receber online: o que acontece entre o toque do cliente e o dinheiro ser seu Um gateway não move dinheiro quando o cliente aprova — alguns só o movem na captura. O que cobrem a Stripe, o PayPal, a Paymob e a Fawry, porque é a sua moeda que escolhe o gateway, e porque o webhook é a única confirmação honesta. 2026-09-23 · 7 min de leitura ![Ilustração de um telemóvel a aprovar um pagamento junto a um POS que recebe a confirmação](https://gosufra.com/blog/online-payments-and-gateways.svg) ## Pontos-chave - Aprovar não é pagar. Em alguns gateways o dinheiro só se move na captura, e uma venda marcada como paga no reencaminhamento é uma venda que pode não ter. - A moeda em que define os preços decide que gateways pode usar — não a sua preferência. - O webhook é a única confirmação que um cliente não consegue falsear fechando o separador no momento certo. - Uma sucursal que factura noutra moeda não herda as chaves da sede, porque essas chaves pertencem a uma só moeda. 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 | Via | Alcance | Melhor para | | --- | --- | --- | | Stripe | A maioria dos países e moedas | A escolha por omissão para cartões fora do Egito | | PayPal | Carteira e cartão, nas moedas que liquida | Clientes que preferem não dar o cartão a um site novo | | Paymob | Egito | Cartões e carteiras locais, em libras egípcias | | Fawry | Egito | Um número de referência que o cliente paga em dinheiro em qualquer ponto | 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. - gateway de pagamento online - pagamentos online restaurante - Stripe para restaurantes - PayPal para restaurantes ## No produto ### [Ponto de venda e pedidos](https://gosufra.com/pt/funcionalidades/software-pos-restaurante/) Explorar ### [Mesas, QR e reservas](https://gosufra.com/pt/funcionalidades/software-de-gestao-de-mesas/) Explorar ## Faça tudo isto a partir de um único sistema POS, cozinha, inventário, custo de receitas, pessoal e contabilidade — ligados, e grátis para começar. [Criar a minha conta grátis](https://app.gosufra.com/register?lang=pt) ## Artigos relacionados ![Ilustração de um QR ao lado de um telemóvel a encomendar](https://gosufra.com/blog/qr-menu-and-online-ordering.svg) Marketing 2026-08-23 · 7 min de leitura ### [Cartas QR e o seu próprio canal de encomendas: sair da passadeira das comissões](https://gosufra.com/pt/blog/cartas-qr-e-o-seu-proprio-canal/) Como funciona mesmo o pedido por QR à mesa, porque expira o token, quanto vale um canal próprio face à comissão do agregador, e os erros que fazem os clientes desistir. Ler artigo ![Ilustração de uma montra num separador de navegador](https://gosufra.com/blog/your-restaurant-website.svg) Marketing 2026-08-09 · 7 min de leitura ### [O site do seu restaurante: um canal de encomendas que é mesmo seu](https://gosufra.com/pt/blog/o-site-do-seu-restaurante/) Para que serve um site de restaurante gerado a partir da carta, como difere de um QR e de uma app de marca, quando um domínio próprio vale a pena, e porque ganha a alugar os habituais a um agregador. Ler artigo ![Ilustração de uma gaveta de caixa ao lado de um valor de diferença](https://gosufra.com/blog/cash-shifts-and-reconciliation.svg) Operações 2026-08-17 · 7 min de leitura ### [Turnos de caixa e contagem de fecho: fazer a gaveta explicar-se](https://gosufra.com/pt/blog/turnos-de-caixa-e-contagem-de-fecho/) Como o fundo de maneio, as entradas, as saídas e os reembolsos produzem um valor esperado, o que uma diferença diz de facto, e porque um fecho que bate sempre certo é o que deve preocupar. Ler artigo [← Todos os artigos](https://gosufra.com/pt/blog/) [Contacte-nos](https://t.me/GoSufraSupport)