Histórico de mensagens em pix

Ok. Entendi que será necessário fazer pesquisa no endpoint do PIX para identificar os problemas de conciliação e aí fazer a baixa que deveria ter sido realizada.

E com CPF poderia ser:
GET /pix/
BODY: inicio=emissão, fim=agora,txidpresente=no,cpf=xxxxxxxxxx

A consulta com e2eid seria assim:
GET /pix/{e2eid}
BODY: inicio=emissão, fim=agora

Você precisa de algum processo out-of-band para receber isso. Por exemplo um formulário "paguei e não recebi" que aí dá oportunidade do cliente passar a informação.

Não posso perder a venda de maneira alguma. Vou ter que conciliar de alguma forma. Como faço receber o E2EID do pagador? No SDK pode ser informado uma chave. Será que posso utilizar para identificar o meu PIX?

Agora, se perder a venda doer muito para você, há dois jeitos de conciliar transações sem txid:
1) O pagador passa o E2EID, e você pesquisa por ele
2) O pagador passa o CPF/CNPJ da conta que fez o pagamento, e você pesquisa por ele.

Aí tem dois jeitos de ver a questão. Se lidar com essas exceções for mais trabalhoso que perder a venda, a GN vai lançar em breve um recurso para rejeitar essas transações. Eu pretendo usar.

O problema ainda acontece, mas com bancos com menos correntistas:
https://github.com/renatofrota/pix-pendencias/issues/21

@rubenskuhl, boa tarde! No vídeo no canal WDEV vc informou que alguns bancos não estavam enviando o txid dos PIX conciliados. Saberia informar se este problema foi solucionado? Obrigado por disponibilizar o conteúdo de valor..

Boa tarde <@!620895261568401428> ! Vou verificar essa questão com nossa equipe responsável e assim que eu tiver uma reposta eu falo com você.

E vale tanto para API quanto para BRCode.

Isso está especificado no manual de padrões para iniciação do Pix:
https://www.bcb.gov.br/content/estabilidadefinanceira/pix/Regulamento_Pix/II-ManualdePadroesparaIniciacaodoPix.pdf

putz, tu é foda Rubens...sempre prestativo :). Muito obrigado mesmo . Acertei então o cadastro, valew.

+5561912345678

#duvida = qual o formato de cadastro da chave no webhook para celular? esquecí isso kkkk e não sei aonde esta mais na documentação, são tantas hoje.

Mostrando que dá erro HTTP 500 caso o grant_type seja submetido via content-type: application/x-www-form-urlencoded ao invés de application/json. Por isso a configuração OAuth2 não consegue fazer o Fetch Tokens.

Exemplo da configuração do OAuth2 no Insomnia, que é igual ao Postman e outros clients compatíveis. Com isso deixa de ser necessário chamar o serviço de geração de token antes, e sempre que expirar. O client REST mesmo toma conta desse gerenciamento. Além do que, o Insomnia não tem a opção de rodar script que manipula as variáveis de ambiente como o Postman, que faz com que seja possível dar aquele "jeitinho" (no bom sentido) para esse tipo cenário. Vejo que o ideal seria usar o próprio padrão. É relativamente simples de resolver, aceitando não só o JSON como também o Form como Content-Type do serviço de geração do Access Token URL.

Pessoal, seria possível fazer com que o serviço https://api-pix.gerencianet.com.br/oauth/token aceitasse o content-type: application/x-www-form-urlencoded ? Desta forma evitaria o erro HTTP 500 ao enviar o body grant_type=client_credentials que é mais compatível com REST Clients como o Insomnia e até o próprio Postman na seção de autenticação OAuth2 usando o grant type "client credentials".

Pessoal, vamos encerrando pro hoje! Uma boa noite é um ótimo fim de semana a todos! 👋

show.. to aprendendo.. valeu demais