Histórico de mensagens sobre documentação

se o CRC calculado tiver menos de 4 caracteres, força 4 caracteres adicionando zeros à esquerda (conforme documentação)

sim, está na documentação... ao consultar a resposta é:
"{"nome":"devolucao_nao_encontrada","mensagem":"Nenhuma devolução encontrada para o identificador informado"}

openssl pkcs12 -in certificado.p12 -out certificado.pem -nodes <-- Foi este que usei e que está na documentação da API da Gerencianet

No início não tinha mesmo. Mas acrescentamos o "loc" para estar em conformidade com o Banco Central, que também possui os dois "location". Você pode verificar aqui a documentação do Bacen https://bacen.github.io/pix-api/#/Cob/put_cob__txid_
Para melhor entendimento, atualizamos nossa documentação com esta informação.

Na versão anterior da documentação tinha um "location": "url", agora esta recebendo alem dele um "loc" : {"location" : "url"}, com o mesmo conteúdo, olhando o exemplo que foi feito em php por parte da consultoria, vi que esta utilizando "loc" : {"location" : "url"}.
Pergunta, vai ser desativado o "location": "url" , em futuras atualizações da api?

<@!788406836813365248> O que eu posso concordar com você é que há, de fato, algumas inconsistências entre os exemplos que a GN mostra (como o que você apontou: não existe status "EM_PROCESSAMENTO"). E haviam alguns outros, mas estamos todos no mesmo barco e, conforme apontamos pra GN, eles logo corrigem. E, de todo modo, tem a documentação oficial do BACEN para ser o seu norte. Nada que está lá pode ser diferente na implementação da GN (exceto recursos que sejam adicionais na GN, como o envio de Pix a terceiros, que ainda não está regulamentado pelo BACEN).

Os status das cobranças da API-Pix são os mesmo definidos pelo BACEN. Os status da API para boleto e cartão são diferentes e também estão definidos em nossa documentação.

Boa tarde <@!788406836813365248>, na documentação tem o fluxo de como autenticar e todos os endpoints com os seus atributos. Disponibilizamos uma collection no Postman https://documenter.getpostman.com/view/13574984/TVetcm6R e estamos trabalhando para liberar SDKs em outros linguagens também. Agradecemos a sugestão do fluxo, com certeza auxiliaria aos integradores e estamos sempre dispostos a melhorar. Estamos seguindo todas as normas do BACEN e os status também respeitam os definidos no mesmo.

Me desculpe, mais sem ler a documentação, você vai ter grandes dificuldades realmente na implementação.

Isso é api de boleto, aqui é pix. Na documentação tem tudo isso que voce perguntou.

Nessa eu estou meio dividido. Acho que toda documentação que auxilie é bem-vinda, mas em se tratando de dinheiro, não se pode dar a impressão de que a versão resumida é suficiente. As empresas brasileiras são campeãs de reclamações, e muito disso vem de questões de pagamento... então sim acho ótimo se o tipo de documentação que você pediu seja produzido, mas ela não substitui entender todo o processo do PIx e da API Pix.

Eu acho o contrário, o fato de ter um SDK e um webinar diz exatamente, e ensina como está fácil implementar o PIX em poucas horas, por que eles tem em documentos e vídeos mostrando como é feito. Ficou simples, porém não é fácil sem ler a documentação e tentar saber o que o BACEN exige, valew 🙂

<@!788406836813365248> tem a lista de status aqui na documentação do BACEN (que a GN segue):

https://bacen.github.io/pix-api/#/Cob/get_cob__txid_

Magno, eu trabalho com sistemas mais completos e não sou focado em meios de pagamento.
Uma empresa inovadora ouve esses comentários e busca melhorias. O fato de haver um Webinar e SDK em php para facilitar, já diz que não está tão fácil.
Ter uma documentação mais aderente a programadores que não estão envolvidos no processo do Pix e que possam começar a integração diretamente pelo PIX sem ter que revisar toda a DOC para achar informações (status de pagamento por exemplo), só vai beneficiar a empresa.

A documentação está ótima, lí ela 5 vezes, antes de começar a fazer alguma coisa, lí a documentação do BACEN, temos todos os endpoints para testar no postman, temos um SDK pronto para uso no github, temos um canal do discord com mais de 10 pessoas da GN prontas para ajudar, temos mais de 100 membros estudando e ajudando. Agora me diga aonde você tem isso fora daqui ? Eu busco soluções, querer tudo pronto de mão beijada em uma linguagem específica ... ai são outros 500. Nenhum outro Banco ou PSP está fazendo o que a GN faz 🙂 . Eu reconheço o esforço de todos.

lembrando que documentação normalmente não explica fluxo, mesmo. especialmente por que isso vai variar conforme o negócio

Engraçado.. ontem mesmo eu estava lendo elogios quanto à documentação da GN lá no <#boas-vindas-gn>

Então é só preencher a chave principal da conta digital, correto?
O Oauth no meio da documentação, tem que usar? Não entendi bem como entra no resto. Eu tenho que gerar um usuário antes? Não tem isso na interface web manualmente?
Já os webhooks, não encontrei exemplos de todos os status e o significado de cada um.
O Qrcode, vem no campo 'location' na resposta da criação de cobrança, correto?

Boa tarde,
parece que esta errado a parte de credentials colocado na documentação da gerencianet na aba "C#",
assim estou com dificuldade para gerar o token

Na documentação de padrões de iniciação, o exemplo de estático não contém ele, mas num documento recente do BACEN destinado aos PSPs onde esclarece como deve ser o processo de tratativa de geração e de leitura de QR Codes, consta que esse campo pode estar presente em qualquer QR (estático ou dinâmico) e, ao mesmo tempo, esclarece que a presença do valor 12 no ID raiz 01 (ou seja, o 010212) não deve impedir o pagamento do QR, apenas serve como indicativo para que o PSP pagador exiba ou não uma mensagem ao pagador referente à existência de pagamento prévio realizado pelo mesmo pagador para o mesmo QR (evitar duplicidade). Então se é o QR de uma compra e o lojista colocou o 0101212, o PSP poderia avisar "parece que você já pagou este QR recentemente (ou em X data), deseja prosseguir?" - não importa se é estático ou dinâmico. Se não constar o 010212 o PSP não deve interferir no processo de pagamento (então a ausência do campo é mais indicada para QR Codes que serão utilizados múltiplas vezes pelo mesmo pagador, como recargas de serviços ou pagamentos recorrentes de uma assinatura, etc).