Histórico de mensagens

Mas sem efetivar o cadastro do webhoook não consigo prosseguir

@placa_preta ainda aguardando o retorno da gerencianet fiz todos os passos mas ainda me retorna 400 pra o cadastro do webhoook, mas chequei os logs do server está batendo lá os Posts deles...

Conseguiu implementar o Webhook?

O Ativo se refere ao status de pagamento e não a disponibilidade

No meu caso, os qrcodes não expiraram. Gerei alguns ontem com expiração em 1 hora e hoje ainda estão como "Ativo", não deveria estar como cancelado/expirado?

Idem

Tentei mudar tb. Só consegui para o status REMOVIDA_PELO_USUARIO_RECEBEDOR

Tenho a mesma dúvida. Tentei mudar o status via revisão em desenvolvimento não rolou...não faz parte do ENUM

Boa tarde. Alguém pode me ajudar com uma dúvida? Estou fazendo testes em produção (não implementei o Webhook ainda). Gero o QRCode, pago, e a grana cai na conta certinho. Porém, o status da cobrança quando consulto fica sempre como ATIVA. Após o pagamento esse status não deveria mudar para CONCLUIDA? Ou isso só ocorre se eu tiver um Webhook configurado? Obrigado!

Sim, perdão, eu me confundi...não vejo muito sentido nisso, já que a API é por conta e cada conta pode ter várias chaves pix mas todas levam a mesma conta no final.

Enfim pra quem quiser, segue a documentação original:


string
title: Chave DICT do recebedor
maxLength: 77

Formato do campo chave

O campo chave, obrigatório, determina a chave Pix registrada no DICT que será utilizada para a cobrança. Essa chave será lida pelo aplicativo do PSP do pagador para consulta ao DICT, que retornará a informação que identificará o recebedor da cobrança.

Os tipos de chave podem ser: telefone, e-mail, cpf/cnpj ou EVP.

O formato das chaves pode ser encontrado na seção "Formatação das chaves do DICT no BR Code" do Manual de Padrões para iniciação do Pix.

A compreensão que tive foi essa, ou seja, por chave pix que tenha cadastrada no gerencianet q irá receber.

Legal, segui esse padrão informado <@!652136709982781470> o retorno agora é este:
{
"nome": "webhook_invalido",
"mensagem": "A URL informada respondeu com o código HTTP 400"
}

será que tem haver com aquela estrutura de mTLS? se sim fiquei na dúvida de como montar o arquivo fullchain

Gente, sobre o webhook. No caso só precisamos cadastrar uma url para receber os post apenas uma vez e não passar toda vez a cada transação, não é?

aguardar agora pra continuar

pedi o certificado, ticket #1618961

vou gerar um qr code em produção antes pra comparar

tbm

Um mistério para ser resolvido :), estou analisando a estrutura da geração que ela fez com a nossa.

testei aqui os mesmos dados no meu código e no dela e o calculo do crc16 deu diferente 🤔

ok, minha duvida é se é no servidor ou no código para dar o acesso 🙂