Discussão sobre API's, Intermediadores e Gateways

[pnegri]

Estou movendo o conteúdo desse Issue para um novo, visto que ficou poluído com coisas fora do tópico principal.

[rubenskuhl]

Já sobre questões da API tenho mantido atualizado o #76 , inclusive citando os que não seguem a API padrão.

[pnegri]

Show.

A iugu irá oferecer a api padrão também, mas iremos manter nossa api de cobrança que é em um nivel mais alto (unica integração == todas as formas de pagamento). Além disso já temos mais de 50 mil lojas integradas, não faz sentido forçar uma nova integração para cada lojista, além de notificações de nova cobrança via email, whats e sms e também de régua de cobrança, desconto por pagamento antecipado por data e juros e multas, já suportados em nosso qr dinâmico.

Patrick Negri - CTO iugu

---

From: Rubens Kuhl notifications@github.com Sent: Monday, November 16, 2020 3:09:17 PM To: bacen/pix-api pix-api@noreply.github.com Cc: Patrick Ribeiro Negri patrick@iugu.com; Author author@noreply.github.com Subject: Re: [bacen/pix-api] Problema no QR Code - Acompanhamento do Lançamento (#185)

Já sobre questões da API tenho mantido atualizado o #76https://github.com/bacen/pix-api/issues/76 , inclusive citando os que não seguem a API padrão.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHubhttps://github.com/bacen/pix-api/issues/185#issuecomment-728232676, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AAAJTDQJLUPQ7OIAGLN3W6TSQFTE3ANCNFSM4TXPMWUQ.

[rubenskuhl]

Não foi o que disse o Banco Central, que claramente vetou APIs proprietárias. Mas falando em API Pix, falta o v2 no QR da URL acima:

00020101021226640014br.gov.bcb.pix2542qr.iugu.com/public/payload/CkmuskvXa6DGXNo52040000530398654041.075802BR5921Patrick Ribeiro Negri6009Sao Paulo62190515CkmuskvXa6DGXNo630407EE

Deveria ser /public/payload/v2/ .

[pnegri]

Ah sim, pq é mais prático pra todo lojista implementar 1 intermediador e 1 fornecedor de pix né. Não faz sentido algum. Se pix matasse de cara cartao de credito e boleto talvez faria sentido, imagina todo pequeno ecommerce que hoje contrata uma iugu, um pagseguro, que já fornece os módulos de ecommerce com uma única integração.

Patrick Negri - CTO iugu

---

From: Rubens Kuhl notifications@github.com Sent: Monday, November 16, 2020 3:25:42 PM To: bacen/pix-api pix-api@noreply.github.com Cc: Patrick Ribeiro Negri patrick@iugu.com; Author author@noreply.github.com Subject: Re: [bacen/pix-api] Problema no QR Code - Acompanhamento do Lançamento (#185)

Não foi o que disse o Banco Central, que claramente vetou APIs proprietárias. Mas falando em API Pix, falta o v2 no QR da URL acima:

00020101021226640014br.gov.bcb.pix2542qr.iugu.com/public/payload/CkmuskvXa6DGXNo52040000530398654041.075802BR5921Patrick Ribeiro Negri6009Sao Paulo62190515CkmuskvXa6DGXNo630407EE

Deveria ser /public/payload/v2/ .

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHubhttps://github.com/bacen/pix-api/issues/185#issuecomment-728241927, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AAAJTDRQXQFU535JQZSDK3DSQFVCNANCNFSM4TXPMWUQ.

[pnegri]

Não falta o v2. O endpoint não é padronizado. Tomar cuidado para não confundir sugestão com enforcement na doc.

Patrick Negri - CTO iugu

---

From: Rubens Kuhl notifications@github.com Sent: Monday, November 16, 2020 3:25:42 PM To: bacen/pix-api pix-api@noreply.github.com Cc: Patrick Ribeiro Negri patrick@iugu.com; Author author@noreply.github.com Subject: Re: [bacen/pix-api] Problema no QR Code - Acompanhamento do Lançamento (#185)

Não foi o que disse o Banco Central, que claramente vetou APIs proprietárias. Mas falando em API Pix, falta o v2 no QR da URL acima:

00020101021226640014br.gov.bcb.pix2542qr.iugu.com/public/payload/CkmuskvXa6DGXNo52040000530398654041.075802BR5921Patrick Ribeiro Negri6009Sao Paulo62190515CkmuskvXa6DGXNo630407EE

Deveria ser /public/payload/v2/ .

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHubhttps://github.com/bacen/pix-api/issues/185#issuecomment-728241927, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AAAJTDRQXQFU535JQZSDK3DSQFVCNANCNFSM4TXPMWUQ.

[rubenskuhl]

O BACEN é o instituidor do arranjo. As regras são dele. E o que não compensa para lojistas é ter uma API diferente para cada fornecedor... a API padrão é o que garante competição e portabilidade.

[rubenskuhl]

Veja o issue #180 a respeito do /v2.

[pnegri]

Não irá acontecer, e duvido que o bacen se posicione assim. Ele pode enforcement de oferecer a api no padrão, mas nada impede de oferecer uma api adicional ou um layer acima. Senão bau bau inovação né? Iugu oferece todo um sistema de gestão de assinaturas e de pagamentos, com envio de fatura meio eletronico e físico, é o que vendemos, não vendo api pra receber pix. Boa parte das funcionalidades que oferecemos não tem a ver com um recebimento avulso de pix.

Patrick Negri - CTO iugu

---

From: Rubens Kuhl notifications@github.com Sent: Monday, November 16, 2020 3:30:06 PM To: bacen/pix-api pix-api@noreply.github.com Cc: Patrick Ribeiro Negri patrick@iugu.com; Author author@noreply.github.com Subject: Re: [bacen/pix-api] Problema no QR Code - Acompanhamento do Lançamento (#185)

O BACEN é o instituidor do arranjo. As regras são dele. E o que não compensa para lojistas é ter uma API diferente para cada fornecedor... a API padrão é o que garante competição e portabilidade.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHubhttps://github.com/bacen/pix-api/issues/185#issuecomment-728244349, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AAAJTDS22SQN6GB6EJRF4ATSQFVS5ANCNFSM4TXPMWUQ.

[rubenskuhl]

O BACEN já se posicionou, está no regulamento: https://www.bcb.gov.br/estabilidadefinanceira/exibenormativo?tipo=Resolu%C3%A7%C3%A3o%20BCB&numero=30

[rubenskuhl]

E isso já tinha sido antecipado no dia 08.09, quando o BACEN mandou o seguinte para os PSPs:

[pnegri]

Conheço o regulamento, e discordo da sua interpretação. Eu preciso garantir a interoperabilidade, mas nada impede que eu ofereça layers de automação adicionais, senão vira uma guerra de preço só e você ainda obriga cada lojista a ter que construir muito mais coisa do lado dele (ex marketplaces tipo doghero e rappi).

Ex. Eu ofereço a api padrao de pix pra receber, mas ofereço uma api que envia o email com o qr code pro pagador (que faça a criação do qr code e o envio do email, inclusive mostrando no log se o pagador abriu o email).

Fora os modelos hibridos (software de gestão que também é ip), onde vc precisa seguir a regra do erp pra poder criar um recebimento. Nesse modelo nem dá pra oferecer a api padrão pq o sistema sequer consegue criar uma fatura.

Patrick Negri - CTO iugu

---

De: Rubens Kuhl notifications@github.com Enviado: segunda-feira, 16 de novembro de 2020 15:36 Para: bacen/pix-api Cc: Patrick Ribeiro Negri; Author Assunto: Re: [bacen/pix-api] Problema no QR Code - Acompanhamento do Lançamento (#185)

O BACEN já se posicionou, está no regulamento: https://www.bcb.gov.br/estabilidadefinanceira/exibenormativo?tipo=Resolu%C3%A7%C3%A3o%20BCB&numero=30

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHubhttps://github.com/bacen/pix-api/issues/185#issuecomment-728247687, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AAAJTDQ575BSX6PV4AJE2T3SQFWKFANCNFSM4TXPMWUQ.

[rubenskuhl]

Não tem problema, a conversa sua é com o Banco Central, pois já foi denunciado. Mas pelo menos Pix deveria estar disponível na API padrão e em alguma API alternativa no mesmo prazo e nas mesmas condições comerciais para poder dizer que é só uma facilidade. Sem a oferta da API padrão no mesmo prazo e condições, é lock-in e vai ser recebido por potenciais clientes como eu dessa forma.

[masyaf]

O bom de tudo isso é que o BACEN estar realizando uma padronização mínima e obrigatória, para não se tornar uma bagunça, vide os CNABS (Inclusive o CNAB 750 para pix), as NFSE, e entre outras. Espero que o BACEN mantenha forças para continuar regulamentando essas padronizações, senão vira bagunça..

[pnegri]

E só lembrando que iugu não oferece uma api de Pix, oferecemos uma api de gestão de cobranças (onde uma pequena parte dela é pix). Acredito que sua confusão está ai.

Patrick Negri - CTO iugu

---

From: Patrick Ribeiro Negri patrick@iugu.com Sent: Monday, November 16, 2020 3:43:09 PM To: bacen/pix-api reply@reply.github.com; bacen/pix-api pix-api@noreply.github.com Cc: Author author@noreply.github.com Subject: Re: [bacen/pix-api] Problema no QR Code - Acompanhamento do Lançamento (#185)

Conheço o regulamento, e discordo da sua interpretação. Eu preciso garantir a interoperabilidade, mas nada impede que eu ofereça layers de automação adicionais, senão vira uma guerra de preço só e você ainda obriga cada lojista a ter que construir muito mais coisa do lado dele (ex marketplaces tipo doghero e rappi).

Ex. Eu ofereço a api padrao de pix pra receber, mas ofereço uma api que envia o email com o qr code pro pagador (que faça a criação do qr code e o envio do email, inclusive mostrando no log se o pagador abriu o email).

Fora os modelos hibridos (software de gestão que também é ip), onde vc precisa seguir a regra do erp pra poder criar um recebimento. Nesse modelo nem dá pra oferecer a api padrão pq o sistema sequer consegue criar uma fatura.

Patrick Negri - CTO iugu

---

De: Rubens Kuhl notifications@github.com Enviado: segunda-feira, 16 de novembro de 2020 15:36 Para: bacen/pix-api Cc: Patrick Ribeiro Negri; Author Assunto: Re: [bacen/pix-api] Problema no QR Code - Acompanhamento do Lançamento (#185)

O BACEN já se posicionou, está no regulamento: https://www.bcb.gov.br/estabilidadefinanceira/exibenormativo?tipo=Resolu%C3%A7%C3%A3o%20BCB&numero=30

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHubhttps://github.com/bacen/pix-api/issues/185#issuecomment-728247687, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AAAJTDQ575BSX6PV4AJE2T3SQFWKFANCNFSM4TXPMWUQ.

[rubenskuhl]

Acredito que essa desculpa não cole com pessoas inteligentes como as do Banco Central. Mas você não precisa me convencer, eu já foquei os 2.2+ milhões de recebimentos por ano em fornecedores que não tentam prender cliente desse jeito.

[pnegri]

Engraçado só o seu posicionamento, tentando forçar o entendimento da regra.

PS. Legal que tem 2 milhões de unidades de recebimento, mais um motivo ainda pra não ser importar com interoperabilidade. Maioria dos grandes nem se importam com isso. Lembrando que a api pública é muito mais uma defesa para os pequenos. ​ O que importa nesse momento é quem está em produção, com suporte a geração de qr dinamico, com preços coerentes e atendimento rápido e estabilidade.

Tem o que assim no ar? Uns 3-4 no máximo contando com a gente?

Patrick Negri - CTO iugu

---

From: Rubens Kuhl notifications@github.com Sent: Monday, November 16, 2020 3:48:07 PM To: bacen/pix-api pix-api@noreply.github.com Cc: Patrick Ribeiro Negri patrick@iugu.com; Author author@noreply.github.com Subject: Re: [bacen/pix-api] Problema no QR Code - Acompanhamento do Lançamento (#185)

Acredito que essa desculpa não cole com pessoas inteligentes como as do Banco Central. Mas você não precisa me convencer, eu já foquei os 2.2+ milhões de recebimentos por ano em fornecedores que não tentam prender cliente desse jeito.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHubhttps://github.com/bacen/pix-api/issues/185#issuecomment-728253901, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AAAJTDRVE4LTK5HAVD432BTSQFXWPANCNFSM4TXPMWUQ.

[rubenskuhl]

O bom de trabalhar anos com padrões é entender o valor disso para o ecossistema. Se a Internet hoje é útil para tanta gente, é por causa dos padrões que a fizeram crescer.

Quanto a estar no ar, o seu está com URL malformada como já informei, então não conta.

[renatofrota]

Não tem problema, a conversa sua é com o Banco Central, pois já foi denunciado. Mas pelo menos Pix deveria estar disponível na API padrão e em alguma API alternativa no mesmo prazo e nas mesmas condições comerciais para poder dizer que é só uma facilidade. Sem a oferta da API padrão no mesmo prazo e condições, é lock-in e vai ser recebido por potenciais clientes como eu dessa forma.

Espero que a sua denúncia não prospere. Meu entendimento é igual ao do Patrick. Não faz o menor sentido o BACEN forçar o fornecimento da API Pix como única forma de automação para todos os pagamentos que forem Pix, especialmente em se tratando de instituições de intermediação, gateways e afins que operam com outras formas de pagamento. Ter que integrar uma API que lida com "tudo menos Pix" e outra que é "a exclusiva do Pix" seria um retrocesso, não um avanço.

[renatofrota]

O bom de trabalhar anos com padrões é entender o valor disso para o ecossistema. Se a Internet hoje é útil para tanta gente, é por causa dos padrões que a fizeram crescer.

Quanto a estar no ar, o seu está com URL malformada como já informei, então não conta.

Nesse aspecto, eu concordo com você. A URL tá fora do padrão. Mas culpo o BACEN pela confusão, vide #180.

[pnegri]

Não está. Leia o issue lá que vc mesmo mencionou. Na 2.0 não era obrigatória e na 2.1 é, porem a 2.x é retro compatível. Tem muito app ainda que só ta lendo a versão 1.0 e tem app ainda com problema.

Patrick Negri - CTO iugu

---

From: Rubens Kuhl notifications@github.com Sent: Monday, November 16, 2020 3:56:22 PM To: bacen/pix-api pix-api@noreply.github.com Cc: Patrick Ribeiro Negri patrick@iugu.com; Author author@noreply.github.com Subject: Re: [bacen/pix-api] Problema no QR Code - Acompanhamento do Lançamento (#185)

O bom de trabalhar anos com padrões é entender o valor disso para o ecossistema. Se a Internet hoje é útil para tanta gente, é por causa dos padrões que a fizeram crescer.

Quanto a estar no ar, o seu está com URL malformada como já informei, então não conta.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHubhttps://github.com/bacen/pix-api/issues/185#issuecomment-728258188, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AAAJTDR3YFL5UJ7P3VENLZDSQFYVNANCNFSM4TXPMWUQ.

[renatofrota]

Não está. Leia o issue lá que vc mesmo mencionou. Na 2.0 não era obrigatória e na 2.1 é, porem a 2.x é retro compatível.

Está. Ver #180.

[pnegri]

Exato. Não ficou claro a obrigatoriedade conforme está no 180, além disso, se ela é compatível não tem coml ser obrigatória.

Patrick Negri - CTO iugu

---

From: renatofrota notifications@github.com Sent: Monday, November 16, 2020 3:58:19 PM To: bacen/pix-api pix-api@noreply.github.com Cc: Patrick Ribeiro Negri patrick@iugu.com; Author author@noreply.github.com Subject: Re: [bacen/pix-api] Problema no QR Code - Acompanhamento do Lançamento (#185)

O bom de trabalhar anos com padrões é entender o valor disso para o ecossistema. Se a Internet hoje é útil para tanta gente, é por causa dos padrões que a fizeram crescer.

Quanto a estar no ar, o seu está com URL malformada como já informei, então não conta.

Nesse aspecto, eu concordo com você. A URL tá fora do padrão. Mas culpo o BACEN pela confusão, vide #180https://github.com/bacen/pix-api/issues/180.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHubhttps://github.com/bacen/pix-api/issues/185#issuecomment-728259200, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AAAJTDVVCACS37K35UP7RYDSQFY4XANCNFSM4TXPMWUQ.

[rubenskuhl]

Não tem problema, a conversa sua é com o Banco Central, pois já foi denunciado. Mas pelo menos Pix deveria estar disponível na API padrão e em alguma API alternativa no mesmo prazo e nas mesmas condições comerciais para poder dizer que é só uma facilidade. Sem a oferta da API padrão no mesmo prazo e condições, é lock-in e vai ser recebido por potenciais clientes como eu dessa forma.

Espero que a sua denúncia não prospere. Meu entendimento é igual ao do Patrick. Não faz o menor sentido o BACEN forçar o fornecimento da API Pix como única forma de automação para todos os pagamentos que forem Pix, especialmente em se tratando de instituições de intermediação, gateways e afins que operam com outras formas de pagamento. Ter que integrar uma API que lida com "tudo menos Pix" e outra que é "a exclusiva do Pix" seria um retrocesso, não um avanço.

Esse argumento poderia defender quem oferece uma API proprietária e uma API Pix padrão conjuntamente nos mesmos prazos e condições comerciais. Não consegue defender quem só tem API proprietária.

[pnegri]

Então Renato. Mas se ela fala que precisa ser retro compatível então gera dúvidas né?

Patrick Negri - CTO iugu

---

From: renatofrota notifications@github.com Sent: Monday, November 16, 2020 3:59:22 PM To: bacen/pix-api pix-api@noreply.github.com Cc: Patrick Ribeiro Negri patrick@iugu.com; Author author@noreply.github.com Subject: Re: [bacen/pix-api] Problema no QR Code - Acompanhamento do Lançamento (#185)

Não está. Leia o issue lá que vc mesmo mencionou. Na 2.0 não era obrigatória e na 2.1 é, porem a 2.x é retro compatível.

Está. Ver #180https://github.com/bacen/pix-api/issues/180.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHubhttps://github.com/bacen/pix-api/issues/185#issuecomment-728259722, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AAAJTDWW2N4TWTNHJQ2LPO3SQFZAVANCNFSM4TXPMWUQ.

[rubenskuhl]

O comunicado que o BACEN enviou está muito claro. A data para colocar v2 na URL era hoje. Não está, está fora de padrão. Mas quem liga, né ?

[pnegri]

Rubens. O que vc não entende é que nem tenho como oferecer uma api pix only. Eu ofereço gestão de cobrança. Tem muito mais info pra criar um item destes.

Entendo de onde vc esta vindo, só não faz sentido. A explicação dos amigos ai em cima retrata bem o que acontece. Talvez faça sentido no seu negócio, mas não vamos esquecer que existem outras formas de pagamento que não irão morrer agora e que, principalmente os pequenos, irão continuar precisando.

Patrick Negri - CTO iugu

---

From: Rubens Kuhl notifications@github.com Sent: Monday, November 16, 2020 3:59:57 PM To: bacen/pix-api pix-api@noreply.github.com Cc: Patrick Ribeiro Negri patrick@iugu.com; Author author@noreply.github.com Subject: Re: [bacen/pix-api] Problema no QR Code - Acompanhamento do Lançamento (#185)

Não tem problema, a conversa sua é com o Banco Central, pois já foi denunciado. Mas pelo menos Pix deveria estar disponível na API padrão e em alguma API alternativa no mesmo prazo e nas mesmas condições comerciais para poder dizer que é só uma facilidade. Sem a oferta da API padrão no mesmo prazo e condições, é lock-in e vai ser recebido por potenciais clientes como eu dessa forma.

Espero que a sua denúncia não prospere. Meu entendimento é igual ao do Patrick. Não faz o menor sentido o BACEN forçar o fornecimento da API Pix como única forma de automação para todos os pagamentos que forem Pix, especialmente em se tratando de instituições de intermediação, gateways e afins que operam com outras formas de pagamento. Ter que integrar uma API que lida com "tudo menos Pix" e outra que é "a exclusiva do Pix" seria um retrocesso, não um avanço.

Esse argumento poderia defender quem oferece uma API proprietária e uma API Pix padrão conjuntamente nos mesmos prazos e condições comerciais. Não consegue defender quem só tem API proprietária.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHubhttps://github.com/bacen/pix-api/issues/185#issuecomment-728259993, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AAAJTDTEZGZR6NMKVKGAUPTSQFZC3ANCNFSM4TXPMWUQ.

[rubenskuhl]

A sua recusa em oferecer a API Pix padrão é exatamente a desobediência ao regulamento. Obrigado por agregar tantas provas cabais ao processo.

[pnegri]

Vamos tentar por. Se quebrar voltamos. Maior problema é sair testando em cada app e banco. Muitos podem quebrar por isso.

Patrick Negri - CTO iugu

---

From: Rubens Kuhl notifications@github.com Sent: Monday, November 16, 2020 4:00:35 PM To: bacen/pix-api pix-api@noreply.github.com Cc: Patrick Ribeiro Negri patrick@iugu.com; Author author@noreply.github.com Subject: Re: [bacen/pix-api] Problema no QR Code - Acompanhamento do Lançamento (#185)

O comunicado que o BACEN enviou está muito claro. A data para colocar v2 na URL era hoje. Não está, está fora de padrão. Mas quem liga, né ?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHubhttps://github.com/bacen/pix-api/issues/185#issuecomment-728260333, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AAAJTDTPXFMO2IRKARCRHJDSQFZFHANCNFSM4TXPMWUQ.

[pnegri]

Rsrsrs. Ainda bem que quem me notifica é o bacen né.

Tenho 50 mil clientes, maioria pequeno, eles estão indo pra produção entre hoje e sexta. Imagina falar pra eles que nessa nova forma eles vão ter que integrar de novo. Não faz sentido e temho certeza que não é o que o bacen quer. Não tenho problema nenhum em parar de ofertar pix e oferecer a api pix only e "jogar fora 50 mil lojas", se for do desejo dl bacen. Participei de todo o processo do bacen pra virar ip que levou quase 3 anos e depois de ter lidado tanto com eles acho difícil esse ser o posicionamento.

Patrick Negri - CTO iugu

---

From: Rubens Kuhl notifications@github.com Sent: Monday, November 16, 2020 4:04:39 PM To: bacen/pix-api pix-api@noreply.github.com Cc: Patrick Ribeiro Negri patrick@iugu.com; Author author@noreply.github.com Subject: Re: [bacen/pix-api] Problema no QR Code - Acompanhamento do Lançamento (#185)

A sua recusa em oferecer a API Pix padrão é exatamente a desobediência ao regulamento. Obrigado por agregar tantas provas cabais ao processo.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHubhttps://github.com/bacen/pix-api/issues/185#issuecomment-728262606, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AAAJTDXJCMCIMFZ7KPRHVC3SQFZUPANCNFSM4TXPMWUQ.

[renatofrota]

Vamos tentar por. Se quebrar voltamos. Maior problema é sair testando em cada app e banco. Muitos podem quebrar por isso. Patrick Negri - CTO iugu

Mas você não tem nem que se preocupar em testar. Tem que seguir a regra e o resto que se mexa para aderir ao padrão exigido, @pnegri . Se for se preocupar em manter compatibilidade, a salada vai continuar. Os outros que recebam e tratem as RDRs deles...

[pnegri]

Renato, o problema é que vc tem o cenario de suporte pra considerar. Vc faz isso e lança, daí tem lá 50 mil lojistas que tem o qr code o cliente tenta pagar pelo banco xpto e não vai. Na hora isso vira um problema para nós pq o lojista vem reclamar aqui que o cliente tentou pagar e não conseguiu.

Neste caso é melhor manter o padrão que está funcionando e daí vc vira a chave da nova spec conforme os apps se tornem compatíveis. Pelo menos para efeito de lançamento.

Patrick Negri - CTO iugu

---

From: renatofrota notifications@github.com Sent: Monday, November 16, 2020 4:09:15 PM To: bacen/pix-api pix-api@noreply.github.com Cc: Patrick Ribeiro Negri patrick@iugu.com; Mention mention@noreply.github.com Subject: Re: [bacen/pix-api] Problema no QR Code - Acompanhamento do Lançamento (#185)

Vamos tentar por. Se quebrar voltamos. Maior problema é sair testando em cada app e banco. Muitos podem quebrar por isso. Patrick Negri - CTO iugu

Mas você não tem nem que se preocupar em testar. Tem que seguir a regra e o resto que se mexa para aderir ao padrão exigido, @pnegrihttps://github.com/pnegri . Se for se preocupar em manter compatibilidade, a salada vai continuar. Os outros que recebam e tratem as RDRs deles...

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/bacen/pix-api/issues/185#issuecomment-728264959, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AAAJTDS32DM4MR337OXPWPTSQF2FXANCNFSM4TXPMWUQ.

[rubenskuhl]

É interessante como algumas start-ups querem concorrência para os outros mas não para elas mesmas. Competição é uma via de duas mãos, e é por isso que o BACEN já enviou alertas (como o reproduzido acima) sobre APIs proprietárias, colocou no regulamento... tanto IFs quanto IPs estão sujeitas ao mesmo regulamento do Pix, e se isso não for enforçado neste caso, não vai ser em nenhum caso e adeus padronização. A co-criação já foi(em boa parte), agora é hora do martelo do regulador.

[renatofrota]

Renato, o problema é que vc tem o cenario de suporte pra considerar. Vc faz isso e lança, daí tem lá 50 mil lojistas que tem o qr code o cliente tenta pagar pelo banco xpto e não vai. Na hora isso vira um problema para nós pq o lojista vem reclamar aqui que o cliente tentou pagar e não conseguiu. Neste caso é melhor manter o padrão que está funcionando e daí vc vira a chave da nova spec conforme os apps se tornem compatíveis. Pelo menos para efeito de lançamento. Patrick Negri - CTO iugu

Discordo totalmente. O cliente que não consegue pagar tem que reclamar com o banco xpto dele que não consegue pagar. Para o seu cliente, basta responder "estou seguindo o regulamento, o problema é com o banco xpto do pagador".

Posições "flexíveis" implantadas unilateralmente pela sua parte à revelia de regras estabelecidas só criam mais problemas, nunca soluções.

No caso da posição do BACEN sobre a oferta de API entendo que cabe a questão da interpretação. Mas no caso da exigência do /v2/ na URL do payload, por mais que tenha havido confusão por parte do BACEN na divulgação, se agora você sabe (e não é mais uma questão de interpretação, eles esclareceram que foi uma falha e a nova regra deve ser seguida, por mais que quebre o padrão da revisão anterior de forma inesperada), deve seguir.

[renatofrota]

@ninrod , já que você tem os contatos, você poderia, por favor, tentar levantar qual a posição do BACEN a respeito das APIs de intermediadores, gateways, integradores, fornecedores de solução de cobrança, [...] oferecerem funções que trazem informações sobre pagamentos que foram recebidos via Pix?

Entendo que o BACEN queira padronizar a API, assim como a operação do Pix como um todo, mas não vejo sentido que empresas que oferecem soluções de pagamentos em geral tenham que ofertar APIs distintas para "tudo exceto Pix" e "API exclusiva do Pix". Isso não favorece a implantação, manutenção, conciliação de pagamentos, etc.

No meu ponto de vista, é justificável a padronização para as instituições que querem passar a oferecer tecnologias mais avançadas do que a mera conta transacional que oferecem hoje. Mas para instituições que oferecem primariamente os serviços de cobrança [e intermediação, ..., etc] como solução (e a existência de uma conta transacional ser apenas uma "peça" do jogo, por vezes necessária para a oferta desses serviços), não vejo razoabilidade em impôr a necessidade de oferecer a API Pix como única solução disponível para acesso a essas informações.

Como já falei em um outro issue: depois que um dinheiro caiu na minha conta (seja a transacional daquele fornecedor de soluções ou a conta transacional de uma outra instituição - sendo a solução apenas de gestão/iniciação de pagamentos) ele já é meu dinheiro. Esse fornecedor de soluções (independentemente de qual foi o método utilizado pelo "pagador" para enviar o dinheiro) não poder me passar informações a respeito do meu dinheiro que está na minha conta por meio de outras APIs que não sejam a padronizada do Pix me soa como uma limitação operacional muito grande (até mesmo uma interferência operacional a nível de negócio que - não sou jurista - me parece que o BACEN nem teria autonomia para criar, por mais que seja um regulador do setor financeiro).

Ficar esperando o que acontece nos bastidores entre as instituições e o BACEN deixa os consumidores (eu incluso) muito limitados em escolhas e inseguros jurídica e financeiramente para tomar uma decisão a respeito da contratação de serviços da instituição A ou B sem saber o que vai acontecer amanhã ou depois.

[pnegri]

Renato, o problema é que vc tem o cenario de suporte pra considerar. Vc faz isso e lança, daí tem lá 50 mil lojistas que tem o qr code o cliente tenta pagar pelo banco xpto e não vai. Na hora isso vira um problema para nós pq o lojista vem reclamar aqui que o cliente tentou pagar e não conseguiu. Neste caso é melhor manter o padrão que está funcionando e daí vc vira a chave da nova spec conforme os apps se tornem compatíveis. Pelo menos para efeito de lançamento. Patrick Negri - CTO iugu

Discordo totalmente. O cliente que não consegue pagar tem que reclamar com o banco xpto dele que não consegue pagar. Para o seu cliente, basta responder "estou seguindo o regulamento, o problema é com o banco xpto do pagador".

Posições "flexíveis" implantadas unilateralmente pela sua parte à revelia de regras estabelecidas só criam mais problemas, nunca soluções.

No caso da posição do BACEN sobre a oferta de API entendo que cabe a questão da interpretação. Mas no caso da exigência do /v2/ na URL do payload, por mais que tenha havido confusão por parte do BACEN na divulgação, se agora você sabe (e não é mais uma questão de interpretação, eles esclareceram que foi uma falha e a nova regra deve ser seguida, por mais que quebre o padrão da revisão anterior de forma inesperada), deve seguir.

Colocamos o v2 (E quebrou em alguns apps). Decidimos tirar com base no #170 onde o @ninrod fala sobre a obrigatoriedade em Janeiro:

"Com a chegada da versão 2.2.0 e com sua obrigatoriedade estabelecida no começo de janeiro, pode-se pensar em rejeitar locations que não apresentem o v2 ou o v[n]."

[renatofrota]

Decidimos tirar com base no #170 onde o @ninrod fala sobre a obrigatoriedade em Janeiro:

"Com a chegada da versão 2.2.0 e com sua obrigatoriedade estabelecida no começo de janeiro, pode-se pensar em rejeitar locations que não apresentem o v2 ou o v[n]."

Observe que a sugestão do ninrod foi que os bancos passem a rejeitar as locations sem /v2/ apenas em janeiro (como medida de convivência). Ele não orientou que você (ou qualquer outro envolvido) continue não incluindo o /v2/ na URL até lá propositadamente. São coisas totalmente diferentes.

[rubenskuhl]

@renatofrota notar que o ponto neste issue nem era ter a API Pix como única, mas não ter nem a API Pix disponível em adição a uma API proprietária. Houve sim um issue em que a discussão foi essa, mas neste o PSP não quer nem oferecer também no mesmo momento e nas mesmas condições a API Pix padrão, já que os regulamentos não se aplicam a ele.

[pnegri]

Decidimos tirar com base no #170 onde o @ninrod fala sobre a obrigatoriedade em Janeiro: "Com a chegada da versão 2.2.0 e com sua obrigatoriedade estabelecida no começo de janeiro, pode-se pensar em rejeitar locations que não apresentem o v2 ou o v[n]."

Observe que a sugestão do ninrod foi que os bancos passem a rejeitar as locations sem /v2/ apenas em janeiro (como medida de convivência). Ele não orientou que você (ou qualquer outro envolvido) continue não incluindo o /v2/ na URL até lá propositadamente. São coisas totalmente diferentes.

Sim Renato, mas se não está funcionando em algum app é melhor retirar e acompanhar melhor momento para voltar. Não estou sugerindo por em Janeiro, só acho que para o bem do Pix em si é melhor tentar ser o mais compatível possível neste momento.

[pnegri]

@renatofrota notar que o ponto neste issue nem era ter a API Pix como única, mas não ter nem a API Pix disponível em adição a uma API proprietária. Houve sim um issue em que a discussão foi essa, mas neste o PSP não quer nem oferecer também no mesmo momento e nas mesmas condições a API Pix padrão, já que os regulamentos não se aplicam a ele.

Rubens, eu não vendo API Pix, seja proprietária ou seja a pública, isso que você não entendeu ainda :). Só existe um recebimento pix na iugu depois que existir uma fatura (que está atrelada a várias regras incluindo régua de cobrança). Não tem como criar um recebimento de Pix na iugu sem existir uma fatura antes. Mesmo em uma implementação com API pública vc iria ter que criar um vínculo com uma fatura.

[rubenskuhl]

Enquanto alguns ignoram o regulamento à seu próprio interesse, outros foram lá e criaram as estruturas de dados necessárias para suportar a API Pix padronizada. E não enforçar isso é mostrar para quem seguiu a regra que eles são trouxas, já que o bom é fazer o que se quer.

[pnegri]

Pessoal, esse tópico era para podermos mapear quais apps estão funcionando com QR Code Dinâmico e qual a estrutura de parâmetro que deveria funcionar. É triste ver o direcionamento e briga antes mesmo do negócio funcionar. Quando e se o Bacen se posicionar sobre o que estamos vendendo, vamos nos adaptar, simples assim.

Estamos subindo mais fixes neste momento e iremos começar uma nova bateria de testes de QR dinâmico em todos os apps que temos acesso. Informarei aqui.

[renatofrota]

Enquanto alguns ignoram o regulamento à seu próprio interesse, outros foram lá e criaram as estruturas de dados necessárias para suportar a API Pix padronizada. E não enforçar isso é mostrar para quem seguiu a regra que eles são trouxas, já que o bom é fazer o que se quer.

Sei que não vai mudar nada pra você, mas me sinto na obrigação de dizer: minha admiração por você tá indo pelo ralo depois de ler algumas falas suas nesse repositório. Divergência de opinião é uma coisa totalmente aceitável, mas a sua postura foge totalmente do que eu esperaria num debate civilizado. :crying_cat_face:

Espero que você possa reler, refletir e se permitir adotar uma postura menos agressiva. Eu mesmo já fiz isso em um dado momento debatendo neste mesmo repositório - usei de ironia de uma forma agressiva - e já me arrependi.

[rubenskuhl]

Defesa de padrões e da vantagem deles para a sociedade é algo que todos podemos exercer.

[pnegri]

Pessoal, estamos subindo uma nova versão em 10 minutos. Refizemos o nosso JKU pq vários apps não estavam aceitando (E Nubank estava), porém acabamos de descobrir que Nubank ainda não está validando os certificados jku em produção (E foi um dos primeiros apps a funcionar a leitura do qr dinâmico).

Assim que subirmos irei resetar o status dos apps e iremos começar a testar novamente.

[renatofrota]

Defesa de padrões e da vantagem deles para a sociedade é algo que todos podemos exercer.

Mas o seu direito termina onde começa o do amiguinho. Não é porque na sua visão você está certo e o outro errado, que você está efetivamente certo e o outro errado. Até porque, não foi você que fez a regra. A bola não é sua e você também não é o juiz da partida, então você não pode colocar a bola embaixo do braço e acabar com a brincadeira.

Como o Patrick já disse, abre a sua reclamação e aguarda. Não precisa ficar, nesse meio tempo, fazendo ataques a mera opinião de outras pessoas/empresas, disfarçados de "críticas ao modelo de negócios". A postura da iugu certamente foi adotada não por má fé mas por terem feito uma interpretação diferente da que você fez a respeito do que foi divulgado pelo BACEN.

E, mesmo você pensando diferente, não precisa forçar muito a barra pra entender o lado da iugu (e de outros players que atuam no mesmo mercado e estão tomando a mesma postura e certamente vão defender a mesma liberdade) que de uma hora pra outra viram um novo meio de pagamento surgir e se verem limitados, impedidos de fornecer as soluções que já ofereciam para outros meios de pagamento.

[rubenskuhl]

A reclamação contra o PSP em referência já foi aberta em 03.11, hoje só adicionei mais dados gentilmente fornecidos pelo representante do PSP. Eu não vejo como dar outra interpretação ao que o BACEN publicou até o momento, mas é ele mesmo que pode interpretar e enforçar o regulamento, então me parece que há um consenso de deixar o BACEN fazer essa interpretação. O mercado financeiro é um mercado de regulação estrita, e quem inova nele precisa jogar as regras do jogo, ou procurar mercados com menor regulação. Por exemplo, talvez ser um PSP no SPI não seja a melhor escolha de quem prefere não oferecer a API Pix e não se encaixa como participante obrigatório (+500 mil contas).

[pnegri]

De qual regulada vc é mesmo Rubens? Pq aqui somos IP e estamos debaixo de um guarda chuvas de regras muito maior que o próprio Pix em si (Do próprio Bacen). Só peço este cuidado ao comparar uma "startup" conosco. Você fala como se não tivéssemos investido mais de 10 milhões de reais em regulatório (E como se não tivesse um jurídico gigante dedicado só pra isso). Cuidado com suas opiniões próprias pq tudo que se escreve fica aí na internet, e o tempo é o maior inimigo de quem busca credibilidade. Abraços

[pnegri]

Defesa de padrões e da vantagem deles para a sociedade é algo que todos podemos exercer.

Mas o seu direito termina onde começa o do amiguinho. Não é porque na sua visão você está certo e o outro errado, que você está efetivamente certo e o outro errado. Até porque, não foi você que fez a regra. A bola não é sua e você também não é o juiz da partida, então você não pode colocar a bola embaixo do braço e acabar com a brincadeira.

Como o Patrick já disse, abre a sua reclamação e aguarda. Não precisa ficar, nesse meio tempo, fazendo ataques a mera opinião de outras pessoas/empresas, disfarçados de "críticas ao modelo de negócios". A postura da iugu certamente foi adotada não por má fé mas por terem feito uma interpretação diferente da que você fez a respeito do que foi divulgado pelo BACEN.

E, mesmo você pensando diferente, não precisa forçar muito a barra pra entender o lado da iugu (e de outros players que atuam no mesmo mercado e estão tomando a mesma postura e certamente vão defender a mesma liberdade) que de uma hora pra outra viram um novo meio de pagamento surgir e se verem limitados, impedidos de fornecer as soluções que já ofereciam para outros meios de pagamento.

Renato, obrigado pelas palavras. Foi bem nesta linha mesmo, fizemos entrevistas com nossos atuais clientes para ver qual era a vontade deles e também fizemos uma análise de custo e oportunidade para ver como oferecer a API neste formato (Se é que é possível no nosso caso). Os clientes tem um consenso que uma única integração é melhor para o negócio deles, mas não queremos perder a oportunidade de quem busca apenas a transação Pix sem nenhum tipo de inteligência ou automação também. Nós corremos atrás do que fazia sentido naquele momento, ofertar para a base atual, já integrada, testada, a prova de carga, uma nova modalidade de pagamento às vesperas de Black Friday.

[rubenskuhl]

De nenhuma, senão eu não estava procurando um PSP com API Pix, que é o que fazem os ECs... mas conforme essa busca me leva ao conhecimento de violações do regramento, é meu dever cívico reportá-las. Eu tenho opiniões publicadas na Internet desde 1995, então o legado delas me é bem familiar.

[pnegri]

De nenhuma, senão eu não estava procurando um PSP com API Pix, que é o que fazem os ECs... mas conforme essa busca me leva ao conhecimento de violações do regramento, é meu dever cívico reportá-las. Eu tenho opiniões publicadas na Internet desde 1995, então o legado delas me é bem familiar.

Exatamente meu ponto. Concorda que talvez você não entenda tanto deste mercado regulado quanto acha que entende? Já disse que não oferto API Pix, seja ela aberta ou fechada. Oferto uma API de Gestão de Cobranças, integradas ao sistema da iugu (Que possui mensalidade), para usar tais funcionalidades (De Gestão de Cobrança). Sem mais.