Histórico de mensagens sobre an em sugestões

Mas a questão q.msm usando outras contas, o domínio, tudo é sempre o msm, só muda o token q vai ser usado na HR de gerar a cobrança... Saca??

Mas blz, q fosse isso, mas q sinalizasse... Mas não, chegaram a falar q não ia precisar rehomologar, mas aí perguntamos, Ok, e como o cliente gera as credenciais se vcs só dão as credenciais depois de homologar, vcs vão gerar algum código para nossa aplicação, igual é com o woocommerce por exemplo, e aí o cliente informa e vcs já liberam as credenciais??? Aí não souberam responder...

Ah sim, precisa fechar o ciclo de vida com o atendimento. Mas posso comentar o nosso caso: a gente pede rehomologação mesmo que use a mesma base de código. Inclusive pq a gente não testa só comandos da API, mas capacidade de gestão de DNS... e isso vai variar mesmo que as chamadas sejam as mesmas.

Como prestador de uma API que exige homologação, eu posso comentar que isso protege bastante contra alegações dos integradores... volta e meia algum diz que coisa X não estava documentada, e a gente mostra o log da homologação que diz que ele soube fazer isso e apenas por isso foi aprovado.

Então eu entendo prestadores que fazem o mesmo...

Eu quero implementar o gerencianet por completo em um projeto teste... Para entender todos os pontos...

Mas gostei bastante da doc e atendimento deles... Só de ter gnt técnica com contato direto aqui pelo discord, ajuda muito... PagSeguro nesse quesito vc não consegue falar com ngm da área técnica, muito difícil...

Mas a doc e o atendimento deles é milhão de vezes pior q da gerencianet...

A versão 4 da api deles, q é a única em vigência se não me engano, faz igual a gerencianet um ambiente só para pix, e um para as outras coisas... Do pix, tem o lance do certificado...

Então, na lista de PSPs de Pix que mantenho, o PagSeguro consta como seguindo o padrão do BACEN... mas não sei se eles ainda mantém o outro endpoint sem certificado.

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...

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.

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ê...

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

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

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.

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.