Histórico de mensagens sobre PSP em pix

Não de PSPs particulares. De qualquer PSP. Qualquer recebimento sem txid.

Não sei se entendi bem o cenário, mas você quer recusar pagamentos de PSPs que não enviam o txid?

No caso de pagamento há PSPs mostrando códigos que são internos dele e não do Pix. Seria o caso ?

PSPs que validam o CRC: exibiam qr code inválido;
PSPs que não validam o CRC: alguns exibiam qr code inválido (por conter 3 caracteres num campo que deveria ter 4); outros ignoravam a regra a tal ponto que o campo 63 era totalmente descartado e o QR era considerá válido (pagável)

No caso o PSP lia o qrcode e apresentava um erro? Tipo aquele erro que acontecia com os centavos ou erro é qrcode inválido?

cara, tem 2 regras:

- o campo 63 precisa ter 4 caracteres
- o CRC16 é calculado em cima de toda a string (incluindo 6304)

então o certo é comparar seguindo a norma:

- pega a string e retira apenas o valor do campo 63 (mantém 6304)
- calcula o CRC em cima do que sobrou

se o CRC do que sobrou é "924" (ou "0924", dependendo da função que vc use pra calcular o CRC já é normal o "0" à esquerda estar presente) o valor do campo tem que ser considerado um "match"

- se algum PSP não considerar a string com "0924" match, tá errado
- se algum PSP considerar a string com "924" match, também tá errado (pq o campo tem que ter 4 caracteres e essa regra já estaria quebrada independentemente do teste de CRC)

Isso, até onde sei só o recebedor/psp pode solicitar o reembolso e pode ser completo ou parcial.

se acontecer pelo psp, sei lá.. eu sou notificado no webhook com a devolução então, certo?

Foi realizado a correção referentes aos valores monetários sendo recusados. Já foi colocado em produção e os valores testados em outros PSPs.

A pressa é amiga da inovação e inserção rápida no mercado! 😁
Mas tranquilo, entendi a limitação com relação ao formato do Bacen (o que não concordo, afinal é fator de diferenciação dos PSPs conseguirem facilitar o processo).

Integrações mais facilitadas surgirão com o tempo. Observe que o BACEN determinou a obrigatoriedade de oferta da API Pix padronizada pelos PSPs que quiserem ofertar API Pix. Talvez a GN oferte outra API posteriormente, mais próxima do que você está acostumado (onde o controle sobre as cobranças e os detalhes internos do arranjo é menor).

A documentação está ótima, lí ela 5 vezes, antes de começar a fazer alguma coisa, lí a documentação do BACEN, temos todos os endpoints para testar no postman, temos um SDK pronto para uso no github, temos um canal do discord com mais de 10 pessoas da GN prontas para ajudar, temos mais de 100 membros estudando e ajudando. Agora me diga aonde você tem isso fora daqui ? Eu busco soluções, querer tudo pronto de mão beijada em uma linguagem específica ... ai são outros 500. Nenhum outro Banco ou PSP está fazendo o que a GN faz 🙂 . Eu reconheço o esforço de todos.

Realizamos alguns testes com esses valores e o pagamento ocorreu nos PSPs, mas nos valores 1.09, 1.16 realmente foi recusado. Questão já foi reportada e está sendo analisada

Na documentação de padrões de iniciação, o exemplo de estático não contém ele, mas num documento recente do BACEN destinado aos PSPs onde esclarece como deve ser o processo de tratativa de geração e de leitura de QR Codes, consta que esse campo pode estar presente em qualquer QR (estático ou dinâmico) e, ao mesmo tempo, esclarece que a presença do valor 12 no ID raiz 01 (ou seja, o 010212) não deve impedir o pagamento do QR, apenas serve como indicativo para que o PSP pagador exiba ou não uma mensagem ao pagador referente à existência de pagamento prévio realizado pelo mesmo pagador para o mesmo QR (evitar duplicidade). Então se é o QR de uma compra e o lojista colocou o 0101212, o PSP poderia avisar "parece que você já pagou este QR recentemente (ou em X data), deseja prosseguir?" - não importa se é estático ou dinâmico. Se não constar o 010212 o PSP não deve interferir no processo de pagamento (então a ausência do campo é mais indicada para QR Codes que serão utilizados múltiplas vezes pelo mesmo pagador, como recargas de serviços ou pagamentos recorrentes de uma assinatura, etc).

blz, entao o app do PSP vai estar preparado para dar o get na URL e obter o payload JWS... Entendi, muito obrigado!

O 59 Merchant pode ser qualquer coisa, e nem deveria ser mostrado... mas como um outro PSP mostra, seria bom por simplicidade de suporte ter o mesmo que aparece no DICT, limitado a 25 caracteres.

O 59 Merchant Name é obrigatório, mesmo que você ponha algo genérico como "Pix". Mas é melhor colocar o nome mesmo, pois alguns PSPs mostram isso ao invés do que tem no BACEN (erradamente).

Outra sugestão é colocar o 26 0 (GUI) como br.gov.bcb.pix . Não está errado em maiúsculas, mas tem vários PSPs ainda tratando isso errado.

normalmente é sim. mas o servidor que hospeda o jogo, normalmente. não o do PSP

$PSP_requisicao = [
'valor' => $MMHospedagem['amount']
];