pix-api

pix-api copied to clipboard

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:

• Banco Inter
• Sofisa

@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.

@gustavcesar ,

a resposta é "o mais rápido possível".

sugiro entrarem em contato oficial com o DECEM para relatarem estas graves percepções.

@gustavcesar ,

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. Se alguém tiver como testar, por favor, divulgue o resultado aqui.

O Banco Inter nos informou que corrigiram o lado deles. Se alguém tiver como testar, por favor, divulgue o resultado aqui.

O @joelemanoel testou e tá ok.

Hoje efetuei um teste e o mesmo funcionou normal!

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:

• 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.

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:

• 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

Foram vários erros (de madrugada) mas em um outro horário, funcionou.

Em dom, 6 de dez de 2020 23:02, joelemanoel [email protected] 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 https://github.com/bacen/pix-api/issues/209#issuecomment-739618854, 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 txid definido em QRCode estático gerado manualmente.

Pelo app deles, sequer dão opção de definir txid, somente descrição, que não retorna também no extrato.

Pode incluir o Banco BS2 nesta lista também. Sobrescrevem o txid definido em QRCode estático gerado manualmente.

Pelo app deles, sequer dão opção de definir txid, somente descrição, que não retorna também no extrato.

Como assim? Você gera o QR Estático com txid = 123, alguém paga, e vc recebe o Pix com outro txid no lugar de 123?

Pode incluir o Banco BS2 nesta lista também. Sobrescrevem o txid definido em QRCode estático gerado manualmente. Pelo app deles, sequer dão opção de definir txid, somente descrição, que não retorna também no extrato.

Como assim? Você gera o QR Estático com txid = 123, alguém paga, e vc recebe o Pix com outro txid no lugar de 123?

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:

00020126360014br.gov.bcb.pix01143798980600016452040000530398654040.155802BR5911Arrumadinho6008Brasilia62260522e433v1524u155f31mDvx016304DD4E

O txid deveria ser e433v1524u155f31mDvx01, correto?

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 E00416968202101300356jBh0Kn2Ejoi é o End To End ID, não o txid.

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?

@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:

Isso é PSP a PSP mesmo. O SPI não sabe se é ou não um QR-Code dinâmico sem olhar o TxID... a não ser que chaves no DICT pudessem receber flag "só aceita QR-Code dinâmico". Acha possível isso, @ninrod ?

@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.

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.

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.

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: 62232889 NOME: BCO DAYCOVAL S.A TIPO: DIRECT

ISPB: 71297899, NOME: CCLA OESTE MINEIRO LTDA-SICOOB TIPO: INDIRECT

Banco Inter na data de hoje (02/03/2021) não está respassando o txId.

Acabei de falar com o Inter, bug está resolvido.

Mais um.

ISPB: 82639451 NOME: COOPERATIVA DE CREDITO VALE DO ITAJAI - VIACREDI | CC VALE DO ITAJAÍ

@mliberato:

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.

"Art. 39-A. Uma transação no âmbito do Pix poderá ser rejeitada pelo participante prestador de serviço de pagamento do usuário recebedor quando houver inconsistência entre a transação e os parâmetros atribuídos à cobrança que a originou, quando se tratar do produto Pix Cobrança."

Baseado nesse artigo, o PSP está livre para implementar as checagens que você descreve. Por exemplo, para uma dada ag/cc, sempre recusar pacs.008 caso venha sem o txid preenchido. Entendimento confirmado.

@mliberato:

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.

"Art. 39-A. Uma transação no âmbito do Pix poderá ser rejeitada pelo participante prestador de serviço de pagamento do usuário recebedor quando houver inconsistência entre a transação e os parâmetros atribuídos à cobrança que a originou, quando se tratar do produto Pix Cobrança."

Baseado nesse artigo, o PSP está livre para implementar as checagens que você descreve. Por exemplo, para uma dada ag/cc, sempre recusar pacs.008 caso venha sem o txid preenchido. Entendimento confirmado.

@ninrod acho que o @mliberato queria isso como mandatório, não como opcional... mas não vejo como, pois há transações válidas sem txid, pelo menos até o método de iniciação ser informado na PACS.008.