Histórico de mensagens sobre dict

Apesar de enviarmos o TradeName alguns PSPs não estão fazendo a leitura das informações disponibilizadas no DICT e por isso a sugestão é você fazer a leitura em outros PSPs.

Pensando na implementação lógica, o fluxo seria mais ou menos esse:

-> se o txid é dinâmico {26,35} a GN valida com base na chave + txid se existe cobrança (talvez isso até já esteja implementado hoje).
-> elseif, txid é nulo, GN consulta a configuração da conta do EC recebedor (ou da chave) se deve acatar Pix com txid nulo.

se a GN tiver como diferenciar quando o Pix foi enviado via "manual" (informando dados bancários) ou com uso da chave DICT, o ideal seria a configuração de aceitar/não os recebimentos com txid nulo ser por chave + uma configuração extra para bloquear todos os recebimentos manuais (que nunca tem txid associado).

se não tiver como diferenciar, a configuração poderia ser global (por conta transacional), com opção de sobrescrever a escolha para chaves individuais (assim poderia bloquear recebimentos com txid nulo para toda a conta [que seria o comportamento padrão] e autorizar o txid nulo em uma chave particular).

e, futuramente:
-> else (txid é estático), valida conforme as regras de aceite do EC (por regex match ou enviando o request de validação para webhookURL/txidmatch, como sugeri acima).

e esse "futuramente" eu não consigo nem ver uma demanda relevante. o importante são as outras funções.

Neste caso não existe, pois entra no que relatei na mensagem anterior sobre um limite de consulta no DICT que o Bacen definiu e por isto não tem como disponibilizarmos um endpoint para consultas de chaves.

Boa tarde <@!812297338605273098>! Você poderia utilizar o endpoint de envio de Pix, com ele você consegue verificar se a chave em que o Pix foi enviado existe ou não, pois, é retornado em nosso endpoint. Mas caso você se refira a consultar as chaves cadastradas no DICT, no momento não é possível, o Banco Central limitou aos PSPs consultas a serem feitas no DICT como se fossem fichas e por isto não tem como liberar um endpoint que permita um retorno de quais chaves estão cadastradas.

<@!715273512688025630> complementando com mais alguns entendimentos:
- A instituição recebedora que aparecerá ao pagador é sempre Gerencianet
- Os dados do estabelecimento do recebedor que aparecerão ao pagador serão: nome fantasia (caso exista) ou razão social.

Importante: não importa o que aparece no BR Code, a informação oficial é a que está no DICT. Ou seja, o correto é que o PSP sempre busque os dados da chave via DICT, ao invés de "confiar" no BR Code. Inclusive, isso é uma questão de segurança. Se o PSP não faz isso, pode acontecer do pagador achar que o pagamento está indo pro A ao invés do B.

Como ainda tem PSP mostrando erradamente o nome no EMV 54 ao invés do DICT, eu acho importante colocar lá a marca fantasia da empresa...

Fui fazer um Pix agora (C6 -> Itaú) e deu problema de look-up no DICT algumas vezes. Depois de algumas retentivas funcionou.

TxId duplicado só é recusado em QR-Code dinâmico, e um pagamento pode ser estático (com ou sem txid). Eu estava pensando e acho que a API tem que ter 2 passos de forma similar à UX do app:
/gn/pagamento (BRCode[obrigatório], idpagamento[obrigatório], valor[opcional])
retorna o valor do pagamento, as informações do recebedor no DICT (eventualmente mascaradas).
Aí a próxima chamada seria
/gn/confirmapagamento (idpagamento[obrigatório],valor[obrigatório])
Tem que passar de novo o valor e o id de propósito, para dizer "eu sei que vai sair x dinheiros da minha conta".

Na chamada de pagamento, o valor opcional seria passado para caso o QR-Code estático não tenha valor associado.

pra isso, a chave deve ser registrada no DICT com o TradeName

No caso, não tem como saber que sou eu consultando e somente a GN no DICT, por isso as consultas de todos os cliente da GN se somariam e poderia limitar novas consultas.

É função do número de transação efetivamente realizadas. Se ficar consultando e não realizar transação, o PSP fica limitado e não consegue consultar o DICT.

O problema de exportar isso numa API é o rate-limit do DICT.

Não é possível atualmente, pois, essa consulta ao DICT tem um limite de "fichas" que podem ser utilizadas. No entanto, entendemos a necessidade e como bem colocado pelo Rubens essa discussão está acontecendo com o BACEN.

ou "App deve ler nome no DICT" pra não ficar com aspecto de que é um erro no próprio brcode que eu gero

acho que vou deixar "Falha ao ler nome do DICT" kkk

Inter
🟩 #1 - Não aceita valores inteiros sem os centavos (com ou sem separador)
🟫 #2 - Despreza Merchant Name do DICT (exibe o nome presente no QR Code)
🟫 #15 - Não exibe informações do QR Code dinâmico como txid, infoAdicionais e solicitacaoPagador

No endpoint POST /pix caso a chave do recebedor não exista, você receberá um erro na hora. Isso significa que o webhook nem será acionado pois a solicitação de envio de Pix não funcionou.

Sobre os aplicativos conseguirem indicar contatos cujo telefone/email já estejam cadastrados no Pix, sabemos que estuda-se isso no BC e inclusive nós enviamos há pouco tempo uma proposta relacionada.

Pode ser que em breve seja viável uma "consulta no cache do DICT", de forma que não se gaste as fichas do bucket oficial...

O Banco Central não deixa. Há um limite baixo para consultas ao DICT sem transação posterior, que a GN se arriscaria muito se fornecesse algo que permitisse isso de forma automatizada.

Atualmente não, essas chaves ficam cadastradas no DICT e não há um endpoint para retornar esta informação. Você poderia detalhar melhor a necessidade desta consulta para que possamos entender melhor?

Boa tarde <@!783359762917752843>! As chaves Pix ficam salvas em um DICT que é consultado no momento do envio do Pix, se este CPF não estiver atrelado a nenhum PSP como chave, então a transação não ocorre. Ym exemplo de retorno ao consumir a rota v2/pix :