Termos mais procurados:
O sistema de pagamentos por cartão tem muito que melhorar, estou com pagamentos em analise a mais de 1 dia já, muitos clientes reclamando do tempo de analise e de todos os dados estarem corretos e ainda sim a compra ser reprovada. Infelizmente se isso não melhorar vou tem q usar apenas o pix da gn, gosto muito da plataforma mas realmente tá impossivel.
Antes de fazer tudo pela GN, eu usava 5 intermediadores de pagamentos diferentes, mais para dar opção para o pessoal, e nunca, nunca tinha visto cartão demorar..
Bom Dia, eu sou novo com relação a API de Pagamentos. Existe a possibilidade de verificar meu saldo atual atraves de alguma das API's da GerenciaNet ?
Então, Pessoal, o Pix é algo que veio para ficar. É nítido o crescente uso da modalidade, seja por Pessoa Física ou por Pessoa Jurídica, e na troca entre os dois. É muito animador tudo que está ocorrendo, e não aderir ao Pix é uma inocência gerencial.
Observamos que a funcionalidade de recusa de txids, desenhada dentro das variáveis do fluxo oficial do Pix, tem tido problemas devido a implementações precárias por parte de alguns PSP's, que estão tecnicamente aquém do que se espera das especificações do Bacen.
Em conversas internas, e diante de nossas responsabilidades, não seria justo, seja com a comunidade ou com o próprio ecossistema do Pix, deixarmos de ofertar possibilidades em decorrência de problemas básicos de aplicação/interpretação da documentação oficial do Bacen por outros PSP's.
Por isso, iremos liberar, ainda hoje, o recurso de recusa de Pix, PARA TODOS, cabendo a nós "puxarmos a orelha" dos outros PSPs e buscarmos que eles sejam tecnicamente mais assertivos sobre a correta implementação do Pix.
Com o apoio de vocês, seguimos fortes na nossa responsabilidade e nossa contribuição com a inovação de Meios de Pagamentos no Brasil.
O <@!326311059759693826> utiliza o endpoint e não estava conseguindo receber os pagamentos.
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.
O caso de uso eh alimentar o ERP com o movimento da conta... por exemplo, que um certo boleto foi pago, dando baixa no contas a pagar, registrando pagamentos a funcionários, etc.
Pegar o csv no site exige um humano.. eh o plano B, mas melhor seria automatizar isso no servidor.
Acho que por mês, resolve. Por período seria melhor.
Dependendo do caso, vai precisar tratar paginação.
Vcs conhecem o openbanking do Sicoob ?
Eles tem um entry-point que eh por mes:
/conta-corrente/extrato/{mes}/{ano}
Caros, alguma previsão de um endpoint que forneça o extrato da conta ?
Algo não somente relacionado a Pix, mas que venham também os pagamentos de boletos, docs, teds, etc...
API de Cobrança. Daria para conciliar recebimentos, não pagamentos. No caso de envio de Pix se você fizer por banco/conta/CPF já vai saber para quem foi, mas por Chave Pix não. E imagino que seja esse o problema.
as notificações de Pix recebido da GN estão trazendo a razão social dos PSPs pagadores em vez do nome comercial. ex: "boletobancario.com tecnologia de pagamentos ltda." em vez de "Juno"
<@!780500321994539068>
Sobre ser um endpoint diferente, é algo que traz um maior conforto até na hora de separar os casos de uso. O atual remete a transferências, o outro a pagamentos. Até pelo fato de, em uma transferência, ao enviar TxId, sabe-se lá se outro PSP vai recusar por existir (coincidentemente) uma cobrança lá com o mesmo identificador...
Sobre o acervo de assinaturas de JWT: perfeito, não teriam como validar
Bom dia <@!689429679115075610>, atualmente já temos em nossa API a funcionalidade de split de pagamentos que é o nosso Marketplace(https://dev.gerencianet.com.br/docs/marketplace-introducao) . Inclusive com um exemplo para testes https://dev.gerencianet.com.br/docs/exemplo-integracao-marketplace. Qualquer dúvida você pode mandar no <#🛒marketplace>
o que vai totalmente na contramão da determinação do BACEN, diga-se de passagem, pois estão oferecendo isso por uma API proprietária (o PagHiper tá passando pro Itaú o txid e o valor para eles registrarem isso do lado deles, a fim de que possam rejeitar pagamentos cujo valor divergir do esperado para aquele txid)
Pessoal, gostaria de opiniões e sugestões em cima desse desenho de endpoint:
PUT /config
Objetivo: permitir que o integrador controle alguns comportamentos. Por hora: receber ou não webhooks, receber ou não a tarifa cobrada como atributo na notificação do webhook, setar uma regex que será considerada na validação do txid.
<@!781134406680838216> eu não sei desde quando a confirmação de identidade por sms está ativa, mas ultimamente nas últimas 3 vezes que tentei entrar na conta da empresa foi pedido um código enviado via sms. Gostaria de sugerir que essa opção de autentificação seja opcional pois as vezes a pessoa que está como dispositivo com o chip SIM não está perto, ou faz parte até de outro setor. Me vem a dúvida, como atendentes que precisam verificar as vezes comprovantes irão poder acessar? Achei muito improdutivo. No Pagseguro havia o mesmo problema, e dificultou bastante o time de atendimento a resolver problemas relacionados a pagamentos.
Melhorando a pergunta:
Pessoal, existe alguma doc para mostrar qual a melhor maneira de gerir as requisições para pagamento de forma que o cliente sinta fluidez na hora de pagar via cartão de crédito?
Se não houver, conseguem me ajudar? Porque ta bem difícil usar o gerenciaNet de maneira fluida para fazer pagamentos via cartão. Fica muitas pontas soltas.
Um comentário disso <@!775350441965649951> é que a recusa de pagamentos duplicados não pode depender do payload. Ela precisa ser feita na ligação com o SPI/PIG.
"a)Fase 1 – até 01/02/2021: Canais de atendimento, produtos e serviços mais relevantes, como contas de depósito à vista e operações de crédito;
b)Fase 2 – até 15/07/2021: Cadastros e transações de clientes relativas aos produtos e serviços da fase 1;
c)Fase 3 – até 30/08/2021: Serviços de iniciação de transação de pagamentos e encaminhamento de proposta de operação de crédito;
d)Fase 4 – até 15/12/2021: Outros produtos, serviços e transações de clientes, como operações de câmbio, investimentos, seguros e contas-salário."
Eu tenho impressão que na fase 1 tem só a tarifa máxima mesmo. Mas um possível pedido seria seguir o mesmo layout do OpenBanking de tarifas públicas disponível via interface autenticada.
