Histórico de mensagens sobre documentação

quando a documentação é atualizada, o exemplo do php tbem é atualizado?

Atualizamos em nossa documentação as rotas para o /v2

<@!781134406680838216> Por gentileza, poderiam me enviar todos os retornos possíveis do webhook em json, o que estou utilizando da documentação da GN está sem o array das devoluções, não estou utilizando o postman. Montei aqui um pagador de QRCode para o modo Dev. Obrigado.

Na documentação tem o link para voce baixar e importar tudo no postman.

Conforme a documentação https://dev.gerencianet.com.br/docs/api-pix#section-criar-cobran-a- qual seria a URL correta para evitar o 404?

No retorno que você enviou o devolucoes não está como um array, nesse caso sugiro fazer a correção. Na documentação em consultar lista de cobranças tem um exemplo da resposta com o devolucoes utilizando um array.

Boa tarde <@!781928420757864468>! O atributo devolucoes é um array que contém as informações da devolução como id, valor, horario etc... Em nossa documentação ele está definido como Array e nos exemplos que contém a devolução o array está definido. Mas a sua consideração está correta. Lembrando que o array fica dentro do objeto PIX

Boa tarde <@!779294097637638164>! Temos em nossa documentação os endpoints da nossa API, veja aqui se te auxilia https://dev.gerencianet.com.br/docs/endpoints

Boa tarde Rivan! Atualmente na Gerencianet o nosso fluxo para pagamento com cartão via API segue a nossa documentação, aqui https://dev.gerencianet.com.br/docs/pagamento-com-cartao

Olá <@!293443355915059210>. Existe uma changelog da nossa documentação, acessível através do link: https://dev.gerencianet.com.br/docs/changelog
Já para o repositório da SKD PIX no GitHub, também iremos inserir o changelog para acompanharem as próximas atualizações.

Acho que você confundiu. O Matheus já falou que é case insesitive de acordo com a documentação e se o valor é minúsculo e está maiúsculo, e na documentação cita que é minúsculo e case insensitive, está errado.

O Matheus havia falado que está verificando com o BACEN a questão do txid em relação ao 62.05

MP leu o dinâmico da Iugu. Observei a presença do "010212" que indica pagamento único, que não está presente no QR da GN que eu testei e não foi lido. Do resto, ele é igual. Mas o payload em si, no caso do exemplo da GN, tem uns caracteres como "_" e "-" no campo do nome do devedor que eu não sei se são aceitos pela documentação (acho que não)

não vi eles dizendo isso. disseram que é case-insensitive pela documentação e que, mesmo assim, estão solicitando orientação do BACEN

esse seu qr tá com o campo 54 preenchido apenas com 00 (pq sua variável de preço tá zerada, provavelmente). quando for assim, é melhor passar 54040.00 (o manual brcode admitiria 54010 também, mas tem banco que não sabe ler documentação e recusa assim!) ou omitir o campo (o que também não recomendo, pois o manual do Pix não menciona a possibilidade de omissão (documenta apenas no manual do brcode) e não testei extensivamente, provável que alguns bancos recussem se omitido, também).

Na documentação do BACEN não existe uma restrição quando a ips de fora do país?

alguém poderia se valer daquele campo do brcode para algum ref-label interno, mas jamais isso poderia constar da documentação

Sugestão: me contratar pra melhorar a SDK PHP e a documentação da API Pix 😂

Voltando ao assunto do mTLS em relação ao Nginx. <@!440035527127990273> Não seria legal na documentação da GN estar igual ao do Apache por exemplo? Na documentação do Apache (vide acima), há exemplos tanto para um vHost só para o Webhook como também para um Location só para o Webhook. Assim poderia ser implementado o ssl_verify_client on; e ssl_verify_client optional; a preferir pelo usuário.

cara.. não terá mTLS nos requests enviados sem o certificado. será mTLS quando tiver o certificado. se pra vc isso é "quase mTLS", questão de interpretação sua. a documentação diz que é e o request não vai chegar onde tem que chegar pq vc barrou, ainda no Nginx. então.... não vamos chegar a lugar nenhum discutindo uma coisa que tá documentada e provada que é mTLS só pq vc acha que não é. 🙂

Talvez colocar na documentação uma versão recomendada, com ssl_verify_client mandatório e server name único, e uma para isso em path específico com optional e aí checagem só no path do webhook.