Histórico de mensagens sobre PSP

A maioria dos PSPs pagadores não está fazendo 100% das críticas que deveriam ao QR-Code e payload de cobranças. Aceitação em um está longe de garantir que não haja erros.

Não, pois ele é gerado pelo PSP do pagador ao fazer o pagamento da cobrança.

Como reforçado pelo Rubens, caso o PSP não envie o txid, o webhook não será acionado. Até por isso cobranças estáticas precisam ter algum txid para serem notificadas quando ocorrer o pagamento.

É que o sintoma parece de falta de txid. E há alguns PSPs sabidamente defeituosos nisso.

Boa tarde <@!585695073908293632>, estamos fazendo os ajustes para inserir no extrato financeiro o txid das cobranças, em breve vai estar disponível a todos os clientes. Em relação ao solicitacaoPagador, caso o cliente informe no campo alguma informação, ele aparece como Descrição no extrato, alguns PSPs só enviam o que o cliente informa no campo digitável do aplicativo.

mas apenas os PSPs, nunca o usuário final

O DICT é a API que o BACEN disponibiliza para os PSPs, mas o BACEN ao restringir as consultas no DICT não permitiu que os PSPs expusessem métodos que os correntistas dos PSPs pudessem usar. Havia uma oportunidade para isso quando o BACEN disponibilizou a consulta para agendas incluindo cache, mas isso foi feito apenas para telefone. (ou telefone e e-mail).

De quais PSPs pagadores ?

Boa tarde <@!241258461713661952> ! Você pode utilizar o endpoint de envio de pix para realizar transferências de um Pix para uma chave Pix cadastrada em um PSP seja da Gerencianet ou não, e também para dados bancários, como é o exemplo 2.

O problema é que se trata de um campo único. Além disso, alguns PSPs não fazem corretamente essa solicitação.

Quando você gera uma cobrança, você tem um location que carrega as informações da cobrança, assim outros PSPs conseguem saber os dados quando fazm a leitura do QRCode ou copia e cola. No caso a Gerencianet oferece um endpoint pro´prio para você gerar a imagem QRCode e copia e cola a partir do id do location.

5. Os usuários recebedores, como clientes da API, são um elo importante na segurança do
sistema, e, portanto, recomenda-se que o PSP tome ações para mitigar os riscos do ambiente
computacional dos seus usuários, uma vez que caso um risco se materialize em um incidente,
o próprio PSP poderá ser afetado. Ações recomendadas (sem prejuízo para outras ações que
o PSP julgar importantes):

Você não precisa do JWS. O PSP do pagador que vai usar isso.

Não, você mostra a imagem do QR-Code para o cliente, o PSP do cliente acessa o location para saber os detalhes da cobrança.

O link do location é para o PSP pagador acessar, ou para você incluir na imagem do QR-Code.

O campo chave, obrigatório, determina a chave Pix registrada no DICT que será utilizada para a cobrança. Essa chave será lida pelo aplicativo do PSP do pagador para consulta ao DICT, que retornará a informação que identificará o recebedor da cobrança.

Certo, <@!659964605766041629>. Não tivemos nenhum reporte de problemas... E realizamos testes neste momento, e conseguimos pagar normalmente com alguns PSPs, inclusive BB.

<@!806859749571821568> na geração da cobrança vc tá passando um campo solicitacaoPagador, o MercadoPago (e outros PSPs que estão seguindo corretamente a documentação) solicitam do pagador um texto de entrada para esse campo e não dá pra prosseguir sem preencher. Se a intenção é apenas exibir algum texto ao pagador, use o array infoAdicionais em vez do solicitacaoPagador.

De qualquer forma, eu acho que os PSPs pagadores erraram em não dizer que o EMV é inválido. Já passei para a PM do C6 e vou levar pro BACEN colocar no conjunto de testes de EMVs inválidos.

Mas os PSPs pagadores estão engolindo isso sem criticar. Há bug, mas em todos eles. 😉