Termos mais procurados:
No caso da API Pix, a Efí segue (como deveriam todos os PSPs) a API Pix padrão do Banco Central publicada em https://github.com/bacen/pix-api/ . Então aplicar isso na API Pix não seria muito bom. Na de Cobranças não Pix, talvez.
Bom dia @edilsoncostafavero_33802 tudo certo?
Lamentamos que tenha tido uma experiência ruim com as cobranças via cartão!
Te acionei no privado para pegar mais informações e entender melhor o ocorrido, tudo bem?
No caso da API Cobranças você deve usar uma das seguintes URLs:
Produção: https://cobrancas.api.efipay.com.br
Homologação: https://cobrancas-h.api.efipay.com.br
Documentação: https://dev.efipay.com.br/docs/api-cobrancas/credenciais#rota-base
Bom dia pessoal, seria interessante adicionar na página de gestão de cobranças/boletos uma coluna com data de pagamento, ideal mesmo seria ter um botão/ícone para escolhermos as colunas visíveis. No meu caso, preciso saber quando o cliente pagou, e para isso preciso entrar em boleto por boleto ou então filtrar pela data de pagamento, se tiver a possibilidade de visualizar essa informação na grid, facilitaria muito o serviço. Grato e parabéns pelo novo layout. 🙂
Em: Gerenciar Cobranças > Carnê > Filtro Inadimplência > ao olhar o mês em atraso de um cliente, na parte de Histórico não mostra o histórico correto.
@everyone Boa tarde, comunidade!
Estamos sempre buscando por melhoria dos produtos e serviços! E para isso contamos com o apoio de vocês, respondendo uma rápida pesquisa a respeito das cobranças via cartão de crédito.
Topa fazer parte dessa transformação com a gente?
Para participar acesse o link a seguir:
https://forms.office.com/r/pmp17Z0W63
Voltamos em breve com novidades!
Agradecemos a observação! Levei seu questionamento ao conhecimento da equipe envolvida.
O departamento responsável pela experiência do cliente, levantou algumas sugestões de melhorias, que estão sendo analisadas, essa estava inclusa no estudo. Caso aconteça a aprovação e/ou alguma outra modificação, faremos a divulgação.
Alguns usuários fornecem acesso a usuários secundários, e por esse motivo, preferem o app desk ou portal web, para que possam emitir cobranças, realizar a gestão de inadimplentes, etc, sem se preocupar de disponibilizar ao usuário acesso por dispositivo próprio. Dessa forma, nem todos teriam acesso a todas ferramentas e ficariam limitados ao uso permitido pelo usuário principal.
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.
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.
...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.
tem PSP implementando isso muuuuuito mal.. e ainda tem as opções do tipo "lembrar recebedor" guardam os dados da conta na lista de recebedor e os clientes pagam por ali em vez de ler QR code (não se dão conta de que precisamos do txid para identificar as cobranças)
isso garante o tamanho mínimo de txid para cobranças e ao mesmo tempo garante que a cobrança não seja criada sem o número de pedido, pois 25 caracteres seria rejeitado pela API
Não sei até que ponto é preciso e disponível, mas achei uma API de feriados:
http://www.calendario.com.br/api_feriados_municipais_estaduais_nacionais.php
Para as cobranças com vencimento, uma infeliz necessidade...
