Termos mais procurados:
Boa tarde <@!305835973474910208> ! A url de notificação você define de acordo com o seu sistema, não temos um padrão definido. No seu caso, você inseriu o parâmetro codempresa, caso tenha necessidade desse segundo parâmetro, pode inserir mas não é obrigatório. E essa url deve ser cadastrada em seu sistema, para que as cobranças sejam emitidas com essa url.
<@!747457595060650014> tem como explicar melhor o seu cenário para que possamos pensar em uma solução? A recomendação seria você ter txid único por cobrança, pois, são cobranças diferentes e o txid serve como um identificador.
eu já consegui cancelar transação com uso de cartão. não sei se foi liberalidade do emissor, mas cancelou. cenário: atendente do guichê do motel apresentou a maquineta, coloquei o cartão e digitei a senha, ela puxou a maquineta pra dentro da cabine (com meu cartão inserido) e depois apresentou outra maquineta de novo dizendo que deu falha na primeira maquineta. não recebi SMS avisando a transação, então confiei e acabei pagando a 2x, numa maquinetas diferente. chegou na fatura as 2 cobranças, de empresas diferentes, mesmo valor. liguei no emissor e reclamei, em uns 3 dias cancelaram uma das transações.
Exatamente, atualmente já é assim, se o txid não existir entre as cobranças, já é recusado.
É por aí mesmo. Pensei em algo sobre txid incompatível com dinâmico(<=25) mas se o txid já não existir entre as cobranças ativas, já vai ser recusado. Então acho que é mais simples não entrar nesse mérito.
Estava criando cobranças no ambiente de homologação, para criar no ambiente de produção preciso trocar apenas a url base, client id e client secrete ou o certificado também?
Pra simplificar seu entendimento das formas de cobrar com Pix, uma associação que você pode fazer com meios de cobrança/pagamento que você (provavelmente) já conhece, é a seguinte:
- QR Estático está mais próximo de um boleto não-registrado;
- QR Dinâmico de cobrança imediata está mais próximo de um boleto registrado;
- QR Dinâmico de cobrança com vencimento está mais próximo de uma duplicata ou de uma "folha" (um boleto registrado individual) de um carnê de cobranças (apesar de poder ser emitido apenas 1 cobrança com vencimento, não necessariamente uma sequência).
E o pagador, vai copiar e colar o código de pagamento (ou escanear o QR Code), em vez de digitar a linha digitável do boleto (ou escanear o código de barras).
Que eu ia adicionar o webhooks quando fosse adicionar cobranças sem fazer pela imediata. Mas posso adicionar desde o inicio
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.
Você pode gerar cobranças com uma url de notificação e cancelar ou marcar como pago, assim enviaremos a notificação para o seu sistema informando sobe a mudança do status.
Boa tarde <@!814577988883972097>, você pode explorar os outros endpoints agora, mas já que você está criando as cobranças com PUT: /v2/cob/{txid}, você pode pegar o id do location retornado após a geração e consumir o GET /v2/loc/:id/qrcode e assim você vai ter o copia e cola e a imagem do Qrcode em base64, portanto, já consegue efetuar o pagamento.
Boa tarde,
Estou com dificuldade para entender o fluxo correto para receber pagamentos via API-PIX.
Por exemplo, já crio cobranças (PUT: /v2/cob/{txid}) e consulto cobranças (GET: /v2/cob/{txid}).
Quais os próximos passos?
Boa tarde <@!389091738007896064>, esta falha ocorre quando o payment_token gerado não é válido, geralmente a falha está associada ao uso de script em um ambiente diferente do utilizado na emissão.
Exemplo: Utilizar o script de desenvolvimento em cobranças de cartão no ambiente de produção.
...ao consultar as cobranças, o serviço não aceita os nanoseconds, e ainda passa a retornar a data de criação com os nanoseconds zerado. Como farei a consulta das cobranças me baseando nas datas exatas de criação da cobrança para enviar os parâmetros obrigatório "inicio" e "fim", temo que cobranças fiquem fora do intervalo e cause problemas para as integrações.
Imagino que o dilema da GN seja o de autorização do BACEN para cobrança pelo serviço, já que o envio de Pix não é tão claramente uma atividade comercial. Emissão de cobranças, mesmo por PF, é claramente atividade comercial então eles podem aplicar tarifas.
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.
Boa tarde!
Temos sim a opção de split de pagamentos para cobranças de cartão ou boleto. O que define o split/divisão/repasse é o parâmetro marketplace, nele você pode passar um array com o payee_code (identificador da conta Gerencianet) e o percentage (porcentagem de repasse)
Segue aqui a documentação completa: https://dev.gerencianet.com.br/docs/marketplace-introducao
Caso tenha dúvidas, estaremos á disposição para ajudá-lo! 😉
Boa tarde <@!812020877792509963>, caso o Pix enviado seja pelo endpoint de Envio de Pix POST /v2/pix então o webhook é acionado no envio. Agora para os recebidos, somente as cobranças geradas com a sua chave(cadastrada no webhook) e que contenham um txid serão notificadas, assim como as devoluções associadas as mesmas.
tem como consultar as cobranças tbm
<@!715273512688025630> você está utilizando os endpoints de consultar as cobranças? Se sim é retornado CONCLUIDA quando a cobrança teve o seu pagamento confirmado. Outros possíveis status são: "ATIVA", "REMOVIDA_PELO_USUARIO_RECEBEDOR" e "REMOVIDA_PELO_PSP"
