Seu gateway de pagamento confia só no webhook? Isso é mais arriscado do que parece.

Um gateway que confirma pagamento só por webhook falha sempre que um firewall (Wordfence, Imunify360, ModSecurity) bloqueia a chamada, deixando pedidos pagos presos em “aguardando pagamento”. Um fallback real precisa de dois caminhos de webhook, verificação no retorno do cliente e confirmação manual como último recurso.

Webhook é uma maravilha quando funciona. O cliente paga, a InfinitePay avisa seu site em segundos, o pedido muda de status sozinho, ninguém precisa fazer nada. O problema é o dia em que ele não chega. E se o seu gateway depende só disso, esse dia vira um pedido pago que nunca sai de “aguardando pagamento”.

Por que o webhook falha, mesmo quando tudo parece certo

Webhook é uma requisição chegando de fora para dentro do seu site, e é exatamente esse tipo de requisição que firewalls de aplicação adoram bloquear. Wordfence, Imunify360, regras de ModSecurity: qualquer um deles pode decidir que uma chamada POST batendo em /wp-json/ parece suspeita e simplesmente descartar antes de chegar no seu plugin.

Do lado da InfinitePay, a requisição foi enviada. Do lado do seu site, ela nunca chegou. E não existe aviso nenhum no meio do caminho.

O que acontece quando isso acontece

Se o gateway só sabe confirmar pagamento por webhook, o pedido fica pendente para sempre, mesmo com o dinheiro já na sua conta. Ninguém vê alerta, ninguém recebe e-mail de erro. Você só descobre quando o cliente reclama que pagou e o produto não liberou, ou quando resolve conferir manualmente o extrato contra os pedidos abertos.

Multiplique isso por um volume razoável de vendas e vira rotina de conferência manual toda semana, que é exatamente o trabalho que um gateway automático deveria eliminar.

O que um fallback de verdade precisa (e o que ele não resolve sozinho)

A resposta óbvia é “então tenha um plano B”. Mas vale entender os limites de qualquer plano B antes de confiar cegamente nele.

A InfinitePay só permite consultar se um pagamento foi confirmado usando dois dados extras além do número do pedido, e esses dois dados só chegam por dois caminhos: o próprio webhook, ou o retorno do cliente quando ele clica em “Continuar” depois de pagar. Ou seja, um poller ou uma verificação agendada não descobre pagamento sozinha do nada. Ela repete uma consulta usando dados que alguém já trouxe antes.

Isso muda o que “ter fallback” realmente significa. Não adianta só agendar uma tarefa que roda de hora em hora se ela depende de informação que talvez nunca tenha chegado.

O que de fato reduz o problema:

Um segundo caminho para o próprio webhook chegar, não só um segundo lugar para verificar depois. Muitos firewalls bloqueiam /wp-json/ com frequência, mas deixam passar o caminho mais antigo usado por PayPal e Stripe, porque ele costuma estar liberado por padrão. Ter os dois caminhos registrados ao mesmo tempo, e não escolher um só, aumenta a chance real de o aviso chegar.

A verificação no retorno do cliente ajuda bastante, mas cobre só quem efetivamente clica em “Continuar” na tela final. Cliente que fecha a aba sem clicar não deixa esse rastro.

Verificações agendadas em intervalos crescentes, poucos minutos, depois mais, depois ainda mais, pegam os casos em que um dos dois caminhos acima já trouxe o dado, e só falta confirmar.

E, no fim da fila, sempre vai sobrar uma fração de pedidos que nenhuma automação resolve. Para esses, o que salva é ter um jeito rápido de confirmar manualmente dentro do próprio pedido, sem precisar abrir o app da InfinitePay e cruzar informação na mão.

O que perguntar antes de confiar num gateway

Se você está avaliando um plugin de pagamento, ou querendo saber se o que já usa está bem resolvido, três perguntas separam o que é robusto do que só parece:

O que acontece se o webhook for bloqueado por um firewall? Se a resposta é “não deveria acontecer”, desconfie: acontece, e com frequência maior do que parece.

Existe algum jeito de o pedido se confirmar sozinho mesmo sem o webhook? Se a resposta depende só do cliente clicar em algo, metade dos casos fica de fora.

Quando tudo falha, dá para resolver em um clique dentro do próprio pedido, ou é preciso abrir outro sistema e cruzar dados na mão?

Como resolvemos isso no Plugin InfinitePay para WooCommerce

O plugin registra dois caminhos de webhook ao mesmo tempo, exatamente para não depender de qual deles um firewall específico decide bloquear. Some a isso a verificação no retorno do cliente, duas rodadas de verificação agendada, e um botão de confirmação manual direto na tela do pedido, para os casos raros que sobram de tudo isso.

Nenhuma camada substitui a outra. Cada uma cobre o ponto cego que a anterior deixa passar.