Histórico de mensagens em sugestões

Da um certo trabalho, pq o mTLS trabalha na camada de infra/webserver, então ativar um gateway, nesse caso, não basta codificar na linguagem escolhida, mas tbm mexer em uma outra camada...

Eu gosto do mTLS, digo da ideia pq ainda não implementei, no webhook, já que um medo q eu sempre tive, era o json vir de uma fonte não confiável, e aí eu tinha que ficar fazendo algumas requests para garantir a autenticidade do json...

Usando por mTLS, fica mais confiável da onde está vindo o json/request do webhook...

A gerencianet tem uma forma de receber pix sem usar certificado... Só usar bolix... Seria uma forma de "contornar" essa camada de segurança...

Detalhe q a versão mais nova da api do PagSeguro, pelo menos de pix, não sei se é toda... Já trabalha com certificado tbm...

Isso é viés de quem depende de ambientes que não suportam mTLS com CA própria de cara. Você quer que o padrão nivele por baixo para o seu conforto ao invés de atender requisitos do maior sistema de transações financeiras já criado.

Eu gasto menos de 70 linhas de código pra implementar cada API de pix pros meus clientes, é muito mais fácil do que ter que trabalhar com certificado, eu só faço uma abstração nos webhooks, e pronto.

Na verdade, eles estão te prendendo na API proprietária para ficar mais difícil de mudar. Se todo mundo pensasse assim em relação a padrões, a Internet não existiria. Ela existe exatamente pq os padrões permitem que sistemas muito diversos se comuniquem.

Prefiro, eles facilitam minha vida, melhor do que ficar denunciando alguém só por deixar as coisas mais fáceis.

Se você prefere os milicianos do mercado, fazer o quê...

o único problema é que a GN vai ficar menos atraente pra quem for integrar

já passou 2 anos, ninguém vai mudar nada, existe um motivo pras suas denúncias não funcionarem.

Não vai fechar, de forma alguma. Só vai ter que mudar a API e dizer para todo mundo usar a API no padrão.

MercadoPago usa o mesmo sistema, nunca alterado, foi criado poucos meses depois da criação do Pix, você acha que o mercadopago vai fechar? 🤣

Eu já mandei aqui no grupo, e tem no site do BACEN o regulamento. Você pode usar a achologia, ou ler o que dizem as normas e conferir. A própria Juno (que aliás não existe mais) reconheceu que estava infringindo e tinha começado a acertar a API deles, até que foi descontinuada de vez. Então se você quer seguir uma API tão certa quanto a contabilidade da Americanas, é com você.

Eu duvido bastante que todas as empresas que eu citei estariam arriscando tudo só pra ter uma API mais fácil e ser multados depois, acho que teve uma má interpretação do que realmente foi estabelecido, eu particularmente nunca li, mas já vi aquele protótipo horroroso com tudo em português, e vários sites divergem nos nomes dos campos mesmo assim, ex: Juno v.s PagSeguro, até mesmo os métodos de criação, que alguns usam PUT e outros POST, acho que era só um padrão recomendado, e não algo obrigatório, exigir certificado em todas as APIs só vai complicar e deixar o sistema mais inacessível.

É indiferente a separação do domínio, já que ambos exigem certificado pra serem acessados, ambos tem a mesma complexidade de autenticação, só é mais um pé no saco pra você criar outra instância do Guzzle/Axios

Ser separado me pareceu a alternativa da GN para não obrigar todo mundo a seguir os padrões mais rigorosos da API Pix, o que me parece que seria o contrário do que você está sugerindo apesar de aí se tornar um ambiente único.

No caso da API Pix, ela é com certificados por exigência do Banco Central. Vários dos que você citou desobedecem regulamentação e eu mesmo já denunciei vários dos que você citou. Então a API pode parecer mais simples hoje, mas quando eles tiverem que mudar para não serem multados, vão descartar e vai ter que ser do jeito que o BACEN especificou.

Qualquer uma que envolvesse recebimentos, essa separação de ambiente também é bem ruim, não é prático pra quem usa Axios/Guzzle

Você está falando da API Pix ou da API de emissões (cartão/boleto) ?

Ajudaria muito as integrações se existisse o mesmo sistema de autenticação da Iugu, onde existe uma autenticação básica só para receber pagamentos, e uma mais complexa com os certificados para enviar pagamentos, assim não correria nenhum risco de compartilhar o token com algum serviço de terceiro, já que ele só poderia receber por você, e não enviar nenhum pagamento, sem contar que isso descomplicaria muito a API.

A maioria das empresas relevantes usam essa autenticação mais leve, de um token sem certificado, PagSeguro, MercadoPago, Juno, PicPay Ecommerce, PagHiper, Stripe, PayPal

A falta dessa autenticação mais simples pra receber pagamentos me afastou muito da gerencianet, e hoje só uso pra receber pagamentos manuais.