PagBank não atualiza status dos pedidos

Há vários motivos que podem fazer seus pedidos não serem atualizados com sucesso em sua loja usando PagBank. Neste artigo veremos todas elas e como contornar o problema.

Usuários Cloudflare e bloqueios de robôs

A Cloudflare e outros provedores costumam exibir desafios captcha e outros desafios humanos a fim de validar um acesso suspeito.

Esses bloqueios e recursos de cache irão impedir que as notificações de pedidos sejam entregues com sucesso, afinal trata-se de um robô.

Se você usa Cloudflare (ou similar) em sua loja, veja o artigo Usuários Cloudflare e CDN's.

Bloqueio do Provedor ou Site fora do ar

Alguns provedores de hospedagem bloqueiam as notificações vindas do PagBank erroneamente. Para validarmos se isso está acontecendo precisamos ver no nosso painel do PagBank se as notificações ao menos foram enviadas.
Para fazer isso, basta acessar os detalhes de uma transação (pedido) no painel do PagBank e localizar o link abaixo no final da página.

Ao clicar nesse link, uma lightbox é exibida com as tentativas que o PagSeguro tentou realizar.

O código HTTP Status, quando 200 indica que a notificação foi recebida com sucesso. O código 111 também é exibido quando uma tentativa ao menos foi realizada (mas não sabemos se teve sucesso ou não, o que também é normal).

Em 90% dos casos trata-se de um bloqueio do provedor/servidor/firewall, e outros 10% são relacionados à indisponibilidade ou degradação do tempo de resposta de seu site no momento da notificação.

Rota alternativa (Proxy)

Em lojas WooCommerce, ativar o recurso de Proxy pode resolver o problema. 

Desative e siga a leitura se isso não resolver.

Mas pedidos com cartão são atualizados corretamente...

Isso ocorre porque quase todos os pedidos com cartão são aprovados imediatamente na criação do pedido, ou negados (impedindo a criação do pedido). Somente pedidos que entrarem em análise manual do PagBank é que precisarão de uma atualização posterior. 

Pedidos feitos com PIX, Boleto ou Checkout PagBank dependem de um pagamento feito após a criação do pedido, e por isso dependem do sucesso em entregar a notificação de pagamento para sua loja.

Configuração de Retorno de dados no painel do PagBank...

Você não precisa configurar o retorno automático ou URL de notificações no site do PagBank.

Este procedimento não é necessário para nenhuma de nossas integrações, pois a URL de notificação é enviada na criação do pedido de forma dinâmica.

Caches

Se seu servidor ou loja estiverem realizando cache da URL que recebe atualizações de pedidos do PagBank, nossa integração não conseguirá recebê-las.

Para ver se este é o seu caso, você pode tentar reenviar uma notificação PagBank.

Em nossas integrações toda vez que uma notificação é recebida, gravamos esta notificação em um arquivo de log.

Se ao tentar realizar um segundo envio de atualização o log não for atualizado registrando aquela notificação, é possível que haja um bloqueio, problema de cache ou algum outro erro impedindo nossa integração de processar a notificação PagBank.

Apache com mod_security ou usuários Hostgator (atualizado em Mar/2026)

Usuários hostgator têm enfrentado problemas no recebimento de notificações devido a uma regra do mod_security (módulo de segurança do apache) que visa barrar robôs de ataque, porém fazendo isso de forma muito abrangente.

Para ver se este é o seu caso, localize o arquivo de log de erros do apache (na hostgator em /usr/local/apache/error_log) e busque por erros semelhantes ao mostrado abaixo:

[Tue Feb 25 02:28:41.243188 2025] [security2:error] [pid 689089:tid 689157] [remote 54.232.144.190:41026] [client 54.232.144.190] ModSecurity: Access denied with code 406 (phase 1). Match of "ipMatch 127.0.0.1" against "REMOTE_ADDR" required. [file "/opt/mod_security/hg_rules.conf"] [line "1457"] [id "909116"] [msg "Golang default UA"] [hostname "seu.dominio.com"] [uri "/"] [unique_id "Z71VCWG-XS9UKSLJnk7AaAAAIDw"]

O mesmo erro poderá ser encontrado no arquivo de logs do apache (na hostgator: /usr/local/apache/domlogs/<seuuser>/<seudominio>-ssl>_log).

54.232.144.190 - - [25/Feb/2025:09:44:43 -0300] "POST /?wc-api=rm_ps_notif&hash=d06d9 HTTP/2.0" 406 226 "-" "Go-http-client/2.0" seu.dominio.com 162.241.62.76

Essa regra provavelmente foi configurada para bloquear solicitações que pareçam vir de scanners ou bots automatizados, especialmente aqueles escritos em Golang, como o do PagBank.

Se este for o seu caso, abra uma solicitação de suporte pedindo para removerem a regra em questão ou ignorá-la quando se tratar do url contendo "rm_ps_notif" ou "pagbank".

⭐️ Se preferir, habilite o recurso de rota alternativa (proxy).

Plugins de segurança (WordPress)

Alguns plugins de segurança como WPCerber (e outros) também podem ser responsáveis por bloquear requisições de notificação do PagBank.

A maioria dos plugins de segurança possuem formas de liberar URLs específicas a fim de evitar problemas. Procure a documentação de seus plugins de segurança e desative-os para fins de teste se desejar.

Status de Pedido não atualiza. Será? (WooCommerce)

A página detalhes de um pedido no admin do WooCommerce utiliza um dropdown para exibir o status do mesmo. No entanto, muitos navegadores cacheiam o valor selecionado.

Veja se este é o seu caso no artigo: Pedidos não são atualizados (WooCommerce). Será?.

User-agent Go-http-client/1.1 sendo barrado (.htaccess ou firewall)

O User-Agent utilizado pelos robôs de notificação do PagBank são escritos em Go. Por essa razão, o header user-agent: Go-http-client/1.1 é enviado em todas as requisições.

Pelo fato de muitos robôs de spam serem escritos nessa linguagem e utilizarem o mesmo header, muitos provedores e configurações acabam bloqueando todos esses tipos de requisições. 

Verifique se o arquivo .htaccess localizado na raiz da sua loja possui alguma menção a este bloqueio, como no exemplo abaixo.

SetEnvIfNoCase User-Agent "Go-http-client" bad_bot

Se não desejar remover totalmente o bloqueio, você pode adicionar uma regra somente para o endpoint de notificação do PagBank. Veja um exemplo abaixo.

# Permitir "Go-http-client" apenas para notificações do PagBank e PagSeguro NO MAGENTO
SetEnvIf Request_URI ^/pagbank/notification$ GoHttpSafe
SetEnvIf Request_URI ^/pseguro/notification$ GoHttpSafe

# Bloquear "Go-http-client" em qualquer outro lugar
SetEnvIfNoCase User-Agent "Go-http-client" bad_bot=!GoHttpSafe

⭐️ Se preferir, habilite o recurso de rota alternativa (proxy). Ele não utiliza este User-Agent.

Faça um teste manual

Embora o processo de reproduzir uma notificação PagBank seja um tanto técnico, criamos um passo a passo completo e até mesmo um vídeo demonstrando como realizar.

Se você realmente quiser descartar as opções acima pois acredita que se trata de um problema na integração PagBank ou mesmo que a notificação não foi enviada pra sua loja, você pode repetir a notificação manualmente.

Se tiver sucesso na atualização do pedido manualmente, reveja os casos acima.

Forçando atualizações automáticas

Embora não seja recomendado, por não resolver o problema na raiz e degradar a experiência de checkout de usuários com PIX, algumas de nossas integrações permitem que seu servidor consulte frequentemente se um pedido foi atualizado. Ou seja, ele passará a buscar de forma pró-ativa por novas atualizações de um pedido.

Este recurso está disponível nas nossas integrações PagBank para WooCommerce e Magento 2, nas configurações gerais de cada um.

Nenhum dos cenários acima

Se você de fato seguiu todos os os passos e soluções propostas acima, por favor entre em contato conosco.

Artigos relacionados

• Como reenviar uma atualização de pedido
• Usuários Cloudflare e CDN's
• Forçar atualização de pedidos no Woo
• Forçar atualização de pedidos no Magento 2