Histórico de mensagens sobre PSP

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

como o <@!780500321994539068> bem observou (comentário em outro local), eles não são PSP, então não impede oferta de API proprietária

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

poderia constar nas regras que os projetos apresentados no <#💻devs> devem fazer uso dos serviços da GN ou serem complementares a eles (um e-commerce que aceite Pix mas use um PSP concorrente para transacionar, por exemplo, acho que não faria sentido ter espaço publicitário no servidor)

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']
];

$MMHospedagem_PSP_Api->DevolverPagamento($ID_Transacao[1],MMHospedagem_Pix_ID_GerarTransacao(10,'333'),$MMHospedagem_PSP_requisicao);

Segue sugestão de EMV/BRCode para dinâmico:

00:01 (versão)
01:12 (uso único)
26 00:br.gov.bcb.pix (em minúsculas pois é o que parece dar menos problema de não reconhecimento)
26 25:qrcodes-pix.gerencianet.com.br/v2/6387cb2c8dd94ca6b1349f9e825a83e8 (location obtido do PSP, hostname em minúsculas, path conforme PSP)
52:0000 (mcc)
53:986 (reais)
54:"40.00" (ou o valor da fatura em questão, parece útil em alguns PSPs para evitar edição de valor)
59:"Meu Estabelecimento" (é mostrado indevidamente por alguns PSPs)
60:"Sao Paulo" (sem acentuação)
61:"01000000" (CEP sem o -)
62 05:"" (TxID de dinâmico vem no payload)
63:CRC