Histórico de mensagens sobre PSP em sugestões

Pessoal, bom dia.

Passamos os últimos três dias testando massivamente a nova funcionalidade, porém acreditamos que ainda podemos ter surpresas com PSP's que fazem uma "abordagem própria", algo que já estamos calejados 🙄 , por exemplo alguns enviam as chaves mesmo nos Pix manuais, ou podem enviar um outro padrão de txid inválido que ainda não pegamos, etc.

Portanto, não iremos liberar a atribuição autônoma de escopos no nosso sistema ainda. Peço aos interessados que informem ao <@!652136709982781470> o Client Id das credenciais de vocês, ele vai atribuir os novos escopos pontualmente. Vamos seguir o entendimento de uma funcionalidade em beta, portanto sugiro que criem uma nova chave evp exclusiva para a utilização das novas configurações, para não atrapalhar a operação de vocês.

Sugiro que acrescente o "Point of Initiation Method" na geração do QRCode no GET /loc/:id/qrcode, alguns PSPs como o Bradesco não estão lendo o QRCode.

Sugestões que me lembre até agora:
- Utilizar % bem parecido com o LIKE do MySQL;
- Utilizar iniciaCom e terminaCom;
- Utilizar o regex bloqueando o uso de "()" (faria com que não demorasse tanto);
- Enviar uma requisição para uma URL para homologar um txid, ex: {webhookUrl}/txidmatch (Essa necessitaria de uma homologação parecida com BACEN x PSP);

O é um erro que por enquanto deveria ser removido pelo PSP recebedor e deixar sem txid.

o único caso especial possível que não seria coberto apenas com os 2 validadores txidNulo e txidEstatico seria um PSP pagador tratar erradamente o txid como int em algum ponto do seu sistema e acabar enviando "0" na PACS em vez de uma string vazia, ou omitir o campo txid, fazendo a validação da GN testar contra a opção de aceite de Pix via qr estático em vez de testar contra o Pix de txid nulo, o que eu não vi ninguém reportar e acho difícil que aconteça (por ser o txid um campo que acata caracteres a-z também). por isso que acho suficientes essas 2 opções. simples e funcionais. e em último caso, a GN poderia tratar a string "0" como txidNulo em caráter de exceção.

O txid nulo acontece por falha de PSPs. O estático só se montar um EMV de propósito...

<@!793123559874494465> Acho que alguns campos das comunicações entre PSPs e BACEN admitem/adotam a grafia "txId" (com I maiúsculo) mas na comunicação PSP <-> EC o termo "txid" foi padronizado para minúsculas em todo o material e API padrão do BACEN (já há algum tempo). Então acho que seria mais consistente para os ECs tratar assim (txid).

se no futuro algum PSP fizer uma merda grande (enviar txid A para QR code com txid B), aí sim, deveríamos estar pensando em meios de validar o txid

as notificações de Pix recebido da GN estão trazendo a razão social dos PSPs pagadores em vez do nome comercial. ex: "boletobancario.com tecnologia de pagamentos ltda." em vez de "Juno"

<@!780500321994539068>
Sobre ser um endpoint diferente, é algo que traz um maior conforto até na hora de separar os casos de uso. O atual remete a transferências, o outro a pagamentos. Até pelo fato de, em uma transferência, ao enviar TxId, sabe-se lá se outro PSP vai recusar por existir (coincidentemente) uma cobrança lá com o mesmo identificador...

Sobre o acervo de assinaturas de JWT: perfeito, não teriam como validar

Portabilidade e reivindicação não são problema pq a chave continua existindo. O problema é se for feita uma remoção no outro PSP.

Pois é, teria que ser um cache do próprio PSP que faz o rateio pra garantir o destino do split. Só que aí vêm questões de portabilidade/reinvindicação que podem invalidar o cache.

Podia por os 2. As vantagens do pix.ae:

1. mais fácil usar (muitas mídias não tornam clicáveis - ou sequer aceitam - links que não sejam http(s))
2. é acessível para todos os clientes Pix universalmente, inclusive os clientes de PSPs que ainda não suportam a integração "automática" pelo header x-pix-brcode (abre no navegador e escaneia/copia o brcode)
3. se propagará mais rápido devido às vantagens 1 e 2 😁

a minha pergunta não foi pra cobrar que validem. foi só pra ajudar a fundamentar a tese de que cabe ao PSP oferecer o suporte ao mTLS mas cabe ao EC usar ou não. se não tem como o PSP saber só com um request individual se o EC está exigindo mTLS, acho que bastaria a GN continuar fazendo a validação no momento do cadastro (pro EC saber que tá configurado correto, se quer usar mTLS) e dar a opção de fazer bypass. ou até mesmo inverter o padrão para não exigir o mTLS e só fazer se o teste se o EC passar x-mtls-check: true no PUT

Sim, correto. Mas... o manual transfere para o PSP checar algumas coisas do EC, inclusive aderência a OWASP top-N. Mas isso não precisa ser feito chamada a chamada, pode e é mais usual ser scan regular.

você quer dizer que cabe ao EC o "require" da validação mTLS e o BACEN não diz explicitamente que o PSP deve validar o PUT?

mas o risco é do EC. o PSP não deveria ser obrigado a exigir mTLS. deveria ser obrigado a oferecer como opção, apenas

O mTLS tenta mitigar tanto a introdução de informações falsas por um PSP fake, quanto o vazamento de informações que eram de um EC para o outro.

e qual o risco que existe para o PSP em mandar um request pra uma URL sem mTLS que não existe com o mTLS? é o EC que tem que confiar ou não. tinha que ser opção do EC.

Mudar de JSON para JWT ? Só precisa ver se o povo vai conseguir abrir JWT direito... até os PSPs estão sofrendo.