Termos mais procurados:
Olá <@!418820500844707840> ! Boa noite. 😃 Para criação de cobranças Pix, o campo valor é obrigatório. Você pode visualizar a descrição deste e de outros campos na nossa documentação: https://dev.gerencianet.com.br/docs/api-pix-endpoints#section-criar-cobran-a-imediata-sem-txid-
Boa tarde, <@!477481308743008257>. Colocamos um fluxograma com alguns meios de consultar as cobranças ou Pix recebidos, segue o link https://dev.gerencianet.com.br/docs/api-pix-fluxogramas#fluxograma-para-consulta-de-pix
Uma duvida, para eu criar uma cobranças eu tenho que enviar esse campo ""chave" => "", // Chave pix da conta Gerencianet do recebedor"
Essa chave eu crio pela propriedade:
$api = new Gerencianet($options);
$pix = $api->pixCreateEvp([], []);
correto?
Sim, as cobranças realmente não acionam o webhook em homologação. Mas, na hora de enviar a requisição, a API recebe a requisição de teste da gerencianet.
Eu fiz um teste com asp.net mvc API...
Fiz um mini app só para criar um arquivo txt com o conteúdo de requisição da gerencianet. Configurei devidamente meu servidor do IIS devidamente para receber requisição com autenticação mútua, só pra fazer esse teste. Aí quando fiz o teste de webhook em homologação, foi gerado um json de teste, ao que eu pôde espionar...
Oi <@!850502535859929110> tudo bem? 😄
Para realizar a integração com os serviços da Gerencianet, se você ainda não tem uma conta, faça seu cadastro, ele será sua identificação e te dará acesso as chaves de utilização da API. Com sua conta criada, você vai precisar das suas credenciais Client_ID e Client_Secret para realizar a integração.
Para visualizar suas credenciais basta fazer login em sua conta Gerencianet ( https://gerencianet.com.br/#login )
Acesse o menu API > Minhas Aplicações, e crie a sua aplicação, como mostra o link: https://gerencianet.com.br/artigo/como-criar-uma-nova-aplicacao-para-usar-a-api-pix/
Você visualizará então as credenciais Client_Id e Client_Secret de Produção e Desenvolvimento.
Vale lembrar que as chaves de Desenvolvimento são utilizadas para simular cobranças e efetuar testes na plataforma. Já as chaves de Produção devem ser utilizadas quando for emitir cobranças reais.
Abaixo seguem alguns links úteis para consulta:
- Temos uma tabela resumindo os tipos de integrações e formas de uso disponíveis, acesse e escolha a que melhor atende suas necessidades. https://dev.gerencianet.com.br/docs/tipos-integracoes
- Possuímos um curso EAD que poderá lhe ajudar a ter uma visão geral do funcionamento da nossa API de boletos, cartão, marketplace e assinaturas. https://www.udemy.com/course/eadgerencianet/
- Para você implementar os serviços de pagamento desejados, em nossa documentação temos exemplos e explicação da utilização em diversas linguagens. https://dev.gerencianet.com.br/docs/gerar-boleto-bancario
Além disso, nosso GitHub tem também uma SDK em PHP com exemplos prontos para facilitar sua integração. https://github.com/gerencianet/gn-api-sdk-php
Quaisquer dúvidas sinta-se à vontade para entrar em contato conosco!
Olá <@!291722988645122049> ! Boa noite. Atualmente não é possível simular o pagamento de um QrCode em homologação. Entretanto, você pode gerar cobranças de R$0,01 em produção e efetuar o pagamento. Não precisa se preocupar, as transações originadas pela API Pix serão gratuitas até o dia 31/07/2021. 😀
É necessário passar a chave a qual o webhook estará associado!
PUT /v2/webhook/:chave
Também vale lembrar, que atualmente não é possível simular o pagamento de um QrCode.
Entretanto, você pode gerar cobranças de R$0,01 em produção e efetuar o pagamento para acionar o webhook.
Não precisa se procupar, as transações originadas pela API Pix serão gratuitas até o dia 31/07/2021.
Oi <@!839243604266319872> tudo bem? 😄
Para realizar a integração você vai precisar das suas credenciais Client_ID e Client_Secret.
Para visualizar suas credenciais basta fazer login em sua conta Gerencianet ( https://gerencianet.com.br/#login )
Acesse o menu API > Minhas Aplicações, selecione então a aplicação desejada.
Você visualizará as credenciais Client_Id e Client_Secret de Produção e Desenvolvimento.
Vale lembrar que as chaves de Desenvolvimento são utilizadas para simular cobranças e efetuar testes na plataforma. Já as chaves de Produção devem ser utilizadas quando for emitir cobranças reais.
Abaixo seguem alguns links úteis para consulta:
Temos uma tabela resumindo os tipos de integrações e formas de uso disponíveis, acesse e escolha a que melhor atende suas necessidades. https://dev.gerencianet.com.br/docs/tipos-integracoes
Possuímos um curso online que poderá lhe ajudar a ter uma visão geral do funcionamento da nossa API de boletos, cartão, marketplace e assinaturas. https://www.udemy.com/course/eadgerencianet/
Para você implementar os serviços de pagamento desejados, em nossa documentação temos exemplos e explicação da utilização em diversas linguagens!
https://dev.gerencianet.com.br/docs/gerar-boleto-bancario
Além disso, nosso GitHub temos também algumas SDKs com exemplos prontos para facilitar sua integração. https://github.com/gerencianet/
Boa tarde, <@!517045334220734581>.
Até o momento, as informações do PIX como histórico de requisições e demais, não estão disponíveis no painel da Gerencianet como é para as demais cobranças.
É possível verificar as transações Pix através do Extrato Financeiro, ou através de consulta na API, como por exemplo, na rota /v2/cob (Consultar lista de cobranças) ou /v2/pix (Consultar Pix recebidos)
Olá <@!818197250840199198>. Bom dia!
Na SDK de PHP você encontra as funcionalidades para utilização do Marketplace e demais demais serviços da Gerencianet.
Obs: A Gerencianet disponibiliza cobranças Pix, mas até o momento no Marketplace é possível cobranças somente via boleto e cartão de crédito.
1 (✅ ) Autenticar na API
2 (❌) Cadastrar devedor -> Não há exemplo de como cadastrar o cliente final na SDK. Este cadastro do devedor deve ser realizado em um banco de dados em seu sistema. A partir deste cadastro, passar as informações para a emissão.
3 (✅) Criar transação de cobrança imediata
4 (✅) Gerar Qrcode dinâmico e código copia e cola de pagamento -> No ambiente Pix é possível. Então nesta compra que o cliente utilizou o Pix, você pode estruturar para que haja o repasse/envio de pix para o vendedor.
5 (✅) Monitorar o pagamento da cobrança -> (webhook: https://dev.gerencianet.com.br/docs/api-pix#section-webhook" class="link-msg">https://dev.gerencianet.com.br/docs/api-pix#section-webhook)
6 (✅) Setar transação de cobrança imediata como paga -> Com o monitoramento da cobrança, é possível setar os status das transações como paga automaticamente, e há opção também de "Marcar como Pago" manualmente uma cobrança via boleto. Em relação à cobrança Pix, você pode utilizar o PATCH /v2/cob para setar o status para "REMOVIDA_PELO_USUARIO_RECEBEDOR"
7 (✅) Enviar pix para o vendedor (O Vendedor poderá configurar se recebe de forma automática ou se faz saques esporádicos) em processo de autoriação. -> Com o Marketplace, cada vendedor deve possuir uma conta Gerencianet, então, você pode informar através da integração como deverá ser feita a divisão do valor recebido entre diferentes contas dos vendedores, de forma automática.
8 (✅) Criar transação de devolução de Pix para o devedor caso haja um desacordo comercial
Veja também em nossa documentação, para encontrar estes endpoints e demais detalhes: https://dev.gerencianet.com.br/docs/api-pix
Bom dia <@!812297338605273098>, respondendo ao questionamento que você fez no 2, sim é possível fazer o envio de Pix de sua conta Gerencianet para uma outra chave/conta via API. Para isto temos o endpoint POST /v2/pix (https://dev.gerencianet.com.br/docs#section-requisitar-envio-de-pix-) que permite o envio para uma outra conta via chave ou dados bancários.
Além disso via API você pode adicionar diversos recursos em seu site como cobranças estáticas e dinâmicas e fazer o controle via endpoints da API. Outro recurso interessante é o webhook que automatiza o seu sistema com os Pix recebidos, sem a necessidade de ter que construir uma rotina que fica realizando consultas na API. Você encontra tudo isso e mais na documentação e caso tenha dúvidas pode mandar aqui canal que te auxiliamos.
Isto <@!558328193438973972>. Só podem ser pagos Pix que forem gerados em produção
Sugerimos utilizar em produção com cobranças de baixo valor. Até o dia 30/04/2021 não haverá cobranças pelo consumo via API
<@!375094642238029824> , a API da GN só gera cobranças (que vc representa com qr dinâmicos para o devedor escanear/copiar e pagar). QR codes estáticos são gerados no aplicativo do banco do recebedor ou por você, de forma autônoma (sem API alguma).
e só dá pra gerar cobranças para chaves na sua conta, mas QR codes estáticos (independentes de API) vc pode gerar pra qualquer conta
Há uma anomalia no endpoint /v2/pix para o método "Consultar Pix recebidos".
Estou filtrando algumas cobranças para analisar os pagamentos e está acontencendo o seguinte:
Ao filtrar os PIX recebidos em um determinado período, a API informou um total de 16 pix recebidos.
Os status das cobranças da API-Pix são os mesmo definidos pelo BACEN. Os status da API para boleto e cartão são diferentes e também estão definidos em nossa documentação.
a API de geração e de baixa de cobranças Pix, existe. e programaticamente, dá pra "baixar" ou cancelar boletos pela API, também. então de alguma maneira, dá. mas não como uma solução pronta. tem que desenvolver em cima das duas API e fazer funcionar como você quer
Boa noite. Quero propor uma mudança no Art. 1º da Lei 7.089/1983 (http://www.planalto.gov.br/ccivil_03/LEIS/L7089.htm). Ele determina que títulos com vencimento em sábados, domingos e feriados podem ser pagos no primeiro dia [útil] subsequente sem juros de mora.
Os PSPs (prestadores de serviços de pagamento) que estão implantando o recurso de cobranças Pix (com vencimento, regras de multa/juros, etc, similar a um boleto registrado) estão com uma dificuldade absurda de implantar isso por causa dessa lei.
A minha proposta é que a redação da lei seja atualizada para o que ela efetivamente propunha em 1983: que os títulos possam ser pagos no primeiro dia útil subsequente ao vencimento quando da impossibilidade de fazê-lo por indisponibilidade do meio de pagamento (ex: bancos simplesmente não podem acatar o pagamento de boletos aos fds/feriados pois não há processo de compensação nestes dias). O Pix é diferente e funciona 24/7/365.
Se a lei for alterada, quem gerar cobranças com possibilidade de pagamento por Pix + boleto, se o pagamento cair num feriado, o boleto continuaria pagável no dia útil subsequente sem juros. O Pix, no entanto, está disponível nos feriados normalmente, então se a cobrança for paga especificamente por Pix no dia útil subsequente ao vencimento, seria cobrado 1 dia de juros normalmente (em outras palavras: o conceito de dia útil/não útil deixaria de valer para o cálculo de juros no Pix - e qualquer outro meio de pagamento 24//7/365).
Pode parecer um retrocesso para o consumidor, mas simplesmente não existe um banco de dados com os feriados municipais de todo o país disponível de forma pública. Somente fontes não oficiais, pagas, que dificultam enormemente a gestão das cobranças e o correto acolhimento dos pagamentos por parte dos PSPs que trabalham com o Pix e encarecerão o uso do Pix para os PSPs e para as empresas, que repassarão esse custo para o consumidor. Detalhes: https://github.com/bacen/pix-api/issues/225 . Obrigado!
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)
