Histórico de mensagens em pix

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 🙂

sim, acho que o código que fiz em php tá certinho

<@!652136709982781470> temos alguma luz de como usar o mTLS então no nosso servidor, eu ainda não entendi muito sobre ele, pois é a primeira vez que estou precisando ter no servidor e não tenho idéia se é com o provedor ou se é comigo via código curl a habilitação 😦

Estou desmontando a estrutura para entender a geração 🙂 Pelo que ví agora o Payload é a url do location pura mesmo.

precisa de toda forma

Webhook
Reúne endpoints para gerenciamento de notificações por parte do PSP recebedor ao usuário recebedor.

Devido a uma norma do Banco Central, será necessário a inserção de uma chave pública da Gerencianet em seu servidor para que a comunicação obedeça o padrão mTLS. Em seu domínio que representa o seu servidor, deverá ser feita uma configuração para exigir a chave pública (mTLS) que estamos disponibilizando para que ocorra a autenticação mútua.

ah que ótimo 😀 vou dar uma olhada lá

Com isso está resolvido <@!709030803291635736> a necessidade de ter o mTLS, pois eles conseguem ler os dados do location certinho, esse Sady é um Ninja 🙂 Atirou no que viu e acertou o que não viu, kkkkkkkkk