Histórico de mensagens sobre PSP

é aberta ou tem que ser psp?

De qualquer forma você pode usar uma vez o end-point da GN e ver como eles geram para inspirar o seu construtor de EMV. Eles já mudaram bastante coisa em resposta a essas idiossincrasias de PSPs pagadores.

É um diagnóstico que pode varia de muito simples (por exemplo, se a mensagem de erro do app é bem específica) a impossível, quando a mensagem de erro é genérica e não há colaboração daquele PSP.

Sim. A crítica de EMV é bem variada entre os PSPs pagadores; alguns "engolem" coisas erradas que outros não aceitam, outros recusam pela falta de ítens opcionais que são tratados como mandatórios.

Lembrando que todos os PSPs estarão realizando o procedimento

Boa tarde <@!689656729314656316> , não vão existir mudanças na estrutura da API para quem consome o serviços dos PSPs, o informativo é mais no sentido de comunicar pra comunidade uma atualização que vai ocorrer no ambiente Pix. Assim podemos acompanhar de perto e sermos ainda mais rápidos caso sejam percebidas oscilações ou instabilidades durante a transição.

Bom dia, <@!127179327447105537>. Como vai? 😃
Esta falha pode ser apresentada, caso a chave pix informada na requisição é inválida, ou a chave está registrada em outro PSP. Ou seja, você deve informar uma chave Pix que está registrada na Gerencianet, na conta que você fez a autenticação na API.

Sim, mas o "/pix" ao final é colocado mesmo que o path termine em "/". Foi um esclarecimento que os PSPs pediram para o BACEN, que determinou desse jeito.

Provavelmente a falha esta nesse PSP, porque analisamos e esta tudo correto. E se tivesse com falha na montagem do pix copia e cola, os outros PSPs tbm ocorreriam a falha

Boa tarde <@!690280170158031328>, exatamente o que o Rubens explicou. O "REMOVIDA_PELO_USUARIO_RECEBEDOR" você mesmo pode alterar o status por meio do PATCH /v2/cob/:txid, já o REMOVIDA_PELO_PSP_RECEBEDOR acontece quando a Gerencianet identifica alguma transação com fraude ou motivos que nos levam a crer que a cobrança não deveria estar apta para pagamento no momento.

REMOVIDA_PELO_EC é porque você removeu através de um comando PATCH. REMOVIDA_PELO_PSP_RECEBEDOR é porque a Gerencianet removeu, o que pode ter motivos como você ter removido a chave Pix, portado a chave Pix ou a Gerencianet ter concluído que era pilantragem. 😉

o que seria REMOVIDA_PELO_EC, REMOVIDA_PELO_PSP_RECEBEDOR ?

Quem tem status é a cobrança, não ? São ATIVA, CONCLUIDA, REMOVIDA_PELO_EC, REMOVIDA_PELO_PSP_RECEBEDOR .

"timeout no psp do recebedor".

ele gera o qrcode e tudo, porém Não é pago no PSP

Nem todo PSP pagador checa tudo, não dá para se basear nisso para dizer que está certo ou errado. Tem que ver o padrão.

Só que essa chamada do QR-Code é não padrão. O que estava previsto no padrão era o PSP te dar o location e você gerar EMV e QR.

Sim, os recursos lá vieram de pedidos de clientes, meus inclusive... 😉
Só o alerta é de que não são portáveis, e que para alcançar os mesmos objetivos em outros PSPs serão necessários procedimentos diferentes.

Calcular a data + expiração. Acessar a URL não tem ainda uma forma padronizada de resposta entre PSPs.

Que eu saiba não, mas a geração de QR-Code, mesmo dinâmico, não precisa depender do PSP, pois ela segue padrões estabelecidos como EMV e BRCODE.