Histórico de mensagens sobre PSP em pix

<@!715273512688025630> complementando com mais alguns entendimentos:
- A instituição recebedora que aparecerá ao pagador é sempre Gerencianet
- Os dados do estabelecimento do recebedor que aparecerão ao pagador serão: nome fantasia (caso exista) ou razão social.

Importante: não importa o que aparece no BR Code, a informação oficial é a que está no DICT. Ou seja, o correto é que o PSP sempre busque os dados da chave via DICT, ao invés de "confiar" no BR Code. Inclusive, isso é uma questão de segurança. Se o PSP não faz isso, pode acontecer do pagador achar que o pagamento está indo pro A ao invés do B.

Como ainda tem PSP mostrando erradamente o nome no EMV 54 ao invés do DICT, eu acho importante colocar lá a marca fantasia da empresa...

Um exemplo de requisição em JS:

<@!715273512688025630> você está utilizando os endpoints de consultar as cobranças? Se sim é retornado CONCLUIDA quando a cobrança teve o seu pagamento confirmado. Outros possíveis status são: "ATIVA", "REMOVIDA_PELO_USUARIO_RECEBEDOR" e "REMOVIDA_PELO_PSP"

Boa tarde <@!811242917040488457>, no comprovante em si não tem essa informação mas você pode colocar no "infoAdicionais" que os PSPs adequados vão mostrar ao seu cliente a informação inserida. Uma forma mais segura é informar a placa como txid, como sugerido pelo Rubens, desta forma você poderia utilizar o GET /v2/pix passando o txid(que seria a placa) como parâmetro e seria retornado se foi pago ou não e os detalhes do pagamento.

Há informações que podem ser colocadas na cobrança para serem mostradas ao pagador, mas eu ainda não vi PSP incluindo essas informações no comprovante de pagamento. Nem acho que seja obrigatório, mas não vou ser taxativo.

atualizando a SAGA DO PIX de hoje, agradeço ao <@!780500321994539068> <@!671763456487325717> <@!440035527127990273> a ajuda, o apoio, a disposição. Hoje em pleno carnaval podemos escrever nos nossos diários "Fizemos Progresso". Deu tudo certo aqui com o webhook recebido após a geração do BRCode , a <@!781134406680838216> também está de parabéns 🙂 Não temos hoje nenhum PSP com esta dedicação, quem sair daqui vai atrasar o projeto em no minimo 5 anos.

Mas isso é com certeza um problema de PSP ou da sua integração.

<@!710205440956563536>, fiz um teste aqui e to recebendo a notificação normalmente. Gerei pela Gerencianet e paguei por outro psp, assim como você fez

O PSP não precisa de um certificado oficial, ele pode gerar um certificado sem problemas.

E só completando aqui a ideia do secret. Não há 2 pessoas envolvidas como você citou. Existe só 1 pessoa. A pessoa cria o secret e ela mesma cadastra o webhook no serviço do PSP. Por isso que o conceito é secret mesmo. Se entrarmos no mérito que alguém do PSP pode acessar a base de dados de cadastro de webhooks aí o negócio começa a ficar extremo, pois da mesma forma poderia ter acesso a outras informações pessoais que teriam muito mais valor que um secret de um webhook. E quem garante que a geração das chaves privadas na CA do PSP, que provavelmente não tem certificação oficial de CA, é mais segura que o acesso às informações privadas de uma base de dados de produção? Comentando aqui só para destrinchar mais o assunto... indo além do tabu.

A única informação que garantidamente voltaria é o txid. Você pode pedir para o pagador colocar informações no infoPagador, mas o pagador põe se quiser. E se o txid que é muito mais importante tem PSP que não manda, infoPagador é pior.

O mTLS faz sentindo. Ainda mais quando se tem volume de transações, se a sua comunicação com o PSP é segura, não tanta há necessidade de checagem do evento (apesar de ser um item de segurança a mais). A questão toda é que um volume alto de transações iria gerar números altos de Webhook + números altos de checagem de Pix recebido, isso poderia bater no ratelimit do PSP.

E há uma questão de timing também: o Banco Central acredita que até 15 de Março vai colocar os PSPs na linha. De repente consegue...

Por exemplo, veja um BRCode de QR-Code dinâmico abaixo: (mas que foi gerado num app em outro PSP)

00020101021226870014BR.GOV.BCB.PIX2565spi-qrcode.bancointer.com.br/spi/245025184c4545608075caebe5c8fd7052040000530398654040.015802BR5921JEFERSON P DOS SANTOS6010ENTRE RIOS62070503630490A8

É que pix e outros métodos ainda seriam do arranjo Pix. Por exemplo, o método cob para avisar que a cobrança foi removida por decisão da Gerencianet. Então eles poderiam ser num sub-domínio pix.exemplo.com.br se eu tiver apenas um PSP de Pix. Já os dos outros arranjos em outros subdomínios.

Hoje ocorreu um problema no Banco Central e alguns PSPs como o Nubank por exemplo ficaram inoperantes, então isto pode ter ocasionado falhas na sua tentativa de realizar um pix.

Pessoal, fizemos testes em vários PSP's e somente no Nubank deu "Pix fora do ar!"

Não temos concorrentes, nenhum PSP em nenhum lugar do planeta tem esta equipe de apoio e dedicação <@!781134406680838216> é sem concorrencia. 🙂

Assim como o endToEndId que o PSP gera para identificar um Pix, o rtrId é a identificação da devolução