[Nova Funcionalidade] Notificação de pagamentos #62
Comments
|
Me parece que há dois casos aqui: os que precisam dos recursos do QR-Code dinâmico, e os que podem funcionar com os recursos do QR-Code estático. Para o QR-Code dinâmico eu não vejo outra alternativa que não a API Pix. Agora, para QR-Code estático poderia haver algum tipo de push notification, ao estilo Firebase ou Firehose. Cada fornecedor de automação poderia ter um endereço na plataforma (ex: 0xAB312BF3) e o cliente configuraria no seu banco (via autenticação já existente) algo como "notificar recebimentos da chave X para 0xAB312BF3". A pergunta de 1 milhão de notas de R$200 é se isso é cost-effective o suficiente para permitir que varejos de ticket médio menor e com fornecedores de automação que cobram preços acessíveis usufruam disso. |
Na verdade eu pensei em algo muito mais simples do que isso. O MercadoPago (assim como o PayPal, PagSeguro e outros intermediadores e gateways), permitem que o cliente configure no painel da sua conta qual é a URL que receberá as notificações de pagamento. Todo pagamento é notificado para aquela URL, não importa se foi um envio de dinheiro de outra pessoa (espontâneo), um pagamento solicitado (seja diretamente ou por recursos como o "rachar contas"), por um link de pagamento, por uma venda do catálogo interno de produtos, por uma transação iniciada via API de cobrança, por um redirecionamento ao sistema de checkout em um e-commerce, etc, etc... todo dinheiro recebido é sempre notificado para aquela URL (exceto em casos onde uma cobrança criada via API especifique que os pagamentos oriundos daquela cobrança em particular devem ser notificados a uma URL específica, ou seja, é possível "sobrescrever" a URL configurada na conta do recebedor). Isso dá uma abertura gigantesca para integrações super facilitadas, bastando o fornecedor de soluções orientar ao seu cliente "vá no painel da sua conta e coloque essa URL |
|
Isso seria um problema de segurança, pois se poderia forçar qualquer PSP a fazer requisições a pontos não confiáveis da Internet ou mesmo a confiáveis tentando se parecer como um ataque. Por exemplo, www.presidencia.gov.br/etc/passwd (não é bem isso mas não vou documentar formas de ataque, mas entendedores entenderão). Por isso a idéia de usar um sistema de mensageria pública já estabelecido. O que você descreveu é o WebHook disponível na API Pix, mas lá há um procedimento de mútua autenticação que faz com que nenhuma requisição HTTP seja enviada antes do estabelecimento de uma sessão TLS onde as duas partes sabem suas contra-partes. E esse tipo de setup de autenticação faz falta na hora em que se deixa o cliente entrar qualquer coisa. |
Acho que você forçou a barra absurdamente nessa interpretação. Um request disparado somente no evento de um pagamento recebido, mesmo considerando um custo mínimo de R$ 0,01 por Pix enviado para disparar esse gatilho, seria extremamente custoso e ineficiente. Qualquer pessoa interessada em fazer um ataque de requisições certamente não usaria esse método. Além disso, o PSP (ou o BACEN) vai ignorar completamente qualquer retorno que essa URL prover, não executá-lo. |
|
Esse issue é EXATAMENTE o meu caso. Eu queria desenvolver um App para pequenos comerciantes poderem verificar em tempo real os Pix que foram pagos, sem precisar deixar o App do Banco deles aberto no caixa. Seria perfeito se pudesse colocar um URL a ser chamado no fim de uma transação que informasse todos os dados do QR Code, tanto para estáticos quanto dinâmicos, bem como se houve erro ou não na operação. O PSP do pagador teria que chamar esse URL no fim do pagamento, já que é ele que viu o QR Code e detém a URL do webhook, mas fica super difícil falar de cobrança disso, já que o PSP do pagador não é vinculado em nada com o recebedor, logo deveria ser de graça esse serviço. Em outras palavras, como eu vou pagar para o PSP do pagador por essa informação? Eu teria que assinar contrato com todos os PSPs do Brasil. O quanto possível é isso nesse momento? Quais são os impedimentos? O fluxo que eu vejo é:
|
|
@feinstein esse é exatamente o cenário que eu vejo. Será essencial para a maioria das pessoas que querem, efetivamente, adotar o Pix como meio principal de pagamento em seus estabelecimentos comerciais, receber as notificações de pagamento (e poder escolher o endereço de forma simplificada). Isso poderia estar vinculado à própria chave, no meu ponto de vista. Recebeu um Pix na chave É um processo tão previsível, simples e óbvio (análogo ao que acontece nas maquininhas de cartão) que me surpreende que não tenha sido levantada essa discussão ainda. Como trabalhar com o Pix de forma segura e prática, sem ter que ficar abrindo o app do banco pra verificar se um pagamento caiu? Só consigo pensar nessa forma e "vincular" o acesso a esse recurso aos demais recursos oferecidos pela API Pix (que, convenhamos, não será assim tão simples, prática e - financeiramente - acessível) me parece bastante estranho. |
|
Pois é.... Gostaria muito de saber quais são os impedimentos pra isso, se sequer existe algum e se tiver, como contornar. |
|
Seria excelente se dentro dos payloads dos recursos Isso eliminaria os 3 endpoints de webhooks e daria muito mais flexibilidade para as integrações. |
Entendo que a URL de notificação poderia ser vinculada à chave Pix e o PSP recebedor (ou o próprio BACEN) simplesmente enviaria um request para essa URL notificando que um pagamento foi recebido. Um request informando meramente o txid + o valor recebido seria suficiente para validação dos pagamentos num cenário onde o Pix esteja substituindo o cartão de débito num comércio presencial. O terminal de caixa pode ficar em comunicação com um sistema [que pode ser externo e] que fica recebendo essas notificações de pagamento continuamente e exibindo sempre a última transação recebida [para o seu txid predeterminado]. O mesmo modelo também resolveria cenários de integração mais básicos para e-commerces, usando unicamente QR Codes estáticos, cujos txid seriam referências diretas ao número do pedido, por exemplo. A definição de uma URL de notificação para uma cobrança especifica poderia substituir ou ser adicional (de forma configurável) à URL de notificação definida para a chave Pix. |
ninrod
changed the title
ninrod
changed the title
|
@ninrod continuando a discussão do #98:
Você pode explicar melhor quais são as suas dúvidas? Estou entendendo haver várias, talvez não explicamos bem o nosso problema e como isso viria a ser uma solução. Quanto as que você já definiu acima:
Por que? As especificações do Pix podem impor um limite a isso. Por exemplo: "Um QR Code só pode ter no máximo 3 URLs. Se tiver mais que isso o PSP não é obrigado a chamar nenhuma URL que venha depois das 3 primeiras" (na realidade eu só vejo necessidade de 1 URL, mas coloquei 3 por ser algo razoável a meu ver para alguma funcionalidade futura desconhecida agora).
O que seria "um contexto de segurança adequado"? HTTPS não é suficiente? Ou você está falando de outra coisa? Eu vi alguém mencionando a possibilidade de DDoS, mas eu honestamente não consegui ver como isso seria viável. Estaríamos falando de 1 request por pagamento, seria um DDoS bem lerdo e bem caro. Qual seria o cenário onde isso aconteceria? Hackear uma loja web e introduzir um URL no QR Code da loja pra a cada venda ter um disparo ao alvo do DDoS? |
Podem me ajudar a entender, em detalhe, a proposta? Entendi que a proposta gira em torno de atribuir a uma cobrança uma URL específica para "notificação". Supondo 10M de cobranças, (há usuários recebedores que geram 10milhões de cobranças por mês), potencialmente, do ponto de vista do PSP recebedor, teria-se em mãos 10 milhões de URLs diferentes para notificar, respectivamente, cada uma destas cobranças. Entendi corretamente a proposta?
Pensando rapidamente, vejo um problema que seria forjar notificações Pix. Veja que é fácil obter o txid dinâmico referente a uma cobrança. Se um hacker sabe que o usuário recebedor utiliza este "esquema de notificações", e se o endpoint servido pelo web sever do usuário recebedor não possui uma camada de segurança adequada, seria possível forjar notificações que estabeleçam que a cobrança foi liquidada, lesando o usuário recebedor por meio de, por exemplo, levá-lo a liberar uma mercadoria tendo em vista este recebimento fake. |
A menção não era a DDoS, mas a requisições maliciosas que causariam problemas para o PSP, onde o PSP ficaria parecendo como culpado de um ataque. E a resposta a esse falso ataque por parte de uma rede ou sistema pode ser o bloqueio da rede do PSP, gerando um DoS (mas não um DDoS). |
Provavelmente essa forma de notificação dependesse de assinatura digital do BACEN, para que possa trafegar em canal inseguro e mesmo assim ser reconhecida como legítima. Não poderia ser assinatura do PSP pois alguém fora do SFN não consegue reconhecer quais os PSPs autorizados. |
Sim, seria isso, mas a meu ver, corrija-me se estiver errado, se um PSP precisa fazer 10M de cobranças ao mês, então já serão 10M de requests à API Pix do bacen de qualquer forma. Se adicionarmos 1 URL, no pior dos casos a gente dobra isso para 20M de requests: 10M ao bancen e 10M ao URL de notificação. Dobrar fica pesado para esses PSPs que já tem a estrutura toda para 10M?
Sim, concordo, por isso que na minha sugestão anterior eu sugeri que houvesse um banco de dados disponibilizado pelo bacen onde a origem dos requests pudesse ser verificada de forma simples, através de uma assinatura digital onde as public keys fossem disponibilizadas pelos bacen, atrelado ao id do PSP. Talvez existam opções melhores, eu não sou especialista em segurança e não conheço todas as soluções de autenticação mutua, mas acredito que existam soluções pra isso e não seja um impedimento total a essa modificação. |
Apenas expondo o ponto de vista do BCB, se entendi corretamente, neste caso, entendo que o BACEN assumiria um papel central na segurança da solução e acredito que estaríamos falando de uma carga brutal pensando no potencial de notificações para atender todo o país. Estabelecer essa comunicação BACEN x [todos os usuários recebedores do Brasil] seria uma arquitetura sem precedentes. Há, inclusive, questões jurídicas potencialmente envolvidas: joje o BACEN estabelece comunicações com instituições reguladas e neste cenário proposto, os usuários recebedores estariam fora do alcance regulatório do BACEN. |
Você diz como e.g. colocar um SQL Injection num HTTP GET dentro de um QR Code e ai o PSP que faria o SQL Injection? Acho que o nome dessa vulnerabilidade é Open Redirect. Realmente isso poderia ser um vetor de ataque, alguém tem ideais de como contornar isso de forma simples? Queria evitar um banco de dados de cadastro de URL seguras, pois isso iria dificultar a inclusão de apps pequenos como o meu, adicionar burocracia e seria mais um request para o PSP. |
Eu não vejo solução para isso usando HTTP. A solução que já comentei de mensageria pública ao estilo Google Firebase e similar é o caminho que vejo para isso. |
|
@rubenskuhl Como assim "mensageria pública ao estilo Google Firebase"? |
Mas o bacen precisaria estabelecer esse contato? Não seria apenas incluir na atual mensagem que o PSP já recebe, notificando que houve uma transação Pix, um campo que contém os dados da transferência, assinada pelo bacen? Dai o PSP apenas reenvia esse dado assinado com um |
Entendo que essa descrição aproxima-se bastante ao cenário proposto pela API Pix hoje, via webhooks. A diferença é que essa URL única é a única possibilidade (você não consegue estabelecer uma URL por pagamento) e no lugar do dashboard você usa o webhook.
Poderia ser um cenário, o PSP recebedor apresentar um dashboard para configurar URLs de notificação "por fora da API". Em todo caso, preocupa-me as questões de segurança levantadas aqui. |
Ok, entendo. O PSP recebedor poderia efetuar o "relay" da mensagem assinada pelo BACEN, evitando o problema da carga. Em tese, baseado na premissa de que sempre o usuário recebedor verificaria a corretude da assinatura, você teria um nível de segurança. Não sei dizer se seria o suficiente. O foco aqui seria atender o fluxo QR Estático -> Confirmação de recebimento? Apenas para entender a necessidade de negócio: se estabelecermos que o PSP do recebedor poderia fornecer em dashboard e mesma funcionalidade de webhooks, mas seguir exatamente o formato estabelecido pelo callback do webhook, resolveria a questão? |
Então intermediadores, fintechs, bancos... que ofereciam notificações de pagamento de qualquer outra espécie deverão deixar de fazê-lo, no caso específico do pagamento que entrou na conta ser um Pix? Não vejo o menor sentido. Seguindo por este raciocínio, então, aplicativos de gestão financeira como o GuiaBolso, que acessa minhas contas bancárias e me auxilia no meu planejamento financeiro, não poderá ler os pagamentos que eu receber quando estes forem Pix (somente DOCs e TEDs)? E ainda seguindo a mesma lógica, os aplicativos dos bancos, sejam desktop/web/mobile que possuem funcionalidade de exportar o meu extrato, também não poderão exportar as transações que forem envios/recebimentos Pix? Complicou! |
O sentido é não ser essa a desculpa para lock-in numa API proprietária.
O GuiaBolso é o caso de uso padrão do OpenBanking, que vai ter acesso às transações recebidas e a ser iniciador de pagamentos. Ele hoje não usa APIs nesses acessos, ele simula um cliente, exatamente pela falta de padronização ainda a ser criada como parte do OpenBanking.
Isso não é uma API, é apenas mais um layout de arquivos. Quer seja em formatos padronizados como ISO 20022 ou CNAB 750, quer seja num formato próprio de um banco, ele não se constitui uma API... no momento layout de arquivos não é escopo de padronização do BACEN. Tem gente que diz que os CNABs tem tanta diferença entre os bancos que isso deveria ser objeto de padronização, mas se for, o que faria mais sentido é uma padronização mais genérica do que só para Pix. Assim como o BR CODE padronizou QR-Code para uso em qualquer arranjo de pagamento. |
Mas isso não é lock-in. O MercadoPago não é o único que oferece notificações de pagamento. Todos os intermediadores e gateways de pagamento oferecem, para todos os recebimentos (e até mesmo alguns bancos "tradicionais", quando não para todos os recebimentos, ao menos para algum tipo de pagamento particular, como é o caso do Itaú Shopline). Você precisa entender que há uma diferença entre a API Pix (que oferece vários recursos) e a API dos intermediadores e gateways:
Uma coisa não compete com a outra. O recebimento que entra na conta por meio do Pix, não será acessível por meio de uma API proprietária de forma que elementos/informações exclusivos do arranjo Pix fiquem disponíveis "por fora" da API Pix. Mas todo recebimento de dinheiro é uma "Operação" (no caso do MP) e eu entendo que, poder consultar determinados dados sobre esta transação (dados estes que também estão disponíveis em todas os demais tipos de transações que o MP é capaz de receber, tais como o nome do pagador, o valor, o horário da transação, o status - que no caso do Pix, por definição, seria sempre "approved") por meio da API proprietária do MP não interfere em nada a existência da API Pix (e o MP oferecê-la ou não). São ações sem equivalência com a consulta de transações por seu txid, criação ou consulta de cobranças, etc - ações estas, sim, disponíveis exclusivamente pela API Pix. Inclusive, há bancos tradicionais que oferecem APIs de comunicação para os correntistas. Estes vão deixar de oferecer consultas às transações da conta (ou limitar os retornos das consultas, omitindo os recebimentos que sejam Pix)? Aposto que não. Uma vez recebido o dinheiro na minha conta, ele é meu dinheiro. Não importa se ele veio por um Pix ou se foi uma compensação de cheque. Ele precisa estar acessível para consulta (ou ser notificado), como qualquer outro dinheiro. |
|
Inclusive, a minha sugestão para que as notificações sejam padronizadas no Pix e acessíveis nem necessidade de um client_id para acesso à API Pix, é exatamente evitar esse "lock-in" em determinados intermediadores/gateways/PSP, tornando este um recurso universalmente acessível no âmbito do Pix e fazendo do Pix uma modalidade de recebimento preferida face a outras, justamente por essa versatilidade que a padronização traria. Não só a facilidade de usar o Pix como substituto a maquinetas aumentaria como, também, a competitividade entre os players, se todos tiverem que oferecer as notificações. O que fizer isso melhor, atender melhor os clientes, agregar mais valor que não especificamente os "recursos Pix" (que são padronizados), terá mais sucesso. |
|
Mesmo nesse argumento, com o qual eu não concordo em seu todo mas vou discorrer sobre seus desmembramentos, TxID é uma informação do arranjo Pix. Então uma API proprietária mesmo que somente notificando que o Pix de TxID tal foi realizado para a conta está em violação. Uma API proprietária que só diga "você recebeu R$ 12,34" e depois permita consulta de extrato onde aparece o TxID, também esta em violação. Agora uma que no extrato diga apenas "Pix" estaria ok. |
Como eu disse:
O que é uma pena. Entendo o interesse, por parte do BACEN, que haja padronização. Mas é pena limitar que parte das informações, que já estão em mãos do PSP e acessíveis pelo recebedor no app mobile não possam ser consultadas por outros meios que não a API Pix. |
|
Continuando o que falei na minha resposta mais acima (a primeira desde a sua última mensagem aqui neste issue e focada na questão técnica - as demais mensagens tem um cunho mais jurídico ou particular do BACEN):
A chave de validação (definida pelo recebedor junto à URL de notificação) poderia, inclusive, ser utilizada para codificar o conteúdo enviado na notificação, aumentando ainda mais a segurança. |
|
@rubenskuhl , já que você parece estar bem por dentro da parte regulatória, se puder me ajudar, me permita voltar à questão de regulação sobre as funcionalidades técnicas que os PSPs podem oferecer aos clientes finais: O Itaú Shopline, por exemplo, oferece a criação de cobranças e estas podem ser pagas tanto por boleto (qualquer cliente) quanto por débito em conta (somente por quem é correntista do Itaú) e todas as "baixas" são notificadas para o recebedor por um webhook. Se eu crio uma cobrança com a identificação Se o Itaú Shopline agregar a opção de o pagador efetuar o pagamento desta cobrança Estou correto neste raciocínio ou há alguma imposição a este processo? |
|
Eu acredito que boletos híbridos, inclusive os com possível pagamento via Pix, não estejam cobertos pelo escopo da API Pix. Neste caso há um outro arranjo de pagamento, um produto específico que inclusive no caso de pagamento do boleto cancela o Pix e no caso de pagamento via Pix cancela o boleto. Não é que alguém chamou o Pix de, por exemplo, de SX e na verdade é o mesmo arranjo... me parece um produto diferente. E aí entra em qualquer outro escopo regulatório, se algum existir... e o fato dele não ter ou não uma API, ortogonal à existência da API Pix. Me parece que esse tipo de avaliação vai precisar sempre de casos específicos... casos genéricos podem parecer tranquilos, dá para imaginar casos esdrúxulos que seriam péssimos do ponto de vista regulatório, mas que cada caso precise de avaliação específica. Esse não me soa sirenes de alerta. |
🤣
Bom, o exemplo que eu dei (Shopline) pode ser diretamente relacionado ao que a API do MercadoPago, PagSeguro, Gerencianet, etc e etc oferecem. No fim das contas, estou vendo que integrar a API Pix e criar cobranças diretamente com ela não será a única forma de "receber um Pix" e conciliar esses recebimentos. Se o próprio Pix oferecesse a notificação de forma mais facilitada, seria mais fácil transitar entre os PSP e a adoção do Pix como meio de recebimento principal (ou até único) aconteceria em um prazo bem mais curto para muitos tipos de negócios. Não sendo o caso (sendo necessário implementar a API Pix, que é bem mais complexa), na prática os clientes continuarão usando os integradores de sempre e a tal "abertura de mercado" oferecida pelo surgimento do Pix será menos expressiva (será um novo meio de pagamento, inovador em natureza, mas concentrado na mão dos mesmos players de sempre). |
|
Se for receber um Pix, aí é Pix e precisa seguir a API Pix. Os 3 PSPs citados na mensagem acima alegaram que vão implementar a API Pix como descrito neste repositório; um deles foi descartado por cobrar MDR (%), mas os outros estão na reta final do processo de escolha para serem o PSP escolhido, com a informação clara de que só a API Pix padrão do BACEN leva a um contrato de prestação de serviços. |
Se eu, como PF ou PJ, autônomo/comerciante/prestador de serviço, usar qualquer intermediador para gerar cobranças e este (intermediador) receber os pagamentos por quaisquer meios (seja boleto, cartão, TEF, TED, criptomoeda, cheque, Pix ou sinal de fumaça), eu não tenho nada a ver com isso. A regulação do Pix se limita ao âmbito do Pix. O intermediador fazer uso do Pix para receber um valor e depois me disponibilizar esse valor (e, inclusive, me notificar que este recurso está disponível) está totalmente fora do contexto do arranjo Pix. Se você entende o contrário, por favor, fundamente melhor.
Você está trazendo informações particulares para o debate. Por favor, observe que a issue onde estamos discutindo tem um aspecto muito amplo que o seu caso de uso particular. Especificamente o trecho onde você diz "os outros estão na reta final do processo de escolha para serem o PSP escolhido" isso não fica claro para os leitores menos informados. |
O âmbito do Pix não se resume aos PSPs e ao BACEN, inclui a relação do PSP com correntistas. Por isso há a API Pix. E isso acontece de forma similar em outros arranjos, onde o instituidor do arranjo define o que quiser definir. O BACEN, e que merece aplausos por isso, resolveu padronizar a API. Ponto final, a API é padronizada. Ficar procurando buracos na regulação é algo que não terá o meu apoio e espero que o BACEN resista. Se você quiser propor soluções para os casos de uso de 3 partes, aí sim proponha, mas não ignorando os problemas relevantes que surgem para se resolver.
É um exemplo de que como todo caso prático não tem problemas teóricos. Você escolheu a lista, não eu, e como eu já tinha lidado com todos esses prestadores pude responder o que eles propõe. |
A relação dos PSP com os correntistas no âmbito do Pix, no que diz respeito a enviar e receber Pix, especificamente Pix, por todos os seus canais de atendimento, faz total sentido que seja padronizado (inclusive a API, para quem quiser utilizá-la), para uma melhor experiência. Mas não é porque o Pix está sendo lançado que todas as soluções de cobrança devam, imediatamente, sofrer qualquer penalização em relação à recursos (features).
Eu não escolhi este repositório para abrir esta issue ao acaso. Eu estou propondo uma melhoria para o Pix, que pode beneficiar a sociedade, e o meio de comunicação com a equipe que está desenvolvendo e implantando escolheu este canal. Onde mais eu deveria fazê-lo? Não me leve a mal ou para o lado pessoal. Eu estava falando especificamente do seu comentário anterior. Para um desavisado que passar por esta issue em particular e ler aquele seu comentário, pode dar a impressão de que estamos (todos aqui) em busca de decidir algum PSP em particular para atender uma necessidade conjunta nossa. Não sei se você confundiu com a issue #57 onde você já falou mais abertamente da sua busca por um PSP. O fato é que esta issue não tinha essa discussão até esse momento e você não deixou no seu comentário que estava se referindo a sua busca pessoal por uma solução, para atender as suas necessidades (e que, convenhamos, nem tem qualquer relação com as mudanças que estamos propondo à sistemática de "Notificação de Pagamentos" que é o título desta issue aqui, #62). |
|
Os comentários que faço aqui também não relação com a busca que estou fazendo, apenas volto a comentar que casos práticos são bem mais úteis nas definições de políticas públicas. Só que para isso eles precisam ser reais, não baseados em suposições que os fatos facilmente demonstrem sua não aplicabilidade. |
|
Prezados, mais uma vez agradeço pelas contribuições. Aqui e em #111 pode-se ver que os endpoints /webhook podem ser melhorados. Sugiro focarmos, como @rubenskuhl também ressaltou, nos casos de uso específicos. Achei interessante o caso de uso listado em #111: o usuário recebedor estabelecer uma URL diferente para o recebimento de QR Estáticos. Em alguns pontos neste repo foi mencionada a funcionalidade de estabelecer URLs diferentes por chave Pix, o que considero menos problemático do que estabelecer "por cobrança", e até interessante:
Vou abrir uma nova issue para reunirmos todos os comentários a respeito de melhorias no webhook e marco vocês lá, ok? |
|
@ninrod me passou uma ideia pela cabeça que talvez possa ajudar a se evitar mTLS em um futuro esquema alternativo. Podemos encriptar a URL do webhook usando a chave publica do PSP recebedor. Dessa forma um hacker não tem como saber qual é a URL que está dentro do QR Code, apenas o PSP recebedor saberá qual é a URL de notificação, usando sua chave privada para desencriptar a URL. Sei que isso não soluciona tudo, nem é algo 100% garantido, mas pode ser uma camada a mais de segurança a ser adotada. Apenas uma sugestão a mais ser considerada. |
|
Na real poderia até ser algo mais simples, junto com os parâmetros de geração de QRCODE o recebedor do pagamento poderia colocar uma URL como opcional, então se a url estivesse presente o sistema do banco central deveria enviar uma requisição post com os dados como: horário do pagamento, status do token de pagamento como "qrcode finalizado", ou "aguardando recebimento de novos pagamentos" (para o mesmo qrcode) e status do pagamento como sendo "pagamento aprovado" ou "cancelado qrcode expirado" |
|
@AdamTeodoro é um ótimo recurso no mundo teórico, sem dúvidas facilitaria muito para os desenvolvedores e usuários finais. Mas no mundo real, me surgem algumas objeções.
Ao meu ver, essa feature só estará mais resolvida quando o Real Digital surgir, pois como ele é baseado em tecnologia blockchain, as transações ficariam em um livro onde os PSPs teriam acesso. E um modelo de negócio será a venda de consulta das transações sob demanda através de smart contracts que ficassem ouvindo as transações autorizadas e serviços que emitissem webhook, e mesmo assim, não seria responsabilidade do BACEN fazer a notificação a qualquer um. Mas teremos que esperar seu desenvolvimento para vermos como serão as novas regras e suas restrições de acesso para essa tecnologia. Por enquanto, sugiro utilizar um PSP que te forneça a opção de webhook para recebimentos em Pix. |
|
O PIX ficaria útil e o custo não seria tanto assim é só o pessoal acomodado tirar o traseiro da cadeira e começar a criar coisas realmente úteis, pra mim tá mais pra babação de ovo de gateway de pagamento que quer meter a mão em uma porcentagem do valor transferido por pix sendo que o próprio banco central poderia cobrar o custo fixo da requisição na transferência do Pix, bem melhor que deixar os gateways de pagamentos saquearem empresas já que cobram até 5% do valor da transferência por pix que tinha o objetivo de ser gratuito, só um idiota acha que uma requisição post custaria em % do valor da transferência, isso deveria ser uma taxa fixa, independentemente do valor transferido. |
São coisas diferentes aí. Uma é porque o Banco Central não presta serviços diretamente; é definição da missão do Banco Central não ser um banco de varejo. Então necessariamente as transações acontecem entre instituições autorizadas pelo Banco Central, quer elas não tenham o Banco Central no meio do arranjo (ex: boleto e cartões) quer elas tenham (ex: Pix). A outra é porque surgiu e se estabeleceu o pagamento por % no Pix. No começo do projeto em 2020 haviam mais prestadores cobrando valores fixos do que percentuais... mas isso foi mudando e acabou-se consolidando a realidade de mais prestadores com percentuais. Curiosamente, parece ter sido quem recebe valores baixos que pressionou para isso, por equivalência com cartão de débito. Diferente de boleto, onde o usual do mercado é valor fixo independente do valor do título. Isso significa que há um subsídio cruzado entre quem recebe valores menores, pagando menos por transação, e quem recebe valores maiores, que provavelmente paga mais do que de outra forma. Mas eu não lembro de já ter visto cobrança de 5%... o típico é algo em torno de 1%, como 0.99% (MP), 1,19% (Efí) e por aí vai. Que eu também acho estranho ao invés de valor fixo, mas aconteceu pelos motivos acima. |
|
Não entendi pq seria banco de varejo se estaria prestando serviço para sistemas de empresas?, o no caso do pix para pessoa física não tá quebrando nenhuma missão do banco central?, a porcentagem que eles pegam sobre o pix é a quela velha exploração clássicas que os gateways de pagamentos já praticam criminosamente, já que não tem regulamentação, eu disse 5% com base em um caso somando todo o valor que o gateway de pagamento pegava, que seria 1,19% taxa do pix + taxa de transferência de 3,67 reais do pagarme, em porcentagem é errado já que vão lucrar por volume de transferências, isso só serve para encarecer os preços para o consumidor final e afetar negativamente nas vendas, nesse caso o gateway de pagamento ficou com aproximadamente 5% do total que era de uns 97 reais. |
Para empresas também são bancos de varejo, só de outro segmento. O Banco Central é um banco de bancos, ele tem como clientes outros bancos e instituições de pagamentos. Sobre a percentagem de gateways específicos, sugiro procurar algum da lista em #76 que tenha condições melhores. |
Trazendo uma discussão que foi aberta na issue #9 (mas não era o foco original da issue) e ficou sem resposta por lá, trago para essa issue em forma de sugestão.
Visando oferecer uma experiência mais próxima à do cartão de débito e facilitando a adoção do Pix em pequenos estabelecimentos comerciais, que hoje contam com um comprovante gerado e impresso imediatamente pelas "maquininhas" de cartão, seria interessante que o QR Code utilizado para realizar as cobranças (ou a chave que está vinculada a ele) tivesse um webhook vinculado, para o qual o próprio BACEN (ou o PSP recebedor) enviaria um request (notificação).
Isso facilitaria que desenvolvedores de software oferecessem um serviço que inclua a notificação de pagamentos aos clientes de seus sistemas de ERP/cobrança. O recebedor do Pix receberia uma notificação de novo pagamento diretamente no celular ou em seu sistema de cobrança, sem precisar de um contrato para acesso à PIX API junto ao PSP.
Em 99,9% dos casos o único recurso da API estritamente necessário para um nível mínimo de controle a ser utilizado por pequenos estabelecimentos é esse, que permite uma notificação ou "baixa" de um pagamento. Os demais, são bem mais restritos a empresas de médio e grande porte.
Do ponto de vista da segurança, também é interessante evitar a necessidade de que um desenvolvedor tenha acesso (e armazene) tokens de API dos clientes, especialmente estes sendo pequenos clientes, sem um departamento de desenvolvimento, segurança ou tecnologia de maneira geral e não podendo realizar as integrações necessárias por conta própria.
Não considero isso propriamente como uma "automação" mas como um requisito básico para adoção do Pix em larga escala em muitos negócios de pequeno porte. Sem este tipo de funcionalidade, fica bem inviável o comerciante verificar os pagamentos (o fluxo de uma pequena padaria de bairro já seria suficientemente grande a ponto de inviabilizar a adoção imediata do Pix), enquanto o cartão de débito fornece uma confirmação segura e instantânea que o Pix, sem tal recurso sugerido, não oferece de forma facilitada e acessível.
The text was updated successfully, but these errors were encountered: