Termos mais procurados:
Mas mesmo que o estabelecimento já tenha uma conta PJ e uma chave Pix em outra instituição, ele pode ter outra conta no mesmo CNPJ na Gerencianet, e você pode (por exemplo) criar uma chave aleatória para os QR-Code dinâmicos. A chave aleatória inclusive, por não ser portável, é a mais indicada para QR-Code dinâmico.
Bom dia! Implementei no meu sistema o pagamento em terminal de vendas pelo QRCODE dinamico do PIX. Sou desenvolvedor e tenho uma carteira de clientes, portanto, cada cliente deverá abrir uma conta na gerencianet para fazer essas movimentações. Meus clientes se demonstraram super interessados, porém me perguntam sobre taxas. Eu estou indicando para que eles abram uma conta na pessoa física. Gostaria de saber o que responder com mais exatidão aos meus clientes.
Bom dia Existe alguma opcao de bloquear o recebimento via chave pix e so aceitar via qr code?
bom dia pessoal, tudo bem?
vc sabe me dizer se com qrcode dinamico a geracao de txid do meu lado ela deve ser única por chave pix emissora ou unica dentro da minha conta como um todo (todas as chaves)?
Boa tarde, tenho uma duvida em relação a taxa de recebimento do pix, quando eu gero um qrcode e faço um pagamento uma taxa e cobrada quando recebo, gostaria de saber exatamente quanto de taxa e cobrado por tranferencia
Pessoal o Pix caiu? Estamos recebendo pagamentos via qr code, porém não está sendo exibido nem no app nem no site a transação, e não está sendo enviado a notificação da compra para o nosso servidor.
Boa tarde, fiz a implantação da API PIX PHP e está retornando tudo certinho, porém percebo que em em produção depois de 3 requisições...retorna um erro e o QRCODE não é gerado... como se tivesse uma limitação para o CPF
Tem transferência, mas não pagamento. A diferença é que não tem como mandar txid ou baixar QR-Code.
https://dev.gerencianet.com.br/docs/api-pix-endpoints#section-requisitar-envio-de-pix
Detalhe que esse endpoint não é por padrão habilitado, você precisa combinar com o @Relacionamento .
Um location é uma URL de onde pode ser baixado um pacote contendo as informações do QR-Code dinâmico. A separação existe para casos de uso onde você queira reaproveitar o mesmo location para mais de uma cobrança, tipicamente em varejo físico. Mas em e-commerce é mais usual usar locations diferentes para cobranças diferentes.
Ou você faz essa requisição para o método do SDK, ou você mesmo usa uma biblioteca EMV e do location gera o QR-Code. De qualquer forma precisa ter esse passo... mas você pode encapsular num método único seu.
Estou usando o SDK da GN para node (gn-api-sdk-node) e já estou chamando o método pixCreateImmediateCharge para criar a cobrança. Posteriormente eu preciso chamar o método pixGenerateQRCode para gerar o QR Code ou eu consigo gerar ele de alguma forma com a resposta do pixCreateImmediateCharge e evitar mais uma requisição?
Sim, esse endpoint você utiliza para alterar uma cobrança ja existente. Então o pix copia e cola e a imagem do qrcode permanecem os mesmos.
se eu só aumentar o tempo de expiração e salvar o pix/copia e cola e a imagem do qr code no banco do cliente ele poderia reimprimir isso na tela ? e pagar normalmente ?
dessa forma funcionaria ? ou estou enganado ?
Bom dia <@!671763456487325717> agradeço o rápido retorno, nem se eu salvar os dados do location no BD do cliente para ele poder realizar uma nova emissão do qrcode por esse location ? nem assim seria possivel, para ele fazer uma reeimpressão do qrcode e pix para pagamento ?
E o POST em /pix também não tem opção de especificar txid, então também não serve para pagar QR-COde, por exemplo, só para transferência.
<@!811617017449676821> <@!800721458875727872> <@!826080016981819402> <@!671762828046106646>
Bom dia! Existe alguma previsão de vocês para adicionar algum mecanismo que facilite os testes em ambiente de homologação? Algo simples, por exemplo:
- Crio uma transação PIX através da minha aplicação
- Vou no painel de vocês, marco a transação como paga
- Isso dispararia o webhook (que nesse caso, por ser homolog, não precisaria de certificado, etc, podemos usar ngrok ou similar para criar um túnel para o localhost) e também marcaria a transação com o status "CONCLUIDA" caso eu queira consultar pela API
Acredito que não teria a necessidade de simular o pagamento via QRCode de início, algo como o fluxo acima resolveria.
Da forma que está hoje, tendo que testar em produção, complica bastante o ciclo de desenvolvimento quando utilizamos a API de vocês, e somos obrigados à ficar fazendo pagamentos reais para testar.
Grato pela atenção!
OBS: Não querendo ser rude, mas estou utilizando API de concorrentes de vocês que, apesar de terem implementado o PIX depois, possuem um ambiente sandbox muito mais avançado e que facilita o desenvolvimento sem a necessidade de ficar fazendo pagamentos reais à todo momento.
Bom dia <@!257617133595262977> , não é possível ler ou pagar os QRCODEs gerados em homologação. Para testar o pagamento você pode gerar um QRCODE de R$0,1 em produção.
