Histórico de mensagens

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.

No caso da API do Registro.br, que tem também TLS com certificados server-side e client-side, a gente já diz que precisa ser ambiente não compartilhado.

Magno, se vc tá usando hospedagem compartilhada, não vai conseguir resolver isso no chat. Só mandando ticket mesmo. E torcendo muito, pois em hospedagem compartilhada buscam não sair dos padrões. Uma reconfiguração interna qualquer lá que envolva reconstrução dos VirtualHost e sua configuração vai pro saco, aí você vai querer processar a hospedagem por lucros cessantes se a sua loja deixar de receber pagamentos... isso tem que ser configurado em um ambiente cujo responsável seja você (para a sua segurança e segurança do seu host).

Ai você fica 40 minutos no chat e eles escrevem....

Fiz isso na solução em produção pra um cliente, criei uma lista dos bancos que homologamos aqui e só depois ele gerar o qr, mesmo que ele possa pagar com os problematicos, mas mentalmente ele ja vai direcionado

É uma saida, até eles resolverem estas questões .

muda em relação ao comprimento (1-25 no estático; 26-35 no dinâmico) mas os caracteres aceitos são os mesmos (a-z, A-Z, 0-9)

Bem pontuado Rubens, a regex muda também do dinâmico para o estático

Estou pensando em criar um combobox para que o cliente selecione o banco que ele usará pra pagar o Qr Code. Se ele informar um banco que pode causar problema na conciliação, apresentarei alguma mensagem informando que a integração com o banco dele está em desenvolvimento, senão apresento o Qr Code. Não é a situação ideal, mas pelo menos dá pra começar a usar sem muitos riscos

Realizei mais testes com o banco Inter aqui hoje, e realmente ele não está se adequando aos padrões do Banco Central, inclusive o webhook não funciona com ele

Boa tarde! O dinâmico precisa do location e seu consumo se faz pela API-Pix, enquanto que o estático não tem essa necessidade e pode ser montado diretamente no QRCode. Você consegue mais detalhes aqui https://gerencianet.com.br/blog/qr-code-estatico-qr-code-dinamico-no-pix/