[Aprimoramento] endpoints /Webhook

ninrod commented 4 years ago

Prezados,

Reunindo contribuições de #111, #62 e #118, e tentando encontrar "o meio do caminho", a proposta de aprimoramento das notificações que se coloca aqui seria associar uma URL de notificação a uma chave Pix considerando que o canal de comunicação seria mTLS.

Seria, grosso modo, assim:

PUT /webhook/{chavepix}

#request

{
  url: "meuserver.example.com/hotsitedepromocoesdiadasmaes",
}

// response 201

{ 
  timestampCriacao: "...",
  chave: "email@example.com",
  url: "meuserver.example.com/hotsitedepromocoesdiadasmaes",
}

//obs: se tentar criar um webhook associado a uma chave que ativamente já está recebendo notificações, HTTP [406](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/406).

Também agregaria-se:


//verifica um webhook especifico
GET /webhook/{chavepix}

// remove um esquema de notificação "do ar"
DELETE /webhook/{chavepix}

// E talvez este aqui: retorna os webhooks estabelecidos. 
// quais parâmetros de busca seriam interessantes? 
//Faz sentido estabelecermos este método?
GET /webhook

// Não teríamos PATCH. o PUT já resolveria o cenário de alteração de URL para aquela chave de maneira idempotente.

Pensamentos?

cc: @rubenskuhl, @renatofrota, @felipedelima19, @feinstein, @fernandogodoy, @franciscotfmc

franciscotfmc commented 4 years ago

Quando uma pacs008 chega, ela não vem com a chave que o pagador utilizou na leitura do QR Code ou no envio manual do Pix.

Sendo assim, acho que, em referência à issue #111, cairíamos no mesmo problema de "não saber em qual URL notificar", pois o integrador pode possuir várias chaves cadastradas, cada qual com sua URL.

_PS.: estou com o pensamento na notificação do QR Code Estático com txid_

ninrod commented 4 years ago

Quando uma pacs008 chega, ela não vem com a chave que o pagador utilizou na leitura do QR Code ou no envio manual do Pix.

Eu questionaria essa afirmação.

franciscotfmc commented 4 years ago

Se não me engano, Prxy.Id é opcional.

rubenskuhl commented 4 years ago

Só um comentário sobre #118, é que a chamada /timestamp existiria tanto no Webhook quanto na API direta, não apenas no Webhook, e este issue discute o Webhook...

ninrod commented 4 years ago

Se não me engano, Prxy.Id é opcional.

É opcional porque existe a "transferência manual", como fazemos para TED, por exemplo. Se houver chave envolvida, o PSP pagador é obrigado a atribuí-la neste campo.

rubenskuhl commented 4 years ago

Prezados,

Reunindo contribuições de #111, #62 e #118, e tentando encontrar "o meio do caminho", a proposta de aprimoramento das notificações que se coloca aqui seria associar uma URL de notificação a uma chave Pix considerando que o canal de comunicação seria mTLS.

Eu não sei se a manutenção do mTLS daria a simplificação imaginada no #62 ... eu gosto porque dá um ótimo nível de segurança, mas acho que o objetivo de negócio embutido naquele pedido não é atendido. É por isso que lá eu sugeri o uso de um serviço público de mensageria ao estilo FCM (Firebase Cloud Messaging).

ninrod commented 4 years ago

Eu não sei se a manutenção do mTLS daria a simplificação imaginada no #62 ... eu gosto porque dá um ótimo nível de segurança, mas acho que o objetivo de negócio embutido naquele pedido não é atendido. É por isso que lá eu sugeri o uso de um serviço público de mensageria ao estilo FCM (Firebase Cloud Messaging).

O mTLS é realmente um requisito aqui. Este caso de uso específico poderia ser atendido via uma API específica de um gateway ou TEF hipotético, penso eu.

rubenskuhl commented 4 years ago

Se não me engano, Prxy.Id é opcional.

É opcional porque existe a "transferência manual", como fazemos para TED, por exemplo. Se houver chave envolvida, o PSP pagador é obrigado a atribuí-la neste campo.

E como a transferência manual não tem TxID, já não seria notificada via webhook de qualquer forma. Então o webhook por chave conseguiria definir aonde alocar QR-Code estático. Eu só colocaria a definição de que em não havendo um webhook por chave configurado, a notificação não deveria ir para nenhum outro webhook, já que os outros por client_id podem ou não estar aptos ou interessados nos estáticos. Ou toda seleção de webhook passaria a exigir chave, o que para mim funcionaria também.

felipedelima19 commented 4 years ago

Grande @ninrod , acredito que já é uma evolução significativa para deixar as notificações mais flexíveis sem inferir em menor segurança.

Meu ponto é que, adicionalmente à sua sugestão, poderíamos considerar a sugestão abaixo de incluir a url de notificação no payload do /cob:

PUT /cob

{
  "calendario": {
    "dataDeVencimento": "2020-12-31",
    "validadeAposVencimento": 30
  },
  "loc": {
    "id": "789"
  },
  "devedor": {
    "cpf": "12345678909",
    "nome": "Francisco da Silva"
  },
  "valor": {
    "original": "123.45",
    "multa": {
      "multaPercentual": "15"
    },
    "juro": {
      "juroAbsoluto": "2.00"
    },
    "desconto": [
      {
        "data": "2020-10-31",
        "descontoAbsoluto": "30.00"
      }
    ]
  },
  "chave": "5f84a4c5-c5cb-4599-9f13-7eb4d419dacc",
  "solicitacaoPagador": "Cobrança dos serviços prestados."
  "urlNotificacao": "meuserver.example.com/hotsitedepromocoesdiadasmaes"
}

Com isso, não limitamos o surgimento de diversos modelos de negócio e dado que toda comunicação segue com mTLS, não vejo perda em questões de segurança.

rubenskuhl commented 4 years ago

Sobre usar POST, eu tenho a sensação de que apesar de não ser necessária idempotência, que por homogeneidade com os demais métodos da API os métodos PUT, PATCH e DELETE poderiam ser usados para criar, alterar e remover webhooks.

ninrod commented 4 years ago

@rubenskuhl

Ou toda seleção de webhook passaria a exigir chave, o que para mim funcionaria também

Essa seria a linha.

ninrod commented 4 years ago

prezado @franciscotfmc ,

Meu ponto é que, adicionalmente à sua sugestão, poderíamos considerar a sugestão abaixo de incluir a url de notificação no payload do /cob:

certo, com mTLS, acredito que a questão de segurança estaria equacionada.

O problema que vejo neste cenário de definir as URLs de notificação "por cobrança" é que você não teria um endpoint para "gerenciamento" das URLs. Aliás, isto é um problema?

Gosto da ideia de eliminar os endpoints em /webhook e, mesmo assim, continuar com a feature. Simplifica a API, o que é ótimo. Então vejo que adotaria-se "por cobrança" XOR "por chave". Ou um ou outro, mas não nenhum e não os dois.

Tendo isso em vista, na possibilidade "por cobrança", vejo os seguintes problemas:

não haveria o problema de perguntar: quais são minhas URLs que estão recebendo notificações?
Do modo como está apresentado, por chave, com um DELETE vc desliga todas aquelas notificações para aquela chave. No modo "cobrança", não há essa possibilidade. Deixo a questão para reflexão.
como ficaria a questão da notificação dos QR estáticos? "por chave" endereça essa questão, "por cobrança" não.

pensamentos?

cryptographix commented 4 years ago

Não sei se entendi bem as questões postas, mas penso que o requisito de usar mTLS tende a inviabilizar esses esquemas de notificação para diferentes endpoints, configurados por cob ou chave.

A implementação de mTLS por lado do "usuário" recebedor não é trivial, considerando questões de aquisição, instalação e renovação de certificados, sem falar do problema perene da guarda segura das chaves privadas, etc. Por exemplo, o certificado terá de ser enviado ao PSP durante a configuração do endpoint .. e alterado ao ser renovado, removido ao ser revogado etc.

Empresas de porte média e grande possuem equipes capacitadas para isso (ou deveriam ter :)) mas as pequenas não, sem falar dos MEI ou usuários comuns.

Será que ter uma granularidade tão fina nas notificações vale a pena? Não seria mesmo esse o papel de um gateway PIX? Por outro lado, algum nível de diferenciação me parece ser interessante.

Por outro lado, se relaxar o requisito de uso do mTLS, penso ser fundamental incluir algum tipo de autenticador nas notificações, de preferência dinâmico (variando por tempo/sequencial/nonce), e/ou mesmo um JWS usando HMAC com segredo informado pelo cliente no cadastro do endpoint?

rubenskuhl commented 4 years ago

Entre por cobrança ou por chave, prefiro por chave, em sendo um XOR. E por chave seria útil enumerar por GET ; GET sem chave lista todos os webhooks, GET com chave o daquela chave.

felipedelima19 commented 4 years ago

não haveria o problema de perguntar: quais são minhas URLs que estão recebendo notificações?

Na minha visão, isso não deveria estar dentro do escopo da API PIX, deixando a responsabilidade dessa gestão para o resource owner.

Do modo como está apresentado, por chave, com um DELETE vc desliga todas aquelas notificações para aquela chave. No modo "cobrança", não há essa possibilidade. Deixo a questão para reflexão.

Não vejo problema nisso, aquela cobrança especificamente ainda notificaria na url informada na request, contudo, próximas cobranças já não teriam mais a url informada, logo sem notificação.

como ficaria a questão da notificação dos QR estáticos? "por chave" endereça essa questão, "por cobrança" não.

Por isso, na minha visão, seriam soluções complementares. Respeitando sempre a url da cobrança, caso informada. Contudo, se pensarmos que a gestão dos webhooks não deva ser escopo da API PIX, isso ficaria a cargo dos PSPs/integradores.

Penso nisso pois o PSP é o nível mais baixo na cadeia, logo, quanto mais limitarmos o escopo da notificação nesse nível, impactamos toda a cadeia "pra cima".

Dessa forma, deixamos o modelo super flexível e agnóstico, não limitando nenhum modelo de negócio.

cryptographix commented 4 years ago

Quanto a granularidade das notificações por chave, há algum requisito na API Pix no que o onboarding/cadastro do cliente restringe quais chaves DICT podem ser utilizadas para a geração de cobranças, além do "óbvio" que a chave deve estar associada àquele PSP como participante do SPI?

Qualquer cliente da API pode criar cobranças para quaisquer chaves do PSP?

rubenskuhl commented 4 years ago

não haveria o problema de perguntar: quais são minhas URLs que estão recebendo notificações?

Na minha visão, isso não deveria estar dentro do escopo da API PIX, deixando a responsabilidade dessa gestão para o resource owner.

Eu prefiro isso na API Pix onde código pode ser usado para confirmar situações operacionais esperadas. Se isso estiver também acessível num dashboard, ótimo, mas o essencial é estar na API.

ninrod commented 4 years ago

@rubenskuhl:

E por chave seria útil enumerar por GET ; GET sem chave lista todos os webhooks, GET com chave o daquela chave.

Interessante. não precisaria do id, a chave seria o id.

ninrod commented 4 years ago

@felipedelima19 ,

Não vejo problema nisso, aquela cobrança especificamente ainda notificaria na url informada na request, contudo, próximas cobranças já não teriam mais a url informada, logo sem notificação.

O caso de uso é: você quer desligar todas as notificações para aquela chave. Você tem milhões de cobranças diferentes, vinculadas àquela chave, e você quer desligar todas. Como proceder?

ninrod commented 4 years ago

@felipedelima19

Penso nisso pois o PSP é o nível mais baixo na cadeia, logo, quanto mais limitarmos o escopo da notificação nesse nível, impactamos toda a cadeia "pra cima".

Não entendo assim. Você poderia ter um gateway de pagamentos ofertando uma API com capacidade de notificação "por cobrança" mesmo com a API Pix estabelecendo uma semântica "por chave".

ninrod commented 4 years ago

@SeanWykes

Quanto a granularidade das notificações por chave, há algum requisito na API Pix no que o onboarding/cadastro do cliente restringe quais chaves DICT podem ser utilizadas para a geração de cobranças, além do "óbvio" que a chave deve estar associada àquele PSP como participante do SPI?

Qualquer cliente da API pode criar cobranças para quaisquer chaves do PSP?

Exatamente, essa linha de atuaçào está bastante aderente à proposta.

ninrod commented 4 years ago

@rubenskuhl

Eu prefiro isso na API Pix onde código pode ser usado para confirmar situações operacionais esperadas. Se isso estiver também acessível num dashboard, ótimo, mas o essencial é estar na API.

Concordo.

franciscotfmc commented 4 years ago

A implementação de mTLS por lado do "usuário" recebedor não é trivial, considerando questões de aquisição, instalação e renovação de certificados, sem falar do problema perene da guarda segura das chaves privadas, etc. Por exemplo, o certificado terá de ser enviado ao PSP durante a configuração do endpoint .. e alterado ao ser renovado, removido ao ser revogado etc.

Concordo que a instalação por parte do integrador possa não ser trivial. Aquisição e renovação o PSP Recebedor consegue abstrair.

franciscotfmc commented 4 years ago

Uma reflexão sobre URLs por cobrança.

EC gera 100 mil cobranças com a URL https://xyz;
EC percebe que precisa trocar a URL das cobranças geradas para https://abc;
EC precisa fazer 100 mil consumos para atualizar a URL de notificação. Caso alguma cobrança tenha sido paga nesse meio tempo, ele poderá ter perdido o callback;

felipedelima19 commented 4 years ago

Uma reflexão sobre URLs por cobrança.

EC gera 100 mil cobranças com a URL https://xyz;

EC percebe que precisa trocar a URL das cobranças geradas para https://abc;

EC precisa fazer 100 mil consumos para atualizar a URL de notificação. Caso alguma cobrança tenha sido paga nesse meio tempo, ele poderá ter perdido o callback;

Esse cenário realmente existe? Eu nunca vi isso acontecer, acho que é um corner case super específico.

franciscotfmc commented 4 years ago

@felipedelima19 pior que vejo isso acontecer de forma recorrente, principalmente em cenários de migração quando um recebedor (dono da conta no PSP) migra de um provedor de serviços para outro (empresa que implementa a integração).

Deixando claro que não sou contra URL por cob. Simplemente trazendo um problema que acredito ser importante levarmos em consideração. Talvez reforça a ideia de URL padrão para a conta.

rubenskuhl commented 4 years ago

Uma reflexão sobre URLs por cobrança.

EC gera 100 mil cobranças com a URL https://xyz;

EC percebe que precisa trocar a URL das cobranças geradas para https://abc;

EC precisa fazer 100 mil consumos para atualizar a URL de notificação. Caso alguma cobrança tenha sido paga nesse meio tempo, ele poderá ter perdido o callback;

Esse cenário realmente existe? Eu nunca vi isso acontecer, acho que é um corner case super específico.

Você diz em termos de volume ? Sim, isso é o que geramos por mês só de boletos, sem contar cartão de crédito. E há preços no mercado para 1 milhão de cobranças por mês (10x) isso, porque há quem tenha esse nível de demanda (concessionárias, farmácias etc.)

Agora, de ter que alterar ? Tudo pode precisar de alteração, inclusive por deployment de novo sistema. Mas tipicamente um sistema legado pode ser mantido por tanto tempo quanto necessário. Então fácil é melhor, mas se for uma consequência de ter selecionado URL diferente da da chave, paciência... a questão é que a definição de webhook por chave para mim parece essencial, e a por cobrança, um "plus a mais". E a condição de contorno é que seja só uma ou outra. Se houvessem ambas, eu escolheria por chave e quem preferir por cobrança, que use...

rubenskuhl commented 4 years ago

@felipedelima19 pior que vejo isso acontecer de forma recorrente, principalmente em cenários de migração quando um recebedor (dono da conta no PSP) migra de um provedor de serviços para outro (empresa que implementa a integração).

Neste caso as cobranças já estão criados no PSP atual, então precisariam ser canceladas e reemitidas de qualquer forma... ou de operar simultaneamente com os dois PSPs, até as cobranças e suas potenciais devoluções de Pix ultrapassem o prazo de devolução.

Deixando claro que não sou contra URL por cob. Simplemente trazendo um problema que acredito ser importante levarmos em consideração. Talvez reforça a ideia de URL padrão para a conta.

Eu também não sou contra, desde que exista a geral. Ter só a específica é que não, mas aí entra a condição de contorno de só uma delas estar disponível.

felipedelima19 commented 4 years ago

Uma reflexão sobre URLs por cobrança.

EC gera 100 mil cobranças com a URL https://xyz;

EC percebe que precisa trocar a URL das cobranças geradas para https://abc;

EC precisa fazer 100 mil consumos para atualizar a URL de notificação. Caso alguma cobrança tenha sido paga nesse meio tempo, ele poderá ter perdido o callback;

Esse cenário realmente existe? Eu nunca vi isso acontecer, acho que é um corner case super específico.

Você diz em termos de volume ? Sim, isso é o que geramos por mês só de boletos, sem contar cartão de crédito. E há preços no mercado para 1 milhão de cobranças por mês (10x) isso, porque há quem tenha esse nível de demanda (concessionárias, farmácias etc.)

Agora, de ter que alterar ? Tudo pode precisar de alteração, inclusive por deployment de novo sistema. Mas tipicamente um sistema legado pode ser mantido por tanto tempo quanto necessário. Então fácil é melhor, mas se for uma consequência de ter selecionado URL diferente da da chave, paciência...

Meu ponto é mais sobre alterar. Se extrapolarmos a situação, isso pode acontecer pra qualquer parâmetro do recurso, certo? Não apenas o parâmetro url.

a questão é que a definição de webhook por chave para mim parece essencial, e a por cobrança, um "plus a mais". E a condição de contorno é que seja só uma ou outra. Se houvessem ambas, eu escolheria por chave e quem preferir por cobrança, que use...

Concordo, sendo que ambas as opções não são excludentes e sim complementares.

felipedelima19 commented 4 years ago

@felipedelima19 pior que vejo isso acontecer de forma recorrente, principalmente em cenários de migração quando um recebedor (dono da conta no PSP) migra de um provedor de serviços para outro (empresa que implementa a integração).

Mas em um cenário de migração de PSPs, as cobranças teriam que ser recriadas anyway, certo? Dado que o recebedor mudou de PSP, alterar somente a URL de notificação não seria suficiente.

Deixando claro que não sou contra URL por cob. Simplemente trazendo um problema que acredito ser importante levarmos em consideração. Talvez reforça a ideia de URL padrão para a conta.

Cara, sinceramente não vejo isso como um problema. É um cenário que não há outra forma de ser contornado. A meu ver, a motivação para o recurso /webhooks existir não pode ser "uma maneira mais fácil de alterar a url de notificação em massa", e sim atender a diversos modelos de negócio.

SadyCoimbraEfi commented 4 years ago

Uma reflexão sobre URLs por cobrança.

EC gera 100 mil cobranças com a URL https://xyz;

EC percebe que precisa trocar a URL das cobranças geradas para https://abc;

EC precisa fazer 100 mil consumos para atualizar a URL de notificação. Caso alguma cobrança tenha sido paga nesse meio tempo, ele poderá ter perdido o callback;

Esse cenário realmente existe? Eu nunca vi isso acontecer, acho que é um corner case super específico.

Trabalhamos hoje com ambos cenários, Url por aplicação, ou chave, e url por cobranças. É recorrente a necessidade de atualização da Url por motivos de alteração de IPs, migração de serviços etc.

Para os cenários por chave a alteração é simples, no entanto em um cenário por cobrança deve ser feito o consumo título a título, uma vez que na Url pode estar presente, por exemplo, o txid ou número do pedido como parâmetro (algo que vemos ser utilizado hoje).

https://meuserver.example.com/hotsitedepromocoesdiadasmaes?txid=txid&pedido=12548

A liberdade para o integrador é maior, mas fica comprometido o ponto de manutenção da integração.

franciscotfmc commented 4 years ago

@rubenskuhl , @felipedelima19 Na verdade, o volume que eu coloquei aí foi só para exemplificar o trabalho que o integrador teria que ter para atualizar a URL cobrança a cobrança. Para os PSP's eu acredito que o volume não é problema. Quanto mais cobranças geradas, melhor.

Apesar disso, eu, como integrador, não gostaria de ter esse trabalho de atualizar as URLs cobrança a cobrança.

Reforço que não me oponho à ideia, porém penso que é bem mais simples do que ter uma URL por chave ou por cobrança, ter uma URL atrelada à conta transacional.

Nesse caso, o integrador escolheria OU utilizar URL da conta (única), OU URLs por client_id (podem variar).

cryptographix commented 4 years ago

A implementação de mTLS por lado do "usuário" recebedor não é trivial, considerando questões de aquisição, instalação e renovação de certificados, sem falar do problema perene da guarda segura das chaves privadas, etc. Por exemplo, o certificado terá de ser enviado ao PSP durante a configuração do endpoint .. e alterado ao ser renovado, removido ao ser revogado etc.

Concordo que a instalação por parte do integrador possa não ser trivial. Aquisição e renovação o PSP Recebedor consegue abstrair.

Concordo. O letsencrypt comprovou que é possível abstrair esses processos, mesmo que até hoje é preciso reinstalar o python no AWS Linux antes de cada renovação de cert ;(

Meu ponto é que, para uma granularidade a nivel de URL por cobrança, qual o caso de uso? Será que os recebedores de pequeno porte / individuais terão como fazer um mTLS com o PSP?

ninrod commented 4 years ago

@SeanWykes

Meu ponto é que, para uma granularidade a nivel de URL por cobrança, qual o caso de uso?

Eu também não consigo enxergar um "killer use case" para a URL por cobrança dado que teríamos na mesa a URL de notificação por chave.

Apenas sendo transparente, a não ser que tenhamos aqui um "killer use case" para URL por cobrança, vamos de URL por chave porque:

nada impede o gateway ou TEF de oferecer uma API apresentando "URL por cobrança";
a URL por cobrança não resolve o cenário dos QR estáticos;
O BACEN não gostaria, se possível, de disponibilizar na API duas maneiras para fazer a mesma coisa. ("keep it simple"). por isso o "XOR;
é difícil, na URL por cobrança, desligar "todas as URLs de notificação" vinculadas àquela conta/chave;
há cenários inexplorados: poderia usar uma URL de notificação já utilizada em outra cobrança?;
a URL por chave já oferece um grau de flexibilidade muito bom e melhora o que já temos em termos de especificação.
Estamos aprimorando a API para a "largada", mas sempre há a possibilidade de agregarmos novas funcionalidades no futuro e de aprimorarmos a API. Precisamos fechar rapidamente uma versão estavél para que os PSPs recebedores possam implementar adequadamente as funcionalidades.

Pensamentos?

@SeanWykes :

Será que os recebedores de pequeno porte / individuais terão como fazer um mTLS com o PSP?

reforço que seria um mercado em que a atuação dos gateways/TEFs seria importante.

ninrod commented 4 years ago

@rubenskuhl ,

Sobre usar POST, eu tenho a sensação de que apesar de não ser necessária idempotência, que por homogeneidade com os demais métodos da API os métodos PUT, PATCH e DELETE poderiam ser usados para criar, alterar e remover webhooks.

Mudei a "spec" para PUT, utilizando a chave e eliminando a necessidade de agregar o id.

rodolfopatane commented 4 years ago

Talvez eu esteja publicando na issue errada me corrijam por favor.

O uso de webhook precisa implementar esse tipo de segurança? Não é uma barreira adicional como citou @SeanWykes para pequenos empreendedores? Será que as PSP vão confiar exclusivamente no webhook para validar transações? ou seria usado apenas como notificação para uma validação real no payload da cobrança? Talvez com a finalidade de prevenir injeção?

ninrod commented 4 years ago

@rodolfopatane , boa tarde.

Não é uma barreira adicional como citou @SeanWykes para pequenos empreendedores?

O BACEN, criador do arranjo Pix, quer estabelecer um nível mínimo de segurança que entende necessário. Para atender estes pequenos empreendedores, há players, como Gateways e TEFs, que oferecerão suas próprias APIs com outros parâmetros de segurança, possivelmente.

rubenskuhl commented 4 years ago

@ninrod , no Fórum Pix foi dito que a API requisito é a 2.0, e a 2.1 terá prazo ainda a definir. Isso no caso de pagamento com vencimento/desconto/juros não é problema pois são parâmetros não presentes na 2.0, mas como fica no caso do webhook ? Seria o caso de criar uma 2.0.1 apenas com a mudança do webhook já na forma na 2.1 ?

renatofrota commented 4 years ago

@ninrod

Em relação a URL ser por chave ou por cobrança: a URL definida para a chave poderia ser a padrão (cobrindo QR Codes estáticos) e podendo ser "sobrescrita" caso exista uma URL específica naquela Cobrança. Não acho que sejam "dois meios de fazer a mesma coisa" pois no caso do QR Code estático não há outro meio que não esse (a URL estar atrelada à chave) e no caso das Cobranças, é natural que a flexibilidade seja maior (e o conjunto de chaves por conta transacional é limitado).

O @sadycoimbraGn deu exemplo de URL:

https://meuserver.example.com/hotsitedepromocoesdiadasmaes?txid=txid&pedido=12548

Eu entendo que tamanha especificidade (número de txid e de pedido) estar presente na URL só é uma necessidade no caso do request de notificação ser um GET simples. Poderia ser simplificado como meuserver.example.com/hotsitedepromocoesdiadasmaes (que poderia estar até mesmo na chave, se acabar sendo a única opção) e o request enviado pelo PSP recebedor incluir informações sobre qual é a cobrança que está sendo notificada.

@SeanWykes

Será que os recebedores de pequeno porte / individuais terão como fazer um mTLS com o PSP?

Concordo com você. Respondo: pouquíssimos. Uma barreira não justificada, no meu ponto de vista. Até mesmo a definição de qual será a URL de notificação da chave, é algo que poderia ser oferecido por uma interface mais simples que não a própria API. Entendo que a maioria dos recebedores de pequeno porte / individuais vão usar exclusivamente esse recurso da API (notificações de pagamento), o que não justifica (no meu ponto de vista) isso estar associado à obtenção de client_id e chaves, geração (e renovação) de certificados e tudo mais. Se isso fosse disponível no app / dashboard do PSP, facilitaria muito a adoção.

@ninrod

Chegou a ver a minha sugestão (aqui) de que cada URL de notificação poderia ter uma chave de codificação associada e as notificações serem enviadas codificadas com esta)? Isso pode resolver essa neura de que as URLs devem estar sob um canal mTLS entre o recebedor e o PSP.

ninrod commented 4 years ago

@ninrod , no Fórum Pix foi dito que a API requisito é a 2.0, e a 2.1 terá prazo ainda a definir. Isso no caso de pagamento com vencimento/desconto/juros não é problema pois são parâmetros não presentes na 2.0, mas como fica no caso do webhook ? Seria o caso de criar uma 2.0.1 apenas com a mudança do webhook já na forma na 2.1 ?

Estas correções no webhook devem entrar agora sim, seria "por fora destas outras mudanças". Podemos tratar como bug e definir na 2.0.1. É uma ótima observação. @rubenskuhl

rubenskuhl commented 4 years ago

@ninrod , no Fórum Pix foi dito que a API requisito é a 2.0, e a 2.1 terá prazo ainda a definir. Isso no caso de pagamento com vencimento/desconto/juros não é problema pois são parâmetros não presentes na 2.0, mas como fica no caso do webhook ? Seria o caso de criar uma 2.0.1 apenas com a mudança do webhook já na forma na 2.1 ?

Estas correções no webhook devem entrar agora sim, seria "por fora destas outras mudanças". Podemos tratar como bug e definir na 2.0.1. É uma ótima observação. @rubenskuhl

Já o reuso de location ficaria para a 2.1.0, imagino... outra definição relevante seria colocar ou não o /v2 já na 2.0.1, o que talvez fosse prudente.

ninrod commented 4 years ago

Já o reuso de location ficaria para a 2.1.0, imagino... outra definição relevante seria colocar ou não o /v2 já na 2.0.1, o que talvez fosse prudente.

Sim, bem observado.

rubenskuhl commented 4 years ago

De todo modo, quero lembrar que restrições técnicas geralmente são contornadas com criatividade, dificultar o acesso ao webhook talvez aumente o volume de requisições no payload da cobrança, ja que nada impede a empresa de iniciar uma tarefa de checagem com requisições em sequência para acompanhar a mudança de estado sem uso do webhook, isso pode provocar um aumento expressivo nas requisições.

O uso de mTLS se aplica tanto ao webhook quanto ao acesso à API do PSP para requisições em sequência, então eu não vejo como isso estaria sendo estimulado.

rodolfopatane commented 4 years ago

De todo modo, quero lembrar que restrições técnicas geralmente são contornadas com criatividade, dificultar o acesso ao webhook talvez aumente o volume de requisições no payload da cobrança, ja que nada impede a empresa de iniciar uma tarefa de checagem com requisições em sequência para acompanhar a mudança de estado sem uso do webhook, isso pode provocar um aumento expressivo nas requisições.

O uso de mTLS se aplica tanto ao webhook quanto ao acesso à API do PSP para requisições em sequência, então eu não vejo como isso estaria sendo estimulado.

Agradeço pelo esclarecimento.

renatofrota commented 4 years ago

De todo modo, quero lembrar que restrições técnicas geralmente são contornadas com criatividade, dificultar o acesso ao webhook talvez aumente o volume de requisições no payload da cobrança, ja que nada impede a empresa de iniciar uma tarefa de checagem com requisições em sequência para acompanhar a mudança de estado sem uso do webhook, isso pode provocar um aumento expressivo nas requisições.

O uso de mTLS se aplica tanto ao webhook quanto ao acesso à API do PSP para requisições em sequência, então eu não vejo como isso estaria sendo estimulado.

Está sendo estimulado porque um fornecedor de soluções, diante da dificuldade dos clientes finais em fecharem mTLS diretamente com os PSPs e fazerem uso dos webhooks, vão acabar oferecendo uma espécie de "proxy" da API (com critérios de segurança menos rígidos entre o fornecedor da solução e o consumidor): o consumidor vai fazer polling nesse integrador e este integrador vai fazer polling na API Pix.

rubenskuhl commented 4 years ago

De todo modo, quero lembrar que restrições técnicas geralmente são contornadas com criatividade, dificultar o acesso ao webhook talvez aumente o volume de requisições no payload da cobrança, ja que nada impede a empresa de iniciar uma tarefa de checagem com requisições em sequência para acompanhar a mudança de estado sem uso do webhook, isso pode provocar um aumento expressivo nas requisições.

O uso de mTLS se aplica tanto ao webhook quanto ao acesso à API do PSP para requisições em sequência, então eu não vejo como isso estaria sendo estimulado.

Está sendo estimulado porque um fornecedor de soluções, diante da dificuldade dos clientes finais em fecharem mTLS diretamente com os PSPs e fazerem uso dos webhooks, vão acabar oferecendo uma espécie de "proxy" da API (com critérios de segurança menos rígidos entre o fornecedor da solução e o consumidor): o consumidor vai fazer polling nesse integrador e este integrador vai fazer polling na API Pix.

Dá para fazer proxy nos dois sentidos. Não há um motivo plausível para que apenas um deles seja mais carregado do que o outro. E como ambos tem mTLS...

renatofrota commented 4 years ago

Dá para fazer proxy nos dois sentidos.

Fato.

Não há um motivo plausível para que apenas um deles seja mais carregado do que o outro. E como ambos tem mTLS...

Discordo. Se o integrador receber uma chamada no seu próprio webhook e não conseguir enviar a notificação para o consumidor imediatamente, por indisponibilidade da URL de webhook na ponta do consumidor, o PSP não vai reenviar esta notificação.

Então, apesar de ser possível oferecer um proxy dos webhooks (no sentido PSP -> integrador -> consumidor) assim como é possível oferecer das chamadas de API no sentido mais tradicional (consumidor -> integrador -> PSP), para o integrador é muito mais fácil (exige menos trabalho, menos storage, menos tráfego, menos infra em geral) fazer o proxy das consultas on demand do consumidor (favorecendo o polling) do que receber webhooks do PSP e manter uma cópia de todo o repositório de Cobranças/Pix na sua própria estrutura para oferecer via API ao consumidor posteriormente e/ou operar sua própria política de re-envio das notificações para o consumidor.

rubenskuhl commented 4 years ago

Dá para fazer proxy nos dois sentidos.

Fato.

Não há um motivo plausível para que apenas um deles seja mais carregado do que o outro. E como ambos tem mTLS...

Discordo. Se o integrador receber uma chamada no seu próprio webhook e não conseguir enviar a notificação para o consumidor imediatamente, por indisponibilidade da URL de webhook na ponta do consumidor, o PSP não vai reenviar esta notificação.

Então, apesar de ser possível oferecer um proxy dos webhooks (no sentido PSP -> integrador -> consumidor) assim como é possível oferecer das chamadas de API no sentido mais tradicional (consumidor -> integrador -> PSP), para o integrador é muito mais fácil (exige menos trabalho, menos storage, menos tráfego, menos infra em geral) fazer o proxy das consultas on demand do consumidor (favorecendo o polling) do que receber webhooks do PSP e manter uma cópia de todo o repositório de Cobranças/Pix na sua própria estrutura para oferecer via API ao consumidor posteriormente e/ou operar sua própria política de re-envio das notificações para o consumidor.

Nos dois sentidos não há scaling, pois cada conta/client_id precisa de uma conexão diferente, pois o mTLS requer autenticação específica. Não há uma conexão genérica no sentido direto que passe número de conta e uma específica no webhook, as duas são por conta/client-id embutidos no client certificate do mTLS. Não há nada que favoreça um dos sentidos. Sugiro olhar as especificações de mTLS que vão quebrar esse conceito incorreto de que um é mais fácil do que o outro.

renatofrota commented 4 years ago

Dá para fazer proxy nos dois sentidos.

Fato.

Não há um motivo plausível para que apenas um deles seja mais carregado do que o outro. E como ambos tem mTLS...

Discordo. Se o integrador receber uma chamada no seu próprio webhook e não conseguir enviar a notificação para o consumidor imediatamente, por indisponibilidade da URL de webhook na ponta do consumidor, o PSP não vai reenviar esta notificação. Então, apesar de ser possível oferecer um proxy dos webhooks (no sentido PSP -> integrador -> consumidor) assim como é possível oferecer das chamadas de API no sentido mais tradicional (consumidor -> integrador -> PSP), para o integrador é muito mais fácil (exige menos trabalho, menos storage, menos tráfego, menos infra em geral) fazer o proxy das consultas on demand do consumidor (favorecendo o polling) do que receber webhooks do PSP e manter uma cópia de todo o repositório de Cobranças/Pix na sua própria estrutura para oferecer via API ao consumidor posteriormente e/ou operar sua própria política de re-envio das notificações para o consumidor.

Nos dois sentidos não há scaling, pois cada conta/client_id precisa de uma conexão diferente, pois o mTLS requer autenticação específica. Não há uma conexão genérica no sentido direto que passe número de conta e uma específica no webhook, as duas são por conta/client-id embutidos no client certificate do mTLS. Não há nada que favoreça um dos sentidos. Sugiro olhar as especificações de mTLS que vão quebrar esse conceito incorreto de que um é mais fácil do que o outro.

Talvez eu não tenha conseguido me explicar. Eu sei que os dois exigem mTLS (consumo da API para consultas e recebimento de notificações nas URLs webhook). O "integrador" aqui no exemplo já é um cliente final da API (usando mTLS tanto nas consultas quanto pra receber os requests para os webhooks determinados). Fim de conversa em relação às exigências da API Pix.

Agora pensa na outra ponta, onde o integrador se comunica com o cliente final dele, contratante do serviço (e as regras são mais flexíveis). É muito mais fácil ele providenciar meios para o cliente final "consumir a API indiretamente" (atuando como um proxy, e permitindo o cliente final fazer o polling, inclusive - assim, consumindo a API do PSP com o mesmo polling), do que "represando" requests webhook e implantando uma sistemática de retentativas de notificação (sistemática essa que o PSP já usa ao comunicar as atualizações via webhook para o integrador, que do ponto de vista do PSP já é o "consumidor da API"). Aí imagina um cenário onde o número de cobranças escale: centenas, milhares, milhões(...?) de cobranças em aberto sendo consultadas com polling.

Por isso eu digo que há um favorecimento ao uso de polling quando o uso de webhooks é mais restritivo. Se os webhooks pudessem ser enviados ao cliente final "efetivo" da cadeia (o cliente do integrador) sem essa exigência de mTLS, o consumo da API via polling seria muito menor.

rubenskuhl commented 4 years ago

Questões de escalabilidade afetam também esse suposto gateway; ao fazer polling, o gateway gastará mais recursos de seus próprios sistemas computacionais. Se eu fosse projetar um desses, eu com certeza usaria o webhook para diminuir o uso de recursos próprios. Então o incentivo para o uso do sistema bidirecional é até maior nesse caso, pois se trata de um sistema que potencialmente agregaria muitos outros clientes.

Outra questão que a experiência de usar webhook em cartão de crédito, após migrar de um adquirente que só tinha polling, mostra é que a taxa de perdas de transações é menor, o que sugere vantagens para todos os pontos da cadeia.

bacen / pix-api

[Aprimoramento] endpoints /Webhook #120