Open eduoct opened 2 years ago
rubenskuhl
commented
2 years ago A melhor maneira é pedir para seu PSP recusar Pix sem txid e também Pix por dados bancário sem chave Pix. Alguns PSPs tem isso mas tem que pedir via canal de relacionamento; em outros, isso é passível de definição via API. Segue um extrato da doc de um PSP que permite essa definição via API: https://dev.gerencianet.com.br/docs/api-pix-endpoints#section-criar-modificar-configura-es-da-conta
eduoct
commented
2 years ago A melhor maneira é pedir para seu PSP recusar Pix sem txid e também Pix por dados bancário sem chave Pix. Alguns PSPs tem isso mas tem que pedir via canal de relacionamento; em outros, isso é passível de definição via API. Segue um extrato da doc de um PSP que permite essa definição via API: https://dev.gerencianet.com.br/docs/api-pix-endpoints#section-criar-modificar-configura-es-da-conta
É uma possibilidade, vou sugerir. Mas acho pouco provável do ponto de vista de negócio, isso é "recusar" dinheiro. Eu preferiria a ter o dinheiro na conta e ter problema de conciliação a recusar o pagamento. Por isso da automação da conciliação. Pensando do ponto de vista da automação, seria realizar as 3 milhões de consultas a cada 5min para verificar se houve pagamento? Existe outra forma?
rubenskuhl
commented
2 years ago A melhor maneira é pedir para seu PSP recusar Pix sem txid e também Pix por dados bancário sem chave Pix. Alguns PSPs tem isso mas tem que pedir via canal de relacionamento; em outros, isso é passível de definição via API. Segue um extrato da doc de um PSP que permite essa definição via API: https://dev.gerencianet.com.br/docs/api-pix-endpoints#section-criar-modificar-configura-es-da-conta
É uma possibilidade, vou sugerir. Mas acho pouco provável do ponto de vista de negócio, isso é "recusar" dinheiro. Eu preferiria a ter o dinheiro na conta e ter problema de conciliação a recusar o pagamento. Por isso da automação da conciliação. Pensando do ponto de vista da automação, seria realizar as 3 milhões de consultas a cada 5min para verificar se houve pagamento? Existe outra forma?
Não é recusar dinheiro pq sendo alertado de que a transação não completou, o usuário vai tratar de seguir o caminho correto (pagar pelo QR-Code). E o custo de tratamento manual dessas transações pode ser significativo, superando a margem de contribuição do que foi vendido.
Nós temos 2.5 milhões e não 10 milhões de clientes, e evitar esse problema era inclusive requisito do lançamento, não ativamos recebimento via Pix antes de ter esse controle disponível e testado.
Mas a outra forma seria incluir de 0 a 99 centavos de desconto em cada Pix, caso seus preços sejam múltiplos inteiros de Reais... assim, de 3 milhões de consultas cai para 30 mil, pois se o Pix é de R$30,42, você já tem uma pista de quais clientes podem ser. Só que são 30 mil consultas para cada Pix recebido sem txid...
eduoct
commented
2 years ago Não é recusar dinheiro pq sendo alertado de que a transação não completou, o usuário vai tratar de seguir o caminho correto (pagar pelo QR-Code). E o custo de tratamento manual dessas transações pode ser significativo, superando a margem de contribuição do que foi vendido.
Correto. Por isso vou levar sua sugestão adiante e verificar no PSP a possibilidade. Mas conhecendo o cliente, eles gostariam da solução anterior( quando retornava CPF/CNPJ ). Alguns dos PSPs ainda retornam a info, o medo é aderirem a especificação oficial e perder essa funcionalidade.
Mas a outra forma seria incluir de 0 a 99 centavos de desconto em cada Pix, caso seus preços sejam múltiplos inteiros de Reais... assim, de 3 milhões de consultas cai para 30 mil, pois se o Pix é de R$30,42, você já tem uma pista de quais clientes podem ser. Só que são 30 mil consultas para cada Pix recebido sem txid...
É um bom ponto. Mas envolve perda financeira, e o número de consulta continua bem alto, pois a aplicação tem que ficar checando o tempo inteiro ( 5 em 5 min, 10 em 10....).
Queria realmente entender se tenho alternativas para manter a funcionalidade de forma razoável e sem perda significativa de performance. Por exemplo, um dos PSPs não retorna na API, mas retorna no CNAB 750. Não consigo entender, rs.
rubenskuhl
commented
2 years ago Mas a outra forma seria incluir de 0 a 99 centavos de desconto em cada Pix, caso seus preços sejam múltiplos inteiros de Reais... assim, de 3 milhões de consultas cai para 30 mil, pois se o Pix é de R$30,42, você já tem uma pista de quais clientes podem ser. Só que são 30 mil consultas para cada Pix recebido sem txid...
É um bom ponto. Mas envolve perda financeira, e o número de consulta continua bem alto, pois a aplicação tem que ficar checando o tempo inteiro ( 5 em 5 min, 10 em 10....).
Mas aí você só faria essa caça para Pix sem txid, com o filtro txIdPresente=FALSE. Os com txid já passariam pelo seu processo de webhook. Em achando um Pix sem txid, aí pelo valor você sabe os possíveis culpados... e cicla por eles.
Queria realmente entender se tenho alternativas para manter a funcionalidade de forma razoável e sem perda significativa de performance. Por exemplo, um dos PSPs não retorna na API, mas retorna no CNAB 750. Não consigo entender, rs.
O fato de não ter mais na API padrão significa que esse recurso tanto vai limitar a um grupo menor de PSPs, quanto que esse grupo vai diminuir com o tempo até se tornar o conjunto vazio.
E uma alternativa para considerar é ver que bancos geram esses pagamentos, e fazer algumas coisas:
GustavoBraz
commented
2 years ago Boa tarde, @eduoct.
A sugestão proposta pelo Rubens realmente é muito boa. Essa recusa do Pix sem txid pode ser apresentada de maneira amigável e orientar o usuário a seguir o caminho correto. Exatamente como o Rubens disse. Uma proposta alternativa seria utilizar uma ferramenta de conciliação que permita automação. A seguinte solução pode fazer sentido pra você: https://dev.gerencianet.com.br/docs/api-pix-endpoints#section-requisitar-extrato-concilia-o Segue também o layout do Extrato de Conciliação: https://gerencianet-pub-prod-1.s3.amazonaws.com/Layout_Extrato_de_Conciliacao_v1.0_1.pdf
eduoct
commented
2 years ago Boa tarde, @eduoct.
A sugestão proposta pelo Rubens realmente é muito boa. Essa recusa do Pix sem txid pode ser apresentada de maneira amigável e orientar o usuário a seguir o caminho correto. Exatamente como o Rubens disse. Uma proposta alternativa seria utilizar uma ferramenta de conciliação que permita automação. A seguinte solução pode fazer sentido pra você: https://dev.gerencianet.com.br/docs/api-pix-endpoints#section-requisitar-extrato-concilia-o Segue também o layout do Extrato de Conciliação: https://gerencianet-pub-prod-1.s3.amazonaws.com/Layout_Extrato_de_Conciliacao_v1.0_1.pdf
Sim, é uma alternativa. Mas ainda sim, não é solução para recebimentos "diretos" em conta. Torna-se solução somente se recusar-se a receber sem identificação, coisa que é obrigatória em um TED, por exemplo. O Pix trouxe um problema antigo que não tinha mais a um bom tempo, o tal do "Deposito não identificado". Campanhas de orientação do usuário resolvem parte do problema. Falando em usuários, sempre vai ter quem não segue as orientações. Ou seja, o problema nunca estará totalmente resolvido.
Olhando a API do extrato, o mesmo ainda não retorna identificação do pagador, o que ainda não permite identificação de uma cobrança com 100% de certeza. O que estou tentando é: Automatizar 100% da conciliação como é feito hoje para TED. Obvio que os clientes querem trocar a TED por Pix devido a todas as vantagens, mas a retirada da identificação do pagador dificultou a substituição para grandes empresas onde acaba gerando um gap de produtividade na conciliação. Não quero entrar no mérito da retirada, e sim ter a melhor prática alternativa como a solução anterior, sem gerar grandes gargalos ( seja descontos, quantidade imensa de requisições na API, etc).
Até então, a solução que atenderia "100%" seria fazer milhares ou milhões de requisições a cada x minutos com a base de CPF/CNPJ que tenha cobranças em aberto, preciso testar essa performance, mas acho que não vai ser agradável...
rubenskuhl
commented
2 years ago Boa tarde, @eduoct. A sugestão proposta pelo Rubens realmente é muito boa. Essa recusa do Pix sem txid pode ser apresentada de maneira amigável e orientar o usuário a seguir o caminho correto. Exatamente como o Rubens disse. Uma proposta alternativa seria utilizar uma ferramenta de conciliação que permita automação. A seguinte solução pode fazer sentido pra você: https://dev.gerencianet.com.br/docs/api-pix-endpoints#section-requisitar-extrato-concilia-o Segue também o layout do Extrato de Conciliação: https://gerencianet-pub-prod-1.s3.amazonaws.com/Layout_Extrato_de_Conciliacao_v1.0_1.pdf
Sim, é uma alternativa. Mas ainda sim, não é solução para recebimentos "diretos" em conta. Torna-se solução somente se recusar-se a receber sem identificação, coisa que é obrigatória em um TED, por exemplo. O Pix trouxe um problema antigo que não tinha mais a um bom tempo, o tal do "Deposito não identificado". Campanhas de orientação do usuário resolvem parte do problema. Falando em usuários, sempre vai ter quem não segue as orientações. Ou seja, o problema nunca estará totalmente resolvido.
Não seguiu as orientações, a transação não completa. Simples assim. É um loop fechado, e não só um "por favor".
Olhando a API do extrato, o mesmo ainda não retorna identificação do pagador, o que ainda não permite identificação de uma cobrança com 100% de certeza. O que estou tentando é: Automatizar 100% da conciliação como é feito hoje para TED. Obvio que os clientes querem trocar a TED por Pix devido a todas as vantagens, mas a retirada da identificação do pagador dificultou a substituição para grandes empresas onde acaba gerando um gap de produtividade na conciliação. Não quero entrar no mérito da retirada, e sim ter a melhor prática alternativa como a solução anterior, sem gerar grandes gargalos ( seja descontos, quantidade imensa de requisições na API, etc).
Tem pagador sim no layout do extrato.
Documento Sim 11 ou 14 CPF/CNPJ do pagador 12345678908
eduoct
commented
2 years ago Boa tarde, @eduoct. A sugestão proposta pelo Rubens realmente é muito boa. Essa recusa do Pix sem txid pode ser apresentada de maneira amigável e orientar o usuário a seguir o caminho correto. Exatamente como o Rubens disse. Uma proposta alternativa seria utilizar uma ferramenta de conciliação que permita automação. A seguinte solução pode fazer sentido pra você: https://dev.gerencianet.com.br/docs/api-pix-endpoints#section-requisitar-extrato-concilia-o Segue também o layout do Extrato de Conciliação: https://gerencianet-pub-prod-1.s3.amazonaws.com/Layout_Extrato_de_Conciliacao_v1.0_1.pdf
Sim, é uma alternativa. Mas ainda sim, não é solução para recebimentos "diretos" em conta. Torna-se solução somente se recusar-se a receber sem identificação, coisa que é obrigatória em um TED, por exemplo. O Pix trouxe um problema antigo que não tinha mais a um bom tempo, o tal do "Deposito não identificado". Campanhas de orientação do usuário resolvem parte do problema. Falando em usuários, sempre vai ter quem não segue as orientações. Ou seja, o problema nunca estará totalmente resolvido.
Não seguiu as orientações, a transação não completa. Simples assim. É um loop fechado, e não só um "por favor".
Olhando a API do extrato, o mesmo ainda não retorna identificação do pagador, o que ainda não permite identificação de uma cobrança com 100% de certeza. O que estou tentando é: Automatizar 100% da conciliação como é feito hoje para TED. Obvio que os clientes querem trocar a TED por Pix devido a todas as vantagens, mas a retirada da identificação do pagador dificultou a substituição para grandes empresas onde acaba gerando um gap de produtividade na conciliação. Não quero entrar no mérito da retirada, e sim ter a melhor prática alternativa como a solução anterior, sem gerar grandes gargalos ( seja descontos, quantidade imensa de requisições na API, etc).
Tem pagador sim no layout do extrato.
Documento Sim 11 ou 14 CPF/CNPJ do pagador 12345678908
Falha minha, li por cima e só li o "Documento". Ai sim, solução atendida. Agora só falta convencer os clientes a utilizar o GerenciaNet, que pelo que parece, está anos-luz a frente dos "PSPzões" em questão de API.
rubenskuhl
commented
2 years ago Falha minha, li por cima e só li o "Documento". Ai sim, solução atendida. Agora só falta convencer os clientes a utilizar o GerenciaNet, que pelo que parece, está anos-luz a frente dos "PSPzões" em questão de API.
O BACEN ainda está em definição de um layout padrão para o Pix que não sabemos ainda se irá incorporar ou não o pagador. Quando for lançado, provavelmente seja disponibilizado por um número maior de PSPs. Quando houver, posso fazer um equivalente ao issue em que mantenho hoje com opções de API PIx, o #76 , ou o de API de envio de Pix, o #480 .
Quanto ao convencimento, se seus clientes preferem retrabalho manual para 30% dos pedidos numa escala de milhões, eles precisam de consultoria de gestão. A gente prefere índices de ação manual de funcionário medido em partes por milhão.
Boa tarde,
Tenho um cliente que atende mais de 10 milhões de usuários, onde implementamos a API Pix. Geramos o cob/cobv identificado pelo txid, quando somos notificados do pagamento pelo webhook o ERP dá a baixa na cobrança desse cliente. Até ai tudo ok. Porém, desse montante de 10 milhões, muito deles iniciam o Pix de maneira direta via chave pix (CNPJ ou aleatória, pois já foram informados dessa chave algum dia). Nesse caso, não temos txid e não recebemos o retorno do webhook. Temos desenvolvido uma inteligência de identificação da cobrança pelo GET /pix, onde até então voltava as infos de CPF/CNPJ. Um dos PSPs não volta essa informação, o que me trouxe pra cá, e vi que foi alterada a especificação do GET /pix. Olhei a discussão #153 , mas ainda não entendi como resolver meu problema. Vi que foram incluídos os filtros CNPJ/CPF no GET /pix. Mas temos mais de 3 milhões de cobranças em aberto por CPF/CNPJ aguardando pagamento, teria que minha aplicação realizar essas 3 milhões de consultas e verificar se volta e2eid? Está correto meu entendimento ou existe outra maneira? Obrigado.