Histórico de mensagens sobre Recebimento em pix

E custo. Menor custo de recebimento de qualquer meio de pagamento da atualidade.

Estou com vontade de retirar a restrição para os bancos do meu sistema, mas esses dois bancos são os que mais afetam minha estratégia. Nos outros bancos, o máximo que pode acontecer é o cliente não conseguir pagar.
Estou esperando aquela configuração da Gerencianet para impedir recebimentos sem txid, mas não sei quando vai ser publicada

Ela pode cobrar 10 reais por recebimento, desde que seja 1 de Abril 🙂

tarifa é uma preocupação pra qualquer desenvolvedor ou EC, sim. não é porque teremos 4 meses de gratuidade que teremos a gratuidade pra sempre. e se a GN resolver cobrar R$ 10,00 por recebimento em abril, como fica? claro que é uma suposição absurda, mas a luz da certeza é sempre melhor que a escuridão da dúvida

Renato, agradecemos suas observações e elas serão consideradas...

Mas esclarecendo os pontos, quando você gera o estático, não consome a API, portanto não gera custo. O que gera o custo, é a utilização do webhook, no estático, utilizamos a webhook para o recebimento, porém, como você mesmo pontuou, esta é uma questão que está sendo verificada.

Mas neste momento não é uma preocupação, visto que temos a tarifa zerada até abril de 2021.
No link enviado a informação é que "As transações originadas pela API Pix serão gratuitas até o dia 30/04/2021."

Apenas corrigindo a minha mensagem, é "Pix recebido com valor IGUAL ou superior a R$90,00 = R$0,89" conforme link:

https://gerencianet.com.br/tarifas/

então a página precisa (novamente) de reformulação pois eu posso receber um QR code estático e nunca consultá-lo pela API. se o custo é pelo recebimento em si, não deveria estar dentro dos custos "de API" na página de tarifas.

ainda está por definir, mas será igual ou inferior ao custo dos recebimentos em cobranças (qr dinâmico)

Pessoal, alguem aqui trabalha ou já trabalhou com recebimentos internacionais em Dollaer/Euro?

Atualizando o caso do calendario.expiracao
O problema da leitura de uma cobrança expirada ocorre da seguinte maneira:
- Existe uma cobrança ATIVA com expiração futura
- Usar a rota PATCH /v2/cob/{txid} para redefinir o tempo de expiração para um tempo passado
- Os bancos leram o qr code, mas não é possível pagar devido a rejeição de recebimento por parte do PSP recebedor (GN)

Obs.: se a cobrança já estiver com expiração vencida antes do PATCH, o leitor nem lê o qr code.
Como não é possível pagar o qr code, vejo como algo irrelevante.
Acredito que seja algo relacionado ao location, pois após o PATCH o location continua o mesmo.

Obs 2: tentei redefinir o expiracao para tempo passado porque estava tentando "excluir" a cobrança, antes do <@!440035527127990273> me alertar sobre a possibilidade de se alterar o status da cobrança via PATCH

o uso da API é voltado ao recebimento de transações que exigem conciliação. e pra conciliar, existe o txid

<@!775350441965649951> , desculpa me intrometer, mas você falou algumas coisas erradas.

1. o GET /pix?txid=xxx é para consultar Pix recebidos (indiferente serem oriundos de QR estático ou dinâmico, tendo txid eles retornam nessa consulta), e não cobranças (que é no GET /cob)

2. pra consultar o(s) Pix recebido(s) por QR estático com um determinado txid ficaria GET /pix?txid=xxx&inicio=data_inicio&fim=data_fim

3. tendo o e2eid (que vem no retorno da consulta acima ou pelo webhook - quando a GN estiver notificando recebimentos oriundos de QR estático), aí pode-se consultar GET /pix/{e2eid}

#dica Tenha o próprio WEBHOOK para testar em modo desenvolvimento. Como ? Use o postman para enviar POST para a sua url de recebimento dos callback . Assim você pode testar todas as possibilidades existentes em modo desenvolvimento , sem ter que ficar entrando em bancos e pagando BRCodes para depois esperar o recebimento do callback, estou testando assim e ajuda muito 🙂

Ao que eu lembre o E2EID é gerado pelo PSP pagador. Por isso que no envio ele é possível antes de se completar o envio, mas no recebimento depende da chegada do Pix.

então.. mas esse E2EID disponibilizado no retorno da solicitação de envio, como ele está disponível antes da conclusão do envio, logo, no meu entender, elementos e2eid podem existir mesmo antes da conclusão do Pix (ele não é "gerado" apenas na efetivação do envio, mas antes disso - ainda que acessível apenas do lado do PSP pagador). no caso de recebimentos, a GN só toma conhecimento do E2EID de um Pix depois que já está efetivado? seria essa a justificativa para não ter status nos webhook (toda notificação sempre se refere a um Pix efetivado e por isso não vemos mais um elemento status no corpo do request)?

ok, porem o sistema estava todo pronto e funcionando com o recebimento dos status do webhook , ao criar a cobrança e quando o cliente pagava, agora sem as vindas destes status, parou tudo aqui 😦 . Eu não estava ainda validando com este endpoint, estava na etapa de validação com a vinda do webhook mesmo 😦 Terei que mudar toda a lógica aqui para poder automatizar tudo de novo 😦

Boa tarde a todos, estou com problemas nos recebimentos com o Itaú.... Hoje estou gerando QRCodes estáticos para os meus clientes pagarem no app, onde eu envio a txId e o valor, tudo em ordem exceto pelo Itaú, pois ele não aceita o txId com 26 caracteres, até 25 caracteres passa ( Mas aí o gerencianet não me deixa gerar a cobrança, pois o mínimo lá é 26 ). Alguém passando por algo parecido ?

As notificações são reenviadas nos casos em que o servidor do cliente não responde com o status de sucesso. Se o seu servidor confirmar o recebimento então não é mais realizado o envio da notificação. Isso é feito para evitar envios repetitivos e sobrecarregar o servidor do cliente.

Tava buscando isso ontem, e de fazer o ajax de verificação do recebimento.

{"rawBody":{"pix":[{"endToEndId":"...","txid":"..","valor":"50.00","horario":"2020-12-21T11:24:58.000Z","tipo":"RECEBIMENTO","status":"RECEBIDO"}]}}

Bom dia! Quais são os tipos de notificações além de RECEBIMENTO ? E quais os status além de RECEBIDO?