Termos mais procurados:
aí, tem duas saídas:
1. confiar que o PSP vai acatar sempre apenas 1 Pix por cobrança e que virá só 1 elemento nos webhooks e consultas e tratar apenas a posição zero do array, sempre. consequência possível: o PSP acatar um segundo Pix pra mesma cobrança e vc terá que se matar pra debugar esses casos no futuro...
2. ler o array todo, tratar o elemento da posição zero e, se houver qualquer elemento adicional, acionar um alerta / marcar uma flag de problema / etc...
Isso impediria como a gente poderia contornar o /pix. Pois o PSP enviaria https://example.com/pix?Client_Id=ASDASDA
E se cadastrássemos como https://example.com/webhook.php?varinutil=/pix?Client_Id=ASDASDA
então vc leu errado... rsrs
a documentação diz que vc cadastra https://URLX e o PSP deve enviar pra https://URLX/pix (adicionar o /pix ao fim da URL que vc cadastrou). Se vc cadastrar com /pix ao fim, o request iria para /pix/pix
O que diz a do BACEN é que vc coloca webhookUrl e o PSP adiciona o /pix nela.
Boa tarde, @Deleted User.
Conforme o Rubens havia mencionado, o txid é gerado pelo recebedor, e o endToEndId é gerado pelo PSP pagador que identifica o pix pago.
O motivo do txid não apresentar nesta consulta, pelo fato do horário/data serem distantes, um do dia 14/12 e outro do dia 19/12, imagina que na geração do QrCode de um foi informado o txid, e do outro não.
Sugiro realizar alguns testes. Se persistir, nos informe que iremos averiguar
Eu passei adicionar o campo 54 para evitar a permissão de edição de valores em qr dinâmicos em alguns PSPs
no Itaú apareceu 1,00
experimenta adicionar o campo 54 informando o valor no seu brcode, pois alguns PSPs erroneamente carregam o valor apenas a partir do brcode
O PSP pagador era o mesmo nos 2 testes ?
O txid é você recebedor que gerar. O e2eid é o PSP pagador que gera para fechar o loop.
é.. o qrcode é válido e não tá expirado, o banco inter fez alguma merda.. tenho um amigo que ta usando outro PSP (porque ele nao pode usar a GN devido a ser jogos online) e no qrcode dele também nao ta lendo...
Você precisa ter o mTLS no seu servidor com o certificado dado pela GN https://pix.gerencianet.com.br/webhooks/chain-pix-sandbox.crt
ou para produção este aqui = https://pix.gerencianet.com.br/webhooks/chain-pix-prod.crt
Vou atualizar aqui a lista de PSPs
esse problema específico ainda existe em outros bancos; e agora tem o outro, do "histórico mal feito" de alguns PSPs, onde vc paga um QR estático ou dinâmico com txid, ele guarda só a chave do recebedor e mostra num histórico pra vc enviar outros pagamentos.. como se bastasse identificar o recebedor pela chave. e o cliente paga por ali, sem ter noção de que precisa ler um novo QR
Pode estar relacionado ao GUI , alguns PSPs não aceitam se estiver em minúscula ou maiúscula
Assim evita-se, também, o problema dos PSPs que "guardam" os QR codes pagos num "histórico" da conta do pagador, mas na hora de "re-pagar" com base no histórico, eles enviam usando só a chave (ignorando os dados lidos do QR que gerou o registro anterior no histórico).
Não de PSPs particulares. De qualquer PSP. Qualquer recebimento sem txid.
Não sei se entendi bem o cenário, mas você quer recusar pagamentos de PSPs que não enviam o txid?
devolver by default. ou bloquear no psp pix sem txid
No caso de pagamento há PSPs mostrando códigos que são internos dele e não do Pix. Seria o caso ?
PSPs que validam o CRC: exibiam qr code inválido;
PSPs que não validam o CRC: alguns exibiam qr code inválido (por conter 3 caracteres num campo que deveria ter 4); outros ignoravam a regra a tal ponto que o campo 63 era totalmente descartado e o QR era considerá válido (pagável)
