Histórico de mensagens sobre PSP

$body = [
"calendario" => [
"expiracao" => 3600
],
// "devedor" => [
// "cpf" => "53147430278",
// "nome" => "Rogerio Brito Soares"
// ],
"valor" => [
"original" => "0.01"
],
"chave" => "34.646.106/0001-89"
// "solicitacaoPagador" => "Informe o número ou identificador do pedido.",
// "infoAdicionais" => [
// [
// "nome" => "Campo 1", // Nome do campo string (Nome) ≤ 50 characters
// "valor" => "Informação Adicional1 do PSP-Recebedor" // Dados do campo string (Valor) ≤ 200 characters
// ],
// [
// "nome" => "Campo 2",
// "valor" => "Informação Adicional2 do PSP-Recebedor"
// ]
// ]
];

Você está montando o QRcode ou utilizando a rota GET/v2​/loc/{id}/qrcode? E qual o PSP que você tentou realizar o pagamento?

Pessoal, vejo que tanto no SDK PHP e como no Postman há o campo de "solicitacaoPagador" preenchido como uma informação que parece ser uma descrição do serviço. Por um erro de alguns PSPs houve uma tratativa errado do campo e alguns somente mostram ele sem requerer nenhum dado do usuário. A GN em sua documentação leva a acreditar também que o campo também serve para isso quando coloca "solicitacaoPagador" => "Cobrança dos serviços prestados."
Sugiro a modificação para algo como "solicitacaoPagador" => "Informe o id do produto", assim o integrador poderá entender com mais facilidade (mesmo que o campo em si já descreva a funcionalidade).

E particularmente não sou fã de usar SDK principalmente na API PIX que você pode ter uma mudança de PSP.

Qual PSP está tentando pagar?

Na realidade nossa rota interna segue exatamente os padrões do BACEN, inclusive acrescentamos o Point of Initiation Method para que alguns PSPs que exigiam este atributo opcional conseguissem "ler" o QR code. Mas foi bom que você encontrou a causa do problema, se precisar estamos a disposição.

Correto. Que pode ser ou num QR estático ou em PSPs que aceitem chave aleatória como destino (não são todos).

<@!818639956263567360> Este link não é possível acessar mesmo. Este link contido no BrCode é o location que possui os dados da cobrança para os PSPs lerem.
O brcode que lhe rotorna neste consumo é o mesmo que o Pix Copia e Cola.
Ou seja, com a string 00020126880014br.gov.bcb.pix2566qrcodes-pix.gerencianet.com.br/v2/c04644cfd18144db9e7f253c20b56e155204727453039865802BR5925PAGAMENTOSRENOVACAOAUTOPI6014Rio de Janeiro6207050363048DAA
você acessa o seu banco e paga através dela

Bom dia <@!818639956263567360>!
Este que QrCode foi gerado utilizando credenciais de Homologação? Se sim, até o momento não é possível a quitação em Homologação, somente em Produção

Caso tenha sido em Produção, qual foi o PSP? Nos mande também o Pix Copia e Cola para analisarmos.

Sim, e deveria ser bloqueado o duplo pagamento tanto no PSP Pagador quanto no recebedor (GN no caso).

Me parece que hoje as opções seriam a transferência por CPF/agência/conta e chave CPF. Você talvez possa aumentar a sugestão que dei ao BACEN em https://github.com/bacen/pix-perguntas-e-respostas/issues/470 com uma opção na API do BACEN para os PSPs de passar um par (chave não CPF, CPF) e o sistema dizer só ok (existe e é desse COF) e não ok (ou não existe ou não é desse CPF).

Apesar de enviarmos o TradeName alguns PSPs não estão fazendo a leitura das informações disponibilizadas no DICT e por isso a sugestão é você fazer a leitura em outros PSPs.

Boa tarde <@!370847985199742977>, você deve cadastrar a chave novamente para que o TradeName seja atualizado, a forma de realizar o teste atualmente é gerar uma transação, como a emissão de uma cobrança, com a chave e depois realizar a leitura via aplicativo da Gerencianet ou algum PSP.

Boa tarde <@!485501766570344454>! O webhook é acionado quando é feito o pagamento de uma cobrança associada a sua chave ou quando você realiza um envio de Pix(POST /v2/pix) utilizando a sua chave no pagador. No entanto, quando você realiza um envio de Pix a partir de um PSP para a sua chave, o webhook não é acionado mesmo.

Se houver alguma coisa no arranjo Pix e/ou no comportamento dos demais PSPs que impeça isso, pq não regride para algo extremamente simples que atenda a necessidade primária da maioria?

Confesso que não entendi o problema. Se algum PSP comete a atrocidade de enviar uma chave Pix em uma transação manual (com ag. e conta definidos pelo pagador), a GN tem duas opções:

1. tratar com base nas regras da chave enviada (segue a regra de aceite definida pra essa chave); ou
2. trata como manual (e a opção "receberSemChave" vai barrar, se o EC quiser).

Então, Pessoal, o Pix é algo que veio para ficar. É nítido o crescente uso da modalidade, seja por Pessoa Física ou por Pessoa Jurídica, e na troca entre os dois. É muito animador tudo que está ocorrendo, e não aderir ao Pix é uma inocência gerencial.

Observamos que a funcionalidade de recusa de txids, desenhada dentro das variáveis do fluxo oficial do Pix, tem tido problemas devido a implementações precárias por parte de alguns PSP's, que estão tecnicamente aquém do que se espera das especificações do Bacen.

Em conversas internas, e diante de nossas responsabilidades, não seria justo, seja com a comunidade ou com o próprio ecossistema do Pix, deixarmos de ofertar possibilidades em decorrência de problemas básicos de aplicação/interpretação da documentação oficial do Bacen por outros PSP's.

Por isso, iremos liberar, ainda hoje, o recurso de recusa de Pix, PARA TODOS, cabendo a nós "puxarmos a orelha" dos outros PSPs e buscarmos que eles sejam tecnicamente mais assertivos sobre a correta implementação do Pix.

Com o apoio de vocês, seguimos fortes na nossa responsabilidade e nossa contribuição com a inovação de Meios de Pagamentos no Brasil.

Nos testes pegamos alguns comportamentos dos PSPs que vão exigir atenção e validação, por isso resolvemos levar pra essa camada de beta

Pessoal, bom dia.

Passamos os últimos três dias testando massivamente a nova funcionalidade, porém acreditamos que ainda podemos ter surpresas com PSP's que fazem uma "abordagem própria", algo que já estamos calejados 🙄 , por exemplo alguns enviam as chaves mesmo nos Pix manuais, ou podem enviar um outro padrão de txid inválido que ainda não pegamos, etc.

Portanto, não iremos liberar a atribuição autônoma de escopos no nosso sistema ainda. Peço aos interessados que informem ao <@!652136709982781470> o Client Id das credenciais de vocês, ele vai atribuir os novos escopos pontualmente. Vamos seguir o entendimento de uma funcionalidade em beta, portanto sugiro que criem uma nova chave evp exclusiva para a utilização das novas configurações, para não atrapalhar a operação de vocês.

Em relação a alguns PSPs não mostrarem o infoAdicionais inclusos na geração da cobrança, isto ocorre por ausência de implementação do próprio PSP, sendo assim é necessário que o mesmo "corrija" e passe a demonstrar aos seu clientes.