[Sugestão] Inclusão das informações do Pagador no callback do Webhook #261
Comments
Boa tarde. É bastante difícil responder questões específicas que dizem respeito a uma implementação particular, mas acredito que o seu problema está neste trecho. O fluxo, na API, começa com o "seu cliente" (banco X, Banco Y) estabelecendo "de que se trata aquela cobrança" antes de emitir o QR e deixar o pagador pagá-lo. O que liga o pagamento e o seu significado é o txid. bastaria que seus clientes de sua API respeitassem o fluxo e estabelecessem o que é aquele QR (vc ficaria sabendo, como PSP recebedor) antes de deixar o pagador pagá-lo. Agora, entendo que eles estão recebendo o pagamento, então são PSPs também, e ao mesmo tempo são clientes seus, mas não usam a API Pix, no entanto usam webhook para te avisar que o pagamento ocorreu, mas não exibem o QR, e quem está exibindo é você. Este é um desenho absolutamente não previsto no fluxo, é uma montagem diferente dos elementos. Muito difícil até de entender e está bem fora da ideia do que é ser um PSP recebedor no Pix. Você é um PSP recebedor, mas ao mesmo tempo oferece um serviço de "exibição de QRs em POS" para PSPs recebedores que não querem exibir seus próprios QRs no POS. Não sei se entendi direito. De qualquer maneira, eu diria que a solução aqui seria que você, antes de exibir o QR teria que saber de que se trata, a priori, a cobrança. |
Você pode entrar comigo e com o @rturk no grupo dos que sentem falta desse atributo que estava nas versões anteriores da API (apesar de opcional). Infelizmente o que você pode pedir hoje é um export de arquivo CNAB750, que diferente da API Pix tem a informação de pagador. |
Fala ai @ninrod, tudo bem? Perdão, acho que talvez não tenha sido claro de fato, vou tentar explicar novamente. Imagine que eu sou uma Adquirente e também participo no arranjo PIX como PSP Direto, certo? Eu como adquirente, forneco POS para meus clientes (EC/Lojista), como também sou um PSP Direto, dou a opção desses lojistas venderem por Crédito/Débito e PIX, caso eles queiram ativar a funcionalidade PIX no POS, irão receber os valores na conta transacional que EU sou o dono, pois sou um PSP Direto, então sou dono de uma conta transacional também, até ai blz.. O Lojista gera um QrCode Dinâmico no POS dele.. vem alguém.. efetua o pagamento.. eu recebo o pagamento e jogo o dinheiro na conta dele (Conta transacional essa que esta aqui dentro de casa) e libero o POS para gerar o CV (Comprovante de Venda), nesse comprovante, como fui eu quem recebeu o pagamento, eu sei quem efetuou o pagamento certo? Então devolvo essa informação pro POS que ele utiliza para jogar no Comprovante de Venda. Entretanto, esse mesmo EC/Lojista, quer usar o meu POS para transacionar PIX.. mas ele não quer receber na contra transacional que eu posso fornecer pra ele, porque? Porque ele tem conta no Banco X (Que também é um PSP mas não tem POS), então eu como Adquirente, fiz um acordo com esse Banco X, para esse Banco X gerar uma chave EVP para esse EC/Lojista .. mas quem vai utilizar essa chave EVP/clientId/clientSecret/mTLS/etc. não será o EC/Lojista, e sim eu (Adquirente/DonaDoPos/PSP) depois do aceite duplo do EC/Lojista (Ele vai precisar dar um aceite no Banco X e na Adquirente), então quando ele for gerar um QrCode Dinâmico no POS dele, eu (Adquirente) não vou mais gerar um QrCode Dinâmico meu, vou usar as credenciais deesse EC para bater na API PIX do Banco X e gerar uma Cobrança usando a chave EVP do Lojista, com isso, ele consegue receber direto na conta do Banco X, certo? Mas qual o problema? Eu gero essa cobrança.. exibo no POS.. um pagador faz o pagamento.. o Banco X recebe esse pagamento.. me manda um webhook/callback com a notificação do pagamento (Pois eu também assinei o webhook usando a chave EVP do EC) e eu mando pro POS pra liberar o CV, entretanto, nesse webhook eu não tenho as informações de quem realizou o pagamento, e porque? Por mais que o Banco X tenha as informações, ele não me passa porque essas informações não estão na Spec da API PIX, ele até gostaria de me mandar.. mas não pode porque não está na Spec entendeu? Por isso gostaria de solicitar a inclusão dessas informações no Callback/Webhook de retorno, pois são informações importantes a serem preenchidas no Comprovante de Venda.
Então pelo visto agora somos 3 pessoas precisando dessa mesma inclusão na Spec, @ninrod acha possível essa inclusão? Os campos podem ser opcionais como eram antes conforme o @rubenskuhl comentou, mas acho que seja importante deles existirem. |
Acho que vocês optaram pelo caminho mais difícil. Sendo PSP vocês poderiam continuar usando esse cenário onde tudo está "dentro de casa", emitir o CV normalmente e depois simplesmente repassar os valores para a conta do EC em outro PSP (a cada recebimento individual; ou em lotes, como normalmente já fazem os adquirentes de cartão de crédito/débito quando não ofertam conta transacional ou o EC quer receber em outro PSP por qualquer razão). Mudar o "fluxo do dinheiro" fazendo ir do pagador ao PSP externo e ao mesmo tempo se colocarem "fora" desse fluxo, mesmo que tendo algum nível de controle sobre as transações, por terem que lidar com credenciais de clientes em outro PSP e tudo mais - sendo que vocês já são PSP - me pareceu uma decisão bem ruim. |
@renatofrota atualmente já estamos fazendo isso que você sugeriu, estamos recebendo todos os valores "dentro de casa" e repassamos esses valores para a conta desejada do EC/Lojista 3x ao dia, acontece que o EC/Lojista prefere receber "real time" e não em lote durante o dia como estamos fazendo, também fica inviável fazer mais de 1 milhão de PIX de forma unitaria todos os dias PIX a PIX, a solução fica muito cara e não fecha a conta no final do mês, por conta disso que estamos seguindo com essa estratégia de delegar todo o processo de criação de cobrança / liquidação da cobrança com o PSP Externo. |
Mas isso limita os PSPs do lojista aos que tenham API Pix funcional (vide #76). É uma quantidade pequena ainda. |
Geralmente 99% dos ECs/Lojistas possuem seu domicilio bancário em 1 dos 5 Bancos Tradicionais e esses 5 Bancos já possuem sua API PIX, então para o nosso cenário já atende, sem contar que o normal seria recebermos os valores em nossa Conta Transacional, visto que somos um PSP Direto no arranjo, essa questão de permitirmos do EC receber em outro PSP já é um extra. |
Mas enviar Pix não custa R$ 0,001? Esse valor é coberto pelas tarifas cobradas do cliente, com certeza. A menos que você esteja falando de economia de custos indiretos.
A solução possível, definitiva, simples e barata, seria o EC receber na conta transacional interna e enviar Pix "pra fora" quando ele bem entender (o que ele pode fazer 24/7). Ter que passar por todo o processo de homologação em outro PSP pra fornecer as credenciais para vocês ficarem transacionando "em nome deles" em outro PSP me soa muito estranho. Vocês estão abrindo pra um PSP terceiro um controle (e informação de volumetria, padrões, etc.. big data) sem necessidade. |
O valor do PIX custa R$ 0,01, em baixa escala não parece um valor muito alto mesmo, você começa a ver problemas quando existem mais de 1 milhão de PIX por dia (Nosso volume atual no Débito que provavelmente comece ser alterado para PIX), mas é como você disse, o maior problema é a questão de custos indiretos mesmo.
Eu também concordo com essa abordagem e pra ser bem sincero, gostaria de seguir dessa forma, pois o EC/Lojista pode muito bem entrar em nossa conta transacional e fazer um PIX para outro domicilio da preferência dele, e se ele não quiser fazer isso, já estamos fazendo isso pra ele 3x por dia, entretanto acabou sendo uma definição do time de Produtos que eu já não tenho muita força pra discutir (Sendo eu do time técnico / TI ) rs Entretanto, me veio outro item agora, na regulamentação do PIX pelo Bacen, deixa claro que no Extrato/Comprovante do PIX, precisa constar as informações de quem efetuou o pagamento/transferência, como vamos ter essas informações se no CallBack da notificação essas informações não existem? Esqueçam por um momento essa minha situação bem especifica, e pensem em um cenário real que já existe hoje: Eu fui atrás desse problema e bati um papo com alguns PSPs no mercado, esses me disseram que estão incluindo as informações do pagador no callback mesmo não tendo na Spec da API PIX.. foram obrigados a colocar porque é obrigatório imprimir essas informações no CV.. @renatofrota Esses não são indicios que de fato precisamos incluir as informações do pagador no webhook de notificação? |
|
Apesar de para mim a opção de ter informação do pagador não dever ter sido removida, eu não vejo um comprovante de venda como a necessidade dela. A NF vai ser emitida para o CPF/CNPJ que o comprador informou, se informou, não para o pagador. Por exemplo, alguém pode comprar algo para empresa e depois pedir reembolso. Se o comprador não informar um CPF/CNPJ, uma instrução que já vi em uma prefeitura de capital foi de colocar o próprio prestador de serviço como tomador. A informação de que o pagador continua sendo informado é interessante para o BACEN ponderar. |
|
Hoje estamos colocando as informações do Pagador no Comprovante de Venda gerado pelo POS, até porque quando a transação é Débito/Crédito nós temos algumas informações do cartão pra jogar no Comprovante, no caso do PIX não temos nada, só as informações do pagador entendeu? Mas isso dentro de casa, no nosso POS e no nosso QrCode, nesse cenário temos as informações do Pagador. O problema mesmo foi o que eu citei quando estamos usando o QrCode de outro PSP, por isso fui bater um papo com vários PSPs e todos estão retornando as informações do Pagador exatamente pra fazer a mesma coisa, ou seja, estão usando a versão 2.2.0 da Spec com um pedaço da 2.0.0 quando tinha as informações do Pagador, por isso acredito que o Bacen precisa por essas informações novamente. |
|
Quando eu vou a uma loja comprar algo e pago com dinheiro físico, saio com
uma nota ou cupom fiscal (em alguns casos, rsrs) e/ou um recibo de
pagamento dizendo que paguei X reais. Neste recibo, na maior parte das
vezes, nem consta meu nome ou um documento. É um recibo que comprova que
foi pago, não importa por quem. Quem estiver de posse desse recibo pode
reclamar o que tiver de reclamar, se a necessidade surgir.
E, em se tratando de QR codes, se for dinâmico, há uma cobrança vinculada e
o devedor é o que importa, se ali constar (também é opcional), não quem
pagou.
Isso já foi discutido no issue onde a decisão de retirar os dados do
pagador foi tomada e, se a necessidade for "verificar se quem pagou é a
pessoa que você esperava", essa possibilidade já existe, consultando pelo
cpf/cnpj e verificando se o Pix em questão é retornado.
Em qua, 23 de dez de 2020 13:51, Filipe Henrique Cavalcanti de Sousa <
[email protected]> escreveu:
… Hoje estamos colocando as informações do Pagador no Comprovante de Venda
gerado pelo POS, até porque quando a transação é Débito/Crédito nós temos
algumas informações do cartão pra jogar no Comprovante, no caso do PIX não
temos nada, só as informações do pagador entendeu? Mas isso dentro de casa,
no nosso POS e no nosso QrCode, nesse cenário temos as informações do
Pagador. O problema mesmo foi o que eu citei quando estamos usando o QrCode
de outro PSP, por isso fui bater um papo com vários PSPs e todos estão
retornando as informações do Pagador exatamente pra fazer a mesma coisa, ou
seja, estão usando a versão 2.2.0 da Spec com um pedaço da 2.0.0 quando
tinha as informações do Pagador, por isso acredito que o Bacen precisa por
essas informações novamente.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#261 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAZ2XSVKT7ZUM26AVAT53XTSWINYPANCNFSM4VBP2PEA>
.
|
Você se refere a operação "GET /pix/{e2eid} Consultar Pix."?, não existem as informações do pagador nela também, na verdade essas informações não existem em nenhuma operação da API PIX =/ |
|
GET /pix?cpf=xxx se o Pix (e2eid) esperado for retornado, bingo. |
Mas ai que está, eu não sei quem realizou o pagamento, consequentemente não tenho esse CPF/CNPJ para realizar a pesquisa, até porque se eu tivesse essas informações o problema estaria resolvido e eu iria conseguir jogar essas 2 informações (Nome/CPF do pagador) no Comprovante de Venda =/ |
|
@ninrod Tem algum problema dos PSPs me retornarem as informações do pagador no Callback mesmo sem estar na Spec oficial da versão 2.2.0? Conversei com alguns e todos gostariam de me repassar, vê algum problema? |
Mas você pode amarrar essas informações ao txid, não pode?
Trata-se de uma extensão da API, o que é previsto. Mas há algumas preocupações: 1) lock in e 2) LGPD. Quais seriam, exatamente, essas informações? |
Não, são informações de quem realizou o pagamento que eu preciso, ou seja, nome/cpf do pagador, não consigo essas informações chamando nenhuma operação da API PIX, nem com o txId nem com o e2eid.
LockIn em tese não vai ter, pois são campos opcionais, os PSPs podem ou não retornar essas informações
Nome/CPF do Pagador, informações que inclusive estavam na versão 2.0.0 da API PIX |
@filipehcds , eu tomaria bastante cuidado. Recomendo fortemente uma consulta ao DECEM tentando reportar o problema específico e falando da necessidade de se obter estas informações.
Cuidado, é uma questão jurídica enrolada. Recomendo muito, mas muita cautela mesmo ao chegar a essas conclusões. Uma consulta ao jurídico e ao DECEM, no mínimo, de saída, é o que eu recomendaria. Como você apontou, o BCB removeu essas informações da versão 2.0.0. Apenas esse fato já fornece uma pista em relação às preocupações que gravitam em torno da questão. |
Como faço para consultar o DECEM? Consegue me passar os endereços/contatos?
Acho que acabei por esquecer de informar que o CPF do pagador é cifrado, a unica informação que ficaria aberta mesmo é o nome da pessoa, informação essa que já consta em qualquer PIX entre PSPs, por isso tomei como verdade que não deveria ferir em nada a LGPD, pois hoje funciona exatamente dessa forma. |
|
DECEM: [email protected] |
Boa tarde pessoal, tudo bem?
Atualmente somos um PSP Direto e já oferecemos a geração de QrCode Dinâmico em nossa solução de captura (POS), após o pagamento, fornecemos um CV (Comprovante de Venda) com as informações de quem realizou o pagamento, até ai tudo bem, acontece que agora estamos ofertando também a possibilidade de gerarmos um QrCode Dinâmico de algum parceiro nosso, Banco X, Banco Y, etc.. nesse mesmo POS, para que o lojista não precise necessariamente receber os valores em nossa conta transacional, e sim na conta transacional que ele já possui em outro PSP.
Onde ocorre o problema? Na integração que estamos fazendo com esses PSPs parceiros por meio da API PIX, quando eles recebem esse pagamento e nos envia um webhook contendo as informações do pagamento, não existe nenhum campo que identifique esse pagador (Sendo que o PSP sabe quem realizou esse pagamento), as unicas informações que existem no callback da versão 2.2.0 são [endToEndId, txid, valor, horario, infoPagador e devolucoes], com isso, não estamos conseguindo imprimir as informações do pagador no CV como já fazemos quando o pagamento é nosso, é possível uma inclusão das informações do pagador no callback de notificação?
Obs: Talvez possamos disponibilizar essas informações até no GET /pix e/ou GET /cob também.
Obrigado
The text was updated successfully, but these errors were encountered: