Callbacks transacionais enviados à URL de webhook + sufixo "/pix" #241
Comments
|
Não justificam as dificuldades de implantar regras de handling - em servidores específicos - já que os cenários que você citou podem muito bem resolvidos de outras formas. Assim como há /cob e /cobv, se não cabe dentro do próprio corpo da notificação enviada por callback ao webhook informações que identifiquem a transação como sendo um split, podem ser criados endpoint diferentes para tratar especificamente desse caso. De qualquer forma, me parece muito mais simples e plausível isso ser tratado no PSP ou no código que vai receber o webhook, com base no corpo da notificação, na chave utilizada e em outros fatores, do que na URL específica que foi utilizada no request do callback. |
Assim como o @renatofrota também não vejo necessidade. Um endpoint {WebHookURL} poderia receber qualquer extensibilidade que seja, isso já acontece com Gateways de Pagamento como o Paypal via WHMCS (Gerenciador Financeiro para Empresas de Hospedagem de SItes). Além disso vejo que poderia quebrar alguns webhooks que não usam url amigável, exemplo: https://esteemeusite112131212.com.br/webhook.php e com /pix ficaria: https://esteemeusite112131212.com.br/webhook.php/pix |
Isso. É muito fácil agregar qualquer
Pois é. Nem todos os sistemas estão preparados ou suportariam receber um novo diretório "/pix" e um "index.php" (ou outra extensão) que vai responder pelo request a "/pix", mesmo com modificações mais extensas nas configurações de handling dos requests. |
|
Só lembrando que a data de publicação da 2.0.0 já com isso foi 18 de Setembro, e hoje é 9 de Dezembro... mas fora isso, a questão de caminhos, extensões e nomes default é totalmente configurável quando se tem controle do ambiente. Hospedagem compartilhada não combina com mTLS e webhook. |
Obrigado pela contribuição, porém:
Mas tudo bem, em face do |
Não há ambientes perfeitos... mas os que tem controle operacional suficiente para mTLS/Webhook não tem os problemas alegados neste issue. |
|
Prezados, conforme foi relatado, está assim desde 18 de setembro. No momento temos um efeito de congelamento em especificações do Pix na linha "Esse navio já partiu". |
Ok. Então os PSPs deverão se adequar e passar a enviar os callbacks para a "WebhookUrl/pix" o quanto antes, correto? |
Mas sobre o issue do #239, é bem provável que alguma modificação seja necessária para garantir autorização. Há a idéia que coloquei lá do /chave, há outra idéia sugerida pela Gerencianet que logo deve ser postada lá... mas a idéia deles é a que provavelmente seja menos diferente da API atual. |
E precisa de qualquer mudança na API? Tem ideias lá que não exigem mudança alguma. E não é possível o PSP validar o mTLS por conta própria na hora de enviar o callback? 🤔 |
As que tem melhor escalabilidade são as que tem mudanças.
Não é esse o problema; o que você descreve é autenticação, e o problema é de autorização. |
Correto @renatofrota |
ninrod
added
Documentação
|
Bom dia pessoal! No caso de o PSP adicionar Nesse sentido, não seria mais interessante forçar que o cadastro da URL de webhook venha com |
Sendo bem sincero, concordo que a API poderia ter sido escrita sem exigir o |
@ninrod Não poderia haver uma consulta com os PSPs que já implementaram ou estão em fase de implementação da API? Assim a gente mantém sem o /pix como está em alguns PSPs. |
Infelizmente, não funciona desta maneira. Qualquer mudança incompatível, ainda que aparentemente inofensiva, pode causar grandes prejuízos não previstos tanto aos usuários recebedores quanto aos PSPs recebedores. Por outro lado, acredito que podemos conviver com essa exigência do |
|
Eu não vejo problema em notificar numa URL diferente; na verdade o que se passa no parâmetro é um path base, e /pix é um desses métodos. Hoje é o único, mas pode não ser no futuro. E também não vejo a exigência do /pix como incontornável. |
|
@ninrod nos ajude a esclarecer alguns entendimentos sobre a concatenação do Procede? |
|
Como está documentado, o O valor de $query passaria de
Inclusive, adicionar um query param vazio ao fim é uma forma de fazer a quarta URL do seu exemplo funcionar mesmo nos casos em que as configurações do location
Se a documentação for atualizada de forma a esclarecer que o Mas, atualização por atualização, seria melhor atualizar a documentação retirando essa regra. Ainda não me convenceu a exigência desse |
Entendi o pensamento. Se houver &pix= no final, aí sim entendo que seria uma URL válida. Talvez seria melhor nem permitir query params no cadastro da URL de webhook. |
Permitir query parms se tornou uma necessidade pra contornar isso do /pix, já não existe motivo suficiente para que fosse enviado /pix se não pudermos contornar ele com algo seria péssimo. |
Entendo que é exatamente assim que está especificado. Concordo que seria melhor remover a exigência do |
Eu acho que seria bastante trivial: Quem já está com URL cadastrada, continua recebendo da forma que recebe hoje, já que ao mudar de PSP teria que cadastrar de novo, então se está fora da spec não precisa forçar a correção. Mas dá pra universalizar e incluir todo mundo na spec sem quebrar nada: O PSP tem a data de cadastramento das URLs pra responder isso no endpoint de consulta (se não tem a data mas salvou a URL absolutamente igual o EC pediu na API, hoje adiciona o "/pix" na hora do envio do callback - que é o certo, inclusive, pois previa-se o uso dessa URL para outros fins, com /outracoisa ao fim), então:
Inclusive, a minha suspeita é que tem outros PSPs que não estão adicionando o "/pix", de qualquer forma, pois ficou muito obscuro até pouco tempo atrás. Quando começamos a debater isso aqui no GitHub já tinha sistema operando. E, seja como for, se coordenar isso como falei acima, não quebra a spec, pelo contrário, acaba com as divergências de implantação. |
|
Só comentando que eu apontei no #289 que já há uma necessidade hoje para uma rota diferente de /pix no webhook, uma rota /cob que manda um objeto cob avisando que aquele objeto mudou assincronamente de situação para REMOVIDO_PELO_PSP. Então o que eu sempre alertei de motivo para se ter um /pix na notificação já se materializou. |
Penso que o rota deveria ser sempre o mesmo, só tratar o body sempre... Essa imposição arbitrária de forçar alguém a utilizar uma rota acaba criando mais trabalho para ambos os lados... |
Mas como já lembrado, esse navio já partiu... as duas formas fazem sentido para mim, mas já que já se escolheu uma, as adições precisam ser coerentes. |
Concordo com o princípio mas não no uso dele como argumento aqui. Não vejo incoerência nenhuma mandar objetos pix e cob para um mesmo webhook. Mas é o BACEN que decide, claro, nós só argumentamos. Mas, @rubenskuhl , aproveitando: você que andou conversando com vários PSPs, sabe como eles implantaram isso? Estão respeitando o E @ninrod , você tem alguma ideia sobre a razão para os demais PSPs não darem as caras aqui pra debater? |
|
Navio partiu, sem problemas... mas para manter coerência com o resto da API, faria sentido colocar a versão da API, como Independente da URL, ao receber a notificação, como cliente recebedor de pix atrelado à cobrança, preciso consultar o PSP novamente acerca da cobrança para pegar o estado de Na API não está claro se as informações do pix no callback (devoluções inclusive) devem coincidir obrigatoriamente com a resposta da consulta cob (a menos de concorrência, parece óbvio, mas interpretações existem). Como cliente recebedor usando pix atrelado à cobrança, me parece mais seguro consultar sempre a Outra coisa é que, pelo JSON da resposta Outro exemplo: quando o recebedor enviar uma solicitação de devolução para um pix com cobrança, só faria sentido se a cobrança estiver CONCLUIDA, sim? Do contrário, devo fazer um Finalmente, uma dúvida de homologação/segurança/consistência: que garantias o recebedor tem, de que não irá aparecer uma devolução com status |
Entendo que "tratar" o body é alterar o objeto que é enviado na notificação. supondo que não exista a exigência de {
type: "pix", // <--- ( para adicionar "cob", por ex, além de ter que introduzir novos elementos no enum, a estrutura mudaria "daqui pra baixo". Complicado.)
arrayDePix: [...],
}Pensando em evolução, o append do
@renatofrota, usar a "data" de registro da URL é uma saída interessante. Entretanto, esse procedimento exige implementação adicional por parte dos PSPs recebedores para adicionar essa inteligência e agrega mais um nível de complexidade ao arranjo, além de criar uma nova área de dúvidas ("por que" o Bacen retirou o `append' do pix?, Não prometeram que não haveria "quebra"?, etc...) O critério que usamos para definir se uma mudança introduz uma "quebra" é o seguinte: Se eu incorporar a mudança
Tudo continua funcionado? Se sim, a mudança pode ser incorporada. Se não, tem que se discutir muito e pensar muito bem na alteração e com bastante calma. |
Debater aqui é uma liberalidade do PSP. Por ex., há PSPs que preferem se comunicar com o BCB diretamente via canal específico. |
|
@dev-gto , bom dia.
Ressalto que há um |
Entendo, mas já é uma melhoria em relação ao |
Eu citei a data mas acabei mudando a linha de raciocínio e, no fim, ela seria irrelevante para o que eu propus. Vou tentar ser mais claro e direto. Sobre a remoção do
Em ambos os casos (PSP adicionando Dito isso: se o Presume-se que o integrador deve ter controle sobre as configurações do virtualhost (Apache) / server (Nginx) / whatever para definir regras de mTLS, então ele deve ter controle sobre o tratamento do request (conforme "path" ou "location") para fazer o request apontar para o script específico que ele quiser, mesmo com um Problema casca grossa mesmo, seria tirar essa possibilidade colocando o |
@ninrod , Isso foi proposto anteriormente, aqui. É como o mercado todo funciona. O Pix foi na contramão. |
É isso mesmo. Ao fim da URL Completa.
Perfeito. |
|
Concordo com o @renatofrota Acrescento também que como o webhook não passa na "rede PIX" essa questão do |
A integração entre ECs e PSPs é tão importante quanto a entre PSPs e BACEN. Padrões existem para serem seguidos. |
Agora eu entendo que "esse barco já partiu" e não dá mais pra mexer. PSPs que eu sabia que estavam enviando o callback para Além disso, depois de ter aberto esse issue, até já encontrei algumas outras possibilidades de uso para o formato Por estas razões, estou fechando esse issue, o considero resolvido. Se alguém tiver razões pra debater isso ainda, sinta-se à vontade para abrir outro issue e referenciar argumentos que foram dados aqui (só não quero "encabeçar" o issue, agora que meu posicionamento mudou). Obrigado a quem colaborou. |
Segundo a documentação, os callbacks transacionais são enviados para "URLwebhook/pix".
Não vejo o menor sentido forçar o "/pix" na URL (exigiria regras de "handling" complexas em alguns webservers).
Poderiam me explicar se há motivo razoável para essa exigência?
Ou, preferivelmente, simplesmente abolir isso da documentação na próxima versão - o quanto antes (já que há PSPs enviando callbacks para a URL específica conforme determinada pelo EC, sem esse sufixo).
The text was updated successfully, but these errors were encountered: