Termos mais procurados:
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)
Presente de Natal = Realizar a implementação do recebimento por cartão com $U$$E$$$O
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?
Putzzzz. Mais por um lado pode ser util, pois posso ser um concentrador de recebimentos de webhook. Que inclusive é o caso aqui 🙂
realmente. por isso estamos pedindo à GN a opção de limitar, chave a chave, o recebimento de pix quando vier sem txid
Mas isso já é um problema da GN com ou sem essa mudança de "impedimento" de recebimento sem txid, Francisco.
Mas para isso teriam que mudar a política de cobrança, pois a tabela de tarifas precifica recebimentos gerados via API, mas não mencionam recebimentos gerados fora da API
