search

bacen / pix-api

API Pix: a API do Arranjo de Pagamentos Instantâneos Brasileiro, Pix, criado pelo Banco Central do Brasil.
https://bacen.github.io/pix-api
2.35k stars 265 forks source link

[Dúvida] Campos Obrigatórios Recebedor - Cobrança com Vencimento #218

Closed llatsch closed 3 years ago

llatsch commented 3 years ago

Em alguns campos obrigatórios do Recebedor, no cenário de cobranças com vencimento: recebedor.logradouro, recebedor.cidade, recebedor.uf, recebedor.cep, temos a seguinte frase "Conforme cadastrado na conta transacional associada à chave Pix.".

Devemos validar essas informações versos o cadastro de sua conta transacional associada a chave informada? Ou seja, caso o usuário recebedor informe uma cidade diferente do seu cadastro da conta associada a chave, devemos negar a criação da cobrança?

monise commented 3 years ago

@ninrod Aproveitando esse tópico, os dados do recebedor devem ser exibidos no payload JSON, mas as informações do recebedor não recebidas na API de geração de cobrança com vencimento (são apenas retornadas no response).

É esperado que o PSP já tenha os dados dos seus usuários recebedores e baseado na autenticação saiba recuperar essas informações? Ou está faltando essas informações na requisição do serviço de criação?

ninrod commented 3 years ago

@llatsch , bom dia.

Devemos validar essas informações versos o cadastro de sua conta transacional associada a chave informada? Ou seja, caso o usuário recebedor informe uma cidade diferente do seu cadastro da conta associada a chave, devemos negar a criação da cobrança?

Observe que o recebedor não informa nada em relação a esse conjunto de informações. O PSP recebedor apenas retorna esta informação. Então não há o que "validar".

@monise

@ninrod Aproveitando esse tópico, os dados do recebedor devem ser exibidos no payload JSON, mas as informações do recebedor não recebidas na API de geração de cobrança com vencimento (são apenas retornadas no response).

É esperado que o PSP já tenha os dados dos seus usuários recebedores e baseado na autenticação saiba recuperar essas informações? Ou está faltando essas informações na requisição do serviço de criação?

Exatamente conforme eu respondi para a @llatsch, @monise. É isso mesmo, de propósito. O PSP recebedor, via KYC, sabe onde o seu usuário recebedor "mora". Então você apenas retorna esta informação que já se encontra em sua base de dados, validada, sanitizada, etc...

A informação é retornada sim, no ato de criação da cobrança, mas o importante é esta informação ser retornada para o app do PSP do pagador via resposta do endpoint GET /cobv/pixUrlAccessToken.

franciscotfmc commented 3 years ago

Na resposta do payload da cobv, consta:

...
"recebedor": {
    "logradouro": "Rua 20 Numero 70, Bairro Luz",
    "cidade": "Belo Horizonte",
    "uf": "MG",
    "cep": "55120750",
    "cnpj": "58900633120711",
    "nome": "Empresa de Abastecimento SA"
},
...

Dúvidas:

renatofrota commented 3 years ago

Pois é... enquanto um webhook só pode ser definido com comunicação via API (mTLS) e só pode ser destinado a um host com mTLS - critérios rígidos de segurança, apesar de ser uma escolha unicamente do recebedor - os seus próprios dados ficam expostos no payload da cobv pra todo mundo ver (já que o payload ser assinado com JOSE não impede a leitura por qualquer pessoa, é só saber decodificar um base64).

E os dados do devedor também ficam expostos no payload da cob normal (sem vencimento) - inclusive sem máscara no CPF.

ninrod commented 3 years ago

Para o caso de pessoa natural, mascarar o CPF? Não é muito invaso, ainda no caso de PF, retornar um endereço em um endpoint aberto? Endereço este que pode ser onde a pessoa mora.

Existe uma lei que diz que tem que aparecer esses dados do recebedor no contexto de pagamento de título, mas aqui já estamos extrapolando os limites deste repositório. Acho válido consultar o DECEM quanto a esse aspecto.

cryptographix commented 3 years ago

@ninrod No endpoint de recuperação do payload COBV, são devolvidas as informações referentes ao recebedor, como logradoura, cep, etc. No entanto, nos exemplos de criação destes mesmos COBV, devem ser enviados as dados do devedor.

A minha dúvida é se está certo isso, os dados de endereço do devedor devem mesmo ser enviados para armazenamento do PSP? O que exatamente o PSP deve fazer com estes, uma vez que não fazem parte do payload?

Dica - tem um errinho no HTML, pois o botão do lado de "pessoa física" tem "object" e não "pessoa jurídica"

ninrod commented 3 years ago

A minha dúvida é se está certo isso, os dados de endereço do devedor devem mesmo ser enviados para armazenamento do PSP? O que exatamente o PSP deve fazer com estes, uma vez que não fazem parte do payload?

Sim, está certo. Objetivo é possibilitar o envio do título por meio físico.

Dica - tem um errinho no HTML, pois o botão do lado de "pessoa física" tem "object" e não "pessoa jurídica"

Ok, vamos verificar, obrigado.

ninrod commented 3 years ago

Dica - tem um errinho no HTML, pois o botão do lado de "pessoa física" tem "object" e não "pessoa jurídica"

@SeanWykes , esse aí é um bug do ReDoc. Problema está em "upstream".

ninrod commented 3 years ago

@SeanWykes , esse aí é um bug do ReDoc. Problema está em "upstream".

Na verdade não, nós que erramos mesmo. Achamos uma duplicação de linhas que estava gerando o erro. Deve ser corrigido na 2.2.1.

cryptographix commented 3 years ago

Sim, está certo. Objetivo é possibilitar o envio do título por meio físico.

Obrigado @ninrod. Só gostaria de compreender o uso que deve-se dar para estes dados, tanto do lado pagador como recebedor, quando de uma cobrança com vencimento.

  1. O PSP pagador recebe o "nome" do QR EMV e, ao consultar o URL, recebe a chave DICT e um bloco de dados do payload (inclusive com nome), também identificando o recebedor. Aí:
    • as informações do DICT são soberanas e devem ser exibidas ao usuário pagador ..
    • o nome EMV do QR deve ser desprezado
    • o recebedor.nome (PF/PJ) do payload deve fazer o quê? Desprezar? Exibir também? Bater contra os dados do DICT?

Teria como antecipar algo do próximo manual de UX que versa sobre o que deve ser exibido, e como, referente às cobranças com vencimento? No v2.1 atual, somente na página 45 tem uma imagem, desatualizada, da tela do pagador, mas consta ali, por exemplo, um campo "Juros/Periodo" que não há como inferir a partir do payload v2.1.

  1. O PSP recebedor, pelo KYC, detém os dados cadastrais do seu cliente (onboarding -> cliente_id). Deveria ter aí o CPF/CPNJ, nome, nome fantasia(PJ), endereço, etc.

    • Ao permitir inclusão de uma cobrança, deve verificar que a chave DICT informada pertence ao mesmo CPF/CNPJ? Senão, não teria como garantir a veracidade dos dados cadastrais?
    • Ou, deve ter um cadastro de todas os "donos CPF/CNPJ" das chaves DICT que podem ser utilizadas em cobranças?

  2. O PSP recebedor, na inclusão de uma cobrança com vencimento, ao receber os dados (facultativos) do "devedor", deve simplesmente refleti-lós no payload, sem maiores validações?

ninrod commented 3 years ago

O PSP pagador recebe o "nome" do QR EMV e, ao consultar o URL, recebe a chave DICT e um bloco de dados do payload (inclusive com nome), também identificando o recebedor. Aí:

  • as informações do DICT são soberanas e devem ser exibidas ao usuário pagador ..
  • o nome EMV do QR deve ser desprezado
  • o recebedor.nome (PF/PJ) do payload deve fazer o quê? Desprezar? Exibir também? Bater contra os dados do DICT?

@SeanWykes, Essa é uma pertinente pergunta de UX que eu recomendo ser encaminhada ao DECEM.

Teria como antecipar algo do próximo manual de UX que versa sobre o que deve ser exibido, e como, referente às cobranças com vencimento? No v2.1 atual, somente na página 45 tem uma imagem, desatualizada, da tela do pagador, mas consta ali, por exemplo, um campo "Juros/Periodo" que não há como inferir a partir do payload v2.1.

Novamente pertinente a pergunta relacionada ao Manual de UX @SeanWykes. Recomendo instar o DECEM a respondê-la.

Ao permitir inclusão de uma cobrança, deve verificar que a chave DICT informada pertence ao mesmo CPF/CNPJ? Senão, não teria como garantir a veracidade dos dados cadastrais?

Não há essa regra nos manuais, no momento. Até porque há grupos econômicos que apresentam diversos CNPJs válidos. Mas concordo que poderia acender um alerta em seus controles anti-fraude (por exemplo, nos casos envolvendo CPF).

Ou, deve ter um cadastro de todas os "donos CPF/CNPJ" das chaves DICT que podem ser utilizadas em cobranças?

Eu não sei se entendi corretamente, mas particularmente acho interessante existir uma funcionalidade, no dashboard, por exemplo, que permita o "cadastramento de uma lista de chaves DICT" a serem utilizadas na API para um CPF/CNPJ específico. Parece ser uma feature interessante de segurança.

O PSP recebedor, na inclusão de uma cobrança com vencimento, ao receber os dados (facultativos) do "devedor", deve simplesmente refleti-lós no payload, sem maiores validações?

É assim que está desenhado, até porque não mencionamos, na especificação, que esses campos deveriam sofrer validações específicas (além das óbvias, formato de cnpj/cpf, etc..., mas isso já está no schema). Validações contra a base da receita, por exemplo, não ajudam muito em mitigar fraudes: é muito fácil achar CPFs e CNPJs válidos.