Histórico de mensagens em pix

<@!727143156973436958> não serve.. me refiro ao POST feito para notificar a alteração de status.

Esta é a rota base de consumo, o v2 esta sim presente na url. Se você observar as rotas, o v2 esta presente logo após a rota base

Não sei se serve, mas a equipe do GN criou um repo inicial para o sdk do pix em php usando o curl...
https://github.com/gerencianet/gn-pix-sdk-php-exemplo/blob/master/funcoes.php

Bom dia! Tudo bem? Vocês podem me fornecer exemplo(s) do post de notificação feito com curl? Quero adicionar aos meus testes unitários.

Mais um dia de estudos, testando criações de tokens, cobranças , com a ajuda da GN e do pessoal aqui "Fizemos Progresso". Amanhã continua a mini-série "A SAGA DO PIX" capítulo teste de mTLS 🙂 Otimo dia a todos.

Me pareceu ser um escopo ainda não suportado, tanto que a documentação não cita cobv.read e cobv.write, ou sua versão em lote.

boa noite! alguém sabe se a api da gn suporta cobrança com vencimento? não vi na documentação da api

disponha. bom descanso!

Verdade, achei que você estava se referindo a rota da collection no Postman. Faremos a correção na documentação, obrigado pelo feedback

apesar de eu ter visto lá agora que a sdk php tem o /v2/

na documentação não consta o v2

Vamos encerrando por hoje pessoal, uma boa noite a todos e até amanhã

As rotas dos endpoints estão com o /v2/, caso alguma esteja funcionando sem, nos avise por favor que faremos a correção.

Equipe GN, sugiro atentar a essa resposta do Bacen quanto à obrigatoriedade da presença do fragmento /v2/ na URL das APIs homologação e produção.

https://github.com/bacen/pix-api/issues/180#issuecomment-736699662

Consegui fazer o webhook funcionar, obrigado a todos.

ok, mais se parar de funcionar, não só este sub-dominio, mais todos os dominios que não estão funcionando, e sem validar a cobrança paga via api, tambem vai correr o mesmo risco do cliente escrever isso 🙂 Já coloquei dupla validação, via webhook e via api, para minimizar exatamente este risco de não receber o postback do webhook.

por isso nenhum host sério vai atender seu pedido em ambiente compartilhado (e vc não deveria confiar, de qualquer forma)

se um cliente tiver problemas, e publica no twitter "paguei e a loja fez de conta que nem recebeu! é fraude!" já mancha sua reputação e seu faturamento cai...

mas esse subdomínio do mTLS deixar de funcionar conforme o planejado, te complica. vc gera cobranças mas não recebe os webhooks.

ok, tudo bem, mais se eles fizerem o mTLS para apenas um sub-dominio nosso, não tem por que influenciar nos outros que estão rodando.