-
Notifications
You must be signed in to change notification settings - Fork 272
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
TXID não transmitido pelo PSP pagador #209
Comments
@rubenskuhl , obrigado pelo reporte. Estamos cientes, é um problema grave, estamos atuando para resolver esta questão com os PSPs pagadores. |
Que bom que estão atuando nisso, Filipe! No QR Code estático, os PSPs pagadores estão exibindo a descrição e o identificador aos clientes e enviando aos PSPs recebedores . Mas os merchants não estão vendo estas informações, que não são apresentadas pelos PSPs. Parece feito de propósito pelos PSPs, para dificultar a conciliação de pagamentos com QR Code estático (gratuitos), forçando as empresas a usarem o dinâmico (pagos). |
@bacen qual a previsão de resolução disto junto aos PSPs? estamos com este problema diariamente afetando nossas conciliações e principalmente afetando negativamente a experiência do usuário que tem seu dinheiro sacado porém os sistemas não são devidamente comunicados do pagamento. |
a resposta é "o mais rápido possível". sugiro entrarem em contato oficial com o DECEM para relatarem estas graves percepções. |
Grato pela sugestão @ninrod , feito. |
O Banco Inter nos informou que corrigiram o lado deles. |
O @joelemanoel testou e tá ok. |
Hoje efetuei um teste e o mesmo funcionou normal! |
Estão sem repassar o txid pro PSP recebedor: (teste com qrcode estático)
Fico imaginando se os desenvolvedores desses PSP ao menos leem essas mensagens aqui. |
Se pelo menos o Neon funcionasse eu conseguiria testar (qrcode dinâmico), mas nem isso consigo fazer kkkk |
Foram vários erros (de madrugada) mas em um outro horário, funcionou.
Em dom, 6 de dez de 2020 23:02, joelemanoel <notifications@github.com>
escreveu:
… Diferente dos problemas do #188
<https://github.com/bacen/pix-api/issues/188>, onde o PSP pagador não
consegue entender/baixar o payload do QR-Code dinâmico, neste issue o foco
é em PSPs pagadores que apesar de conseguirem fazer o pagamento, não mandam
o txid. Isso impede a conciliação pelo recebedor e pode gerar situações de
discórdia entre pagadores e recebedores ("mas eu paguei", "mas eu não
recebi").
PSPs pagadores até o momento detectados com esse problema:
- Banco Inter
- Sofisa
Estão sem repassar o txid pro PSP recebedor: (teste com qrcode estático)
- Banco Neon
- Cora
Fico imaginando se os desenvolvedores desses PSP ao menos leem essas
mensagens aqui.
Se pelo menos o Neon funcionasse eu conseguiria testar (qrcode dinâmico),
mas nem isso consigo fazer kkkk
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#209 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/ACQ3S7ILGMLI7JN6BBYN6ATSTQZVDANCNFSM4UC7KKCQ>
.
|
O banco PJBank (https://www.pjbank.com.br/) não está repassando o txId (qrcode dinâmico). |
Pode incluir o Banco BS2 nesta lista também. Sobrescrevem o Pelo app deles, sequer dão opção de definir |
Como assim? Você gera o QR Estático com txid = |
Exato! Mas vou usar o Banco Inter de exemplo aqui, que aconteceu o mesmo. Por exemplo, usei exatamente o mesmo QRCode de #236, mudando apenas a chave para meu banco, ficando assim:
O Porém depois de pago o Pix, o extrato mostra como Id da transação: E00416968202101300356jBh0Kn2Ejoi. Em nenhum local encontro o e433v1524u155f31mDvx01 que gostaria. Será que estou fazendo algo errado? |
O O txid, por enquanto, você só tem acesso por meio da API Pix (que você deve contratar com o PSP onde você tem conta e recebeu o Pix). Mas, em breve (espera-se) os PSPs começarão a se adequar ao manual de UX 3.0 (lançado há não muito tempo) e começar a exibir o txid nos comprovantes e no extrato do recebedor, também. |
@ninrod já tem a previsão para essa correção? |
@fuku5hima, a correção é realizada por parte dos PSPs. É caso a caso, com cobrança realizada pelo DECEM. |
Pessoal, identificamos ontem este erro com a Stone onde o mesmo foi tratado e está na nova versão do android 1.29.0. |
Continuando da #335:
@rubenskuhl , eu já até conversei com o DECEM sobre a possibilidade. Acho tecnicamente possível; por outro lado, será que resolve mesmo? Porque pode ser que ok, a gente pare de receber TXIDs nulos, mas comece a receber TXIDs errados. Exemplo 000000000000... Não acho que ajuda tanto assim. O que acredito que vai ajudar mesmo a estancar o problema é o processo de homologação com o QRTester. A ver. |
A maior parte dos problemas atualmente que temos recebido com pagamentos de qrcode dinâmico são txid nulos pelos motivos explicitados aqui: #299. Contudo, uma funcionalidade legal e necessária pelos problemas atuais é a possibilidade de configurar, no PSP recebedor, determinada chave (EVP) para não aceitar pagamentos com txid nulo. Nesse caso depende do PSP recebedor oferecer essa facilidade, mas acredito que isso poderia virar funcionalidade prevista regulamentada. Não afeta endereçamento no DICT, é simples e direto. |
Como eu disse acima, @mliberato, seguindo essa estratégia da "configuração da chave dict", pode ser que ok, a gente pare de receber TXIDs nulos, mas comece a receber TXIDs errados. Exemplo 000000000000... Não acho que ajude tanto assim. Ajuda, mas não acho que resolve. |
O ponto que levantei é que é praticamente inexistente esse cenário de receber txid "errado", pelo menos pela minha experiência. Em dezenas de milhares de pagamentos de mais de 130 PSPs, tivemos apenas uns 10 erros desse tipo, de apenas 1 instituição, em janeiro. Entrei em contato, foi resolvido e não aconteceu mais. Acho que a maior preocupação e que de fato "resolve" é entender quem pode "burlar" o sistema, de propósito ou sem querer. A #299 apresenta cenários "sem querer". Mas, como sabemos, é muito fácil obter a chave pix a partir de qualquer qr code dinâmico, bastando um request para o payload. Esses seriam os casos "de propósito", onde uma pessoa possa tentar burlar o sistema, obtendo a chave a partir do payload e fazendo um pagamento de valor diferente, por exemplo. Mas mesmo que faça o pagamento com o valor "correto", prejudica a conciliação. Com certeza "marcar" o DICT para que determinada chave aceite só qrcode dinâmico é a melhor opção para resolver este ponto, pois não dependeria dos PSPs e poderia ser rejeitado de maneira centralizada. Se não for possível alterar o DICT para contemplar essa feature, talvez a ideia de recusar para chaves específicas no recebedor seja uma boa opção. Para não permitir txid inexistente/errado, como entendo que seja a exceção da exceção, não vejo problemas em manter as tratativas pelo lado do PSP recebedor/merchant, em último caso devolvendo o pagamento. Até porque nesse caso a única solução para manter centralizado seria criar um serviço de registro central do txid, que acredito não valer a pena. Mesmo assim, deveria ser mandatório para o PSP recebedor, ao receber um PIX com um txid inexistente, recusar o pagamento. E ai nesse ponto caberia a homologação do Bacen validar esse ponto. |
Interessante o relato. Pode ser que resolva mesmo. Sensibilizar o DECEM quanto a essa problemática e quanto a essa solução seria a minha recomendação. |
Identificamos mais dois ISPB que não estão gerando o TXid, peço a regularização: ISPB: 71297899, |
Erros de PSP que nao enviam TxId derrubam a confiança em todo o sistema.
Esses erros podem persistir mesmo depois de maio, quando entram as sancoes.
Posso escolher bem o PSP pra receber os pagamentos, mas nao posso escolher
o PSP que o cliente vai pagar.
Colocar como requisito obrigatorio ajudaria MUITO a aumentar a confianca
pois muito mais PSPs iriam implementar.
Em sex., 12 de mar. de 2021 às 00:33, renatofrota ***@***.***>
escreveu:
… (...) a ideia seria obrigar o PSP a fornecer funcionalidade para o EC
marcar determinada chave para recusar pagamentos sem txid. Dessa forma, de
maneira organizada, vc permite ao EC implementar seu caso de uso melhor
forma possível.
Ou seja, apenas quem sentir a necessidade, pode escolher usar essa opção.
O maior prejudicado é o EC, e hoje ele não tem opção nem voz ativa no PSP
para demandar tal funcionalidade, sendo obrigado a devolver (estorno) o
pagamento e ficar no prejuízo da taxa do PIX.
Aí você deveria se perguntar: Se o EC tem a liberdade de escolher qualquer
ofertante da API Pix, por que o EC escolheria um que não atende as
necessidades dele?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#209 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/ACQ3S7KGIJ4AHIPGA4LSVVTTDGDSLANCNFSM4UC7KKCQ>
.
|
Se o seu PSP (recebedor) oferece o recurso de bloqueio de recebimentos sem txid a seu pedido, não importa a caquinha que os outros PSPs façam, você nunca terá que realizar estornos por essa razão (Pix recebido sem txid). Por isso, não precisa da obrigatoriedade de oferta do recurso para que você esteja a salvo. Basta o seu PSP (que é você quem escolhe) oferecer. Usar um PSP que não dá ouvidos aos seus clientes - quando há outros PSPs dando ouvidos - é uma escolha questionável. |
Se sua percepção é de não ter voz ativa no PSP, você provavelmente não está usando o PSP mais adequado a você. |
Não é uma percepção pessoal, tenho visto colegas no mercado sofrerem com detalhes e "desculpas" de que algo não está especificado e "não deve" ser feito. Sei que isso pode se tornar fator de escolha entre um PSP ou outro, mas ao mesmo tempo entendo que a falta de padronização/definição pode levar a procedimentos alternativos inadequados. Por exemplo, o PSP "A" pode implementar essa função recebendo e estornando, o "B" marcando a chave, o "C" não implementando por entender que "não pode". O EC que não tem (e teoricamente não precisaria) conhecimento profundo desses detalhes da estrutura do PIX, não consegue nem colocar na balança pra decidir se vai para o A, B ou C, principalmente por entender que o PIX é padronizado. Para nós que estamos discutindo todos os detalhes, é fácil optar pelo A ou B. Ao padronizar, o ecossistema se fortalece, e o mercado todo ganha. Não precisa ser uma função "obrigatória" como eu coloquei, mas que pelo menos seja padronizada, ainda que opcional. |
Se padronizado, seria interessante seguir esta configuração oferecida por um PSP:
Isso faz tanto a mitigação de recusar transações que deveriam ter vindo com txid, quanto mitigação do ataque dos centavos. |
E há também uma evolução na conversa em ter algo como validar txid via regex ou outros métodos. |
Um dos outros métodos sugeridos (este por mim) é o PSP enviar um request para |
Pessoal estamos em fase de testes no Pix cobrança com vencimento e estamos com o problema descrito nesse forúm, muitos dos nossos parceiros enviam o pagamento sem o txid o que afeta diretamente a conciliação. Gostaria de saber se houve uma evolução sobre esse tema. Qual caminho estão tomando para resolver essa questão de pagamento sem txid? |
Quais PSPs não estão enviando txid ? |
Bom dia Pessoal! Gerei um QR Estático para o Banco Inter (recebedor) com inclusão de um TXID e o Inter recusou o pagamento (Feito pela CAIXA). Se eu gerar o mesmo QR Code sem o TXID o Inter aceita. Lendo esse tópico entendi que isso é uma política do Banco Inter e que não há o que fazer. Estou correto nesse entendimento? Algum outro banco com essa mesma política. Desde já agradeço a atenção. |
Não tem essa de política, se o Inter estiver fazendo isso é caso de denúncia ao Banco Central. |
Acredito que o txid atende às regras sim, pois fiz o teste com outros bancos e não tive problema. No caso o txid era "20230527120617074" , ou seja, Data atual, com horas, minutos, segundos e microsegundos sem nenhuma formatação. |
O Inter não tem recusado meus TxId não
Em sáb., 27 de mai. de 2023 12:26, Josimar Cordeiro <
***@***.***> escreveu:
… O txid atendia às regras sintáticas de txid para estático ?
Acredito que o txid atende às regras sim, pois fiz o teste com outros
bancos e não tive problema. No caso o txid era "20230527120617074" , ou
seja, Data atual, com horas, minutos, segundos e microsegundos sem nenhuma
formatação.
—
Reply to this email directly, view it on GitHub
<#209 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/ACQ3S7OVTHAAQLXOGES7WYTXIIMKXANCNFSM4UC7KKCQ>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
Esse txid atende sim ao regex. É denúncia mesmo para fazer o pessoal lá se mexer. |
@rubenskuhl realizei novos testes e realmente o Inter não está aceitando meu txid. 00020101021126580014br.gov.bcb.pix0136ac8f3bdf-d72d-46db-811e-75f039bcf3bf52040000530398654041.005802BR5916JOSIMAR CORDEIRO6014BELO HORIZONTE622105172023052712061707463042FCD o txid foi: 20230527120617074 Estou QR Code acima estou recebendo a seguinte mensagem do banco pagador (CAIXA) "Pagamento rejeitado pelo PSP do recebedor" O mesmo QR Code usando uma chave na CAIXA funciona normalmente (com o mesmo txid). Segue abaixo: 00020101021126580014br.gov.bcb.pix01362ed5ab31-a5a7-4577-b356-f09d6f43b0ff52040000530398654041.005802BR5916JOSIMAR CORDEIRO6014BELO HORIZONTE62210517202305271206170746304725F @flaviolenz No caso estou testando com contas de pessoa física e MEI no Inter. No seu caso, a conta recebedora seria uma conta PJ (exceto MEI)? |
Uso PJ e PF no Inter.
Seu código não consegui pagar mesmo, mas meu código consegui.
Engraçado eh que eh de Inter pra Inter.
Esses R$0,10 de GerenciaNet foi pago no Inter:
00020126580014br.gov.bcb.pix01365a5ea8c2-cbb5-4c25-a7be-2a778871fc5f52040000530398654040.105802BR5916DummyRestaurante6008Brasilia62240520e433v2433u155f31m50163047A58
Esse, tb de R$0.10, foi pago de Inter pra Inter: (origem PF, destinatário
PJ)
00020126580014br.gov.bcb.pix0136909b6475-d67d-4cb8-a1a8-82cc5200f0b152040000530398654040.105802BR5908ContaHUB6008Brasilia62230519e1v2002u155f5mTeste6304F057
Em sáb., 27 de mai. de 2023 13:13, Josimar Cordeiro <
***@***.***> escreveu:
… @rubenskuhl <https://github.com/rubenskuhl> realizei novos testes e
realmente o Inter não está aceitando meu txid.
Segue abaixo o copia e cola do QR Code:
00020101021126580014br.gov.bcb.pix0136ac8f3bdf-d72d-46db-811e-75f039bcf3bf52040000530398654041.005802BR5916JOSIMAR
CORDEIRO6014BELO HORIZONTE622105172023052712061707463042FCD
o txid foi: 20230527120617074
Estou QR Code acima estou recebendo a seguinte mensagem do banco pagador
(CAIXA) "Pagamento rejeitado pelo PSP do recebedor"
O mesmo QR Code usando uma chave na CAIXA funciona normalmente (com o
mesmo txid). Segue abaixo:
00020101021126580014br.gov.bcb.pix01362ed5ab31-a5a7-4577-b356-f09d6f43b0ff52040000530398654041.005802BR5916JOSIMAR
CORDEIRO6014BELO HORIZONTE62210517202305271206170746304725F
@flaviolenz <https://github.com/flaviolenz> No caso estou testando com
contas de pessoa física e MEI no Inter. No seu caso, a conta recebedora
seria uma conta PJ (exceto MEI)?
—
Reply to this email directly, view it on GitHub
<#209 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/ACQ3S7KEF4NGRND6OWJMTATXIIR4HANCNFSM4UC7KKCQ>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
@flaviolenz seria possível você fazer um teste com o destinatário sendo uma conta PF no Inter? Acho que o problema no Inter pode ser o tipo da conta recebedora. |
Esse que fiz. Usa o 2o codigo que passei. São todos de R$0,10
Em sáb., 27 de mai. de 2023 13:33, Josimar Cordeiro <
***@***.***> escreveu:
… @flaviolenz <https://github.com/flaviolenz> seria possível você fazer um
teste com o destinatário sendo uma conta PF no Inter? Acho que o problema
no Inter pode ser o tipo da conta recebedora.
—
Reply to this email directly, view it on GitHub
<#209 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/ACQ3S7ITZKLXUWMJDRFY6M3XIIUEFANCNFSM4UC7KKCQ>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
Mas o segundo que você passou o destinatário é PJ e não PF. Consegue gerar um aí cujo destinatário seja PF. O segundo você informou que o destinatário é PJ.. entendeu?
|
00020126330014br.gov.bcb.pix01112892205034952040000530398654040.105802BR5916DummyRestaurante6008Brasilia62240520e433v2436u155f34m5036304DC86
Em sáb., 27 de mai. de 2023 13:57, Josimar Cordeiro <
***@***.***> escreveu:
… Mas o segundo que você passou o destinatário é PJ e não PF. Consegue gerar
um aí cujo destinatário seja PF.
O segundo você informou que o destinatário é PJ.. entendeu?
Esse, tb de R$0.10, foi pago de Inter pra Inter: (origem PF, destinatário
PJ)
—
Reply to this email directly, view it on GitHub
<#209 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/ACQ3S7KGNMY3DN72FQNYKMLXIIXBHANCNFSM4UC7KKCQ>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
Faltou mesmo, pagando de Inter PJ pra Inter PF.
Denuncia no BC, eh o caso
Não eh pq tem um TXID que eles podem recusar
Em sáb., 27 de mai. de 2023 14:06, Flavio Lenz Cesar ***@***.***>
escreveu:
…
00020126330014br.gov.bcb.pix01112892205034952040000530398654040.105802BR5916DummyRestaurante6008Brasilia62240520e433v2436u155f34m5036304DC86
Em sáb., 27 de mai. de 2023 13:57, Josimar Cordeiro <
***@***.***> escreveu:
> Mas o segundo que você passou o destinatário é PJ e não PF. Consegue
> gerar um aí cujo destinatário seja PF.
>
> O segundo você informou que o destinatário é PJ.. entendeu?
>
> Esse, tb de R$0.10, foi pago de Inter pra Inter: (origem PF, destinatário
> PJ)
>
> —
> Reply to this email directly, view it on GitHub
> <#209 (comment)>,
> or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/ACQ3S7KGNMY3DN72FQNYKMLXIIXBHANCNFSM4UC7KKCQ>
> .
> You are receiving this because you were mentioned.Message ID:
> ***@***.***>
>
|
Muito obrigado pessoal! Vou relatar esse problema aos Devs do Inter. Se não houver solução vou denunciar ao Banco Central. @ninrod acha que consegue ajudar nesse caso? |
Infelizmente trago mais um relato sobre inconsistências na exibição de identificador e descrição de pagamentos.
Todos eles aceitam pagamentos para um mesmo identificador repetido, independente do valor. Triste porque a impressão que fica é a de que eles não mostram essas informações para forçar uma contratação de uma API Pix para empresas, quando em muitos casos, uma solução simples de BR Code estático resolveria a situação sem incorrer no pagamento de taxas ou contratação de serviços extras. Sem essas informações fica muito difícil fazer a conciliação dos pagamentos. |
Não atribua a malícia o que pode ser explicado por incompetência... |
Diferente dos problemas do #188, onde o PSP pagador não consegue entender/baixar o payload do QR-Code dinâmico, neste issue o foco é em PSPs pagadores que apesar de conseguirem fazer o pagamento, não mandam o txid. Isso impede a conciliação pelo recebedor e pode gerar situações de discórdia entre pagadores e recebedores ("mas eu paguei", "mas eu não recebi").
PSPs pagadores até o momento detectados com esse problema:
The text was updated successfully, but these errors were encountered: