Termos mais procurados:
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...
você pode ir fazendo as requisições nas urls da api via via http client, ou via do próprio laravel, CURL, ou o modo mais "simples" usando o sdk da gerecianet com o colega acima citou.
namespace App\Http\Controllers;
use Illuminate\Http\Request;
use Illuminate\Support\Facades\Http;
class PostController extends Controller
{
/
Write code on Method
@return response()
/
public function index()
{
$response = Http::get('https://urldeexemplo.com.br');
$jsonData = $response->json();
dd($jsonData);
}
}
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.
Só um reparo: o recurso do + já existia antes da LGPD. E deveria sim ser aceito... https://uasg.tech/ tem bons recursos para guiar a GN em crítica de endereços de e-mail válidos. ( @Consultoria Técnica )
Olá Pessoal, boa tarde!
Existe um problema com a API de boletos / bolix.
Quando um e-mail usa + a api retorna como erro "{message": "A string não corresponde ao modelo: ^[A-Za-z0-9_\\-]+(?:[.][A-Za-z0-9_\\-]+)@[A-Za-z0-9_]+(?:[-.][A-Za-z0-9_]+)\\.[A-Za-z0-9_]+$.",
"property": "/payment/banking_billet/customer/email"}".
Pq isso é um erro?
Com a entrada da LGPD em vigor o google, hotmail entre outros criaram um serviço email+{qualquercoisa}@[gmail|hotmail].com.
O uso disso se da para criar e-mails unicos para cada servico Ex: [email protected], ou seja nesse e-mail só posso receber assuntos do mercadolivre se receber qualquer outra coisa é um SPAM e esta quebrando as regras da lei LGPD.
Talvez para todos os mercados isso não gere problemas mas para nos como plataforma de e-commerce isso afeta muito.
Bom dia, tudo bem ? Hoje você tem a opção de utilizar o nosso sistema de notificações. Nele, você envia uma URL que será notificada toda vez que a cobrança tiver o status alterado
Demanda sendo tratada em chat privado
Lembrando que módulo já está instalado
Perdi ajuda no ticket mais de uma semana
Galera estou precisando de ajuda para por gerencianet no meu whmcs
Bom dia!! Tudo bem? Quando tiver algum suporte na ativa, por favor.
Não consigo avançar na integração. Sempre me retorna 403 Forbidden. Estou realizando todos os testes pelo Postman.
Já fiz a configuração de environment e de certificado p12 mas não consigo avançar.
