Termos mais procurados:
É sim <@!747457595060650014>, no momento que é feito a requisição já enviamos ao BACEN e ao respectivo PSP a solicitação de devolução, podendo esta ser concluída com sucesso , status "DEVOLVIDO". Pode ser interpretado como "Pix reverso".
Sugiro que acrescente o "Point of Initiation Method" na geração do QRCode no GET /loc/:id/qrcode, alguns PSPs como o Bradesco não estão lendo o QRCode.
Pq vc passa um path, o PSP adiciona /pix.
Mas a imagem que você gerou, você conseguiu ler em algum psp?
Sim, mas vou buscar com a equipe se existe como retornar para você está informação, é um pouco mais complexo porque exige que o PSP recebedor nos reporte a causa da falha e não uma mensagem padrão de recusa.
Isso vai depender muito do PSP que recusou o pagamento, pois, será enviado uma mensagem ao BACEN nos informando apenas que a transação não foi efetuada por recusa do PSP. Mas quando houver alguma falha deste tipo você pode me mandar mensagem que eu vou buscar estas informações junto ao financeiro.
Bom dia Henrique! Quando você faz uma solicitação de envio de pix, tem o risco do psp recusar esse envio ou ter uma falha... Então quando é "concluído" enviamos o webhook da seguinte maneira... como o Matheus havia mostrado ontem:
Sugestões que me lembre até agora:
- Utilizar % bem parecido com o LIKE do MySQL;
- Utilizar iniciaCom e terminaCom;
- Utilizar o regex bloqueando o uso de "()" (faria com que não demorasse tanto);
- Enviar uma requisição para uma URL para homologar um txid, ex: {webhookUrl}/txidmatch (Essa necessitaria de uma homologação parecida com BACEN x PSP);
O é um erro que por enquanto deveria ser removido pelo PSP recebedor e deixar sem txid.
o único caso especial possível que não seria coberto apenas com os 2 validadores txidNulo e txidEstatico seria um PSP pagador tratar erradamente o txid como int em algum ponto do seu sistema e acabar enviando "0" na PACS em vez de uma string vazia, ou omitir o campo txid, fazendo a validação da GN testar contra a opção de aceite de Pix via qr estático em vez de testar contra o Pix de txid nulo, o que eu não vi ninguém reportar e acho difícil que aconteça (por ser o txid um campo que acata caracteres a-z também). por isso que acho suficientes essas 2 opções. simples e funcionais. e em último caso, a GN poderia tratar a string "0" como txidNulo em caráter de exceção.
e há sim-PSPs com APIs não padrão, também 😆
Mas há não-PSPs com APIs não padrão de Pix, de fato.
em qualquer PSP que seguir o padrão
O txid nulo acontece por falha de PSPs. O estático só se montar um EMV de propósito...
A API da GN é padrão então o código serve em qualquer PSP... 😉
O status não muda, mas não deveria aceitar mais o pagamento. Tanto PSP pagador quanto recebedor deveriam checar expiração e rejeitar.
<@!793123559874494465> Acho que alguns campos das comunicações entre PSPs e BACEN admitem/adotam a grafia "txId" (com I maiúsculo) mas na comunicação PSP <-> EC o termo "txid" foi padronizado para minúsculas em todo o material e API padrão do BACEN (já há algum tempo). Então acho que seria mais consistente para os ECs tratar assim (txid).
se no futuro algum PSP fizer uma merda grande (enviar txid A para QR code com txid B), aí sim, deveríamos estar pensando em meios de validar o txid
Boa tarde <@!812297338605273098>! Você poderia utilizar o endpoint de envio de Pix, com ele você consegue verificar se a chave em que o Pix foi enviado existe ou não, pois, é retornado em nosso endpoint. Mas caso você se refira a consultar as chaves cadastradas no DICT, no momento não é possível, o Banco Central limitou aos PSPs consultas a serem feitas no DICT como se fossem fichas e por isto não tem como liberar um endpoint que permita um retorno de quais chaves estão cadastradas.
Endpoint destinado a realizar o envio direto de um Pix para uma chave Pix cadastrada em um PSP seja da Gerencianet ou outro. POST /v2/pix
