Histórico de mensagens sobre erro em sugestões

Estou tentando vincular a conta Gerencianet pessoa física ao MK-auth, mas estou tendo erro ao gerar os boletos

Erro 500... nesse caso

No console do developer tools aparece algum erro ? Precisa ativar e depois retentar a transação. Eu topei com umas falhas na v7, mas não nessa transação, relatei e foram corrigidas.

Estranho, olhei na network e da erro 500

Boa tarde
Uma sugestão que eu gostaria de dar, referente a API em python (e talvez as outras, se não tiver)
Já aconteceu de algumas notificações do token dar erro, e não serem reenviadas.
Quando isso acontece, eu vou em API -> Minhas Aplicações -> Transações, clico no 'olhinho' da conta em questão, e reenvio a notificação por lá
Mas pra fazer isso, eu preciso entrar no site do gerencianet
Eu vi que quando clico no botão pra reenviar a notificação, ele consome o webservice
GET /charge//notification/resend
Seria interessante se esse endpoint fosse adicionado na API python, pra conseguir solicitar esse reenvio do token pelo meu sistema interno

Certo.. Então, mas acho que vocês poderiam criar dados errados propositais para dar erro com as informações da primeira mensagem..

Se o dev digitar dados X, ele quer receber mensagem de numero do cartão inválido
Se o dev digitar dados Y, ele quer receber mensagem de data vencida
Se o dev digitar dados Z, ele quer receber mensagem de cvv inválido

e eetc

Certo, mas ai se eu envio o token, depois de verificado os dados que foram enviados e eles estão incorretos não retornam mensagem de erro

Oi pessoal, boa tarde!
Estava aqui pensando em algum jeito de testar alguns tipos de erros em transações e acho que tenho uma sugestão para vocês (caso já exista, por favor me sinalize como utilizar).

Eu gostaria que tivesse dados de cartão de crédito para a gente testar em sandbox onde a mensagem daria por exemplo que o digito (cvv) tá incorreto, a validade tá incorreta, numero do cartão ou outra coisa... Se tivessem esses dados na documentação seria ótimo para testarmos isso e poder retornar a informação correta para o usuário.

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

O é um erro que por enquanto deveria ser removido pelo PSP recebedor e deixar sem txid.

Outra sugestão seria possibilitar uma devolução manual pelo site, para qualquer erro na integração o estabelecimento conseguir fazer a devolução

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

<@!793123559874494465> então isso não só facilita o trabalho de codificar o pagamento, quanto é a única maneira de implementar seguindo a ferro e fogo o manual de segurança do BACEN.

Além disso, o erro retornado é genérico demais: Ocorreu um erro ao requisitar o pix .

Sobre o pagamento/transferência via POST em /pix, eu acho que ele devia ser mudado para PUT. O POST hoje não tem idempotência, e está sujeita a duplicações... a idempotência seria garantida com um parâmetro id (similar ao id de devolução), diferente do eventual txid (que é do recebedor). Para não ter que criar muitos métodos distintos, acho que poderia ser um único... se não tiver txid ou código, a ação é de transferência. Se tiver txid ou código, é pagamento... mas são mutuamente exclusivos. Ou tem o txid, ou tem o código do Pix Copia e Cola.
No geral fica:
chave mutuamente exclusivo com banco/tipo/agência/conta/cpf , mas um deles é requerido
txid mutuamente exclusivo com código, mas é opcional.
idenvio obrigatório, e garante idempotência. Se receber duplicado, só dá erro se for diferente. <@!793123559874494465>

<@!793123559874494465> achei interessante, mas a dúvida é como seria as mensagens de erro? Ex: Quando um cliente atingisse a limitação de 20 chaves?

<@!671762828046106646> Você conseguiu verificar aqueles erros que te passei do sub-usuário?

obs: até porque, uma cobrança estar com status CONCLUIDA não é um erro. É um status perfeitamente normal para uma cobrança.

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