Termos mais procurados:
<@!781134406680838216> Segundo o Matemático Oswald de Sá, em breve teremos no painel nosso da GN o envio do webhook para teste em modo homologação e pagamento de cobranças 🙂 Um passarinho disse a ele, ele fez os calculos, aprovando 🙂
@Efí Temos alguma informação sobre a mudança de status de cobranças PIX com mais de 5 dias criadas para "RECEBIDA" sem ter sido paga ?
Se você for fazer via API pode usar o Consultar cobrança ou Consultar cobranças recebidos
Exatamente! Você vai precisar gerar as cobranças via API para realizar o consumo dos endpoints que mencionei.
Só um preciosismo: as cobranças imediatas (escopo cob) não tem vencimento, mas sim expiração. Apenas as do escopo cobv (quando suportado) terão vencimento.
Mas falando do problema específico, o location mudou quando você alterou a expiração ?
Bom dia <@!498292925352902657>! As consultas na API são feitas pela cobrança e não pelo cliente. No entanto, você pode armazenar em um banco de dados as cobranças e associa-la ao nome do cliente. Você pode utilizar o endpoint GET /v1/charge/:id ou a forma mais utilizada, a nossa url de notificações
Mais um dia de estudos, testando criações de tokens, cobranças , com a ajuda da GN e do pessoal aqui "Fizemos Progresso". Amanhã continua a mini-série "A SAGA DO PIX" capítulo teste de mTLS 🙂 Otimo dia a todos.
mas esse subdomínio do mTLS deixar de funcionar conforme o planejado, te complica. vc gera cobranças mas não recebe os webhooks.
Consegui fazer a implementação da API no meu sistema, mas enquanto não for resolvido esta lista de bancos não vou publicar versão com a opção de pagamento via PIX. Pagamentos via QR Code pelo Banco Inter não dão baixa nas cobranças, pois na GN o pagamento aparece como pagamento via chave Pix e não via Qr Code
Neste link https://dev.gerencianet.com.br/docs/exemplo-integracao-cartao você encontra um exemplo que temos de cobranças com cartão de crédito. Você pode analisar como esta sendo chamado esse script para desenvolver em sua linguagem.
Para gerar cobranças do tipo cartão de crédito é necessário a obtenção do payment_token. EM nossa documentação você encontra um sessão explicando como você gerar esse paymet_token
Não , com o token novo, voce tem 1 hora para gerar cobranças novas neste tempo.
Claro <@!728426952595210293>. Ele pode seguir como base a documentação do nosso pluing WordPress (WooCommerce) utilizada para cobranças de boleto e cartão de crédito. https://dev.gerencianet.com.br/docs/wordpress-woocommerce
agradeço muito Guilherme, preciso validar isso para poder gerar cobranças em produção 🙂
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)
Hoje antes de dormi posso escrever no meu diário "Fizemos Progresso". Finalmente, e com muita paciência, persistência e estudo, consegui criar o abençoado do certificado .pem em produção (Alô Produção), para criar o token de geração de cobranças, eu não uso linux aqui na máquina que estou. Mais hoje tirei o dia para resolver isso, procurei muito e encontrei uma solução for windows do openssl = https://slproweb.com/products/Win32OpenSSL.html usei este instalador = https://slproweb.com/download/Win64OpenSSL_Light-1_1_1h.exe e usei este comando openssl pkcs12 -in certificado.p12 -out certificado.pem -nodes
Finalmente gerou e funcionou normalmente o certificado de produção 🙂
ainda é possível usar um endereço de callback "externo" ao ambiente que lança as cobranças, mas sendo mTLS é mais seguro do que fazer o PSP enviar requests para qualquer destino desconhecido. o mTLS poderia não se justificar nos casos em que a iniciação é do PSP, mas na iniciação externa fica mais garantido que é intencional o uso de determinada URL para callback
estava refletindo e entendi porque os locations são abertos. para permitir a existência das soluções de "iniciação pix" por parte de empresas que não são instituição de pagamento ou instituição financeira. e aí até faz algum sentido o callback ser obrigatoriamente por um canal mTLS. dá mais controle ao processo, impedindo que eles sejam direcionados a destinos "selvagens" que não foram pre-acordados com o PSP recebedor quando a iniciação também não for via cobranças armazenadas no próprio PSP
Com o modo dev. eu consigo criar cobranças normalmente , fiz a consulta deste QR acima e retornou: {
"parametros": {
"inicio": "2020-11-28T16:01:35.000Z",
"fim": "2020-11-29T16:01:35.000Z",
"paginacao": {
"paginaAtual": 0,
"itensPorPagina": 100,
"quantidadeDePaginas": 1,
"quantidadeTotalDeItens": 8
}
},
"cobs": [
{
"calendario": {
"criacao": "2020-11-29T11:43:03.000Z",
"expiracao": 200000
},
"txid": "GSEH5xD2SF3k1KN5KoqXcQMlQxorderid",
"revisao": 0,
"loc": {
"id": "29",
"location": "https://qrcodes-pix-h.gerencianet.com.br/v2/3a3fa476e6824db58dd9a3afc1d974e7",
"tipoCob": "cob",
"criacao": "2020-11-29T11:43:03.000Z"
},
"location": "https://qrcodes-pix-h.gerencianet.com.br/v2/3a3fa476e6824db58dd9a3afc1d974e7",
"status": "ATIVA",
"devedor": {
"cpf": "12345678909",
"nome": "Francisco da Silva"
},
"valor": {
"original": "124.45"
},
"chave": "fc9a4366ff3d4964b5dbc6c91a8722d18",
"solicitacaoPagador": " Renato Frota Pix ae."
},
na verdade a exigência de mTLS me pareceu interessante para o fluxo de criação de cobrança. fica bem mais restritivo e difícil alguém criar as cobranças por você, mesmo que sua aplicação tenha uma brecha que permita a obtenção de suas credenciais, não tendo o certificado em si (que normalmente só o acesso root poderia dar)
