Erro no retorno de confirmação de pagamento

[objetivoup]

Olá boa tarde!

Estou com problema no retorno de confirmação de pagamento, verifiquei todas as configurações necessárias para utilizar o modulo, porem o modulo ainda não dá a confirmação de pagamento automaticamente.

Já faz uns 10 dias que isso esta ocorrendo, já uso o modulo desdo inicio do ano, somente agora esta dando este erro.

Fico no aguardo, obrigado!

[henriqueccruz]

Creio que você tenha encontrado este problema desde que atualizou seu WHMCS para a v7.8 Por favor utilize a versão mais recente do módulo (v2.0.1.3) Peço a gentileza de fechar este ticket caso o erro não se repita com a versão nova.

[objetivoup]

Olá bom dia Henrique! Tudo bem?

Infelizmente não funcionou novamente, todos os outros módulos que eu uso estão funcionando o retorno automático. Verifiquei se havia algum problema na hospedagem como o bloqueio da URL de retorno da paghiper porem não há..

Fiz um teste hoje e quando é gerado um boleto o modulo do paghiper não marca o Código da Transação na Fatura. Todos os demais módulos faz isso. Talvez seja esse o problema.

Obrigado pelo ajuda... Abraços

[ownserver]

Estou com o mesmo problema a alguns dias, estou tendo que fazer tudo manualmente. Notei que isso passou a ocorrer quando a taxa deles foi alterada (pode ser coincidência).

[henriqueccruz]

Entendo. Geração de boletos ocorre normalmente mas estão com problemas na baixa? Seria legal se vocês conseguissem nos mandar o conteúdo do "Log de portais de pagamento" pra análise. Assim descobrimos o motivo de não informar o ID nas transações da fatura.

[objetivoup]

Olá boa noite Henrique!

Olá ownserver, obrigado por se manifestar para tentarmos resolver o problema.

O problema esta na geração do boleto, não esta vinculando o número da transação na fatura, gerando o boleto manualmente ou automático nenhum vincula o número da transação.

Quando o pagamento é confirmado o paghiper envia a notificação, porem não há como vincular o pagamento, porque não há nenhuma fatura com o número da transação.

O número do pedido no whmcs é apenas uma referencia, sendo assim, precisamos saber se o modulo do paghiper esta com problema. Porque eu estou usando outros métodos e todos eles vinculam um número da transação na fatura ao serem selecionados.

LOG DO PORTAL DE PAGAMENTO

transaction_id => 7VOFBPW4IGP9N5OB notification_id => II7DQK5GP0TJOAQJZ6VP2Z7IOH6U5HZOZ61QQ67F70YWBPFBVB0YA7GYOMTU4SI4 notification_date => 2019-09-11 09:02:17 idTransacao => 7VOFBPW4IGP9N5OB dataTransacao => 2019-09-11 09:02:17 dataCredito => valorOriginal => 170.00 valorLoja => 168.15 valorTotal => 170.00 numeroParcelas => 1 tipoPagamento => Boleto codPagamento => Boleto status => Aguardando nomeCliente => Luis * emailCliente => admin@ ***** rgCliente => cpfCliente => 16755945000153 sexoCliente => cnpjCliente => razaoSocialCliente => frete => tipoFrete => vendedorEmail => financeiro@ ** idPlataforma => 4399 urlPagamento => https://www.paghiper.com/checkout/boleto/eedb1afd1f9930fc5b33f527e3d2645b63727af76eae21351da0cc9a8e5025b3db560fa6999ffc88fe7108a190f3d5b731d9c2f1c94ed13088676dc8a95b1702/7VOFBPW4IGP9N5OB/20408883 linhaDigitavel => 03399.87836 48900.000208 40888.301013 1 80180000017000 descontoBoleto => 0 notaFiscal => fraseFixa =>
codRetorno => II7DQK5GP0TJOAQJZ6VP2Z7IOH6U5HZOZ61QQ67F70YWBPFBVB0YA7GYOMTU4SI4 dataStatus => 2019-09-11 09:02:17 value_cents_paid => late_payment_fine => per_day_interest => early_payment_discounts_days => early_payment_discounts_cents => open_after_day_due => 4 apiKey => apk_43385157-BGmYqzFfEGcCViwRaGzOIWReJBfRfHjh produto_codigo_1 => 4399 produto_valor_1 => 170.00 produto_descricao_1 => Fatura #4399 produto_qtde_1 => 1.00 numItem => 1 idPostRetorno => 26511676 url => https://www.objetivoup.com.br/conta/modules/gateways/paghiper.php

transaction_id => FRYMA95NDS9X8PWJ notification_id => QSF0NURJ2Y47BUM3T9E2F2F8BCH080FZTV0HQR0SQ5020M6TWLVCNBKZN1ZW2EWV notification_date => 2019-09-11 09:01:31 idTransacao => FRYMA95NDS9X8PWJ dataTransacao => 2019-09-11 09:01:31 dataCredito => valorOriginal => 290.00 valorLoja => 288.15 valorTotal => 290.00 numeroParcelas => 1 tipoPagamento => Boleto codPagamento => Boleto status => Aguardando nomeCliente => Jesipe emailCliente => admin@ rgCliente => cpfCliente => 02335565000155 sexoCliente => cnpjCliente => razaoSocialCliente => frete => tipoFrete => vendedorEmail => financeiro@ *** idPlataforma => 4394 urlPagamento => https://www.paghiper.com/checkout/boleto/4201f66982be9bd2ac5ba9e4c9c3dbe0d8e9fa3c6ab4809a7ef3f5364b418c59e6f852bf909674d804e933b4da0d44b20362ede3b9a2356e6007846b7da21874/FRYMA95NDS9X8PWJ/42647821 linhaDigitavel => 03399.87836 48900.000422 64782.101014 1 80180000029000 descontoBoleto => 0 notaFiscal => fraseFixa =>
codRetorno => QSF0NURJ2Y47BUM3T9E2F2F8BCH080FZTV0HQR0SQ5020M6TWLVCNBKZN1ZW2EWV dataStatus => 2019-09-11 09:01:31 value_cents_paid => late_payment_fine => per_day_interest => early_payment_discounts_days => early_payment_discounts_cents => open_after_day_due => 4 apiKey => apk_43385157-BGmYqzFfEGcCViwRaGzOIWReJBfRfHjh produto_codigo_1 => 4394 produto_valor_1 => 290.00 produto_descricao_1 => Fatura #4394 produto_qtde_1 => 1.00 numItem => 1 idPostRetorno => 26511398 url => https://www.objetivoup.com.br/conta/modules/gateways/paghiper.php

[objetivoup]

ESSE É DE UMA FATURA BAIXADA COM SUCESSO, AS 2 ACIMA SÃO QUE NÃO FOI DADOS BAIXA.

result => success response_message => notification_id encontrada transaction_id => OW3AG2B7TCVFQYOX order_id => 4354 created_date => 2019-09-02 14:46:19 status => paid payer_email => chang@ ** payer_name => Chang *** payer_cpf_cnpj => 01204355000165 payer_phone => payer_street => payer_number => payer_complement => payer_district => payer_city => payer_state => payer_zip_code => status_date => 2019-09-03 05:42:51 value_cents => 5200 value_fee_cents => 185 discount_cents => 0 shipping_price_cents => 0 value_cents_paid => 5200 late_payment_fine => 0 per_day_interest => 0 early_payment_discounts_days => early_payment_discounts_cents => 0 open_after_day_due => 4 bank_slip => digitable_line => 03399.87836 48900.000166 58611.601012 7 80010000005200 url_slip => https://www.paghiper.com/checkout/boleto/825a8655531788b14b8ef0b2f7a6913c82d31f4b691d47f804d71d625428bcec5ffaaec6650f9aeb3dc9655ae5fbe6a189ac3679e8c86f8527a342b97009718b/OW3AG2B7TCVFQYOX/16586116 url_slip_pdf => https://www.paghiper.com/checkout/boleto/825a8655531788b14b8ef0b2f7a6913c82d31f4b691d47f804d71d625428bcec5ffaaec6650f9aeb3dc9655ae5fbe6a189ac3679e8c86f8527a342b97009718b/OW3AG2B7TCVFQYOX/16586116/pdf due_date => 2019-09-03 num_cart_items => 1 items => 0 => item_id => 4354 description => Fatura #4354 quantity => 1 price_cents => 5200 http_code => 201

[ownserver]

Entendo. Geração de boletos ocorre normalmente mas estão com problemas na baixa? Seria legal se vocês conseguissem nos mandar o conteúdo do "Log de portais de pagamento" pra análise. Assim descobrimos o motivo de não informar o ID nas transações da fatura.

Então, percebi também que alguns boletos não "geram/gravam" o ID...Ele é gerado corretamente no Paghiper (confirmo via e-mail) mas não é gerado/inserido no sistema.

Um exemplo no screenshot a seguir: https://i.imgur.com/QxJNX6F.png

A única ID salva dentro do whmcs é o que eu dei baixa na fatura manualmente..ele não salvou o mesmo ID na hora da geração do boleto.

Não achei o ID LG0QF1FBW3WVGJDP dentro do Gateway Log.

[objetivoup]

Olá ownserver

Sim, é isso que esta ocorrendo conosco também, talvez esteja ocorrendo com outros usuários porem não perceberam ainda. Não fiz nenhuma mudança do modulo antes de aparecer o problema e nem mudei a versão do whmcs ainda é a mesma 7.6 o servidor não também não houve alteações e estou usando todos os recursos solicitados para serem ativos para o funcionamento do modulo.

Provavelmente o erro esta no exato momento na geração do boleto x ID da transação não sendo gravado no fatura para posteriormente dar baixa na fatura ao ser pago o boleto.

Vamos ficar no aguardo do pessoal da paghiper nos ajudar nisto!

Obrigado!

[henriqueccruz]

A princípio não acreditamos que se trate de um problema com o módulo mas sempre existe a possibilidade de algum tipo de problema. Esses logs são de faturas baixadas, porém o ideal seria vermos o conteúdo completo do log.

De qualquer forma, antes mesmo de reunir itens do log, confirma por gentileza se seu usuário de acesso ao banco de dados do WHMCS tem permissões pra fazer alterações. Fizemos uma mudança no banco de dados e pode ser que esteja aí o problema.

Se for esse o caso, basta dar permissões de modificação no banco e emitir um novo boleto.

[objetivoup]

Olá boa noite Henrique! Tudo bem?

Eu verifiquei e o banco de dados esta autorizado para o usuário do banco. Tambem deletei a tabela do paghiper do banco de dados do whmcs para ser criada novamente ao instalar o modulo, sim fiz a instalação novamente e o whmcs criou uma nova tabela, nos logs dos portais de pagamento gerou um erro:

post => json => status_request => result => reject response_message => notification_id não informada ou inválida http_code => 200

Verifiquei no portal da paghiper e o erro é no ID da transação, sendo assim, não sei mais o que fazer.

Todos os outros modulos de pagamento estão gerando o ID da transação e eu acho que todos devem seguir a mesma logica de desenvolvimento, sendo assim, neta parte de processamento de pagamento ambos geram o ID.

Obrigado pela ajuda! Abraços!

[ownserver]

A princípio não acreditamos que se trate de um problema com o módulo mas sempre existe a possibilidade de algum tipo de problema. Esses logs são de faturas baixadas, porém o ideal seria vermos o conteúdo completo do log.

De qualquer forma, antes mesmo de reunir itens do log, confirma por gentileza se seu usuário de acesso ao banco de dados do WHMCS tem permissões pra fazer alterações. Fizemos uma mudança no banco de dados e pode ser que esteja aí o problema.

Se for esse o caso, basta dar permissões de modificação no banco e emitir um novo boleto.

Bom dia Henrique/Objetivoup,

Como podemos fornecer um log "completo" ?

No meu caso por exemplo ele não gera alguns logs (igual citado acima).. Agora cedo mesmo estou com 3 novos casos de não ter gerado/gravado a ID no banco de dados mas o boleto foi gerado normalmente e pago (notificado via e-mail do paghiper)

As permissões do banco de dados não foram alteradas previamente, como precaução eu criei um novo usuário com permissão full.

[henriqueccruz]

Alguma chance de vocês estarem utilizando mod_security?

[ownserver]

Alguma chance de vocês estarem utilizando mod_security?

Em minha estrutura utilizo uma solução chamada cpGuard/OpsShield que controla o mod_security. Sempre funcionou com ele ativo, mas fiz um teste agora e nada.

Criei uma nova fatura, o boleto foi gerado com sucesso mas novamente o ID da transação não foi salvo no banco.

Não sei se haveria alguma relação mas isso "começou" praticamente quando recebi um e-mail de alteração de valor de taxa..que antes era 1.78 (algo assim) para 1.98...

[henriqueccruz]

Tem acesso aos logs do cpGuard? Ou está utilizando estrutura compartilhada?

[ownserver]

Tudo que é "travado" ou vai para quarentena fica no log que mando abaixo. No meu caso, só tenho logs de bloqueios de ataques comuns de WordPress (nosso site)

Seguem screenshots: https://i.imgur.com/LMv36Zy.png | https://i.imgur.com/AiYADL3.png

Algo que não tinha feito anteriormente mas também não resolveu foi alterar o TOKEN.

[henriqueccruz]

Alterar o token não vai resolver no seu caso mesmo, cpGuard provavelmente está esvaziando os parâmetros que a notificação da PagHiper contém. Ja vimos isso acontecer antes.

Procura no seu log por notificações contendo o IP 107.23.219.74, ou pelo endpoint /modules/gateways/paghiper.php

[ownserver]

Eu havia colocado 2 Ipv4 do Paghiper na Whitelist do firewall, adicionarei esse acima para testar. Tenho os seguintes logs:

`162.158.74.37 - - [23/Oct/2019:09:23:24 -0300] "POST /central/modules/gateways/paghiper.php HTTP/1.1" 404 7864 "-" "GuzzleHttp/6.2.1 curl/7.35.0 PHP/5.5.9-1ubuntu4.19"

108.162.216.62 - - [23/Oct/2019:09:23:39 -0300] "POST /central/modules/gateways/paghiper.php HTTP/1.1" 404 7864 "-" "GuzzleHttp/6.2.1 curl/7.35.0 PHP/5.5.9-1ubuntu4.19"

162.158.74.37 - - [23/Oct/2019:09:23:39 -0300] "POST /central/modules/gateways/paghiper.php HTTP/1.1" 404 7864 "-" "GuzzleHttp/6.2.1 curl/7.35.0 PHP/5.5.9-1ubuntu4.19"`

"interessante" que ele dá erro 404 mas acessando via url direta ele gera log correto de acesso (cod 200).

Pensando ser o CloudFlare que está ativo eu desativei e fiz o teste, o erro persistiu. Coloquei o domínio na whitelist do cpGuard + os 3 IP's que tenho da Paghiper.

Gerei um novo teste e veja:

162.158.62.169 - - [23/Oct/2019:10:48:23 -0300] "GET /central/modules/gateways/paghiper.php?invoiceid=18958&uuid=833&mail=xxxxxxxxx@dominio.com.br&json=1 HTTP/1.1" 200 403 "-" "-"
162.158.74.145 - - [23/Oct/2019:10:48:39 -0300] "POST /central/modules/gateways/paghiper.php HTTP/1.1" 404 7864 "-" "GuzzleHttp/6.2.1 curl/7.35.0 PHP/5.5.9-1ubuntu4.19"

Quando dá o GET ele gera de boa...Mas na hora do POST dá erro 404.

[henriqueccruz]

Sim. Erro 404 não é gerado pelo plugin ou pelo WHMCS, tem uma interface bloqueando a requisição, seja Cloudflare, seja cpGuard. Coloca esse IP na whitelist do cpGuard e do Cloudflare. Vamos avaliar internamente maneiras de evitar esse problema.

[ownserver]

Henrique,

Primeiramente lhe agradeço o incrível suporte ao plugin e a paciência na tratativa do caso. Após esse Debug eu acionei o suporte do cpGuard a fim de que me informassem mais logs e realmente é algo neles.

Eles fizeram um update que coincidiu com a data da alteração do valor da taxa (que eu tinha citado acima como coincidência)..e as regras extras que foram inseridas nesse update não exibidas nos logs "comuns".

Ele bloqueava o User-Agent:

GuzzleHttp/6.2.1 curl/7.35.0 PHP/5.5.9-1ubuntu4.19

[Wed Oct 23 11:26:38.621375 2019] [:error] [pid 19745:tid 47675259053824] [client 107.23.219.74:39336] [client 107.23.219.74] ModSecurity: Access denied with connection close (phase 1). Pattern match "guzzlehttp" at REQUEST_HEADERS:User-Agent. [file "remote server"] [line "-1"] [id "913119"] [msg "Malware.Expert - Found User-Agent associated with scripting/generic GuzzleHttp"] [hostname "dominio.com.br"] [uri "/central/modules/gateways/paghiper.php"] [unique_id "XbBjHjSAVp0lVwALSs4gPwAAAI4"]

Eles me passaram umas alterações a serem feitas a fim de permitir esse Agent e BUMM...tudo voltou as mil maravilhas.

172.68.59.204 - - [23/Oct/2019:12:11:24 -0300] "POST /central/modules/gateways/paghiper.php HTTP/1.1" 200 - "-" "GuzzleHttp/6.2.1 curl/7.35.0 PHP/5.5.9-1ubuntu4.19"

162.158.75.20 - - [23/Oct/2019:12:11:24 -0300] "POST /central/modules/gateways/paghiper.php HTTP/1.1" 200 - "-" "GuzzleHttp/6.2.1 curl/7.35.0 PHP/5.5.9-1ubuntu4.19"

Talvez esse pode ser o problema do Objetivoup também (talvez).

Em segundo lugar peço desculpas em tomar o seu tempo em resolver algo (no meu caso) que no fim não é falha/bug no plugin que desenvolveu.

Obrigado mais uma vez.

[henriqueccruz]

Não tem problema! Estamos aqui para prestar o melhor suporte que pudermos. Estamos estudando maneiras de evitar esse problema em um futuro próximo, é importante acompanhar e entender problemas complexos como no seu caso. Agradeço pela paciência em reportar e trazer logs e reports para analisarmos. Vamos aguardar o retorno do nosso amigo @objetivoup para encerrar o ticket.

[objetivoup]

Olá boa noite Henrique! Tudo bem?

Verificamos tudo e como o ownserver resolveu o problema na hospedagem/servidor, constatou que era um tipo de bloqueio, vamos mudar de servidor para solucionar o problema.

Agradeço a sua ajuda e o empenho para resolvermos o problema.

Obrigado ownserver por contribuir conosco, ficamos felizes em saber que vocês conseguiram encontrar o problema juntamente com o Henrique.

A nossa solução é mais radical, mudar de servidor! Fizemos um teste em outro ambiente e o log funcionou, sendo assim, fazem mais de 25 dias tentando encontrar o erro, mais o erro estava no servidor.

Um grande abraço!!! Obrigado e desculpe qualquer coisa!

[objetivoup]

Vou fechar o suporte!!!!!!!!!