[Dúvida] GET /pix

[eduoct]

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.

[rubenskuhl]

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]

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]

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]

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]

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:

• Orientar clientes desses bancos a não fazerem a sequência que leva ao pagamento de txid. Algo na linha "Clientes dos bancos X, Y e Z, favor clicar aqui para informação importante sobre seu pagamento."
• Ao identificar um pagamento sem txid, que você consiga conciliar por algum método, avisar o cliente de que foi reconhecido o pagamento mas que teve esse problema, de que isso pode causar problemas e sugerir fazer diferente.
• Verificar se os bancos que geram muito isso já estão com pagamento OpenFinance habilitado. Pois no OF dá para conciliar pelo OF, mesmo o Pix sendo feito por dados bancários. E aí sugerir para clientes desses bancos usar o OF.

[GustavoBraz]

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]

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]

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]

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]

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.