Termos mais procurados:
Sim @rubenskuhl, mas a Efí pode manter o padrão da API Pix do jeito que é hoje. Porém ao invés deu utilizar uma UI para criar os certificados, eu utilizaria uma API para isso. A API cria as credenciais, as chaves, isso funcionando seria como se fosse a UI da Efí hoje só que permitindo que eu parametrizasse a conta do cliente e obtesse os dados necessários para utilizar a API Pix. Entendeu?
@Relacionamento @Consultoria Técnica uma dica: vocês poderiam fornecer um fluxo de autenticação OAuth 2.0 para a conta do cliente. Assim seria mais fácil a conexão com aplicações SaaS.
Estou imaginando um módulo em minha aplicação com o nome "Efí Pay", ou até mesmo a instalação do plugin do WooCommerce. A configuração basicamente seria um botão "Conectar" ai um fluxo OAuth me permitiria configurar tudo para o cliente. Desde gerar certificados, até criar credenciais para uso nas API's disponíveis.
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.
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.
Esse primeiro deploy traz uma versão mais simples, na qual a Gerencianet resolve tudo. Isso atenderá a alguns perfis de clientes. Lembrando que nós não armazenamos a chave privada.
Mas a sugestão de aceitar um CSR é tão boa que já tá até no Roadmap, neste card: https://www.notion.so/Gera-o-de-certificados-API-Pix-a-partir-de-um-CSR-de6f5650a5d44ed092af81d6b830ed66
Foi colocado no sistema a geração de certificados, mas ela gera tanto a parte secreta quanto pública. O usual de CAs é que apenas o titular tenha a parte secreta, envia sua chave pública para a CA e essa assina a chave pública. Sugiro que seja alterado para usar um CSR e não gerar a chave.
A respeito do discutido em https://discord.com/channels/775322853884821504/775328670784159744/796748024566120519:
A GN poderia oferecer na parte de API > Aplicações, uma opção para compartillhar os direitos de acesso à essa aplicação com um integrador parceiro por dentro da plataforma da GN, que poderia ver o client_id e client_secret e solicitar certificados.
Assim não dependeria do cliente fazer o processo de obtenção de credenciais, solicitar certificado, receber senha por SMS (que tem período de validade relativamente curto - 4 horas) e depois encaminhar tudo isso pro integrador por fora do sistema.
