Histórico de mensagens sobre erro em pix

<@!671762828046106646> será que consegue salvar nesse erro ai que estou tendo com Apache, ou tenho que abrir chamado?

Agora estou com este mesmo erro, <@!727143156973436958> conseguiu algo?

não é erro da GN kkk eu só copiei e colei aqui o array de retorno do sdk, foi só pra printar mesmo, esqueci de mudar o success pra false

que "erro" mais esquisito é esse, né? diz success => true 🤣
tem que ver isso aí, GN...

os erros que recebo quando o GN tenta bater no meu webhook

aah então esse print que tirei, esse erro da toda vez que bato a primeira vez na URL, mas na segunda vez ele roda normal

quando bato na url esse é o erro que estou tendo, mas se recarrego a página exibe o código 200 normal

Entendi, estranho que quando eu removo o certificado CA ele bate na URL mas da erro de TLS mutuo, aí quando volto o certificado fala que está inacessível

Pessoal to apanhando pra configurar o webhook, já configurei o certificado CA, aí quando tento configurar o webhook eu recebo o erro: A URL informada está inacessível, porém quando eu bato na url no navegador ele me retorna o 200 que coloquei pra retornar

Sim, <@!742492546198143151>. Eu passei para o Guilherme e para o Matheus como reproduzir o erro em alguns passos.

Há um time debruçado no problema neste exato momento. É um erro pontual neste parâmetro. Webhooks não são acionados.

Quando está com status concluída sem estar pago, é um erro da GN.

Aconteceu comigo 6 vezes, mas como faço o tratamento para verificar se a soma dos pix recebidos menos a soma das possíveis devoluções bate com o valor devido, não realizei nenhuma baixa indevida. Você consegue verificar isso através de uma consulta GET /v2/cob e filtrando "inicio=data_inicial&fim=data_final&status=CONCLUIDA". Feito o filtro, faça uma varredura para verificar quais estão sem o array pix. Daí você verifica o txid dessas cobranças no seu sistema para ver se estão marcadas como pagas.
Edit: aconteceu da cobrança mudar o status, não a parte do usuário tentar pagar e dar o erro causando a mudança de status

Este é o primeiro relato similar que vejo, mas se tivesse acontecido comigo, dividiria a análise do caso em 3 partes.
- certificar se o cliente realmente não foi debitado, uma vez que pelo relato, ele não sabe o saldo anterior e, aparente, não sabe consultar o histórico de movimentações
- certificar se houve mudança de status na GN que justifique a baixa da cobrança
- certificar se o sistema está fazendo baixas apenas com base em notificações realmente pagas, pois nem toda cobrança com status "CONCLUIDA" está de fato paga

Minha impressão é que pode ter ocorrido o seguinte (HIPÓTESE):
Algumas cobranças passam para o status "CONCLUIDA" em determinadas situações, principalmente quando consumimos a rota PUT /v2/cob. Não era pra acontecer, mas acontece. Daí, pode ser que quando o cliente leu o location, a cobrança pode ter mudado de status para "CONCLUIDA". Então, quando ele tentou pagar deu erro, pois a cobrança não estava mais "ATIVA". Uma notificação de mudança de status ocorreu ao alterar para "CONCLUIDA" e o sistema processou a baixa sem verificar se o array de pix estava devidamente preenchido

Pessoal, será que tem um erro na DOC? Primeiro fala que é obrigatório, depois fala que não é obrigatório

Homologação ? Veja se não é o problema do erro HTTP 403 que vive dando lá...

deu erro ao ler o qr code

deu erro ao ler o qr code ou trouxe zerado?

Deu erro direto

no Itaú apareceu 1,00
experimenta adicionar o campo 54 informando o valor no seu brcode, pois alguns PSPs erroneamente carregam o valor apenas a partir do brcode