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]

O regulamento e o esclarecimento do BACEN reproduzido acima falam por si. Eles são questões de fato, não de opinião. A falácia de se usar posição para discutir algo se chama argumentum ad verencundiam , mas ela não vai funcionar ao discutir isso com o BACEN. Comigo, assuma que eu sou burro que está tudo certo.

[pnegri]

O regulamento e o esclarecimento do BACEN reproduzido acima falam por si. Eles são questões de fato, não de opinião. A falácia de se usar posição para discutir algo se chama argumentum ad verencundiam , mas ela não vai funcionar ao discutir isso com o BACEN. Comigo, assuma que eu sou burro que está tudo certo.

Ah sim, pq vc já conversou com o regulador várias vezes para discutir outras questões né? Meu amigo, pare de falar besteira que você está passando vergonha pra todo mundo que lê o tópico. Você fala como se já não tivessemos passado por outras questões em relação a IP, esquece que somos Instituição de Pagamento regulada com N obrigações perante ao orgão. Desculpe, mas você está errado. E como eu havia dito, SE o regulador se posicionar contra, iremos apresentar nosso argumento e o resultado que vier a gente segue, assim como as outras N questões do regulador. Claramente você não entende do que está falando, e ainda poluiu um tópico genuíno.

[rubenskuhl]

De fato eu já discuti outras questões com o regulador como PixLink e Requisição de Pagamento, e é uma pena que eu tenha que ficar denunciado violações ao regulamento ao invés de contribuir propositivamente. Mas é o que vou ter que fazer sempre que esse tipo de violação chegar ao meu conhecimento. Se o regulador não se posicionar contra, ele terá grande dificuldade por questões isonômicas de enforçar a API Pix em muitos outros contextos. O que está escrito no regulamento e no aviso iriam por terra. Os dados de realidade são o regulamento (https://www.bcb.gov.br/estabilidadefinanceira/exibenormativo?tipo=Resolu%C3%A7%C3%A3o%20BCB&numero=30) e o alerta enviado aos PSPs no início de Setembro, que junto numa única resposta para conveniência dos leitores:

[pnegri]

De fato eu já discuti outras questões com o regulador como PixLink e Requisição de Pagamento, e é uma pena que eu tenha que ficar denunciado violações ao regulamento ao invés de contribuir propositivamente. Mas é o que vou ter que fazer sempre que esse tipo de violação chegar ao meu conhecimento. Se o regulador não se posicionar contra, ele terá grande dificuldade por questões isonômicas de enforçar a API Pix em muitos outros contextos. O que está escrito no regulamento e no aviso iriam por terra.

Tudo isso é Pix, estou falando de discutir realmente questões fora do Pix (Que é novo), com o regulador. Acho engraçado que nunca passou por outras questões reguladas do bacen fora do contexto de Pix (A água bate bem mais embaixo viu). Bem, por gentileza vamos encerrar a discussão e faça o que achar melhor, você não está no direito de discutir nada conosco por aqui (e nem é de sua alçada). Peço a gentileza de sair do tópico.

[rubenskuhl]

Achei que esse fosse o GitHub do BACEN.

[renatofrota]

Achei que esse fosse o GitHub do BACEN.

E é. Por isso que ele pediu a gentileza. Mas se vê que você desconhece (ou ignora) a palavra. :roll_eyes:

[rubenskuhl]

Achei que esse fosse o GitHub do BACEN.

E é. Por isso que ele pediu a gentileza. Mas se vê que você desconhece (ou ignora) a palavra. 🙄

"no direito" não é gentileza. No direito, todo cidadão pode interagir com a administração pública.

[renatofrota]

Achei que esse fosse o GitHub do BACEN.

E é. Por isso que ele pediu a gentileza. Mas se vê que você desconhece (ou ignora) a palavra. roll_eyes

"no direito" não é gentileza. No direito, todo cidadão pode interagir com a administração pública.

Você tem dificuldades latentes de interpretação, Rubens. Direito, você tem. E ninguém lhe negou. Fica aí interagindo. Boa noite.

[pnegri]

Pessoal, atualizamos a lista.

Podem testar e enviar Issue ou PR?

https://iugu.github.io/lancamentopix/

[pnegri]

Atualizado com novas infos, ainda instável :(

[rodrigonunes100]

@pnegri O iugu oferece o PIX através da PIX API? Se a resposta for não, isso que você está fazendo no mínimo é uma propaganda negativa. O regulamento do Bacen em relação a essa questão não dá espaço para interpretação. "Sendo vedada a oferta de APIs proprietárias".

[renatofrota]

Quem diria, o PagTesouro oferece geração de cobranças, consulta de status e fornece, inclusive, notificação de conclusão de pagamento (inclusive para pagamentos via Pix). Recursos estes que estão todos disponíveis na API Pix mas, no entanto, fazem isso - exclusivamente - por meio de uma API proprietária.

Créditos ao @rubenskuhl pela informação lá no #182

Aguardando a abertura da denúncia... :smile:

[rubenskuhl]

Quem diria, o PagTesouro oferece geração de cobranças, consulta de status e fornece, inclusive, notificação de conclusão de pagamento (inclusive para pagamentos via Pix). Recursos estes que estão todos disponíveis na API Pix mas, no entanto, fazem isso - exclusivamente - por meio de uma API proprietária.

Créditos ao @rubenskuhl pela informação lá no #182

Aguardando a abertura da denúncia... 😄

Mesmo grupo econômico, é um tema que já foi abordado em outro issue. Do mesmo jeito que o C6 e o PayGo não precisam usar a API Pix se não quiserem para a interligação entre os sistemas do C6 e os POS do PayGo. Do mesmo jeito que a Via Varejo e o BanQi podem usar ou não entre eles a API Pix.

[renatofrota]

Mesmo grupo econômico, é um tema que já foi abordado em outro issue. Do mesmo jeito que o C6 e o PayGo não precisam usar a API Pix se não quiserem para a interligação entre os sistemas do C6 e os POS do PayGo. Do mesmo jeito que a Via Varejo e o BanQi podem usar ou não entre eles a API Pix.

Compreendo.

De qualquer forma, tudo que foi discutido aqui a respeito do "pode" / "não pode" sobre a forma de atuação da iugu (e que, para que fique claro para desavisados, outros gateways/intermediadores fazem exatamente igual), está resumido, em pontos chaves:

@ ninrod - aqui, na issue 62, especificamente (com grifo meu):

Esse "seguindo todos os intermediadores, gateways, acquirers e subacquirers do mundo, como você bem observou" é um ponto importante que, acredito, tem que ser esclarecido: o BACEN não está padronizando, neste repositório, uma API para gateways, acquirers, subacquirers ou TEFs, os quais continuarão existindo. Estamos estabelecendo uma API para implementação por parte dos PSPs nos quais o usuário recebedor possui conta. O "gateway" pode continuar notificando seu cliente do jeito que achar melhor.

E, mesmo se a iugu e outros players similares não forem considerados "gateways", o que eles fazem emitindo cobranças e notificando as "baixas" (a compensação dos pagamentos), se encaixa numa discussão que tivemos na mesma issue 62 em relação a bancos e outras IFs que oferecem APIs de cobrança e consulta (e já ofereciam antes do Pix):

@ renatofrota - aqui, especificamente:

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.

@ rubenskuhl - aqui (com grifo meu):

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.

Ou seja, lá no #62 você concordou com meus argumentos e falou claramente que a notificação de que um pagamento foi recebido (desde que não informando o txid, que é informação interna do arranjo Pix) estaria "ok" e passou todo esse tempo aqui nessa issue indo contra a sua própria opinião. Me parece pura birra.

[pnegri]

Não tem a ver com mesmo grupo econômico, tem a ver com o que é oferecido, que é o consumo de geração e pagamento de guias do GRU. E não, não é o mesmo grupo econômico nem de perto. O problema é que o pessoal está com dificuldade de diferenciar API Pix (Baixo Nível), de API <Serviço de Valor Agregado> (Alto Nível). São coisas diferentes pessoal.

Imagina uma empresa, vamos pegar por ex. Natura. Ela vai lá e faz o app dela com todo o ecosistema, e incluí a geração de recebimentos por Pix. Posteriormente, ela decide ofertar a automatização de processos do app, e uma dessas funcionalidades é a geração de cobrança. A vendedora da Natura está dentro da plataforma, ela precisa necessariamente passar por lá por conta de regras de comissionamento, marketplace, etc, inclusive contratualmente. Nesse caso, a Natura tem uma API e ela não é obrigada a ofertar a API Pix de forma nativa, só pq existe este serviço dentro do serviço de valor agregado que é o negócio em si.

Outro caso são as centralizadoras PagSeguro, PayPal, Wirecard, e nós Iugu mero mortais nesse ecosistema de e-commerce,que são responsáveis por mais de 500 mil lojas hoje, e que levaram anos para ter todas as integrações com todas as plataformas de ecommerce existentes (Magento, Wordpress, WooCommerce, VTex). Essas lojas, já estão integradas, e, algumas plataformas, como a iugu, levaram quase 3 anos para ter plugins para toda essa renca de lojas online existente. Aliás, a própria integração da VTex para pagamentos é "genérica" para qualquer forma de pagamento, e é o Intermediador que integra. Essas 500 mil lojas hoje já estão integradas nestas plataformas, e para a maioria, que é pequeno, é quase inadmissível ter que integrar uma nova forma sendo que eles escolheram uma high level exatamente pela simplicidade e por elas terem bancado o custo (Lembra que todas essas lojinhas podem ir lá e contratar uma adquirente e um banco para emitir boleto mas preferem um intermediador exatamente por isso).

Nestes dois casos citados acima, não tem comercialização de API Pix e sim comercialização de algo maior. Não tiro de forma alguma o argumento de que se eu comercializar uma API Pix, preciso oferecer no padrão.

Novamente, meu entendimento é que não é isso que ofereço. Meus clientes usam gatilhos para saber se o cliente deles abriu o e-mail, e calcular automaticamente a próxima automação em caso do cliente não ter aberto o e-mail (Ligo pro cliente com msg de audio automática? Mando pro meu ERP pra uma fila de cobrança?), fora os clientes de assinatura e faturamento (Ex: Compania de telefonia que todo dia consome a API para tarifar o consumo dos clientes, e no final do mês, é calculado e gerado uma fatura com código de barras, e agora com Pix. Meu cliente compra isso de mim. Só pix não faz sentido pra ele pq ele precisa de toda essa infra de faturamento, controle de churn, etc.

[pnegri]

Eu não tenho problema nenhum em separar minha API (Se for possível para determinados clientes), e ofertar. O problema é que eles não querem. Eles não querem 1 plugin pra Magento pra todas as formas de pagamento e outro plugin pra Pix. Eles não querem ter que esperar todo o prazo de desenvolvimento de plugins para cada uma dessas plataformas, e finalmente, eles não querem API's diferentes para conciliar os pagamentos. As plataformas deles já estão integradas com ERP's, seja de pequeno porte ou de grande porte. Enfim, faz sentido zero o que foi falado nesse post pelo Rubens.

Agora, se eu tivesse numa concorrência para uma API específica para Pix, com registro de chaves de endereçamento e tudo mais (O que não é o caso), eu até concordaria com o que está sendo falado. Aliás, nem tenho API's pra isso pq não estou oferecendo infra pra indiretos ou pra quem quer trabalhar exclusivamente com Pix. Pelo menos, não ainda, nosso foco nesse momento é poderizar de imediato os 50 mil lojistas abaixo de nós, do dia para noite, com zero integração. Se em algum momento eles quiserem instalar um novo plugin, ou fazer uma nova integração, e não quiserem a nossa comodidade, é só comprar um plugin ou contratar um desenvolvedor e ir atrás de quem faz isso (Muito ecommerce nasce num intermediador, e o caminho natural quando cresce é contratar sua própria adquirente e seu banco emissor de boletos).

O amigo sequer leu a API e tentou ver quem são nossos clientes hoje. Nossa API existe a 8 anos, está documentada aqui de forma bem aberta https://dev.iugu.com/reference, tem negócios que ganham dinheiro vendendo plugin para todas essas plataformas de e-commerce. Ele está querendo pegar a API de um negócio que resolve problemas bem maiores do que "receber um pix", e forçar a empresa a oferecer a API para ele receber um pix, sendo que não é isso que oferecemos.

[rubenskuhl]

De qualquer forma, tudo que foi discutido aqui a respeito do "pode" / "não pode" sobre a forma de atuação da iugu (e que, para que fique claro para desavisados, outros gateways/intermediadores fazem exatamente igual), está resumido, em pontos chaves:

Todos os que tenho tido conhecimento estão listados em #76 . De fato não é só o PSP deste issue, o que torna ainda mais importante que isso seja esclarecido.

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.

Ou seja, lá no #62 você concordou com meus argumentos e falou claramente que a notificação de que um pagamento foi recebido (desde que não informando o txid, que é informação interna do arranjo Pix) estaria "ok" e passou todo esse tempo aqui nessa issue indo contra a sua própria opinião. Me parece pura birra.

Questão de contexto, pois o ponto eram APIs de informação sobre a conta bancária versus API de cobrança claramente alternativas ao Pix Cobrança. E se usar o txid para concluir qual cobrança foi liquidada, o efeito é o mesmo.

[rubenskuhl]

Sobre clientes reféns de APIs proprietárias não quererem mudar, isso é análogo à Síndrome de Estocolmo, onde os sequestrados passam a empatizar com seus captores.

[flaviolenz]

Pessoal, atualizamos a lista.

Podem testar e enviar Issue ou PR?

https://iugu.github.io/lancamentopix/

A Iugu eh uma IP ? Ja está funcionando HOJE pra receber um Pix por QR-Estatico, por exemplo e ter como consultar via uma API qualquer? (ou receber um webhook)

[pnegri]

Sim, ip.

Não temos api pix, porem vc pode usar api de automação de cobrança para fazer isso que vc quer. Uns 30 min de integração em qquer linguagem.

Patrick Negri - CTO iugu

---

From: flaviolenz notifications@github.com Sent: Tuesday, November 17, 2020 11:02:27 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] Discussão sobre API's, Intermediadores e Gateways (#185)

Pessoal, atualizamos a lista.

Podem testar e enviar Issue ou PR?

https://iugu.github.io/lancamentopix/

A Iugu eh uma IP ? Ja está funcionando HOJE pra receber um Pix por QR-Estatico, por exemplo e ter como consultar via uma API qualquer? (ou receber um webhook)

— 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-729327265, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AAAJTDXE3WDGAU2UXUP6U2LSQMTLHANCNFSM4TXPMWUQ.

[pnegri]

1. Cria uma fatura, por padrao ela pode ser paga com cc, debito, boleto, ted e pix. Mas especifique que aceita pix apenas. Se for marketplace, pode configurar as rotas pata distribuição do dinheiro.
2. Se a fatura for paga, vc recebe um gatilho com as infos
3. Vc pode chamar api de verificação por lote de faturas ou de uma única fatura.

Temos lib para ruby, java, php, etc.

Att

Patrick Negri - CTO iugu

---

From: Patrick Ribeiro Negri patrick@iugu.com Sent: Tuesday, November 17, 2020 11:11:01 PM To: bacen/pix-api reply@reply.github.com; bacen/pix-api pix-api@noreply.github.com Cc: Mention mention@noreply.github.com Subject: Re: [bacen/pix-api] Discussão sobre API's, Intermediadores e Gateways (#185)

Sim, ip.

Não temos api pix, porem vc pode usar api de automação de cobrança para fazer isso que vc quer. Uns 30 min de integração em qquer linguagem.

Patrick Negri - CTO iugu

---

From: flaviolenz notifications@github.com Sent: Tuesday, November 17, 2020 11:02:27 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] Discussão sobre API's, Intermediadores e Gateways (#185)

Pessoal, atualizamos a lista.

Podem testar e enviar Issue ou PR?

https://iugu.github.io/lancamentopix/

A Iugu eh uma IP ? Ja está funcionando HOJE pra receber um Pix por QR-Estatico, por exemplo e ter como consultar via uma API qualquer? (ou receber um webhook)

— 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-729327265, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AAAJTDXE3WDGAU2UXUP6U2LSQMTLHANCNFSM4TXPMWUQ.

[rubenskuhl]

Como se chama uma API de múltiplos meios de pagamento que permite selecionar apenas Pix como meio de pagamento permitido ? API Pix proprietária.

[pnegri]

É o que eu vendemos, um layer acima da camada de recebimento, a 8 anos já. Em breve vamos permitir que vc escolha seu provedor de pix também. Usa o nosso se quiser, ou contrata do player X e usa.

Att

Patrick Negri - CTO iugu

---

From: Rubens Kuhl notifications@github.com Sent: Tuesday, November 17, 2020 11:24:03 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] Discussão sobre API's, Intermediadores e Gateways (#185)

Como se chama uma API de múltiplos meios de pagamento que permite selecionar apenas Pix como meio de pagamento permitido ? API Pix proprietária.

— 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-729334263, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AAAJTDQS7ER2XIDZMCROX53SQMV4HANCNFSM4TXPMWUQ.

[pnegri]

Essa regra veio depois (bem depois). Além disso, somos um intermediador, entramos como ip sob essa premissa. E vamos oferecer a api pix (low level). O que oferecemos é outra coisa (somos um software de tesouraria). Já eramos uma empresa que só vendia automação via api. O cliente compra isso da gente a anos. Tem havido uma confusão entre api de pix e apis no geral. O negócio da iugu sempre foi vender essa automação (sempre via api), poderizar marketplaces e empresas de faturamento/assinatura. Como já disse no issue, vamos esperar o posicionamento do regulador, vamos apresentar nossa defesa e acatar o que o regulador falar. Mas pensa o seguinte, um erp (ex SAP), sempre contratou um gateway, intermediador ou van por conta da redução de integrar um único player, ao invés de fazer tudo isso mais a conciliação (o que pode ser um investimento de 100k vs um de 1m). Eu vendo isso, estou pouco interessado em vender a transação de pix ou uma api só pra criar qr code e verificar pagamentos dessa modalidade. Para isso, tem dezenas aí.

Patrick Negri - CTO iugu

---

From: rodrigonunes100 notifications@github.com Sent: Tuesday, November 17, 2020 11:53:05 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] Discussão sobre API's, Intermediadores e Gateways (#185)

@pnegrihttps://github.com/pnegri, se não pode obedecer regras pq a iugu entrou para o PIX ? O alipay foi um exemplo, não concordou com as regras do pix e preferiu se retirar.

— 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-729342833, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AAAJTDWWP3K5JTS74YQSMDLSQMZJDANCNFSM4TXPMWUQ.

[pnegri]

Outro ponto são os marketplaces. Boa parte desses clientes contratam a solução da iugu para receber e controlar repasses a cada comissionado. Pix não tem a ver com isso, é só um meio para o dinheiro chegar o mktplace. E os erps, que criam contas de pagamento conosco para gerenciar a tesouraria, tem um passo antes aí que é criar essas contas para cada cliente e retirar extrato e tudo mais, esses players estão interessados na solução de carteira eletrônica e isso acontece bem antes de haver um recebimento de pix, e envolve ao erp poder pagar tributos e controlar estatística de inadimplência. É bem simples Rodrigo, não tem muito esforço pra entender e duvido que um player que ofereça apenas o recebimento pix consiga entrar nesse mercado, esse mercado nem busca isso.

Patrick Negri - CTO iugu

---

From: Patrick Ribeiro Negri patrick@iugu.com Sent: Wednesday, November 18, 2020 12:02:38 AM To: bacen/pix-api reply@reply.github.com; bacen/pix-api pix-api@noreply.github.com Cc: Mention mention@noreply.github.com Subject: Re: [bacen/pix-api] Discussão sobre API's, Intermediadores e Gateways (#185)

Essa regra veio depois (bem depois). Além disso, somos um intermediador, entramos como ip sob essa premissa. E vamos oferecer a api pix (low level). O que oferecemos é outra coisa (somos um software de tesouraria). Já eramos uma empresa que só vendia automação via api. O cliente compra isso da gente a anos. Tem havido uma confusão entre api de pix e apis no geral. O negócio da iugu sempre foi vender essa automação (sempre via api), poderizar marketplaces e empresas de faturamento/assinatura. Como já disse no issue, vamos esperar o posicionamento do regulador, vamos apresentar nossa defesa e acatar o que o regulador falar. Mas pensa o seguinte, um erp (ex SAP), sempre contratou um gateway, intermediador ou van por conta da redução de integrar um único player, ao invés de fazer tudo isso mais a conciliação (o que pode ser um investimento de 100k vs um de 1m). Eu vendo isso, estou pouco interessado em vender a transação de pix ou uma api só pra criar qr code e verificar pagamentos dessa modalidade. Para isso, tem dezenas aí.

Patrick Negri - CTO iugu

---

From: rodrigonunes100 notifications@github.com Sent: Tuesday, November 17, 2020 11:53:05 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] Discussão sobre API's, Intermediadores e Gateways (#185)

@pnegrihttps://github.com/pnegri, se não pode obedecer regras pq a iugu entrou para o PIX ? O alipay foi um exemplo, não concordou com as regras do pix e preferiu se retirar.

— 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-729342833, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AAAJTDWWP3K5JTS74YQSMDLSQMZJDANCNFSM4TXPMWUQ.

[renatofrota]

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.

Ou seja, lá no #62 você concordou com meus argumentos e falou claramente que a notificação de que um pagamento foi recebido (desde que não informando o txid, que é informação interna do arranjo Pix) estaria "ok" e passou todo esse tempo aqui nessa issue indo contra a sua própria opinião. Me parece pura birra.

Questão de contexto, pois o ponto eram APIs de informação sobre a conta bancária versus API de cobrança claramente alternativas ao Pix Cobrança. E se usar o txid para concluir qual cobrança foi liquidada, o efeito é o mesmo.

Se o BACEN não quisesse intermediadores fazendo esse trabalho de gerir cobranças e a integração do Pix aos sistemas de intermediadores preexistentes aos Pix, teria acatado o #62 e pronto.

Tem muita hipocrisia rondando esse assunto. Os bancos estão notificando por push, por e-mail e até por SMS quando um Pix é recebido! "Ah, mas enviar um request para um webhook que está num host arbitrário [que o recebedor escolheu(!) e está sob TLS] sem mTLS seria inseguro"... what?!

O que os intermediadores que notificam baixas de pagamento de cobranças por outras sistemáticas quaisquer estão fazendo é exatamente a mesma coisa. E se não repassarem a informação "txid", restrita do Pix, não tá fora da regulamentação. E a iugu, como o Patrick já falou acima, é uma IP. Se é "claramente alternativa" ou não, problema de quem acha isso. Pode chorar.

Agora me dá licença que vou ali fazer o meu parser de e-mails pra monitorar recebimentos de Pix que caíram no meu "bancão"... e shhh!! não contem pra ninguém, porque isso configura uma "API proprietária"

[rubenskuhl]

O que houve em Setembro foi apenas um esclarecimento do DCEM, a definição de que a API Pix seria padronizada vinha de meses antes nas discussões do Fórum Pix. Então, a regra não veio bem depois, mesmo que tenha demorado para cair a ficha do mercado.

[pnegri]

Que seria padronizada sim. Mas que seria obrigatoria não. Mas já falei pessoal, iremos acatar o regulador, se der pra oferecer boa, se não der, a gente se retira e pronto, ofereço uma integração pro pix cair na conta de pagamento com o fornecedor X e boa, não afeta o nosso negócio. E outra, já estamos desenvolvendo uma api padronizada, mas não vou parar de oferecer aquilo que já vendo. E esse é inclusive o posicionamento de outras ips na mesma situação, principalmente as ips de adquirencia.

Patrick Negri - CTO iugu

---

From: Rubens Kuhl notifications@github.com Sent: Wednesday, November 18, 2020 12:28:30 AM 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] Discussão sobre API's, Intermediadores e Gateways (#185)

O que houve em Setembro foi apenas um esclarecimento do DCEM, a definição de que a API Pix seria padronizada vinha de meses antes nas discussões do Fórum Pix. Então, a regra não veio bem depois, mesmo que tenha demorado para cair a ficha do mercado.

— 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-729359525, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AAAJTDXW2TYLLGFKFKGCX3TSQM5N5ANCNFSM4TXPMWUQ.

[rubenskuhl]

Sobre mTLS, apesar de pesado eu entendo a preocupação que advém de premissas como o sigilo bancário. É diferente o banco hoje descuidar disso de o BACEN criar uma arquitetura que seja vista como comprometendo isso. E para uma integração do próprio correntista com sua IF/IP para o Pix Cobrança o mTLS não tem se mostrado uma dificuldade de implementação; já para um terceiro com algum papel a desempenhar, o Credentials Code Flow é sim uma dificuldade e o #83 (Auth Code Flow) é muito provavelmente o caminho a seguir.

[flaviolenz]

Agora me dá licença que vou ali fazer o meu parser de e-mails pra monitorar recebimentos de Pix que caíram no meu "bancão"... e shhh!! não contem pra ninguém, porque isso configura uma "API proprietária"

KKK Boa. Tambem pensei em fazer um interceptador de notificacao em um celular. Mas os caras tao omitindo TXID!!!

[flaviolenz]

Que seria padronizada sim. Mas que seria obrigatoria não. Mas já falei pessoal, iremos acatar o regulador, se der pra oferecer boa, se não der, a gente se retira e pronto, ofereço uma integração pro pix cair na conta de pagamento com o fornecedor X e boa, não afeta o nosso negócio. E outra, já estamos desenvolvendo uma api padronizada, mas não vou parar de oferecer aquilo que já vendo. E esse é inclusive o posicionamento de outras ips na mesma situação, principalmente as ips de adquirencia. Patrick Negri - CTO iugu … ____ From: Rubens Kuhl notifications@github.com Sent: Wednesday, November 18, 2020 12:28:30 AM 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] Discussão sobre API's, Intermediadores e Gateways (#185) O que houve em Setembro foi apenas um esclarecimento do DCEM, a definição de que a API Pix seria padronizada vinha de meses antes nas discussões do Fórum Pix. Então, a regra não veio bem depois, mesmo que tenha demorado para cair a ficha do mercado. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub<#185 (comment)>, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AAAJTDXW2TYLLGFKFKGCX3TSQM5N5ANCNFSM4TXPMWUQ.

Eu acho que vc nao ta fora da norma em oferecer por outros canais. So, que tem que implementar a API TAMBEM.

[pnegri]

Isso do txid tá uma droga né. Estamos mostrando certo na iugu. Conciliação é yma grande preocupação.

Patrick Negri - CTO iugu

---

From: flaviolenz notifications@github.com Sent: Wednesday, November 18, 2020 12:57:28 AM 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] Discussão sobre API's, Intermediadores e Gateways (#185)

Agora me dá licença que vou ali fazer o meu parser de e-mails pra monitorar recebimentos de Pix que caíram no meu "bancão"... e shhh!! não contem pra ninguém, porque isso configura uma "API proprietária"

KKK Boa. Tambem pensei em fazer um interceptador de notificacao em um celular. Mas os caras tao omitindo TXID!!!

— 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-729388787, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AAAJTDRHWR5BMOHSK6P3QUDSQNA2RANCNFSM4TXPMWUQ.

[flaviolenz]

Sim, ip. Não temos api pix, porem vc pode usar api de automação de cobrança para fazer isso que vc quer. Uns 30 min de integração em qquer linguagem. Patrick Negri - CTO iugu

Nesse caso, nao queremos chamar sua API pra iniciar o pagamento. Queremos gerar o QR estatico e quando o dinheiro bater na conta da IUGU, que haja uma maneira de consultar (ou receber um webhook qualquer padronizado ou nao). Rola?

Onde alguem consegue informacao comercial? Tipo, valores que vcs vao cobrar, etc...

[pnegri]

Que seria padronizada sim. Mas que seria obrigatoria não. Mas já falei pessoal, iremos acatar o regulador, se der pra oferecer boa, se não der, a gente se retira e pronto, ofereço uma integração pro pix cair na conta de pagamento com o fornecedor X e boa, não afeta o nosso negócio. E outra, já estamos desenvolvendo uma api padronizada, mas não vou parar de oferecer aquilo que já vendo. E esse é inclusive o posicionamento de outras ips na mesma situação, principalmente as ips de adquirencia. Patrick Negri - CTO iugu … ____ From: Rubens Kuhl notifications@github.com Sent: Wednesday, November 18, 2020 12:28:30 AM 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] Discussão sobre API's, Intermediadores e Gateways (#185) O que houve em Setembro foi apenas um esclarecimento do DCEM, a definição de que a API Pix seria padronizada vinha de meses antes nas discussões do Fórum Pix. Então, a regra não veio bem depois, mesmo que tenha demorado para cair a ficha do mercado. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub<#185 (comment)>, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AAAJTDXW2TYLLGFKFKGCX3TSQM5N5ANCNFSM4TXPMWUQ.

Eu acho que vc nao ta fora da norma em oferecer por outros canais. So, que tem que implementar a API TAMBEM.

Oi Flávio, então, este é o plano, inclusive estamos olhando a dias já. A API Pix é simples, não deveria demorar mais de 10 dias para implementarmos, o problema é a estrutura de conciliação e o modelo da iugu em si, não casa a API com os objetos que criamos que visam simplesmente resolver conciliação, comissionamento de marketplace e assinaturas. Estamos tendo bastante dificuldade em fazer a API conversar com isso, pq a iugu é isso, os objetos giram em torno disso, vc não tem como por exemplo receber qualquer valor (De qualquer forma de pagamento aqui, boleto, cc, etc), sem ter uma fatura vinculada, cada linha de nosso extrato está vinculada a um recebimento desses (Que é o maior problema do extrato tradicional de banco). Estamos pensando em como resolver mas ainda não tivemos uma luz sobre isso.

[flaviolenz]

Tendi, corre ai! Se vc registra Chaves PIX de seus clientes, isso vai acontecer de qualquer maneira. (um dia alguem vai fazer uma transferencia manual)

Se precisar de ajuda e quiser fazer uns pilotos, so me contactar no gmail.com com o mesmo usuario. ERP desse lado aqui.

[pnegri]

Sim, ip. Não temos api pix, porem vc pode usar api de automação de cobrança para fazer isso que vc quer. Uns 30 min de integração em qquer linguagem. Patrick Negri - CTO iugu

Nesse caso, nao queremos chamar sua API pra iniciar o pagamento. Queremos gerar o QR estatico e quando o dinheiro bater na conta da IUGU, que haja uma maneira de consultar (ou receber um webhook qualquer padronizado ou nao). Rola?

Onde alguem consegue informacao comercial? Tipo, valores que vcs vao cobrar, etc...

Não conseguimos ainda QR estático por conta da conciliação (é terrível). Mas vamos falar via fone, adoraria entender a necessidade e ver se conseguimos encaixar no roadmap.

[pnegri]

Tendi, corre ai! Se vc registra Chaves PIX de seus clientes, isso vai acontecer de qualquer maneira. (um dia alguem vai fazer uma transferencia manual)

Se precisar de ajuda e quiser fazer uns pilotos, so me contactar no gmail.com com o mesmo usuario. ERP desse lado aqui.

Legal, atendemos bastante erps já hoje, inclusive com abertura de conta transparente e pagamento de contas, tributos, etc. Acabamos de receber um investimento da Goldman Sachs de 120m (Primeiro delas em fintech de equity no Brasil) e estamos expandindo as iniciativas relacionadas a ERP, um de nossos carros chefes aqui.

[renatofrota]

Que seria padronizada sim. Mas que seria obrigatoria não. Mas já falei pessoal, iremos acatar o regulador, se der pra oferecer boa, se não der, a gente se retira e pronto, ofereço uma integração pro pix cair na conta de pagamento com o fornecedor X e boa, não afeta o nosso negócio. E outra, já estamos desenvolvendo uma api padronizada, mas não vou parar de oferecer aquilo que já vendo. E esse é inclusive o posicionamento de outras ips na mesma situação, principalmente as ips de adquirencia. Patrick Negri - CTO iugu … ____ From: Rubens Kuhl notifications@github.com Sent: Wednesday, November 18, 2020 12:28:30 AM 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] Discussão sobre API's, Intermediadores e Gateways (#185) O que houve em Setembro foi apenas um esclarecimento do DCEM, a definição de que a API Pix seria padronizada vinha de meses antes nas discussões do Fórum Pix. Então, a regra não veio bem depois, mesmo que tenha demorado para cair a ficha do mercado. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub<#185 (comment)>, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AAAJTDXW2TYLLGFKFKGCX3TSQM5N5ANCNFSM4TXPMWUQ.

Eu acho que vc nao ta fora da norma em oferecer por outros canais. So, que tem que implementar a API TAMBEM.

Oi Flávio, então, este é o plano, inclusive estamos olhando a dias já. A API Pix é simples, não deveria demorar mais de 10 dias para implementarmos, o problema é a estrutura de conciliação e o modelo da iugu em si, não casa a API com os objetos que criamos que visam simplesmente resolver conciliação, comissionamento de marketplace e assinaturas. Estamos tendo bastante dificuldade em fazer a API conversar com isso, pq a iugu é isso, os objetos giram em torno disso, vc não tem como por exemplo receber qualquer valor (De qualquer forma de pagamento aqui, boleto, cc, etc), sem ter uma fatura vinculada, cada linha de nosso extrato está vinculada a um recebimento desses (Que é o maior problema do extrato tradicional de banco). Estamos pensando em como resolver mas ainda não tivemos uma luz sobre isso.

Eu entendo que o txid não precisaria (talvez nem deveria) ser uma informação acessível para os seus clientes. Assim, manteria a aderência ao seu ponto de vista de que você vende gestão de cobranças e não "API Pix".

Se toda cobrança da iugu já tem um identificador, o identificador particular ("interno") do método de pagamento é irrelevante. O cliente iugu só precisa ser notificado que a "cobrança xpto" foi paga, não que um "Pix com txid = kwy" foi pago.

E aí, no caso particular dos QR estáticos, basta fazer todo recebimento que tiver um txid de comprimento 1..25 (e, consequente não constante na base de cobranças atual, cujos txids são todos de comprimento 26..35), gerar uma nova cobrança (já baixada, ou baixá-la em seguida) e notificar que uma cobrança foi paga (e o cliente consulta o status pelo id da cobrança, onde o txid estático pode ser um campo 'custom', 'ref', etc que lojistas já usam hoje para conciliação da cobrança com os seus próprios pedidos). Ou ainda, oferecer consulta a estes Pix provenientes de QR codes estáticos somente pela API padronizada que você já adiantou que pretende oferecer em breve, e não pela sua API atual, que é de cobranças.

[pnegri]

Que seria padronizada sim. Mas que seria obrigatoria não. Mas já falei pessoal, iremos acatar o regulador, se der pra oferecer boa, se não der, a gente se retira e pronto, ofereço uma integração pro pix cair na conta de pagamento com o fornecedor X e boa, não afeta o nosso negócio. E outra, já estamos desenvolvendo uma api padronizada, mas não vou parar de oferecer aquilo que já vendo. E esse é inclusive o posicionamento de outras ips na mesma situação, principalmente as ips de adquirencia. Patrick Negri - CTO iugu … ____ From: Rubens Kuhl notifications@github.com Sent: Wednesday, November 18, 2020 12:28:30 AM 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] Discussão sobre API's, Intermediadores e Gateways (#185) O que houve em Setembro foi apenas um esclarecimento do DCEM, a definição de que a API Pix seria padronizada vinha de meses antes nas discussões do Fórum Pix. Então, a regra não veio bem depois, mesmo que tenha demorado para cair a ficha do mercado. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub<#185 (comment)>, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AAAJTDXW2TYLLGFKFKGCX3TSQM5N5ANCNFSM4TXPMWUQ.

Eu acho que vc nao ta fora da norma em oferecer por outros canais. So, que tem que implementar a API TAMBEM.

Oi Flávio, então, este é o plano, inclusive estamos olhando a dias já. A API Pix é simples, não deveria demorar mais de 10 dias para implementarmos, o problema é a estrutura de conciliação e o modelo da iugu em si, não casa a API com os objetos que criamos que visam simplesmente resolver conciliação, comissionamento de marketplace e assinaturas. Estamos tendo bastante dificuldade em fazer a API conversar com isso, pq a iugu é isso, os objetos giram em torno disso, vc não tem como por exemplo receber qualquer valor (De qualquer forma de pagamento aqui, boleto, cc, etc), sem ter uma fatura vinculada, cada linha de nosso extrato está vinculada a um recebimento desses (Que é o maior problema do extrato tradicional de banco). Estamos pensando em como resolver mas ainda não tivemos uma luz sobre isso.

Eu entendo que o txid não precisaria (talvez nem deveria) ser uma informação acessível para os seus clientes. Assim, manteria a aderência ao seu ponto de vista de que você vende gestão de cobranças e não "API Pix".

Se toda cobrança da iugu já tem um identificador, o identificador particular ("interno") do método de pagamento é irrelevante. O cliente iugu só precisa ser notificado que a "cobrança xpto" foi paga, não que um "Pix com txid = kwy" foi pago.

E aí, no caso particular dos QR estáticos, basta fazer todo recebimento que tiver um txid de comprimento 1..25 (e, consequente não constante na base de cobranças atual, cujos txids são todos de comprimento 26..35), gerar uma nova cobrança (já baixada, ou baixá-la em seguida) e notificar que uma cobrança foi paga (e o cliente consulta o status pelo id da cobrança, onde o txid estático pode ser um campo 'custom', 'ref', etc que lojistas já usam hoje para conciliação da cobrança com os seus próprios pedidos). Ou ainda, oferecer consulta a estes Pix provenientes de QR codes estáticos somente pela API padronizada que você já adiantou que pretende oferecer em breve, e não pela sua API atual, que é de cobranças.

Renato, estou aberto a entender mais. Maior problema do QR Estático é o cliente digitar o valor e não ter um uma forma de cruzar isso com uma fatura da iugu, pensamos nessa solução de ficar duplicando a fatura, mas no poc não ficou mto bom (Na verdade ficou bem porco e pareceu mais uma gambiarra do que uma solução). Vamos falar.

[ninrod]

Prezados, buscando esclarecer melhor a questão, e como já mencionei algumas vezes antes aqui neste repositório, o BACEN não determina absolutamente nenhum regramento para TEFs e Gateways, de maneira que "os lojistas" que já estão integrados hoje continuarão integrados com seus TEFs e Gateways, se assim preferirem.

Com relação a PSPs, existem grupos econômicos que apresentam estrutura verticalizada: são ao mesmo tempo gateway+PSP. Obviamente, nestes casos, também não há o que se falar em termos de obrigatoriadade da API Pix (porque justamente a operação ocorre "dentro de casa", o gateway pode conversar com o PSP usando a API que bem entender).

O espírito por trás da API Pix é que o usuário recebedor deveria ter a opção de utilizá-la naquele PSP, caso o PSP ofereça "integração automatizada Pix". O recebedor tranquilamente pode usar a API prop. da TEF ou do Gateway, se assim preferir.

Entendo que a questão não é simples e há nuances. Por exemplo, qual é exatamente a linha que separa um gateway de um PSP, em termos de API? Essas questões são melhor endereçadas com uma consulta diretamente ao DECEM. Este repositório procura focar mais em questões técnicas e menos em questões de negócio como o título desta issue.

[rubenskuhl]

O espírito por trás da API Pix é que o usuário rebedor deveria ter a opção de utilizá-la naquele PSP, caso o PSP ofereça "integração automatizada Pix". O recebedor tranquilamente pode usar a API prop. da TEF ou do Gateway, se assim preferir.

Além de ter a opção, para de fato ela ser uma livre escolha, essa opção precisa ser oferecida dentro das mesmas condições de tempo e dinheiro. Por exemplo, se uma outra já está disponível, a API Pix também esteja. Para determinada condição comercial (volume, ticket), o custo nas duas ser o mesmo, também. Vou preparar um paper disso e mandar para o DECEM.

[pnegri]

Rubens, pare de se posicionar como se fosse autoridade no assunto. Filipe é do bacen e acabou de posicionar, entramos em contato com o bacen ontem e já recebemos uma resposta inicial hoje que não estamos fora da regra e que irão avaliar a necessidade de estarmos compliant e darão uma resposta oficial para nós. Portanto, a partir desse momento fique quieto ok? Na próxima colocaremos Pinheiro Neto no seu encalce por difamar a gente publicamente. Sem mais.

Patrick Negri - CTO iugu

---

From: Rubens Kuhl notifications@github.com Sent: Wednesday, November 18, 2020 9:36:48 AM 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] Discussão sobre API's, Intermediadores e Gateways (#185)

O espírito por trás da API Pix é que o usuário rebedor deveria ter a opção de utilizá-la naquele PSP, caso o PSP ofereça "integração automatizada Pix". O recebedor tranquilamente pode usar a API prop. da TEF ou do Gateway, se assim preferir.

Além de ter a opção, para de fato ela ser uma livre escolha, essa opção precisa ser oferecida dentro das mesmas condições de tempo e dinheiro. Por exemplo, se uma outra já está disponível, a API Pix também esteja. Para determinada condição comercial (volume, ticket), o custo nas duas ser o mesmo, também. Vou preparar um paper disso e mandar para o DECEM.

— 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-729649761, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AAAJTDUXXWJ4OOOKPDKPQU3SQO5WBANCNFSM4TXPMWUQ.

[pnegri]

O espírito por trás da API Pix é que o usuário rebedor deveria ter a opção de utilizá-la naquele PSP, caso o PSP ofereça "integração automatizada Pix". O recebedor tranquilamente pode usar a API prop. da TEF ou do Gateway, se assim preferir.

Além de ter a opção, para de fato ela ser uma livre escolha, essa opção precisa ser oferecida dentro das mesmas condições de tempo e dinheiro. Por exemplo, se uma outra já está disponível, a API Pix também esteja. Para determinada condição comercial (volume, ticket), o custo nas duas ser o mesmo, também. Vou preparar um paper disso e mandar para o DECEM.

Você não é o interpretador da regra, é o Bacen quem é. Pode falar o que for pro DECEM mas já explicamos o caso e inclusive iremos fazer um comitê em Brasília convidando os players que são gateways (Que não são poucos viu). Além disso, o DECEM também está ciente que muitos não oferecem a API Pix e irão cobrar prazo e atuar em cima de quem perder o prazo. O Bacen sempre se posicionou de forma a estimular a concorrência e tinha bastante dúvida se ele ia jogar fora a base de 500 mil lojistas dos PSP que são intermediadores e a resposta de bate pronto foi que não. Fica quietinho. Abração.

[rubenskuhl]

Tentar calar vozes de quem aponta falhas é típico de quem não quer mudar de atitude. Comentário já encaminhado ao DECEM.

[pnegri]

Ah, e como eu havia dito, aparentemente só vamos precisar oferecer API Pix se de fato eu quiser comercializar esse produto de forma independente nas mesmas condições oferecidas pela concorrência no sentido de consumo. Quanto ao preço, pode ser sim diferente, em geral, tende a ser mais barato do que o consumo de uma api de alto nível. Assim que sair o pronunciamento oficial irei postar a resposta aqui quando chegar no BC Correio (Software de email oficial do Bacen).

[pnegri]

Tentar calar vozes de quem aponta falhas é típico de quem não quer mudar de atitude. Comentário já encaminhado ao DECEM.

Comédia você :) kkkkkkkkk rindo demais aqui, entendidão!

[rubenskuhl]

Quem ri por último, ri melhor. Ditado popular.

[pnegri]

Quem ri por último, ri melhor. Ditado popular.

Que parte você não entendeu que já falamos com Bacen? @ninrod dá uma mão aqui e pede pro Rubens parar de se posicionar como se fosse o Bacen? Não é o foco do github essas discussões, ainda mais com todo mundo ocupado com o lançamento.

[rubenskuhl]

Eu não sou do BACEN e jamais me apresentei como tal.

[pnegri]

Eu não sou do BACEN e jamais me apresentei como tal.

Não é o que o seu posicionamento de como a regra funciona demonstra. A regra não funciona do jeito que você está falando. Ponto.