Histórico de mensagens sobre pagamentos em pix

Sim, temos como lidar, é só devolver os pagamentos em duplicidades, a questão é receber as notificações e também temos que ler via api os status e de quantos txid iguais foram pagos.

Mais deixando o BRcode dinamico para ser pago apenas uma vez isso já elimina a possibilidade de dois pagamentos, correto ?

<@!783359762917752843> e <@!440035527127990273> vou levar essa questão de bloqueio de pagamentos sem txid a nível de chave e retorno para vocês.

esse problema específico ainda existe em outros bancos; e agora tem o outro, do "histórico mal feito" de alguns PSPs, onde vc paga um QR estático ou dinâmico com txid, ele guarda só a chave do recebedor e mostra num histórico pra vc enviar outros pagamentos.. como se bastasse identificar o recebedor pela chave. e o cliente paga por ali, sem ter noção de que precisa ler um novo QR

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

Especulação minha, eu acho que há algum entrave relacionado ao financeiro.
Se a GN fizer tal filtro, seria possível receber todos os pagamentos via qr code estático, sem custo, e ainda fazer a conciliação, bastando para isso gerar qr code estático com txid.

mas aí tu bloqueia todos pagamentos estáticos..

Por isso Isadora, rejeitando todos os pagamentos que não tem txid o usuário terá que usar outro App que informe o txid, o que acontece hoje é que o usuário lê o qrcode, paga, o app não informa o txid mas o usuário pagou..

Acho que você não entendeu o pedido do Ezequiel. Ele quer evitar que a conta dele receba Pix que não tenham txid. A GN já ofereceu isso aqui nesse mesmo canal no passado (não exatamente com base na existência de txid, mas com base na existência de cobrança vinculada - então a GN verificaria se existe cobrança para o txid e, se existir, acata o pagamento, do contrário, rejeita - porém o BACEN já deu abertura para que a análise seja com base na existência do txid (independentemente de haver cobrança ou não), só cabe à GN a decisão de atender esse pedido; de qualquer forma, talvez a oferta existente, já atenda a necessidade do Ezequiel, não sei se ele precisa receber pagamentos com txid vindos de QR estáticos, não ligados à cobranças).

mas aí vc tem que anotar os e2eid dos pagamentos que vc já "processou" (ou, pelo menos, o e2eid/data do pagamento mais recente já processado). e só considerar os pix retornados na consulta que forem mais recentes do que o último já processado para aquele cliente

Não tem como no momento, ele não é apto para pagamentos. Vamos realizar algumas melhorias no ambiente de homologação para possibilitar estes testes. Recomendamos que gere cobranças de R$0,01 em produção para testes de pagamento

Há uma anomalia no endpoint /v2/pix para o método "Consultar Pix recebidos".
Estou filtrando algumas cobranças para analisar os pagamentos e está acontencendo o seguinte:
Ao filtrar os PIX recebidos em um determinado período, a API informou um total de 16 pix recebidos.

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

passando pra avisar que atualizei a lib com 3 novos métodos para consulta e pedidos de reembolso de pagamentos PIX

então, to usando c#, transformando o certificado do endpoint em um x509certificate2 , tem um metódo Verify(), ele já não meio que faz todas essas verificações?

Retornando um Verify() true, conferindo o Issuer == "[email protected], CN=api-pix-h.gerencianet.com.br, OU=Infraestrutura, O=Gerencianet Pagamentos do Brasil Ltda, S=Minas Gerais, C=BR"

Restringindo também (como comentou) o IP, eu nem precisaria verificar o thumbprint? já estaria validado?

Eu pulei esta etapa, na pratica fazer em modo DEV não testa nada se nao temos o retorno do webhook para receber, creio que em breve teremos os envios e pagamentos em modo DEV.

Estou usando o campo solicitacaoPagador para exibir uma informação na tela, mas pagamentos sem preencher nenhuma informação não foram barrados.

Por isso disse que tô quase desistindo, esta é a parte delicada 🙂 No inicio faziam pagamentos em envelopes nos caixas eletronicos para os clientes, agora tudo está mais fácil não é mesmo GN ?

Boa Tarde, existe como usar uma conta Gerencianet para vários clientes?
Exemplo, temos uma plataforma de ecommerce, então teriamos uma conta na Gerencianet para a plataforma, e cada lojista que desejar utilizar iria informar sua chave pix para receber os pagamentos

Alguém sabe me dizer se os pagamentos PIX ainda estão com horários limitados? Ontem de madrugada o Itaú, Nubank, Inter e Gerencianet estavam com problema para ler meus QR Codes. Depois vi que no app do Itaú minhas chaves estavam ocultas e o menu do PIX desapareceu. Hoje voltou tudo ao normal. Isso ocorreu por volta de 4 da manhã