Termos mais procurados:
Bom dia <@!313668091114553346>, você pode associar a sua chave pix ao webhook e desta forma toda vez que enviarmos a notificação informando do pagamento você realiza o redirect, com um
É possível também criar novas chaves Pix do tipo aleatória e excluí-las também.
https://dev.gerencianet.com.br/docs#section-criar-chave-evp
https://dev.gerencianet.com.br/docs#section-remover-chave-evp
o cliente vai precisar criar a chave pix pelo celular
Bom dia, tenho uma sugestão de disponibilizarem a lista de chaves PIX na Web...
só pra ficar claro: a "chave" que aparece no retorno da consulta é uma chave Pix que aponta para a sua conta transacional na Gerencianet, mas ela é reutilizável (não representa uma cobrança específica). por isso só haverá baixa na cobrança se vc pagar, especificamente, a cobrança (com o qr code / pix copia e cola que a representa)
Você está fazendo a requisição em ambiente de produção ou homologação? Porque o endpoint de gerar evp(chave pix) só funciona em produção.
> elseif, txid é nulo, GN consulta a configuração da conta do EC recebedor (ou da chave) se deve acatar Pix com txid nulo.
Estou gostando disso.
> Ah, e sempre com a exceção - nem configurável - de que se a titularidade de origem é a mesma do recebedor, a transação é aprovada.
Perfeito!
Pensando na implementação lógica, o fluxo seria mais ou menos esse:
-> se o txid é dinâmico {26,35} a GN valida com base na chave + txid se existe cobrança (talvez isso até já esteja implementado hoje).
-> elseif, txid é nulo, GN consulta a configuração da conta do EC recebedor (ou da chave) se deve acatar Pix com txid nulo.
se a GN tiver como diferenciar quando o Pix foi enviado via "manual" (informando dados bancários) ou com uso da chave DICT, o ideal seria a configuração de aceitar/não os recebimentos com txid nulo ser por chave + uma configuração extra para bloquear todos os recebimentos manuais (que nunca tem txid associado).
se não tiver como diferenciar, a configuração poderia ser global (por conta transacional), com opção de sobrescrever a escolha para chaves individuais (assim poderia bloquear recebimentos com txid nulo para toda a conta [que seria o comportamento padrão] e autorizar o txid nulo em uma chave particular).
e, futuramente:
-> else (txid é estático), valida conforme as regras de aceite do EC (por regex match ou enviando o request de validação para webhookURL/txidmatch, como sugeri acima).
e esse "futuramente" eu não consigo nem ver uma demanda relevante. o importante são as outras funções.
É isso mesmo. Eu só descreveria de outra forma pq sem txid e sem a informação do método de iniciação de pagamento, saber se era um QR dinâmico, um QR estático ou um Pix via chave é impossível... ao menos até que isso venha na PACS.008 como está planejando o BACEN. Acho que só o Pix manual vem diferente.
Importantes essas considerações de vocês sobre o que trará mais valor no momento.
Vejam se estamos falando disso:
- QR Dinâmico: valida-se se possui cobrança atrelada e o valor está correto
- QR Estático: permite ao EC aceitar ou não TxId nulo
- Pix via Chave: permite ao EC recusar ou não
- Pix Manual: permite ao EC recusar ou não
Em um segundo passo, para QR Code Estático:
- Validações de padrão do TxId
<@!440035527127990273> <@!780500321994539068>
A sua pergunta me fez crer que você entendeu "cobrança imediata" como uma operação que vai retirar dinheiro da conta do pagador. O Pix não funciona assim. "Cobrança imediata" é apenas uma forma de se referir a uma cobrança que não tem uma data de vencimento estipulada. É uma cobrança que, normalmente, faz parte de um processo de transação comercial (compra em um e-commerce, por exemplo) onde o potencial pagador é um devedor mas não tem, necessariamente, compromisso de pagar.
Quando você gera a cobrança, você deve apresentar pro pagador um QR Code que representa a cobrança e o pagador vai ter que escanear o QR Code e te pagar, voluntariamente - não é feito um débito compulsório somente por que você criou a cobrança.
A chave Pix vinculada à uma cobrança é a sua (recebedor). Quem paga, está usando a conta transacional, não uma chave (o pagador nem precisa ter chave Pix para enviar uma transferência Pix ou pagar uma cobrança Pix).
bom dia. voltando à questão do regex para aceitar/não os recebimentos com base no txid. alguém da GN pode me esclarecer quais os cenários específicos onde vocês visualizaram uma necessidade de aceitação com base em regex? que eu me lembre, essa ideia apareceu como como uma evolução da necessidade de barrar recebimentos com txid vazio. porém:
- para recebimentos de cobranças (QR dinâmico) o txid precisa ser correspondente a uma cobrança existente na GN ou ela já poderia ser descartada (independente de qualquer crivo por parte do EC); e
- para recebimentos de QR estático, é perfeitamente compreensível que a GN não tenha ciência prévia dos txid dos recebimentos mas não vislumbro problemas maiores que exijam uma validação do txid com base em critérios definidos pelo EC (somente o problema conhecido de pagamentos entrando sem txid).
então, eu pergunto:
1. já foi implementada a possibilidade de bloqueio de recebimentos de Pix sem txid (seja a nível de chave Pix ou de conta transacional)?
2. se não foi, a evolução dessa funcionalidade para algo baseado em regex (ou outras regras) não está atrasando desnecessariamente a implantação da função de bloqueio de recebimento sem txid?
Lembrando que esse bloqueio é essencial para os EC que precisam de 100% de assertividade na conciliação automática.
Boa tarde <@!812297338605273098>! Você poderia utilizar o endpoint de envio de Pix, com ele você consegue verificar se a chave em que o Pix foi enviado existe ou não, pois, é retornado em nosso endpoint. Mas caso você se refira a consultar as chaves cadastradas no DICT, no momento não é possível, o Banco Central limitou aos PSPs consultas a serem feitas no DICT como se fossem fichas e por isto não tem como liberar um endpoint que permita um retorno de quais chaves estão cadastradas.
Boa tarde, <@!127179327447105537>.
Está correto. Este é o atributo é a chave Pix, a mesma cadastrada pelo aplicativo, que pode ser celular, e-mail, CPF e/ou chave aleatória
Bom dia Pessoal, eu abri um ticket relativo a geração de uma chave pix em produção. Não conseguimos gerar nem pela API e pelo App ta dando pau
uma chave pix?
Prepara já a chave pix pra receber que eu garanto
Boa tarde, estamos trabalhando em uma API e gostaria de saber se há alguma forma de gerar uma chave Pix para o ambiente de homologação. Geramos o certificado e uma nova aplicação com todas as permissões possiveis de Pix mas quando tentamos executar os serviços de /v2/gn/evp dá uma mensagem de erro dizendo : "insufficient_scope".
