Webhooks, chaves e atualização de vínculo na conciliação

[franciscotfmc]

Boa tarde pessoal!

Sobre a definição dos webhooks por chaves, já discutida em outra issue (#120): ótimo, atenderá a muitos casos de uso.

Contudo, senti falta de mantermos ainda a criação da url por client_id, conforme a especificação 2.0.

Nosso entendimento é que existem casos de uso para URLs por credenciais. Entendemos que a criação da funcionalidade por chave é boa, mas a remoção da criação da URL por client_id é ruim, e quebra a versão 2.0.

Acredito que alguns PSPs e/ou ECs já estavam preparados para essa semântica por credencial. Falta 1 semana para o Go Live.

Sendo assim, segue o questionamento:
É possível oferecer os 2? Por chave e/ou por credencial?

[ninrod]

Nosso entendimento é que existem casos de uso para URLs por credenciais. Entendemos que a criação da funcionalidade por chave é boa, mas a remoção da criação da URL por client_id é ruim, e quebra a versão 2.0.

@franciscotfmc, consideramos como um bug. Vai ser por chave mesmo. Em tempo, o BCB não estabeleceu prazo para que os PSPs recebedores apresentem suas implementações da API. Só há prazo para os PSPs pagadores estarem aptos a lerem o QR.

[franciscotfmc]

@ninrod ainda estamos com dúvida nesse ponto:

O Webhook é único por client_id ou por client_id + chave?

Seria possível, por exemplo, o seguinte cadastro:

1. client_id_1, chave_1, URL_1
2. client_id_1, chave_2, URL_2
3. client_id_2, chave_3, URL_3
4. client_id_2, chave_1, URL_3

[ninrod]

@franciscotfmc , obrigado pela contribuição. Esse trecho selecionado é um bug.

O webhook é único por chave.

Se dois client_ids consultarem GET /webhook eles verão a mesma coisa.

[franciscotfmc]

Outra dúvida.

O client_id continua sendo por conta, certo?

No caso de uma atualização de vínculo, quando uma chave atrelada à conta-1 passa a apontar para a conta-2 (no mesmo PSP), temos um cenário problemático: lançamentos passam a acontecer na conta-2, sendo que o client_id está cadastrado na conta-1 e, portanto, não comunica com a conta-2. Perceba que as cobranças foram geradas para a conta 1, porém, os pagamentos começam a chegar para a conta 2.

Deixo a reflexão sobre o transtorno que é explicar isso a um cliente recebedor caso, por algum motivo, ele resolva fazer essa atualização de vínculo (não há nada que o impeça disso).

2 perguntas:

• Nesse cenário, recusa-se a ordem de pagamento? (txid não seria encontrado para a conta-2)
• Se for para aceitar, seria correto implementarmos algum bloqueio antes que a chave fosse alterada?

[ninrod]

corrigido

[franciscotfmc]

Bom dia @ninrod!

Você conseguiria nos ajudar no entendimento da questão acima de atualizações de vínculos?

[ninrod]

Bom dia @ninrod!

bom dia @franciscotfmc

Você conseguiria nos ajudar no entendimento da questão acima de atualizações de vínculos?

Acabou passando. Respondo agora.

[ninrod]

No caso de uma atualização de vínculo, quando uma chave atrelada à conta-1 passa a apontar para a conta-2 (no mesmo PSP), temos um cenário problemático: lançamentos passam a acontecer na conta-2, sendo que o client_id está cadastrado na conta-1 e, portanto, não comunica com a conta-2. Perceba que as cobranças foram geradas para a conta 1, porém, os pagamentos começam a chegar para a conta 2.

Deixo a reflexão sobre o transtorno que é explicar isso a um cliente recebedor caso, por algum motivo, ele resolva fazer essa atualização de vínculo (não há nada que o impeça disso).

2 perguntas:

Nesse cenário, recusa-se a ordem de pagamento? (txid não seria encontrado para a conta-2)
Se for para aceitar, seria correto implementarmos algum bloqueio antes que a chave fosse alterada?

client_id está cadastrado na conta-1

@franciscotfmc , o client_id não está cadastrado na "conta-1" ele está vinculado ao CPF/CNPJ do usuário recebedor. O client_id tem acesso a qualquer conta do usuário recebedor naquele PSP.

Perceba que as cobranças foram geradas para a conta 1,

@franciscotfmc , semanticamente não está correto. As cobranças foram geradads para a "chave1". Dependendo da chave, pode mudar com o tempo. O usuário recebedor tem que ter isso em mente. Se não se quer que a chave seja atualizada, basta utilizar-se a chave aleatória (EVP)

Deixo a reflexão sobre o transtorno que é explicar isso a um cliente recebedor caso, por algum motivo, ele resolva fazer essa atualização de vínculo (não há nada que o impeça disso).

Eu recomendaria utilizar sempre a chave EVP (chave aleatória). Não consigo enxergar nenhum motivo para não se utilizar exclusivamente chaves aleatórias para QRs Estáticos e Dinâmicos. Não existe portabilidade para chaves aleatórias e nem "atualização de vínculo".

Nesse cenário, recusa-se a ordem de pagamento? (txid não seria encontrado para a conta-2)

Não seria o caso. O usuário efetivamente recebeu o pagamento corretamente de acordo com a informação carregada pela chave. Nenhum problema. Isso teria que ser observado na conciliação a posteriori, talvez o ERP tenha que ter isso em mente para acertar as alocações dos recebíveis, mas fora isso, não vejo maiores problemas.

Se for para aceitar, seria correto implementarmos algum bloqueio antes que a chave fosse alterada?

Conforme exposto acima, usando EVP você evita qualquer problema relacionado à "atualização de vínculo".

[franciscotfmc]

@franciscotfmc , o client_id não está cadastrado na "conta-1" ele está vinculado ao CPF/CNPJ do usuário recebedor. O client_id tem acesso a qualquer conta do usuário recebedor naquele PSP.

@ninrod , se me permite, não vejo vantagem neste ponto. Inclusive, no meu entendimento, isso quebra em 100% a concepção trazida na versão 2.0. Essa definição me soa como um v3.0.

Concorda que é muito melhor para o integrador poder criar credenciais independentes em cada conta que ele possui no PSP? Cada credencial com o seu escopo, gerando lançamentos em extratos separados.

Se no onboarding para obtenção do client_id + credenciais o usuário está logado na conta X, não faz sentido, pra mim, aquele client_id ter poder para acessar a conta Y. Percebe a confusão aqui?

[ninrod]

@ninrod , se me permite, não vejo vantagem neste ponto. Inclusive, no meu entendimento, isso quebra em 100% a concepção trazida na versão 2.0. Essa definição me soa como um v3.0.

@franciscotfmc, na 2.0 não foi diferente. Não há nenhuma associação de client_id com conta em nenhum lugar da API. Você pode sim ter mais de um client_id por CNPJ/CPF, para organizar seus serviços. Por exemplo, o ERP pode ter um client_id próprio, mas com permissão apenas para endpoints de GET. Já o PDV, teria outro client_id, com permissão para PUTS, e por aí vai. Não há associação com contas.

Agora, nada impede que você estabeleça esta semântica como usuário recebedor. A API não proibe isso. Você poderia ter um client_id gerando cobranças apenas para uma chave específica. Isso é uma questão de organização interna e não uma restrição colocada pela API.

Concorda que é muito melhor para o integrador poder criar credenciais independentes em cada conta que ele possui no PSP? Cada credencial com o seu escopo, gerando lançamentos em extratos separados.

Não teria como funcionar: o txid é único por CNPJ/CPF do usuário recebedor e não por client_id. Se você tivesse dois client_ids diferentes conforme você descreve, cada um observando "seu próprio escopo de conta", um não poderia usar o txid do outro:

//client_id-1 e client_id-2 começam a operar, cada um ligado a sua respectiva conta

client_id-1: PUT /cob/1 //ok!
client_id-2: PUT /cob/1 //ERRO! o id 1 já foi utilizando por outro client_id. 

Se no onboarding para obtenção do client_id + credenciais o usuário está logado na conta X, não faz sentido, pra mim, aquele client_id ter poder para acessar a conta Y. Percebe a confusão aqui?

Não há essa premissa de o client_id-1 estar associado à "conta-1". O client_id é simplesmente uma parte da credencial conferida ao RO pelo AS, a semântica do onboarding é:

"O resource owner (RO) quer obter acesso automatizado aos seus dados junto ao PSP recebedor, o resource server (RS). Para isso, recebe credenciais do AS no qual o RS confia".

[franciscotfmc]

Agora, nada impede que você estabeleça esta semântica como usuário recebedor. A API não proibe isso. Você poderia ter um client_id gerando cobranças apenas para uma chave específica. Isso é uma questão de organização interna e não uma restrição colocada pela API.

Perfeito @ninrod , esse comentário nos ajudou bastante no entendimento.

"O resource owner (RO) quer obter acesso automatizado aos seus dados junto ao PSP recebedor, o resource server (RS). Para isso, recebe credenciais do AS no qual o RS confia".

Fechado!

Muito obrigado!