Histórico de mensagens sobre documentação

É uma ótima sugestão. Faremos sim um vídeo para explicar as dúvidas mais frequentes da comunidade. Vamos subir em nossa documentação os endpoints de devolução agora e depois o do webhook.

<@!671762828046106646> Disse que irá subir nova documentação pra facilitar a esse respeito

Utilizei os dados da documentação do pix pra validar se o crc16 bate e bateu direitinho.

Vou alterar a documentação para ficar mais claro

context.load_verify_locations('caminho-certificados/certificado-público-Gerencianet.crt')
context.load_cert_chain(
'caminho-certificados/privkey.pem',
'caminho-certificados/privkey.pem')
app.run(ssl_context=context, host='0.0.0.0')

público-Gerencianet.crt (baixei o que disponibilizou na documentação)
caminho-certificados/privkey.pem (utilizei o que me mandaram no chamado de produção)
caminho-certificados/privkey.pem (Não sei como conseguir)

Pode me informar qual o arquivo se refere ao fullchain na documentação

Boa sugestão! Vamos incluir para auxiliar, enquanto isso você consegue verificar em nossa documentação os tipos de respostas para cada endpoint

@Efí Na documentação do Postman vocês também poderiam salvar alguns exemplos de retorno. Seria interessante para quem ainda vai começar a consumir a API

Bom dia! Pessoal, sobre os endpoints de devolução, já está pronto e funcional. Estamos fazendo os últimos ajustes e vamos liberar na documentação os endpoints de devolução.

Estou aguardando a documentação mais explicada, porque é uma coisa que não domino tão bem

Segundo a documentação, segue essa regra \d{1,10}.\d{2}

Boa tarde, no exemplo da API está sendo utilizados traços no TXID e o campo não aceita, apenas letras e número, como é informado na regex de documentação do campo.

A utilização do mTLS é um requisito obrigatório do Banco Central e todos os PSP devem atender a ele. Você consegue chegar essa informação na própria documentação do Banco Central. Segue um trecho da mesma "O PSP deve implementar o framework OAuth 2.0 (RFC 6749)63 com TLS mútuo (mTLS – RFC
870564) para autenticação na API"

Já estão sim, o que estamos preparando aqui é um tutorial para a configuração simplificando o processo. Mas seguindo a nossa documentação você já consegue utilizar os webhooks. As chaves públicas de homologação e produção estão disponíveis aqui https://dev.gerencianet.com.br/docs#section-webhook

Pessoal quando a nossa equipe terminar de verificar essa questão da quantidade de caracteres do txid, vou atualizar aqui e em nossa documentação.

Eles não estão considerando por que o txid está no campo do ID 62 é Additional Data Field Template e ele é opcional. Ai ele fala que o objeto é primitivo , sendo objeto 62 05 primitivo, portanto este é obrigatório. Em outra documentação fala que ele é O, opcional o ID 62.

Os endpoints de GET, PUT e POST com retorno de sucesso: 200 é necessário tbm de acordo com a documentação, me parece que a gerencianet faz pra saber se está tudo certo conforme o modelo em Python na documentação...

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 documentação ficou confusa nesse ponto, vc ja conseguiu exito nessa etapa?

Acredito que sim, abre o site da GN que tem lá o exemplo... Ou veja o github do bacen com a API pix em swagger... Tem um link pra a documentação da Master logo no Readme