Histórico de mensagens sobre QR CODE em sugestões

se no futuro algum PSP fizer uma merda grande (enviar txid A para QR code com txid B), aí sim, deveríamos estar pensando em meios de validar o txid

8ª - A página com o QR Code para pagamento poderia ser atualizada automaticamente quando o Pix é pago, assim facilitaria para o usuário identificar que o pagamento dele deu certo, sem ter que fazer o envio de comprovante ou qualquer outra coisa

7ª - Se por ventura o cliente não conseguir pagar o QR Code de imediato e sair da página de pagamento, não dá pra gerar outro QR Code ou visualizar o QR Code gerado anteriormente

Ao acessar o pedido enquanto está com o status Aguardando, apenas mostrará o que ele está comprando e as informações de endereço

<@!368230019740205058> vou te chamar no privado pra ver sobre a questão de você não conseguir gerar o qrcode.

5º - Se a opção "Habilita o checkout em um passo" está desabilitada na configuração do plugin, e o valor do pedido for inferior a R$ 5,00 fica impossível seguir para a parte de gerar o QR Code

3º - Incompatibilidade com alguns bancos. Cadastrei uma chave de e-mail, configurei tudo no WooCommerce, na hora de pagar recebo o QR Code, mas nem todos bancos conseguem ler a image, como no caso do PicPay, o erro apresentado é que o Pix ainda não está disponível para este código... mas se tento ler com o Nubank por exemplo, funciona

Este pode ser um problema de não ter o Nome do Recebedor no QRCode, o PicPay não aceita se não tiver.

boa tarde, estou testando o plugin do WooCommerce e gostaria de enviar algumas sugestões:

1º - Puxar o CPF/CNPJ do cliente no momento do Checkout automaticamente em vez de ficar perguntando toda vez qual o CPF
2º - Adicionar um código Copia e Cola abaixo da imagem do QR Code gerado, nem todos clientes fazem o pedido pelo computador
3º - Incompatibilidade com alguns bancos. Cadastrei uma chave de e-mail, configurei tudo no WooCommerce, na hora de pagar recebo o QR Code, mas nem todos bancos conseguem ler a image, como no caso do PicPay, o erro apresentado é que o Pix ainda não está disponível para este código... mas se tento ler com o Nubank por exemplo, funciona
4º - O identificador do Pix poderia ser o número do pedido gerado no site, complementar ao "Nome da fatura" configurado no plugin. Assim ficaria muito mais fácil de identificar o pagamento no painel GN

TxId duplicado só é recusado em QR-Code dinâmico, e um pagamento pode ser estático (com ou sem txid). Eu estava pensando e acho que a API tem que ter 2 passos de forma similar à UX do app:
/gn/pagamento (BRCode[obrigatório], idpagamento[obrigatório], valor[opcional])
retorna o valor do pagamento, as informações do recebedor no DICT (eventualmente mascaradas).
Aí a próxima chamada seria
/gn/confirmapagamento (idpagamento[obrigatório],valor[obrigatório])
Tem que passar de novo o valor e o id de propósito, para dizer "eu sei que vai sair x dinheiros da minha conta".

Na chamada de pagamento, o valor opcional seria passado para caso o QR-Code estático não tenha valor associado.

<@!793123559874494465> eu estava pensando e acho que para o pagamento de Pix é melhor mesmo um endpoint diferente, recebendo o BRCode. Aí se for estático/dinâmico já faz o tratamento devido e o pagamento. O único ponto é que se for de QR-Code estático, precisa de um id como o de devolução para garantir idempotência.

a função de gerar qr code de cobrança pelo app (que cria uma página de pagamento similar ao pix.ae) ficou bem legal.

só reportando alguns problemas:
- o txid digitado está sendo forçadamente convertido em maiúsculas (sendo que txid é case-sensitive);
- o símbolo R$ aparece sempre junto do valor (sem espaço), quando a notação correta é com um espaço;
- no app, depois de gerado o QR, se eu clico pra editar o valor, um novo QR é gerado mas o valor exibido continua sendo o antigo, dando a impressão de que editar o valor não teve nenhum efeito.

O mesmo vale para o GET de imagem do QR-Code.

basicamente.. o Itaú tá usando QR estático para um cenário onde deveria estar usando dinâmico. apenas se pouparam de ter que oferecer a leitura de qr codes via payload. deixaram todos os dados da cobrança a cargo do integrador, guardando somente a associação txid <-> valor, e rejeitando o que não coincidir

essa recusa que vc recebeu é pq o Itaú tá recusando QR codes "autônomos" que não sejam gerados no app/API deles (no seu caso, com o txid batendo mas com valor diferente, eles recusam da mesma forma)

<@!522899003663450113> mas aí você tá chamando de "manual" só pq foi vc que gerou o qr code estático. Quando falamos "manual" estamos falando de inserção de dados do recebedor (banco, ag, conta, nome, cpf/cnpj), igual no envio de TED

Não entendi. Qual txid você colocou no QR code que vc mesmo gerou? Se era o mesmo txid de um QR Code que o PH emitiu, o valor era o mesmo?

Discordo disso. Um teste que fiz com o Paghiper foi o seguinte:

O Paghiper não é PSP e está usando a chave "[email protected]", então peguei o txid de uma transação e tentei enviar um QRCode Estático com o txid (porque ai eu poderia tentar enviar com valor menor da cobrança). O Itaú recusou o Pix porque estava efetuando uma transação manual e não por causa do regex do txid, por exemplo.

tem PSP implementando isso muuuuuito mal.. e ainda tem as opções do tipo "lembrar recebedor" guardam os dados da conta na lista de recebedor e os clientes pagam por ali em vez de ler QR code (não se dão conta de que precisamos do txid para identificar as cobranças)

Report de bug:

Os payloads de cobrança pagas estão retornando um JSON contendo erro: "status_cobranca_invalido", mensagem: "A cobrança não está mais com o status ATIVA". Assim, os apps dos PSPs pagadores estão apresentando "erro ao ler o QR".

O payload deveria continuar sendo retornado no padrão JOSE (com certificado e assinatura, igual as cobrança ativas), com o status alterado para CONCLUIDA, para tratamento adequado, conforme status + possível presença do template 01 com valor 12 (qr code de apresentação única).

No extrato, em detalhes da transação, seria interessante exibir a instituição usada para a transação. O app atualmente exibe na notificação, mas no extrato não há essa informação.

É útil pra identificar os problemas, já que não são todos os bancos que estão funcionando 100%. Como o banco Inter, que mesmo o cliente pagando com QR Code, o sistema reconhece como se tivesse sido pago com chave, e os dados acabam não batendo com os da API, precisando fazer a aprovação manual do pagamento.

Seria interssante que alem do token fosse devolvido tambem a razao social / nome da conta na GN, isso serveria pra dar mais seguranca na transacao, uma vez que meu frente loja vai mostrar o QR-code e gostaria de mostrar tambem o nome da conta.