[Dúvida] no [QR CODE] - É possível gerar um QR Code para um terceiro?

[feinstein]

Digamos que existam as empresas A e B com contas em bancos diferentes.

A quer receber dinheiro de um cliente. É possível que B gere um QR Code para que o cliente de A pague por um produto de A?

A ideia é que a empresa B possa receber confirmação que houve um pagamento à A e poder mostrar a informação a A.

[ninrod]

bom dia @feinstein

A quer receber dinheiro de um cliente. É possível que B gere um QR Code para que o cliente de A pague por um produto de A?

• O dinheiro cairá em qual conta? de A ou de B?
• Ambas as empresas estabeleceram automação comercial com acesso à API Pix de seus respectivos PSPs?

[feinstein]

O dinheiro deve ir pra conta de A.

B é uma startup pequena que não tem acesso ao DICT e está contratando uma API de um banco que tem acesso ao DICT.

[ninrod]

Por que exatamente o acesso ao DICT seria um fator? Não é necessário acesso ao DICT para gerar um QR dinâmico via API.

Entendo que B é exatamente o tipo de empresa que fornece a automação comercial de que A necessita.

Quem contrata a API é A com o PSP de A. Em onboarding/KYC A obtem seus client_ids de seu PSP e entrega para B. B configura o canal mTLS, configura client_id e secret obtidos em onboarding e a partir daí opera a API em nome de A.

correto o cenário?

[feinstein]

Eu quis contratar uma API Pix de um BaaS e me falaram que eu não poderia gerar QR Codes para um terceiro pois eu não teria acesso ao DICT. Eu só poderia gerar QR Codes para a minha conta no BaaS (a minha empresa é a empresa B, uma startup pequena, não tem 1mi de capital para ser um Participante Indireto no Pix).

A no caso seriam pequenas empresas que não tem um sistema complexo de pagamento, uma padaria, um restaurante, um bar de esquina, então não sei se esse fluxo todo de PSP seria possível para um estabelecimento como esse.

Eu não sei a fundo as especificações técnicas, mas acho que talvez B fica como um PSP nas especificações? A ideia é B poder rastrear o que está acontecendo quando um cliente paga um QR Code a A.

O que é necessário para que uma pequena startup B possa rastrear que um QR Code (tanto dinâmicos quanto estáticos) foi pago a A?

[ninrod]

me falaram que eu não poderia gerar QR Codes para um terceiro pois eu não teria acesso ao DICT.

Essa afirmação está incorreta. A empresa B precisaria apenas de acesso à API Pix de um PSP em que A detenha uma conta transacional. Isso é tudo o que B precisa.

A no caso seriam pequenas empresas que não tem um sistema complexo de pagamento, uma padaria, um restaurante, um bar de esquina, então não sei se esse fluxo todo de PSP seria possível para um estabelecimento como esse.

Seja A uma padaria, um restaurante ou o comércio que você imaginar, não existe distinção nesse contexto: se A tem conta em um PSP que provê a geração de QR Codes, então A tem direito à utilização da API Pix desse PSP. Tudo que a empresa B precisa fazer é orientar A a entrar em contato com o PSP de A e obter o certificado correto para fechar o canal mTLS e obter as credenciais client_id e secret conforme se queira. É plenamente possível. Obviamente, dependendo do tamanho de A, outras considerações podem entrar em cena, como volume de transações, uso ou não de webhooks, entre outros fatores que transcendem o escopo desta issue.

A partir daí, sua empresa, B, obteria acesso à API Pix em nome de A e poderia interagir com a API Pix para efeitos de conciliação e geração de pagamentos.

Cenário bastantes simples: a empresa B gera QRs Estáticos associados a um txid (em função de algum comando vindo do caixa, por exemplo) em nome de A (um QR Estático pode ser criado diretamente, inclusive no notepad), e concilia os pagamentos recebidos via GET /pix?txid={txid}.

O que é necessário para que uma pequena startup B possa rastrear que um QR Code (tanto dinâmicos quanto estáticos) foi pago a A?

É necessário estabelecer um relacionamento contratual com um estabelecimento, não importa o tamanho: pode ser um restaurante, uma padaria, ou uma operadora de telefonia, desde que esse estabelecimento, digamos o A, detenha uma conta em um PSP que disponibilize a API Pix.

Os PSPs podem eventualmente estabelecer algum critério de segurança específico para liberar certas features consideradas mais perigosas, por exemplo, devolução de pagamentos. Então, eventualmente, a empresa B terá que implementar alguns cuidados e políticas específicas para estar aderente aos procedimentos de segurança estabelecidos.

Todo e qualquer PSP que quiser fornecer integração automatizada com o arranjo Pix deve fazê-lo implementando a API especificada aqui.

Ficou mais claro? posso responder alguma dúvida adicional?

[feinstein]

Eu ainda estou com algumas dúvidas, você poderia aceitar o meu convite no LinkedIn para que eu pudesse passar uns dados mais específicos?

[ninrod]

prezado @feinstein , boa tarde.

Estou impedido de prestar consultoria específica. Peço a você que submeta eventuais dúvidas de cunho técnico, conforme avaliação sua, neste fórum/formato para a apreciação da comunidade. Dúvidas muito específicas relacionadas a sua empresa seriam melhor tratadas dentro de um contexto específico de consultoria (existem algumas no mercado).

[feinstein]

Ok, entendo, então vou tentar sumarizar aqui.

O que caracteriza um PSP?

Pelo o que você me respondeu acima a Startup B precisaria ser um PSP para poder atender a empresas A, ou a empresa A já precisa ter um contrato com uma PSP. Então fica a dúvida do que é uma PSP, como se torna uma, o que separa ela do resto dos parceiros?

[ninrod]

@feinstein :

Pelo o que você me respondeu acima a Startup B precisaria ser um PSP para poder atender a empresas A, ou a empresa A já precisa ter um contrato com uma PSP. Então fica a dúvida do que é uma PSP, como se torna uma, o que separa ela do resto dos parceiros?

A startup B é apenas uma software house que desenvolve um "cliente" da API Pix e opera "em nome" da empresa A, atuando como operador da automação comercial da empresa A. Ou seja, a empresa B não precisa ser um PSP. A empresa A precisa ter uma conta em um PSP que disponibilize a API Pix.

[feinstein]

Aí que eu vejo problema, a empresa A pode ter conta em uma infinidade de PSPs. Cada PSP tem a sua própria API que é única e cada um cobra um valor pra ter acesso a essa API. Isso dificulta imensamente o meu projeto, deixa ele muito mais caro e com um prazo bem mais longo e "refém" das PSPs. Estou errado na minha avaliação?

Até onde eu entendo pode-se fazer um Pix por um numero identificador, como o número do celular, sendo assim seria possível o Bacen incluir na especificação do QR Code um QR Code simplificado que qualquer pessoa possa criar? Assim como qualquer pessoa pode escrever o número de celular da outra em texto, ele também poderia escrever como QR Code, porém gostaria que houvesse uma funcionalidade extra também, eu explico abaixo:

Eu imagino que se um QR Code puder ser gerado com o seguinte, já seja suficiente para garantir segurança e funcionalidade, sem colocar um custo grande para uma empresa se inserir no mercado de operações com Pix:

• Um numero identificador do recebedor (celular, email, CPF e etc.)
• Valor a ser pago (opcional)
• Código identificador do QR Code (opcional)
• Uma URL em HTTPS que vai ser chamada ao fim da operação de transferência (opcional).
  Em caso de falha deve-se tentar chamar a URL 3 vezes com exponential backoff (parâmetros do tempo do exponential backoff a serem determinados no futuro).

A URL vai receber os itens opcionais do QR Code como parâmetros (query string) quando a operação for concluída, bem como outros itens:

• O valor pago (caso fornecido no QR Code)
• O Código identificador do QR Code (caso fornecido no QR Code)
• Um código de status da transação que indica se ela foi executada com sucesso, ou se houve um erro.
• O Código único da instituição financeira que leu o QR Code e portanto executou a transferência.
• Um nonce para evitar Ataques de Replay.
• A assinatura digital de todos os valores acima, onde a chave pública da assinatura digital é de livre acesso num banco de dados do Bacen, constituído somente de Participadores Diretos ou Indiretos no Pix. A consulta a esse banco de dados é feita pelo "código único da instituição financeira" fornecido acima.

Basicamente esse QR Code vai ser quase que a mesma coisa que uma pessoa física abrir o celular e digitar o CPF de outra pessoa no App do banco dela e um valor e concluir a transferência. A diferença é que esse QR Code pode ser gerado de graça por qualquer um e ele permite a automação da transação.

Por automação eu digo que o dono da URL vai receber uma chamada em seu servidor quando uma transferência for realizada, com todos os dados da transferência inclusos (caso estiverem presentes no QR Code). Sendo assim temos um sistema ainda mais descentralizado, ainda mais aberto, ainda mais livre de custos e impedimentos à inovação.

Tem algo de errado nisso? Isso vai contra a especificação do Pix? A meu ver é igual a um pagamento Pix usando o email da outra pessoa, só que com uma URL a ser chamada no final.

---

Entendo que as especificações do Pix já estão praticamente fechadas e em breve ele entra em atividade, mas essa pode ser considerada uma especificação estendida, v1.1, algo assim. É fácil de ser implementado pelas instituições, os dados do QR Code podem ser um simples JSON a ser lido e chamar a URL teria um custo extra ínfimo de infraestrutura. O Bacen teria que montar o servidor com as chaves públicas, mas não acredito que seja nenhum grande esforço.

[ninrod]

@feinstein

Aí que eu vejo problema, a empresa A pode ter conta em uma infinidade de PSPs. Cada PSP tem a sua própria API que é única e cada um cobra um valor pra ter acesso a essa API. Isso dificulta imensamente o meu projeto, deixa ele muito mais caro e com um prazo bem mais longo e "refém" das PSPs. Estou errado na minha avaliação?

Qual é exatamente o problema de a empresa A poder ter conta em uma infinidade de PSPs se todos eles serão obrigados a implementar exatamente o contrato estabelecido nesse repositório? Em outras palavras, não importa qual é o PSP com o qual o seu software cliente esteja falando, você tem certeza de duas coisas: 1) a segurança é sempre a mesma (Oauth2 client credentials flow + mTLS) e 2) o PSP tem que implementar todos os endpoints especificados aqui, nem um a menos e nenhum a mais.

Até onde eu entendo pode-se fazer um Pix por um numero identificador, como o número do celular, sendo assim seria possível o Bacen incluir na especificação do QR Code um QR Code simplificado que qualquer pessoa possa criar?

Entendo que já está especificado: é o QR Estático.

Para as demais questões, acredito que seja de seu interesse acessar o corpo de documentação do Pix.

[feinstein]

Qual é exatamente o problema de a empresa A poder ter conta em uma infinidade de PSPs se todos eles serão obrigados a implementar exatamente o contrato estabelecido nesse repositório? Em outras palavras, não importa qual é o PSP com o qual o seu software cliente esteja falando, você tem certeza de duas coisas: 1) a segurança é sempre a mesma (Oauth2 client credentials flow + mTLS) e 2) o PSP tem que implementar todos os endpoints especificados aqui, nem um a menos e nenhum a mais.

O problema é que o BaaS que eu quis contratar para gerar QR Codes quis me cobrar 4 mil reais de "setup" da conta (fora o preço de cada QR Code gerado e transicionado). Eles me falaram que só podem gerar QR Codes para o dono da conta. Então fica muito difícil eu convencer uma loja pequena a abrir uma conta num PSP, pagar 4 mil reais, para então poder integrar no meu serviço, pois pelo o que estou vendo isso vai ser bem caro para eles. Porém toda loja pequena já tem uma conta PJ num banco, então na minha especificação acima eu poderia gerar um QR Code para a conta PJ do banco da lojinha, sem que ela precise pagar mais nada.

Tem como essa loja pedir pro banco deles as credenciais necessárias e com isso eu gerar um QR Code diretamente pra essa conta do banco deles?

Minha preocupação é o custo de acesso a essa tecnologia.

[rubenskuhl]

De 18 propostas de Pix que já tenho em mãos, 5 tinham taxa de setup mas a maioria não tinha. Não pegue todo o mercado por esse prestador; a maioria tem noção de que taxa de setup não vai colar. Alguns também tem franquia mínima, que não adianta para pequenas empresas, e alguns tinham cobrança por MDR (%) que não faz o menor sentido num sistema como o Pix. Mas há um bom número de opções sem taxa de setup, com taxa transacional fixa razoável e com franquia mínima inexistente ou pequena.

[feinstein]

@rubenskuhl você pode me passar essas opções por mensagem pessoal no meu linkedin? Fico muito agradecido.

Além da taxa de setup eu só recebi propostas com valor fixo por transação, algo como 30 centavos o Pix, o que é um absurdo se você quer pagar uma bala de 1 real com Pix, vai dar 30% do valor do produto. E também recebi propostas com valor mínimo de 20 mil operações ao mês.

@ninrod é por isso que estou tentando ver como gerar um QR Code sem precisar de um PSP, com esses preços está impraticável fazer sistemas Pix para microempresas.

[flaviolenz]

@feinstein, acho que sua solucao eh o QR estatico, nao eh nao?
Veja a documentacao na pagina 10:
https://www.bcb.gov.br/content/estabilidadefinanceira/pix/Regulamento_Pix/II_ManualdepadroesparainiciacaodoPix-versao1.1.pdf

O que vc vai precisar eh pegar da banca de jornal que vende essa bala de R$1 eh o "Merchant Account Information" (nao sei se isso vai estar no Internet banking dele, ou algo assim)

Gerar o QR pro cliente pagar eh uma coisa e acho que isso ai em cima resolve.

Outra coisa, eh ter a chamada do webhook do PSP recebedor pra o seu sistema.
Isso pra mim ainda eh uma icognita... Se os PSPs vao disponibilizar realmente isso e como vao cobrar por isso dos estabelecimentos...

Alguem tem isso mais claro?

[feinstein]

@flaviolenz daria pra fazer com QR Code dinâmico também?

@ninrod a chamada do webhook que está no QR Code não é obrigatória segundo a documentação? (ainda não li sobre isso, apenas me baseio no que foi dito anteriormente).

@ninrod tem alguma regra no Pix que força os PSP a darem as informações dos clientes como "Merchant Account Information" caso eles peçam? Por ser algo tão técnico eu aposto que vai ficar escondido e ninguém no SAC do PSP vai saber ajudar nisso, a menos que seja obrigatório.

[renatofrota]

@feinstein, acho que sua solucao eh o QR estatico, nao eh nao?
Veja a documentacao na pagina 10:
https://www.bcb.gov.br/content/estabilidadefinanceira/pix/Regulamento_Pix/II_ManualdepadroesparainiciacaodoPix-versao1.1.pdf

Peço que evite enviar links diretos aos PDFs. Este citado, por exemplo, não é versão mais recente no momento (este documento está na v 2.0). Sempre passe o link da Página do Pix que reúne os links atualizados (no botão Regulamentação relacionada ao Pix).

O que vc vai precisar eh pegar da banca de jornal que vende essa bala de R$1 eh o "Merchant Account Information" (nao sei se isso vai estar no Internet banking dele, ou algo assim)

O "Merchant Account Information" é composto pelo GUI do BACEN + a chave Pix que vai receber o pagamento (aquelas famosas chaves que estamos todos sendo bombardeados pelos bancos e fintechs a cadastrar: CPF/CNPJ, telefone, e-mail ou chave aleatória). Ou seja, não é necessário "pegar" essa informação com ninguém.

Gerar o QR pro cliente pagar eh uma coisa e acho que isso ai em cima resolve.

Outra coisa, eh ter a chamada do webhook do PSP recebedor pra o seu sistema.
Isso pra mim ainda eh uma icognita... Se os PSPs vao disponibilizar realmente isso e como vao cobrar por isso dos estabelecimentos...

Alguem tem isso mais claro?

Os PSPs poderão cobrar pelo acesso à API do Pix. Ainda não encontrei informações claras de nenhum PSP que vá fazê-lo de graça.

No meu ponto de vista, receber uma chamada à um Webhook está muito distante das demais necessidades de integração que a API Pix proporciona e sugeri que isso seja oferecido gratuitamente a todos os clientes na issue #62. Se vocês concordam comigo, manifestem-se por lá, por favor.

[ninrod]

@ninrod a chamada do webhook que está no QR Code não é obrigatória segundo a documentação? (ainda não li sobre isso, apenas me baseio no que foi dito anteriormente).

É sim obrigatório o PSP implementar essa funcionalidade. Por outro lado, o cliente da API escolhe se usa o webhook ou não. Você poderia simplesmente efetuar um pooling em GET /cob/{txid} ou GET /pix?txid={txid}.

[ninrod]

@feinstein :

@ninrod é por isso que estou tentando ver como gerar um QR Code sem precisar de um PSP, com esses preços está impraticável fazer sistemas Pix para microempresas.

Citando o @rubenskuhl :

De 18 propostas de Pix que já tenho em mãos, 5 tinham taxa de setup mas a maioria não tinha. Não pegue todo o mercado por esse prestador; a maioria tem noção de que taxa de setup não vai colar. Alguns também tem franquia mínima, que não adianta para pequenas empresas, e alguns tinham cobrança por MDR (%) que não faz o menor sentido num sistema como o Pix. Mas há um bom número de opções sem taxa de setup, com taxa transacional fixa razoável e com franquia mínima inexistente ou pequena.

[feinstein]

@ninrod como assim "o cliente da API escolhe se usa o webhook ou não.", quem seria esse cliente no caso?

[ninrod]

@ninrod como assim "o cliente da API escolhe se usa o webhook ou não.", quem seria esse cliente no caso?

@feinstein o "cliente" seria o elemento de software que se comunica com a API Pix em nome do usuário recebedor.

[feinstein]

Mas se o PSP é obrigado a implementar a chamada a webhooks, então como que a chamada é facultativa pelo App do PSP?

[ninrod]

Mas se o PSP é obrigado a implementar a chamada a webhooks, então como que a chamada é facultativa pelo App do PSP?

@feinstein não entendi a relação do webhook com o App do PSP (pagador, supostamente?).

[franciscotfmc]

Mas se o PSP é obrigado a implementar a chamada a webhooks, então como que a chamada é facultativa pelo App do PSP?

@feinstein neste caso, basta o elemento de software não cadastrar a URL do webhook.

[feinstein]

Desculpa, eu ainda não li a documentação de webhooks então estou falando mais por "instinto" do que eu acho que deve ser.

A minha dúvida é: se os PSPs são obrigados a implementar a chamada a um webhook, então como que um cliente podem ter elementos facultativos que podem chamar ou não chamar? Isso me parece contraditório e instável já que não há garantias que a funcionalidade de webhooks vai funcionar ou não.

[ninrod]

como que um cliente podem ter elementos facultativos que podem chamar ou não chamar?

São dois casos de uso distintos, eu diria: 1) o acesso ao status das cobranças ou pix via pooling: GET /cob/{txid}, GET /pix?txid={txid} e 2) o recebimento de notificação "push style" ou "por interrupção" que é o caso de webhooks.

Você poderia argumentar que a API Pix serve a diversos públicos: quem não quer, por exemplo, manter um web server online, pode optar por uma via mais simples e apenas implementar a opção 1), via pooling. No caso de um usuário recebedor mais robusto, que sinta-se confortável em manter uma infraestrutura mais complexa, talvez a opção 2) seja interessante.

Isso me parece contraditório e instável já que não há garantias que a funcionalidade de webhooks vai funcionar ou não.

Entendo que quem teria que garantir o funcionamento do webhook é o implementador da API, no caso, o PSP recebedor.

[rubenskuhl]

Manter webhook é inviável por exemplo se um PDV estiver falando diretamente com a API Pix, quando a maioria dos PDVs - fora recursos computacionais limitados - está atrás de uma cadeia de NATs (roteador do acesso da loja, CGNAT da operadora). Por isso webhook foi corretamente especificado como obrigatório para o PSP e opcional para o correntista.

[feinstein]

Hmm, então os webhooks seriam chamados pelos PDVs... Achei que seriam pelos servidores dos PSPs ao receber a mensagem de confirmação de transferência do Pix.

[rubenskuhl]

Webhooks são chamados pelos servidores dos PSPs. Mas como consumidores da API podemos tanto ter e-commerce com servidores dedicados e bem conectados, quanto PDVs com conectividade e recursos limitados... por isso deixar o consumidor informar se quer ou não webhook.