Histórico de mensagens sobre PSP em sugestões

Só que ainda é um serviço "beta", então um número limitado de PSPs tem acesso...

Então, na lista de PSPs de Pix que mantenho, o PagSeguro consta como seguindo o padrão do BACEN... mas não sei se eles ainda mantém o outro endpoint sem certificado.

Agora entendi. O que fizemos para isso foi construir nosso PSP Pix interno, mas não é um projeto público.

Sugestão é ter um end-point de status da API Pix (quem sabe demais APIs também). Ele retorna um JSON tipo { token = ok, cob = ok, pix = ok, payload = ok, spi = ok } Onde token significa que o endpoint de token está legal, cob que o /cob está legal dado um token válido, pix que o /pix está ok, payload que o end-point para os outros PSPs buscarem os dinâmicos está ok, spi que a compensação de Pix está ok.

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).

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