Dúvidas API de Webhook

[alexpedrero]

Caros, boa tarde! Ficamos com algumas preocupações nas APIs de webhook documentadas: 1) O nome da URL é genérica (/webhook), isso não criará problemas de identificação da transação? 2) Como a URL de callback (do cliente recebedor) cadastrada será protegida?

Obrigado

[dmkamers]

Caros, boa tarde! Ficamos com algumas preocupações nas APIs de webhook documentadas:

1. O nome da URL é genérica (/webhook), isso não criará problemas de identificação da transação?

2. Como a URL de callback (do cliente recebedor) cadastrada será protegida?

Obrigado

@alexpedrero em /webhook o 'cliente da api' apenas registra uma url. Podes exemplificar melhor a questão por gentileza? Quando uma transação ocorrer, a url registrada (citada acima) recebe o POST com um objeto 'pix'. Este objeto contém todo o contexto da transação que foi realizada (recebida), e está sendo comunicada pelo PSP (que faz o POST) ao 'cliente da api' (que hospeda a url antes registrada). Sobre a segurança do endpoint de callback (servidor no lado do 'cliente da api'), está especificado o TLS mútuo.

[dmkamers]

Prezados, Há uma seção dedicada a webhook no novo "Anexo I - API Pix: Conceitos de Negócio", que faz parte do "Manual de Padrões para Iniciação do Pix", disponível na Página do Pix. - quadro "Regulamentação relacionada ao Pix" (à direita).

[ninrod]

Prezado @alexpedrero , podemos responder alguma questão adicional?

[flaviolenz]

(1) Se a pergunta foi em relacao a um ataque de DDOS, por exemplo, poderia-se especificar que os PSPs indicariam a seus clientes quais os IP's origem das chamadas. (2) Mas acredito que a pergunta foi em relacao a URL do recebedor ficar recebendo chamadas falsas (de alguem querendo burlar dizendo que algo foi pago, quando nao foi). (3) Ou, algo entre o PSP e o recebedor interceptar a mensagem e ter informações indevidamente.

Nao encontrei na especificacao, mas foi falado acima foi que um objeto do tipo PIX seria enviado ao webhook. *melhor que isso conste em alguma especificacao pra evitar misselanea de implementacoes que podem prejudicar a portabilidade de PSPs

O excesso de informacao poderia causar uma falha de segurança, tanto por qualquer interceptacao como pelo caso 2 (caso o ERP nao faca a chamada pra verificar a vericidade). O ideal é o wehbook ser chamado indicando somente a chave do objeto que sofreu alguma mudança (txid ou e2eid) e não passar nenhuma informação a mais. O sistema do recebedor, entao, faria uma chamada ao /pix/{e2eid} ou /cob/{txid} pra ver o status atual. (isso evitaria o caso 2) O oauth resolvem as questoes de autenticidade (resolve tambem o caso 3).

Estamos falando de Recebimento Pix. Mas o webhook tambem deveria contemplar as devolucoes de pagamentos. (no caso, webhook para o pagador)

[ninrod]

bom dia @flaviolenz ,

(2) Mas acredito que a pergunta foi em relacao a URL do recebedor ficar recebendo chamadas falsas (de alguem querendo burlar dizendo que algo foi pago, quando nao foi).

tem que fechar um canal mTLS para enviar callbacks.

Está especificado aqui.

Mas o webhook tambem deveria contemplar as devolucoes de pagamentos. (no caso, webhook para o pagador)

Também está especificado. Um pix pode estar associado a zero ou mais devoluções e essa informação é recebida via callback.

[flaviolenz]

tem que fechar um canal mTLS para enviar callbacks.

Muito pesado pra todo ERP-zinho implementar. E, desnecessario, na verdade. Bastaria que o ERP fizesse a consulta logo em seguida. Nem mesmo o HTTPS seria necessário.

Já fiz algumas implementações com webhook, mas desprezo os dados daqueles que mandam tudo e vou consultar eu mesmo o status das transacoes. Algumas adquirentes fazem (corretamente) so com uma notificacao. O webhook acaba servindo como um wakeup call. Outras, mandam todos os dados. Um ERP não atento à falha de segurança, vai considerar a mensagem toda.

Está especificado aqui.

Correto.. está ai mesmo. Minha sugestão eh que fosse um array de TXID ou e2eid e nao o array de Pix completo.

Mas o webhook tambem deveria contemplar as devolucoes de pagamentos. (no caso, webhook para o pagador)

Também está especificado. Um pix pode estar associado a zero ou mais devoluções e essa informação é recebida via callback.

Pode mandar o link de onde isso está?

Seria interessante ter o WebHook tambem para o Pagador. (um novo Pix mesmo - sem ser devolucao) Caso de uso: empresa faz o pagamento no Mobile Banking, e o ERP recebe o webhook com o PIX pago. Já está contemplado também?

[rubenskuhl]

HTTPS é o mínimo hoje em dia. A IETF está abolindo todos os protocolos sem criptografia de canal. Só por IP não dá num mundo onde ainda não há RPKI generalizado. Agora, se precisa ser mTLS ou se poderia ser outra forma, dá para discutir. Mas em a autenticação estando satisfeita, dá para confiar nos dados que vem no webhook, e economiza uma chamada de checagem no GET.

Apesar do BACEN nunca ter dito isso em todas as letras, eu entendo que a API Pix só contempla recebimento inicialmente pq a parte de pagamento virá com o IP (Iniciador de Pagamento) e o Open Banking.

[ninrod]

@flaviolenz, boa tarde.

E, desnecessario, na verdade. Bastaria que o ERP fizesse a consulta logo em seguida.

A consulta também requer mTLS e, ainda, Oauth2.

Pode mandar o link de onde isso está?

aqui

[renatofrota]

Boa noite, caros.

Partindo do pressuposto que meu sistema gera QR Code estáticos de pagamento para diferentes clientes (recebedores), entendo que terei duas opções para verificar/identificar se uma transação está concluída:

1. Consultar pelo txid o status da transação Pix de tempos em tempos (ou sob demanda, quando o pagador informar no meu sistema que fez o pagamento); ou

2. Ter previamente registrado um webhook que receberá notificações de novos pagamentos.

Pelo que eu entendi ao ler a documentação, em ambos os casos (seja para verificar a transação ou para fazer o registro do endereço de webhook) vou precisar realizar uma autenticação OAuth e essas consultas serão feitas ao PSP onde a chave relacionada à cobrança está cadastrada (e não a uma API central do BCB). Assim, minhas dúvidas são:

1. Onde posso encontrar documentação detalhada de como proceder a autenticação (obtenção dos tokens) e quais são as URLs de API de cada um dos PSP (já que os meus clientes - recebedores - poderão ter suas chaves vinculadas a qualquer um deles)?

2. O token OAuth é relativo a cada chave individualmente ou, caso negativo, qual é o escopo de autorização, exatamente?

3. No caso do token (e consequentemente o seu webhook) não ser específico por chave, não seria mais interessante a URL de webhook ser definida no ato da criação da cobrança/QR Code, permitindo maior flexibilidade no uso de múltiplas aplicações para gerar (e gerir) as cobranças por parte de um mesmo recebedor?

Obrigado desde já.

[rubenskuhl]

Partindo do pressuposto que meu sistema gera QR Code estáticos de pagamento para diferentes clientes (recebedores), entendo que terei duas opções para verificar/identificar se uma transação está concluída:

Algum motivo para ter preferido estático ao invés de dinâmico ? Não afeta a resposta, mas achei curioso ter menos opções quando isso costuma custar a mesma coisa.

1. Consultar pelo txid o status da transação Pix de tempos em tempos (ou sob demanda, quando o pagador informar no meu sistema que fez o pagamento); ou
2. Ter previamente registrado um webhook que receberá notificações de novos pagamentos.

Correto.

Pelo que eu entendi ao ler a documentação, em ambos os casos (seja para verificar a transação ou para fazer o registro do endereço de webhook) vou precisar realizar uma autenticação OAuth e essas consultas serão feitas ao PSP onde a chave relacionada à cobrança está cadastrada (e não a uma API central do BCB). Correto

Assim, minhas dúvidas são:

1. Onde posso encontrar documentação detalhada de como proceder a autenticação (obtenção dos tokens) e quais são as URLs de API de cada um dos PSP (já que os meus clientes - recebedores - poderão ter suas chaves vinculadas a qualquer um deles)?

Cada cliente vai precisar te passar URLs e tokens para você acessar...

2. O token OAuth é relativo a cada chave individualmente ou, caso negativo, qual é o escopo de autorização, exatamente?

Se é da conta ou da chave ? Eu imaginaria da conta, mas é uma pergunta interessante.

3. No caso do token (e consequentemente o seu webhook) não ser específico por chave, não seria mais interessante a URL de webhook ser definida no ato da criação da cobrança/QR Code, permitindo maior flexibilidade no uso de múltiplas aplicações para gerar (e gerir) as cobranças por parte de um mesmo recebedor?

Isso você pode fazer ao registrar, por exemplo, cliente1.webhook.exemplo.com.br no webhook do 1, cliente2.webhook.exemplo.com.br no do 2 etc. E isso pode ser feito usando entrada wildcard de DNS que aponta *.webhook.exemplo.com.br para o mesmo IP, e pelo indicador de Host no HTTP você sabe qual cliente é, que chave tem que apresentar etc. Basta que os PSPs suportem SNI (Server Name Indication).

@ninrod e @dmkamers , fica a sugestão da API Pix explicitamente apontar que o suporte a SNI é requisito.

[renatofrota]

Partindo do pressuposto que meu sistema gera QR Code estáticos de pagamento para diferentes clientes (recebedores), entendo que terei duas opções para verificar/identificar se uma transação está concluída:

Algum motivo para ter preferido estático ao invés de dinâmico ? Não afeta a resposta, mas achei curioso ter menos opções quando isso costuma custar a mesma coisa.

Apenas me pareceu mais simples a implementação - é um benefício poder gerar os QR Codes "offline": eles serão gerados "no matter what", desde que o formato especificado seja seguido - e não prevejo um recurso que o dinâmico ofereça que seja necessário aos meus clientes (vou reler a documentação para ver se deixei algo passar batido mas agradeço se você puder apontar algum recurso que pode ser crucial na sua visão).

1. Onde posso encontrar documentação detalhada de como proceder a autenticação (obtenção dos tokens) e quais são as URLs de API de cada um dos PSP (já que os meus clientes - recebedores - poderão ter suas chaves vinculadas a qualquer um deles)?

Cada cliente vai precisar te passar URLs e tokens para você acessar...

Se eu já achei difícil obter esse tipo de informação, imagina os clientes? Seria muito mais simples eu oferecer uma lista de PSPs já suportados e eles simplesmente apontarem qual é o PSP deles - ou solicitarem a inclusão de um ainda não suportado, se for o caso.

1. O token OAuth é relativo a cada chave individualmente ou, caso negativo, qual é o escopo de autorização, exatamente?

Se é da conta ou da chave ? Eu imaginaria da conta, mas é uma pergunta interessante.

Obrigado. Minha esposa também vive me dizendo que eu faço boas perguntas... (afirmação mútua). :grin:

1. No caso do token (e consequentemente o seu webhook) não ser específico por chave, não seria mais interessante a URL de webhook ser definida no ato da criação da cobrança/QR Code, permitindo maior flexibilidade no uso de múltiplas aplicações para gerar (e gerir) as cobranças por parte de um mesmo recebedor?

Isso você pode fazer ao registrar, por exemplo, cliente1.webhook.exemplo.com.br no webhook do 1, cliente2.webhook.exemplo.com.br no do 2 etc. E isso pode ser feito usando entrada wildcard de DNS que aponta *.webhook.exemplo.com.br para o mesmo IP, e pelo indicador de Host no HTTP você sabe qual cliente é, que chave tem que apresentar etc. Basta que os PSPs suportem SNI (Server Name Indication).

Sim, é bastante viável dessa forma, obrigado pela sugestão.

Mas ainda acho que seria muito mais simples se houvesse uma forma de registrar uma URL webhook atrelado ao QR Code estático (ou atrelado à própria chave Pix em si), eliminando totalmente a necessidade de um relacionamento mais estreito com os PSPs só para ter acesso à informação de "baixa" do pagamento, que é basicamente o único recurso necessário para 99,9% dos clientes de sistemas ERP ou cobrança.

Inclusive, os pagamentos passarão sempre pelo BC quando efetivados, certo? O próprio BCB poderia se encarregar de mandar uma notificação (quando houver a URL de webhook registrada para aquele QR Code ou chave) quando um pagamento fosse efetuado, em vez de deixar isso na mão dos PSP. Da forma que está definido hoje, quaisquer indisponibilidades e falhas de operação por parte dos PSPs vão afetar a imagem e confiabilidade dos clientes no Pix/BCB.

[rubenskuhl]

Algum motivo para ter preferido estático ao invés de dinâmico ? Não afeta a resposta, mas achei curioso ter menos opções quando isso costuma custar a mesma coisa.

Apenas me pareceu mais simples a implementação - é um benefício poder gerar os QR Codes "offline": eles serão gerados "no matter what", desde que o formato especificado seja seguido - e não prevejo um recurso que o dinâmico ofereça que seja necessário aos meus clientes (vou reler a documentação para ver se deixei algo passar batido mas agradeço se você puder apontar algum recurso que pode ser crucial na sua visão).

O dinâmico checa automaticamente se o valor é o especificado e recusa o valor se não for, no estático o valor vem, você precisa ver que não foi suficiente para quitar aquela cobrança e aí fazer um refund do Pix ou informar um crédito do pagador no estabelecimento.

O dinâmico evita automaticamente recebimentos duplicados; o PSP pode recusar QR-Code estático com TxID duplicado se você pedir e ele tiver essa opção, mas não é automático.

Cada cliente vai precisar te passar URLs e tokens para você acessar...

Se eu já achei difícil obter esse tipo de informação, imagina os clientes? Seria muito mais simples eu oferecer uma lista de PSPs já suportados e eles simplesmente apontarem qual é o PSP deles - ou solicitarem a inclusão de um ainda não suportado, se for o caso.

Então você vai precisar falar com cada PSP, ver como é a URL, mas ainda sim vai precisar do seu cliente para obter tokens de acesso. A conta é do cliente, o dinheiro é do cliente... alguns bancos e instituições de pagamento tem documentação online da API (BTG, PagSeguro), e tenho uma de grande banco que posso disponibilizar.

O que você poderia fazer é você ser o correntista que recebe o dinheiro, faz a conciliação e só manda Pix para o cliente já conciliado. Aí tanto faz onde o cliente tenha conta, você transfere o dinheiro para ele via Pix mesmo. E que pode ser a cada Pix recebido, se o cliente quiser o dinheiro na hora, ou a cada dia útil, ou a cada algumas horas... e aí você faz uma integração única e o cliente tem banco onde ele bem quiser. Isso inclusive permite que você procure o fornecedor com melhor custo; enquanto os grandes bancos cobram tipicamente 50 centavos por Pix, há preços de até 5 centavos no mercado.

Mas ainda acho que seria muito mais simples se houvesse uma forma de registrar uma URL webhook atrelado ao QR Code estático (ou atrelado à própria chave Pix em si), eliminando totalmente a necessidade de um relacionamento mais estreito com os PSPs só para ter acesso à informação de "baixa" do pagamento, que é basicamente o único recurso necessário para 99,9% dos clientes de sistemas ERP ou cobrança.

Aí entra o ponto da sua pergunta do escopo de autenticação. Se houver um escopo "chave", isso está resolvido.

Inclusive, os pagamentos passarão sempre pelo BC quando efetivados, certo? O próprio BCB poderia se encarregar de mandar uma notificação (quando houver a URL de webhook registrada para aquele QR Code ou chave) quando um pagamento fosse efetuado, em vez de deixar isso na mão dos PSP. Da forma que está definido hoje, quaisquer indisponibilidades e falhas de operação por parte dos PSPs vão afetar a imagem e confiabilidade dos clientes no Pix/BCB.

Isso transformaria o Banco Central num banco de varejo... me parece que não é o papel dele no ecossistema. Sobre imagem, isso é assim mesmo num sistema de revendas/canais, e por isso o BC tem se preocupado em estabelecer regras claras para o arranjo para que imagem no arranjo Pix como um todo não seja prejudica por elementos menos cuidadosos.

[renatofrota]

O dinâmico checa automaticamente se o valor é o especificado e recusa o valor se não for, no estático o valor vem, você precisa ver que não foi suficiente para quitar aquela cobrança e aí fazer um refund do Pix ou informar um crédito do pagador no estabelecimento.

O dinâmico evita automaticamente recebimentos duplicados; o PSP pode recusar QR-Code estático com TxID duplicado se você pedir e ele tiver essa opção, mas não é automático.

Obrigado por detalhar. São diferenciais de menor relevância no meu cenário. A possibilidade de geração offline é mais vantajosa, "apesar dos pesares".

Então você vai precisar falar com cada PSP, ver como é a URL, mas ainda sim vai precisar do seu cliente para obter tokens de acesso. A conta é do cliente, o dinheiro é do cliente... alguns bancos e instituições de pagamento tem documentação online da API (BTG, PagSeguro), e tenho uma de grande banco que posso disponibilizar.

Se puder me enviar, eu agradeceria muito. Meu e-mail é meu nome de usuário at "big G".

O que você poderia fazer é você ser o correntista que recebe o dinheiro, faz a conciliação e só manda Pix para o cliente já conciliado. Aí tanto faz onde o cliente tenha conta, você transfere o dinheiro para ele via Pix mesmo. E que pode ser a cada Pix recebido, se o cliente quiser o dinheiro na hora, ou a cada dia útil, ou a cada algumas horas... e aí você faz uma integração única e o cliente tem banco onde ele bem quiser. Isso inclusive permite que você procure o fornecedor com melhor custo; enquanto os grandes bancos cobram tipicamente 50 centavos por Pix, há preços de até 5 centavos no mercado.

Mais uma boa dica, mas vejo 2 possíveis inconvenientes:

1. receber, "reter" (custodiar) e repassar dinheiro sem ter no CNAE nada relativo a intermediação (e preciso ver outras possíveis implicações fiscais);

2. se a "iCPMF" for aprovada, o cliente perderá 4% a mais em relação a receber o PIX diretamente, só por ter passado nas minhas mãos primeiro (isso se eu repassar o meu custo com o imposto) - e dá-lhe mais possíveis implicações fiscais/judiciais por repassar custo de imposto (por mais que eu determine em contrato que os 4% são operacionais, não consigo confiar no judiciário brasileiro a ponto de correr esse risco :cry: ).

Mas ainda acho que seria muito mais simples se houvesse uma forma de registrar uma URL webhook atrelado ao QR Code estático (ou atrelado à própria chave Pix em si), eliminando totalmente a necessidade de um relacionamento mais estreito com os PSPs só para ter acesso à informação de "baixa" do pagamento, que é basicamente o único recurso necessário para 99,9% dos clientes de sistemas ERP ou cobrança.

Aí entra o ponto da sua pergunta do escopo de autenticação. Se houver um escopo "chave", isso está resolvido.

Tomara que tenha.

Inclusive, os pagamentos passarão sempre pelo BC quando efetivados, certo? O próprio BCB poderia se encarregar de mandar uma notificação (quando houver a URL de webhook registrada para aquele QR Code ou chave) quando um pagamento fosse efetuado, em vez de deixar isso na mão dos PSP. Da forma que está definido hoje, quaisquer indisponibilidades e falhas de operação por parte dos PSPs vão afetar a imagem e confiabilidade dos clientes no Pix/BCB.

Isso transformaria o Banco Central num banco de varejo... me parece que não é o papel dele no ecossistema. Sobre imagem, isso é assim mesmo num sistema de revendas/canais, e por isso o BC tem se preocupado em estabelecer regras claras para o arranjo para que imagem no arranjo Pix como um todo não seja prejudica por elementos menos cuidadosos.

Se o BC não cobrar do recebedor por essa notificação (que poderia ser única, sem retentativas nem nada do tipo - nas falhas pontuais, uma verificação manual resolve), não vejo por que isso o transformaria num banco de varejo. O dinheiro ainda saiu da conta transacional do pagador no PSP A e foi enviado à conta transacional do recebedor no PSP B. Ele só estaria provendo uma funcionalidade extra para o recebedor de informá-lo sobre a baixa. Informação essa que diz respeito a uma transação que envolve o dinheiro do cliente, inclusive. E já é o próprio BACEN que fornece ao PSP pagador a informação acerca da conta/PSP de recebimento para viabilizar a transação, então ele já é uma fonte de informação no processo, de qualquer forma.

[rubenskuhl]

Mais uma boa dica, mas vejo 2 possíveis inconvenientes:

1.

receber, "reter" (custodiar) e repassar dinheiro sem ter no CNAE nada relativo a intermediação (e preciso ver outras possíveis implicações fiscais);

Você poderia ser visto como um arranjo de pagamento, mas não como efetivo beneficiário.

1. se a "iCPMF" for aprovada, o cliente perderá 4% a mais em relação a receber o PIX diretamente, só por ter passado nas minhas mãos primeiro (isso se eu repassar o meu custo com o imposto) - e dá-lhe mais possíveis implicações fiscais/judiciais por repassar custo de imposto (por mais que eu determine em contrato que os 4% são operacionais, não consigo confiar no judiciário brasileiro a ponto de correr esse risco 😢 ).

A iCPMF especulada é de 0.2%, mas os demais se aplicam se isso infelizmente for aprovado.

[renatofrota]

Errei em uma "casa" o percentual, seriam 0,4%, pois a proposta do governo é que eu pague 0,2% pra receber e mais 0.2% pra mandar pro cliente (diferente da CPMF, que era cobrada só do pagador).

Vou pesquisar a respeito das burocracias de me qualificar um arranjo de pagamento (quando na verdade eu só queria mesmo era desenvolver software, rsrs). Pois é, bom mesmo seria se o BC enviasse a notificação. :(

Em qui, 8 de out de 2020 22:21, Rubens Kuhl notifications@github.com escreveu:

Mais uma boa dica, mas vejo 2 possíveis inconvenientes:

1.

receber, "reter" (custodiar) e repassar dinheiro sem ter no CNAE nada relativo a intermediação (e preciso ver outras possíveis implicações fiscais);

Você poderia ser visto como um arranjo de pagamento, mas não como efetivo beneficiário.

1. se a "iCPMF" for aprovada, o cliente perderá 4% a mais em relação a receber o PIX diretamente, só por ter passado nas minhas mãos primeiro (isso se eu repassar o meu custo com o imposto) - e dá-lhe mais possíveis implicações fiscais/judiciais por repassar custo de imposto (por mais que eu determine em contrato que os 4% são operacionais, não consigo confiar no judiciário brasileiro a ponto de correr esse risco 😢 ).

A iCPMF especulada é de 0.2%, mas os demais se aplicam se isso infelizmente for aprovado.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/bacen/pix-api/issues/9#issuecomment-705910808, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAZ2XSSYFQA4V337AACBRALSJZQTJANCNFSM4RYWSHLA .

[ninrod]

Caros apenas respondendo a uma questão:

O token OAuth é relativo a cada chave individualmente ou, caso negativo, qual é o escopo de autorização, exatamente?

O escopo de autorização do access Token é relativo ao client_id que o requisitou.

[flaviolenz]

o PSP pode recusar QR-Code estático com TxID duplicado

Pode? Entendi que o estatico, pode ser de um produto, impresso na vitrine, por exemplo... vários clientes vão usar o mesmo QR pra comprar aquele produto e o TxId seria esse código do produto.

[ninrod]

Pode?

O QR estático não está atrelado a uma cobrança, então não, não poderia.

[rubenskuhl]

o PSP pode recusar QR-Code estático com TxID duplicado

Pode? Entendi que o estatico, pode ser de um produto, impresso na vitrine, por exemplo... vários clientes vão usar o mesmo QR pra comprar aquele produto e o TxId seria esse código do produto.

O que o BACEN já disse em outro issue é que se a pedido do estabelecimento, o PSP pode sim rejeitar TxID publicado. O que ele não pode é rejeitar TxID duplicado indiscriminadamente, pois cada estabelecimento pode fazer usos onde o TxID se repita.

[ninrod]

O que o BACEN já disse em outro issue é que se a pedido do estabelecimento, o PSP pode sim rejeitar TxID publicado. O que ele não pode é rejeitar TxID duplicado indiscriminadamente, pois cada estabelecimento pode fazer usos onde o TxID se repita.

a pedido do estabelecimento, sim. Mas seria uma feature "não padronizada", embora tecnicamente possível. Realmente, entendo que a documentação não impede que seja implementado desta maneira. Não entramos em detalhes sobre isso. Em tese, o PSP poderia ou não apresentar essa característica que seria configurada, por exemplo, via dashboard ou algo assim.

[lucapwn]

Olá, boa noite! Tudo tranquilo, galera? Alguém pode me dar um exemplo de como posso cadastrar o link do meu webhook através do método PUT em PHP? Estou tentando há um tempo, mas não estou conseguindo. Até o momento não encontrei nenhum exemplo de como posso implementar. Vocês poderiam me ajudar? Grande abraço! :D

[joelemanoel]

Olá, boa noite! Tudo tranquilo, galera? Alguém pode me dar um exemplo de como posso cadastrar o link do meu webhook através do método PUT em PHP? Estou tentando há um tempo, mas não estou conseguindo. Até o momento não encontrei nenhum exemplo de como posso implementar. Vocês poderiam me ajudar? Grande abraço! :D

<?php
$ch = curl_init();
curl_setopt($ch, CURLOPT_URL, "ENDPOINT DO PSP");
curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
curl_setopt($ch, CURLOPT_HTTPHEADER, array(
    "Authorization: Bearer: TOKEN AQUI"
    "Content-Type: application/json"
));
curl_setopt($ch, CURLOPT_CUSTOMREQUEST, "PUT");
curl_setopt($ch, CURLOPT_POSTFIELDS, json_encode([
    "webhookUrl" => "SUA URL AQUI"
]));
?>

[GuzztMega]

Pessoal boa tarde, tudo bem? Estou implementando pela primeira vez a API do PIX na minha empresa. Eles ja possuem uma integração com o Santander, agora estou responsável por implementar a integração com o BB e Itau. É possível utilizar o exato mesmo webhook da minha empresa para todos os bancos? Tentei fazer a chamada no endpoint do Itau /pix_recebimentos/v2/webhook/{chavePix} com o corpo em json "webhookUrl": "https://exemplo.com.br/pix/webhook".

Fiquei com essa duvida devido ao seguinte retorno e não encontrei em lugar nenhum algo parecido:

{
    "type": "https://pix.bcb.gov.br/api/v2/error/WebhookOperacaoInvalida",
    "title": "Webhook inválido.",
    "status": 400,
    "detail": "A presente requisição busca criar um webhook sem respeitar o schema ou, ainda, com sentido semanticamente inválido.",
    "correlationId": "272e2bb8-f2ba-47e2-9d45-32aaaf63d6c6",
    "violacoes": [
        {
            "razao": "422 : [{\"messages\":[{\"errorCode\":\"422\",\"message\":\"There is a target registered using same product_name, target_name and message_type using target-id {hashCode}\"}]}]",
            "propriedade": "webhookUrl",
            "valor": "https://exemplo.com.br/pix/webhook"
        }
    ]
}

[rubenskuhl]

Pessoal boa tarde, tudo bem? Estou implementando pela primeira vez a API do PIX na minha empresa. Eles ja possuem uma integração com o Santander, agora estou responsável por implementar a integração com o BB e Itau. É possível utilizar o exato mesmo webhook da minha empresa para todos os bancos? Tentei fazer a chamada no endpoint do Itau /pix_recebimentos/v2/webhook/{chavePix} com o corpo em json "webhookUrl": "https://exemplo.com.br/pix/webhook".

Fiquei com essa duvida devido ao seguinte retorno e não encontrei em lugar nenhum algo parecido:

{
    "type": "https://pix.bcb.gov.br/api/v2/error/WebhookOperacaoInvalida",
    "title": "Webhook inválido.",
    "status": 400,
    "detail": "A presente requisição busca criar um webhook sem respeitar o schema ou, ainda, com sentido semanticamente inválido.",
    "correlationId": "272e2bb8-f2ba-47e2-9d45-32aaaf63d6c6",
    "violacoes": [
        {
            "razao": "422 : [{\"messages\":[{\"errorCode\":\"422\",\"message\":\"There is a target registered using same product_name, target_name and message_type using target-id {hashCode}\"}]}]",
            "propriedade": "webhookUrl",
            "valor": "https://exemplo.com.br/pix/webhook"
        }
    ]
}

Essa mensagem tem alguma outra causa que não o uso do mesmo atendedor de webhook por mais de um PSP. Agora, a configuração de mTLS para esse cenário requer incluir múltiplas autoridades certificadoras e checagem de múltiplos common-name... então pode ser mais simples ter URLs diferentes, mesmo que mapeadas para o mesmo atendedor.

[pedroeckel]

Pessoal boa tarde, tudo bem? Estou implementando pela primeira vez a API do PIX na minha empresa. Eles ja possuem uma integração com o Santander, agora estou responsável por implementar a integração com o BB e Itau. É possível utilizar o exato mesmo webhook da minha empresa para todos os bancos? Tentei fazer a chamada no endpoint do Itau /pix_recebimentos/v2/webhook/{chavePix} com o corpo em json "webhookUrl": "https://exemplo.com.br/pix/webhook".

Fiquei com essa duvida devido ao seguinte retorno e não encontrei em lugar nenhum algo parecido:

{
    "type": "https://pix.bcb.gov.br/api/v2/error/WebhookOperacaoInvalida",
    "title": "Webhook inválido.",
    "status": 400,
    "detail": "A presente requisição busca criar um webhook sem respeitar o schema ou, ainda, com sentido semanticamente inválido.",
    "correlationId": "272e2bb8-f2ba-47e2-9d45-32aaaf63d6c6",
    "violacoes": [
        {
            "razao": "422 : [{\"messages\":[{\"errorCode\":\"422\",\"message\":\"There is a target registered using same product_name, target_name and message_type using target-id {hashCode}\"}]}]",
            "propriedade": "webhookUrl",
            "valor": "https://exemplo.com.br/pix/webhook"
        }
    ]
}

@GuzztMega Você conseguiu resolver esse problema? Estou enfrentando a mesma dificuldade ao realizar a integração com o Itaú

[ValfridoWolff]

Pessoal boa tarde, tudo bem? Estou implementando pela primeira vez a API do PIX na minha empresa. Eles ja possuem uma integração com o Santander, agora estou responsável por implementar a integração com o BB e Itau. É possível utilizar o exato mesmo webhook da minha empresa para todos os bancos? Tentei fazer a chamada no endpoint do Itau /pix_recebimentos/v2/webhook/{chavePix} com o corpo em json "webhookUrl": "https://exemplo.com.br/pix/webhook". Fiquei com essa duvida devido ao seguinte retorno e não encontrei em lugar nenhum algo parecido:

{
    "type": "https://pix.bcb.gov.br/api/v2/error/WebhookOperacaoInvalida",
    "title": "Webhook inválido.",
    "status": 400,
    "detail": "A presente requisição busca criar um webhook sem respeitar o schema ou, ainda, com sentido semanticamente inválido.",
    "correlationId": "272e2bb8-f2ba-47e2-9d45-32aaaf63d6c6",
    "violacoes": [
        {
            "razao": "422 : [{\"messages\":[{\"errorCode\":\"422\",\"message\":\"There is a target registered using same product_name, target_name and message_type using target-id {hashCode}\"}]}]",
            "propriedade": "webhookUrl",
            "valor": "https://exemplo.com.br/pix/webhook"
        }
    ]
}

@GuzztMega Você conseguiu resolver esse problema? Estou enfrentando a mesma dificuldade ao realizar a integração com o Itaú

@pedroeckel, você mencionou há um tempo estar com problemas para implementar seu Webhook Api. Estou com o mesmo problema que você mencionou. Você conseguiu solucionar? No meu caso a integração é com o Santander. Consegue dar alguma dica por favor? Grato, Valfrido Wolff