Webhook e fallback do InfinitePay no WooCommerce: como a confirmação de pagamento funciona de verdade

A confirmação de pagamento entre a InfinitePay e o WooCommerce depende de duas peças: o webhook, que avisa em tempo real, e o payment_check, que consulta o status direto na InfinitePay. O problema é que quase ninguém explica uma restrição real desse segundo endpoint, e essa restrição decide se o seu “plano B” funciona ou fica só no papel.

Como a confirmação funciona

Quando o cliente paga, a InfinitePay dispara um webhook para a loja com os dados da transação. Esse webhook é o gatilho, não a autorização. Antes de marcar qualquer pedido como pago, o plugin consulta o payment_check da própria InfinitePay para confirmar de verdade, e compara o valor pago contra o amount esperado, nunca contra paid_amount.

Esse detalhe do amount parece pequeno, mas evita um bug real: quando o lojista repassa a taxa da maquininha ao comprador, o valor cobrado no cartão fica maior que o valor do produto, e o campo paid_amount reflete essa diferença. Comparar contra o campo errado reprovaria todo pagamento no cartão com taxa repassada.

O limite que poucos fallbacks contam

Aqui está o ponto que a maioria do material sobre esse assunto não menciona. O payment_check só responde de verdade quando recebe dois dados extras, além do identificador do pedido: o transaction_nsu e o slug da transação. Sem os dois, a resposta vem vazia, mesmo que o pagamento tenha sido aprovado.

E esses dois dados só existem em dois lugares: dentro do próprio webhook, ou nos parâmetros da URL quando o cliente clica em “Continuar” depois de pagar.

Isso significa que um fallback automático que simplesmente reconsulta o payment_check de tempos em tempos não resolve o cenário mais comum de falha, que é justamente o webhook não ter chegado. Se o webhook falhou, os dois dados nunca chegaram à loja, e a reconsulta automática não tem o que perguntar. O pedido segue pendente até alguém confirmar manualmente, ainda que o plugin ofereça um botão de “verificar pagamento”.

Não é falha de implementação. É uma restrição real da API da InfinitePay. Mas conhecer o limite muda o que vale configurar em torno dele.

As camadas que realmente ajudam

Como o próprio endpoint de consulta depende de dados que só chegam por dois caminhos, a estratégia que funciona é multiplicar as chances de esses dois caminhos chegarem, em vez de confiar numa reconsulta que não tem para onde puxar informação.

No InfinitePay para WooCommerce, isso significa:

Dois endereços de webhook registrados ao mesmo tempo, um pelo caminho REST e outro pelo caminho mais antigo usado por PayPal e Stripe. Muitos firewalls, como Wordfence, Imunify360 e regras de ModSecurity, bloqueiam o primeiro com frequência, mas deixam passar o segundo por estar liberado por padrão.

Verificação no retorno do cliente, que captura os mesmos dados quando ele volta do checkout, mesmo se o webhook nunca tiver chegado.

Duas rodadas de verificação agendada depois disso, que reconsultam o pagamento assim que um dos dois caminhos acima já trouxe o identificador.

E um botão de confirmação manual dentro do próprio pedido, para a fração que sobra de tudo isso, sem precisar abrir o aplicativo da InfinitePay e cruzar dado na mão.

Nenhuma camada substitui a outra, e nenhuma promete resolver sozinha o que a própria API não permite resolver sozinha.

O que aparece no pedido

Cada pedido mostra qual camada confirmou o pagamento, a data e hora da confirmação, e um link direto para o comprovante oficial da InfinitePay, sem precisar sair do WooCommerce para conferir.

Licença que não trava o gateway

Um detalhe que vale considerar antes de escolher qualquer plugin de pagamento: o que acontece com o gateway quando a licença vence. No InfinitePay para WooCommerce, a resposta é simples: nada. O plugin continua recebendo e confirmando pagamentos normalmente, licenciado ou não. Só as atualizações e o suporte dependem da licença estar em dia.

É uma escolha deliberada. Um meio de pagamento que para de funcionar por causa de uma renovação atrasada, um erro de digitação na chave, ou uma indisponibilidade momentânea do servidor de licenças, é risco grande demais para colocar em cima do faturamento de outra pessoa.