Histórico de mensagens sobre Recebimento

Sim, mas na informação de recebimento você recebe também o E2EID.

Tem que criar um novo, tal como na cobrança. O E2EID é o do recebimento, mas cada devolução precisa de um novo ID.

Melhor do que o Santander que cobrou R$ 4 num recebimento de Pix de uma conhecida... parece que tem gente tentando o "vê se cola".

De recebimento em conta PF só poderia cobrar ou situação claramente de venda (exemplo: API) ou acima de 30 por mês.

ele disse que foi em recebimento (de outra instituição para o PagBank)

Sobre sua frase:

"O modelo de cobrança eu tô entendendo como sendo por transação de recebimento, independente do tipo de qrcode."

Na tabela de tarifas diz: "Pix pago ou recebido pelo aplicativo" => grátis

Então na prática, se vc for ao app da GN e gerar o QR Code que vai colocar na sua catraca (mesmo ele tendo txid), o recebimento é gratuito. E eles tem que notificar o webhook por determinação do BACEN.

O modelo de cobrança eu tô entendendo como sendo por transação de recebimento, independente do tipo de qrcode. Realmente o modelo prejudica as micro transações, mas eu espero que isso vai se ajustar com o tempo. O modelo de cobrança ainda não está claro para ninguém no mercado. Independente de ser ideal ou não, eu fico muito feliz da GN sair na frente e colocar na mesa uma proposta inicial....

será que eles vão tarifar os recebimentos com qr estático? achei mal explicada essa questão. um QR que eu gero pelo app (estático e que pode, inclusive, ter txid) e um QR que eu gero por uma ferramenta externa, não diferem em nada tecnicamente. então fica difícil saber se enquadra no "receber via app" da tabela de tarifas (que seria gratuito) e, ao mesmo tempo, também não se enquadra no "Pix via API" da tabela, pois o recebimento em si não se dá pela API (nem no caso das cobranças, só a geração delas é pela API).

também deveria ser modificada a nomenclatura: "tarifa por pix pago", quando na verdade pagamos por receber, não por pagar. (observe que as tarifas de cartão de crédito estão definidas como sendo "de recebimento", adequadamente).

e por fim, não gostei da "escada" de tarifas, com vários degraus. um pix de R$ 3,00 paga R$ 0,06 (R$ 2,94 líquido) e um de R$ 3,01 paga R$ 0,20 (R$ 2,81 líquido).. atrapalha totalmente o cenário de micro-transações (receber menos quando se vende mais caro, não faz nenhum sentido). acho que a tarifa poderia ser simplificado como "X%, com mínimo de R$ 0,01 e máximo de R$ 0,89". continuaria progressivo e nos daria uma flexibilidade adequada na estipulação dos preços para micro-transações. com base nos R$ 30,00 do valor da tarifa máxima (R$ 0,89), esses X% seriam 3% (mas se for menor, melhor! rsrs)

valeu <@!440035527127990273> ! realmente com qrcode dinamico, saindo do nubank recebi o request no webhook! \o/

mas estando com esse 'filtro' no recebimento de Pix com base na previsão do txid, se o banco do pagador não mandar o txid, há a recusa. então a conciliação está garantida. o que não estaria garantido, com esse recurso ativo na conta, é a "cobertura" (não poder receber pagamentos desses bancos problemáticos), certo?

criar uma aplicação na GN, copiar seus tokens, abrir um ticket solicitando seu certificado .p12, no tickets informar o numero da sua conta da GN e os dois tokens criados tanto para desenvolvimento e como para produção 🙂 Depois , aguardar o recebimento da resposta da GN, .

Ou recebimento por QR Code estático não se enquadra no uso da API e não pago o recebimento?

<@!666644688320593931> , a tarifa de R$ 0,01 só é cobrada quando gerada uma cobrança pelo endpoint /cob (pagável apenas via QR Code dinâmico)? No caso de eu gerar um QR estático para receber pagamentos, pago apenas a tarifa de recebimento por cada Pix recebido, conforme os degraus de valores?

Pensando aqui, #reflexoes, a grande vulnerabilidade para o usuario comum ao efetuar um envio utilizando "copia e cola" é se esta url seja interceptada, modificada com outra chave de recebimento e validada novamente como um novo pix, retornando uma nova url "copia e cola" modificada o seu destino de envio. Ai não tem como impedir, tem como saber quem recebeu, ai são outros 300.

> <@!656144788017381377> atualmente estão trabalhando na evolução der recebimento, há alguma perspectiva ou planos de também oferecer o pagamento via api?
<@!715273512688025630> Oi <@!715273512688025630> . Sim. Estamos trabalhando forte para disponibilizar envio de Pix via API. A expectativa é de termos novas informações e a disponibilização dessa funcionalidade nos próximos dias.

<@!656144788017381377> atualmente estão trabalhando na evolução der recebimento, há alguma perspectiva ou planos de também oferecer o pagamento via api?

> pelo que eu entendi na documentação Api PIX só tem recebimentos e não pagamentos
<@!778772807935983627> por isso escreví "recebimentos". Daqui a pouco a galera diz de forma concreta, se faz pagamentos 🙂

pelo que eu entendi na documentação Api PIX só tem recebimentos e não pagamentos

> <@!778772807935983627> O suporte dá apoio amanha as 8h, vendo a lógica da sua pergunta a transferencia de fundos é feita entre chaves e não é uma TED ou DOC entre os bancos, portanto voce pode sim fazer isso, basta ter os endereços de recebimentos (chaves). Valew.
<@!710205440956563536> Via Api PIX?

> Olá. Gostaria de saber se é possível transferir fundos da minha conta PJ na GerenciaNet para conta de terceiros em outro banco via Api PIX. Alguém pode me ajudar???
<@!778772807935983627> O suporte dá apoio amanha as 8h, vendo a lógica da sua pergunta a transferencia de fundos é feita entre chaves e não é uma TED ou DOC entre os bancos, portanto voce pode sim fazer isso, basta ter os endereços de recebimentos (chaves). Valew.