Pedro.Bravin

Olá desenvolvedor, neste post irei atualizar sobre a modalidade de transmissão de boletos chamada Web Service. Como é atualmente: Normalmente é utilizado o tráfego dos arquivos de remessa e retorno, onde para que você obtenha seus boletos registrados no banco é necessário gerar um arquivo de remessa, e para que o boleto consta como "Atualizado" em seu sistema é necessário realizar a inclusão de um arquivo de retorno conforme exemplo abaixo: Realizar a geração do boleto; Gerar o arquivo de remessa; Acessar o internet banking; Realizar o Upload do arquivo de remessa no internet banking; Realizar o Download do arquivo de retorno do internet banking; Realizar o Upload do arquivo de retorno na Aplicação; Consultar o Protocolo do arquivo de retorno; Verificar quais os boletos acabaram sendo conciliados com o arquivo; Mas vamos ser honestos, isso é extremamente cansativo e faz você perder muito do seu preciooooso tempo 🕞. Mas pode ficar sossegado que seus problemas acabaram com a chegada do Web Service Bancário!!! O que é o Web Service bancário? Basicamente o Web Service Bancário seria um novo método tráfego de boletos do seu ERP para o banco e vice-versa. Ou seja antes ao invés de realizar toooodo aquele processo, seu boleto já é REGISTRADO no banco de forma instantânea. Vamos lá, sei que é difícil acreditar em uma tecnologia dessa, mas da uma conferida aqui abaixo como seria o Fluxo de transmissão do boleto ao banco: Realizar a geração do boleto; Consultar o boleto; Nossa, mas é só isso? Sim, é apenas isso. 😱 O método de transmissão em si, seria através do XML, ou seja, "por trás dos panos", a API encaminha as informações do boleto ao banco via XML, e com isso o banco processa as informações ( no máximo 3 segundos ) e com isso o mesmo já encaminha para a API, a request do boleto trazendo a informação atual do mesmo, como por exemplo seu status de REGISTRADO ( Apto para o pagamento ). Mas e quando meu boleto já está no banco, e ele é pago? Calma, pode ficar tranquilo, que seria necessário apenas rodar uma consulta do boleto na API, que a nova informação já é retornada. Maaaaaaasss caso utilize a nossa API PlugBoleto, esta consulta é realizada de forma automatizada pela API, e para que você seja notificado sobre a atualização do mesmo, eu recomendo fortemente a utilização do WebHook ( também disponível no Plugboleto. E também como nem tudo são Flores 🌻, segue abaixo as vantagens e desvantagens da utilização do Web Service: Vantagens: O registro é instantâneo. No Registro via Web Service, o boleto será registrado instantaneamente e não se faz necessário aguardar o arquivo de retorno para ser possível o pagamento. Não é necessário gerar a remessa. (Como o registro é feito na emissão do boleto, não se faz necessário gerar a remessa para o registro) A consultar o boleto na API, é retornado o real estado do boleto no banco de forma instantânea. Desvantagens: A resposta obtida através da API/WebService de certos bancos pode conter menos dados do que o retorno fornecido pelo CNAB. (Diante dessa situação, existe a possibilidade de enriquecer as informações ausentes ativando a VAN, que permite a recepção automática dos retornos CNAB) . Sobre a transmissão automática de arquivos de Remessa e Retorno, recomendo a leitura desta documentação: Entendendo Transmissão automática das remessas e retornos Obs: Mas fica tranquilo que cada dia que passa, os bancos vão atualizando os Web Services bancários e com isso cada vez mais disponibilizando maiores informações em sua response. Particularmente recomendo a utilização do Web Service bancário? Sim, com toda a certeza do mundo pois acaba agilizando e muito o tempo e acaba evitando problemas. Demora muito para realizar a ativação desta funcionalidade? Não, ela pode ser ativada em menos de 1 dia. Agora irei lhe fazer a pergunta do Show do Milhão. Se você respondeu: Opção 3 - API PLUGBOLETO Certa respostaaaaaa !!!! Atualmente na API PlugBoleto temos todas estas funcionalidades implementadas e disponíveis para uso. Caso tenha qualquer dúvida sobre o cenário explicado ou se quiser conhecer nossas soluções , estaremos sempre à disposição e será um prazer ajudar!

Olá desenvolvedor, a seguir apresentamos a lista dos bancos homologados disponíveis para a utilização da Boleto Direto em o seu software: Banco da Amazônia (003) Bancoob/Sicoob (756) Banese (047) Banespa (353) Banco do Nordeste (004) Banestes (021) Banpará (037) Banrisul (041) Banco do Brasil (001) Bank of America (755) BCN (291) BankBoston (479) Bradesco (237) HSBC (399) Caixa (104) CECRED (085) Citibank (745) Credisan (089) Banco de Brasília (BRB) (070) Itaú (341) Nossa Caixa (151) Mercantil do Brasil (389) Real (356) Safra (422) Santander (033) Sicredi (748) Sudameris (347) Unibanco (409) Daycoval (707) Deutsche Bank (487) Unicred (136) Uniprime Iguacu (099) Uniprime (084) ABC (246) Voiter (653) Fibra (224) Sofisa (637) BS2 (218) Votorantim (655) Cresol (133) Inter (077) BRK (092) Sifra (233) Credisis (097) BTG Pactual (208) Caso tenha qualquer dúvida sobre esta documentação ou se quiser conhecer nossas soluções , estaremos sempre à disposição e será um prazer ajudar!

Olá, pessoal! Hoje vamos falar sobre um erro comum que pode ocorrer ao usar o Web Service do Banco Itaú para registro de boletos. O erro em questão é: “Erro: Erro na validação de Campos - Campo: COD-RET - Mensagem: Título já cadastrado na cobrança - Valor enviado: .” O que significa esse erro? Esse erro indica que o boleto que você está tentando registrar já existe no banco com as mesmas informações. Ou seja, você está tentando registrar um boleto duplicado. Como resolver? A solução para esse problema é bastante simples: Verifique o Registro do Boleto: Antes de registrar um boleto, verifique se ele já foi registrado. Você pode fazer isso verificando o histórico de transações ou usando a funcionalidade de pesquisa diretamente na API PlugBoletos. Não Registre Novamente: Se o boleto já foi registrado, não há necessidade de registrá-lo novamente. Isso pode causar confusão e possíveis problemas no futuro. Emita um Novo Boleto: Se você precisa emitir um novo boleto com as mesmas informações, você deve alterar pelo menos uma das informações para que o boleto seja considerado único. Isso pode ser o número do boleto, a data de vencimento, o valor, entre outros. Caso tenha qualquer dúvida sobre o cenário explicado ou se quiser conhecer nossas soluções , estaremos sempre à disposição e será um prazer ajudar!

Olá desenvolvedor! Neste post, iremos abordar um problema comum relacionado ao código de erro "ERRO DE CONSISTÊNCIA: CEP INVÁLIDO (19)" ao utilizar nossa API. Mensagem de erro: O erro "ERRO DE CONSISTÊNCIA: CEP INVÁLIDO (19)" pode surgir durante o uso da nossa API devido a problemas de validação do CEP junto ao banco. É importante destacar que esse retorno de rejeição não é gerado diretamente pela nossa API, mas sim pela validação feita pelo banco para o valor de CEP definido. Ao receber esse erro, é crucial entender que o CEP especificado pode não ser reconhecido como válido em diversas ferramentas de busca, como por exemplo a ferramenta dos Correios: Busca CEP - Correios. Como corrigir: Para solucionar o problema do CEP inválido, é necessário revisar o CEP definido na requisição e garantir que ele corresponda a um CEP válido. Recomenda-se realizar uma verificação utilizando ferramentas de busca de CEPs confiáveis, como a mencionada ferramenta dos Correios, para confirmar a validade do CEP em questão. É importante ressaltar que, devido à validação realizada pelo banco, pode ser que o retorno de rejeição indique um CEP como inválido mesmo que corresponda ao endereço definido. Nesse caso, é importante contatar o banco para esclarecimentos adicionais e verificar se há algum problema específico com o CEP em questão. Caso tenha qualquer dúvida sobre o cenário explicado ou se quiser conhecer nossas soluções , estaremos sempre à disposição e será um prazer ajudar!

Olá a desenvolvedor tudo bem? Se você já tentou gerar boletos pelo Banco Inter e se deparou com a mensagem {"error":"401","error_title":"Login/senha inválido"}, não se preocupe. Apesar de assustador, esse erro tem uma solução, e estamos aqui para explicar de uma forma mais fácil. O Que é o Erro 401? Essa mensagem significa que algo deu errado com suas informações de acesso (como usuário e senha) referente ao Web Service. O banco Inter não conseguiu validar as informações que você inseriu no cadastro do Web Service nas configurações de convênio. Dicas Simples para Resolver o Problema: Confira Suas Informações: Verifique se o usuário (ClientID) e senha (Secret) que você inseriu nas configurações do Web Service estão corretos; Certifique-se de que o certificado que você está usando para acessar o banco esteja válido e configurado direitinho; Renove Suas Informações de Acesso: Se tiver dúvidas sobre a validade das suas informações, pense em gerar novamente o usuário, a senha e o certificado no site do Banco Inter. Siga a Documentação: Dê uma olhada nas instruções do Banco Inter e da Tecnospeed conforme a doc Utilizando o registro via Web Service Bancário com o Banco Inter (V2) Elas possuem uma explicação detalhada de como fazer essa integração. Por Que Isso é Importante? Entender o que está acontecendo com esse código de erro pode economizar tempo e evitar dor de cabeça. Este guia fácil está aqui para ajudar você não só a resolver o problema agora, mas também para evitar que ele aconteça de novo. Tem Perguntas ou Precisa de Ajuda? Se mesmo seguindo essas dicas você ainda estiver com dificuldades, chame nosso suporte técnico. Estamos aqui para garantir que você consiga gerar seus boletos sem estresse. Esperamos que esse guia simplificado torne mais fácil para você lidar com esse problema e evite que você precise entrar em contato toda vez que algo assim acontecer. Compartilhe suas experiências ou faça mais perguntas se precisar!

Olá desenvolvedor tudo bem? Ao lidar com boletos bancários, o fator de vencimento desempenha um papel crucial na determinação da data de vencimento. No entanto, é comum surgirem dúvidas sobre o que acontece quando essa contagem atinge o número 9999. Mas pode ficar tranquilo que neste post iremos explorar esse cenário e tirar as suas dúvidas. Entenda o Fator de Vencimento: O fator de vencimento é um número inteiro que representa a quantidade de dias decorridos desde a "data base". Ele é calculado a partir de uma data base 7 de outubro de 1997, conforme padrões bancários brasileiros e aumenta em "1" a cada dia subsequente. O que acontece quando o número passa de 9999?: Após o dia 9999, a data base é automaticamente atualizada para garantir que o sistema continue funcionando sem problemas, após o 9999, a data base é ajustada para 1000 e continua a contar a partir daí, estendendo o ciclo de vida do fator de vencimento. Isso permite que o sistema continue a calcular datas de vencimento de maneira consistente e precisa. A partir de 22/02/2025, o fator de vencimento retornará para “1000”, e será adicionado “1” a cada dia subsequente a esse fator. Por exemplo, o fator de vencimento para 22/02/2025 será 1000, para 23/02/2025 será 1001, para 24/02/2025 será 1002, e assim por diante. Em termos práticos, os boletos continuarão a ser gerados e processados normalmente, mesmo após ultrapassar o 9999. A atualização da data base é uma medida inteligente implementada pelos sistemas bancários para garantir a funcionalidade contínua. Agora você entende o que acontece com o fator de vencimento do boleto quando o número passa de 9999. Esse conhecimento é fundamental para lidar com boletos bancários e entender como eles funcionam. Entender o fator de vencimento e seu comportamento além do 9999 é essencial para garantir que os processos relacionados a boletos sejam executados sem contratempos. Mantenha-se informado e esteja ciente dessas nuances para proporcionar um serviço de qualidade aos seus clientes. Se restar alguma dúvida ou se precisar de mais informações, estamos aqui para ajudar!

Olá desenvolvedor Delphi! Se você está começando no mundo do desenvolvimento com Delphi e precisa entender como instanciar um componente, este guia é para você. A instância de componentes é um passo fundamental para trabalhar com a construção de interfaces gráficas e funcionalidades em suas aplicações Delphi. Vamos passo a passo: 1. Abra o Delphi: Inicie o Delphi e abra seu projeto existente ou crie um novo projeto. 2. Adicionando um Componente: No Editor de Formulários, localize a paleta de componentes (normalmente à esquerda da tela). Nela, você encontrará diversos componentes disponíveis, como botões, editores de texto, etc. Escolha o componente desejado (por exemplo, um botão) e clique nele. Agora, seu cursor terá a forma do componente selecionado. Vá até o formulário onde deseja adicionar o componente e clique na área desejada para posicioná-lo. Isso adicionará o componente ao seu formulário. 3. Atribuindo um Nome ao Componente: Com o componente selecionado, vá até o Object Inspector (normalmente à direita da tela). Localize a propriedade "Name" e atribua um nome único ao seu componente. Este nome será usado para referenciar o componente em seu código. 4. Instanciando o Componente em Código: Agora que você adicionou o componente ao formulário e atribuiu um nome a ele, você pode instanciá-lo em seu código Delphi. Abra o editor de código (pressione F12 ou clique no botão "View Source" na barra de ferramentas). No código, declare uma variável do tipo do seu componente e, em seguida, use o comando Create para instanciá-lo. Por exemplo, se você tem um botão chamado btnExemplo, o código seria algo assim: var MeuBotao: TButton; begin MeuBotao := TButton.Create(Self); end; 5. Configurando Propriedades: Após instanciar o componente, você pode configurar suas propriedades conforme necessário. Utilize as propriedades do componente, como Caption, Width, Height, etc. MeuBotao.Caption := 'Clique em Mim'; MeuBotao.Width := 100; 6. Adicionando ao Formulário: Para que o componente seja exibido no formulário, você precisa adicionar manualmente ao formulário. Use o seguinte código: MeuBotao.Parent := Self; Isso faz com que o botão seja um filho do formulário e seja exibido corretamente. 7. Libere Recursos Quando Não For Mais Necessário: Lembre-se de liberar a memória quando o componente não for mais necessário, utilizando o comando Free. MeuBotao.Free; Conclusão: Agora você aprendeu os passos básicos para instanciar um componente no Delphi. Esse conhecimento é fundamental para a construção de interfaces gráficas e a manipulação de funcionalidades em suas aplicações. Espero que este guia seja útil em sua jornada de desenvolvimento Delphi. Se precisar de mais informações ou tiver dúvidas específicas, sinta-se à vontade para buscar mais recursos na documentação oficial do Delphi ou entrar em contato com a comunidade Delphi. Happy coding!

Olá desenvolvedor! No ecossistema dinâmico das APIs e serviços web, deparar-se com o código de erro HTTP 429, também conhecido como "Limite de Requisições Excedido", é uma situação comum. Neste post, vamos explorar o significado desse código e oferecer estratégias eficazes para lidar com limites de requisições e otimizar a interação entre cliente e servidor. Vamos aprofundar nesse aspecto essencial: Desvendando o Código de Erro 429: "Limite de Requisições Excedido" O código de erro 429 é uma resposta do servidor indicando que o cliente atingiu ou excedeu o limite de requisições permitido dentro de um determinado período de tempo. Essa medida é implementada para proteger o servidor contra solicitações excessivas que podem prejudicar o desempenho. Estratégias para Gerenciamento de Limites: Verificação de Cotas: Conheça as cotas de requisições permitidas para seu serviço específico e ajuste suas implementações conforme necessário. Implementação de Backoff: Integre estratégias de "backoff" para permitir que o cliente espere antes de tentar novas requisições após receber o código 429. Notificações de Limite: Considere implementar notificações ou informações claras para usuários finais ou desenvolvedores quando o limite de requisições estiver próximo de ser atingido. Prevenção de Exceder Limites: Rate Limiting Local: Considere implementar mecanismos de "rate limiting" local no lado do cliente para evitar exceder inadvertidamente os limites estabelecidos pelo servidor. Identificação de Erros 429: Monitore e identifique padrões de erros 429 para ajustar dinamicamente as estratégias de requisição. Importância da Resiliência: A implementação eficaz de estratégias para o código de erro 429 contribui para a resiliência da sua aplicação, garantindo uma interação suave mesmo em situações de carga intensa. Precisa de Suporte ou Mais Informações? Se precisar de assistência para lidar com o código de erro 429 ou se tiver dúvidas adicionais, não hesite em entrar em contato com nosso suporte técnico.

Olá desenvolvedor! No vasto universo do desenvolvimento web, encontrar o código de erro HTTP 404, também conhecido como "Recurso Não Encontrado", é uma experiência comum. Neste post, vamos explorar o significado desse código e oferecer estratégias eficazes para lidar com situações em que o recurso solicitado não é localizado. Vamos aprofundar nesse aspecto fundamental: Desvendando o Código de Erro 404: "Recurso Não Encontrado" O código de erro 404 é uma resposta do servidor indicando que o recurso solicitado não foi encontrado no servidor. Isso pode ocorrer por diversas razões, como alterações na estrutura do site, URLs incorretas ou exclusão do recurso. Estratégias para Resolução Rápida: Verificação de URL: Assegure-se de que a URL fornecida na requisição esteja correta e corresponda exatamente ao caminho do recurso desejado. Atualização de Links: Se ocorreram mudanças na estrutura do site, certifique-se de atualizar todos os links e referências para evitar problemas futuros. Logs de Acesso: Analise os logs de acesso para identificar possíveis padrões ou erros que levaram ao código de erro 404. Páginas Personalizadas: Considere a implementação de páginas de erro personalizadas para fornecer aos usuários informações úteis e direcioná-los para áreas relevantes do seu site. Prevenção de Erros 404: Redirecionamentos Adequados: Utilize redirecionamentos adequados quando alterar a estrutura do site ou remover recursos para garantir uma transição suave. Links Relativos: Ao criar links, use URLs relativas sempre que possível para evitar dependências de URLs absolutas. Importância da Experiência do Usuário: A rápida resolução de erros 404 é crucial para manter uma experiência do usuário positiva. Páginas não encontradas podem levar à frustração e afetar a confiança dos usuários no seu site. Precisa de Ajuda ou Mais Informações? Se, após seguir essas estratégias, o problema persistir ou se você tiver dúvidas adicionais, sinta-se à vontade para entrar em contato com nosso suporte técnico. Estamos aqui para ajudar a garantir a navegabilidade suave do seu site.

Olá desenvolvedor! Quando se trata de interações entre sistemas e segurança de API, o código de erro HTTP 401, conhecido como "Não Autorizado", é uma questão crucial a ser abordada. Neste post, exploraremos o significado deste código e forneceremos estratégias para lidar eficientemente com situações de não autorização. Vamos aprofundar nesse tópico vital: Compreendendo o Código de Erro 401: "Não Autorizado" O código de erro 401 é uma resposta do servidor indicando que a requisição não foi realizada porque o cliente não possui as credenciais necessárias para acessar o recurso solicitado. Esse cenário é frequentemente associado a problemas de autenticação. Estratégias Eficientes para Solução de Problemas: Verificação de Credenciais: Certifique-se de que as credenciais de autenticação fornecidas na requisição estão corretas e atualizadas. Token de Acesso Expirado: Caso utilize tokens de acesso, verifique se eles não expiraram. Renove ou solicite um novo token, se necessário. Permissões de Acesso: Garanta que o usuário ou a aplicação tenha as permissões necessárias para acessar o recurso solicitado. Mecanismos de Autenticação: Confira se os mecanismos de autenticação utilizados estão alinhados com as exigências do servidor. Melhores Práticas para Prevenção: Renovação Automática de Tokens: Implemente a renovação automática de tokens para evitar expirações e interrupções não planejadas. Feedback de Erro Detalhado: Forneça mensagens de erro detalhadas para orientar os usuários sobre como resolver problemas de autenticação. Importância da Resolução Pronta: Resolver rapidamente problemas de não autorização é crucial para manter a segurança e a integridade das suas aplicações. Além disso, contribui para uma experiência do usuário mais confiável. Precisa de Assistência Adicional? Se, após seguir essas estratégias, o problema persistir, não hesite em contatar nosso suporte técnico. Detalhes específicos sobre a requisição e as verificações realizadas podem acelerar o processo de resolução.

Olá desenvolvedor! No intricado mundo das APIs e desenvolvimento web, o código de erro HTTP 400, também conhecido como "Requisição Inválida", pode ser um desafio comum. Neste post, vamos explorar o significado desse código e fornecer insights valiosos sobre como abordar e resolver problemas associados a ele. Vamos adentrar esse universo técnico: Entendendo o Código de Erro 400: "Requisição Inválida" O código de erro 400 é uma resposta do servidor indicando que a requisição feita pelo cliente é inválida ou malformada. Isso pode ocorrer por várias razões, desde dados ausentes até formatos de requisição incompatíveis. Dicas Essenciais para Solução de Problemas: Formato Correto da Requisição: Certifique-se de que a requisição esteja formatada corretamente, seguindo a estrutura e os padrões necessários. Parâmetros Ausentes ou Incorretos: Verifique se todos os parâmetros obrigatórios estão presentes e se estão com os valores corretos. Validação de Dados: Realize uma validação rigorosa dos dados enviados para garantir que estejam de acordo com as expectativas do servidor. Headers e Autenticação: Confira se os headers da requisição estão corretos e se a autenticação (se necessária) está sendo realizada de maneira apropriada. Limites de Tamanho: Esteja atento aos limites de tamanho da requisição. Em alguns casos, exceder esses limites pode resultar em um erro 400. Importância da Resolução Rápida: Resolver rapidamente problemas relacionados ao código de erro 400 é fundamental para manter a eficiência das suas integrações. O tempo economizado na identificação e correção de erros resulta em uma experiência mais fluida para os usuários finais. Como Melhorar: Logs Detalhados: Implemente logs detalhados para capturar informações específicas sobre a requisição, facilitando a identificação do problema. Dúvidas ou Precisa de Ajuda? Se, após seguir essas dicas, o problema persistir, não hesite em entrar em contato com nosso suporte técnico. Fornecer informações detalhadas sobre a requisição e as verificações realizadas pode acelerar o processo de resolução. Esperamos que este guia sobre o código de erro 400 seja útil em sua jornada de desenvolvimento. Se precisar de mais esclarecimentos ou assistência, estamos à disposição para ajudar.

Olá desenvolvedor! No vasto mundo da programação e integrações, a escolha da codificação de caracteres pode parecer uma decisão técnica trivial, mas suas ramificações podem ser significativas. Neste post, vamos explorar a importância de encaminhar as requisições usando a codificação UTF-8 em vez de ASCII. Entender essa escolha pode ser crucial para evitar problemas de comunicação e garantir a integridade dos dados. Vamos aprofundar: Diferenças Essenciais: UTF-8 vs. ASCII Antes de mergulharmos na importância de UTF-8, é crucial entender as diferenças fundamentais entre UTF-8 e ASCII. ASCII (American Standard Code for Information Interchange): ASCII é uma codificação de caracteres que representa caracteres básicos em inglês e alguns caracteres especiais. No entanto, é limitado e não suporta caracteres de outros idiomas. UTF-8 (Unicode Transformation Format - 8 bits): UTF-8 é uma codificação de caracteres que suporta uma ampla gama de caracteres, incluindo os de vários idiomas. Ele é uma extensão do ASCII e é capaz de representar praticamente todos os caracteres do Unicode. Importância de UTF-8 nas Requisições: Suporte a Múltiplos Idiomas: UTF-8 permite a representação eficiente de caracteres de diferentes idiomas, facilitando a internacionalização de suas aplicações. Compatibilidade com Padrões Web: A maioria dos padrões da web e protocolos modernos, como HTTP e JSON, são baseados em UTF-8. Usar ASCII pode resultar em problemas de interpretação e exibição inadequada de caracteres especiais. Previne Perda de Dados: Ao enviar dados em ASCII, caracteres fora do conjunto suportado serão perdidos ou substituídos por espaços em branco, levando à perda de informações. Futuro-Proofing: UTF-8 é uma escolha mais robusta e preparada para o futuro, considerando a crescente diversidade de usuários e a globalização das aplicações. Dicas para Implementação: Defina a Codificação Explicitamente: Certifique-se de definir explicitamente a codificação como UTF-8 em suas requisições, evitando assim interpretações ambíguas por parte do servidor. Configurações do Servidor: Verifique se o servidor está configurado para aceitar e interpretar corretamente as requisições UTF-8. Conclusão: Ao adotar UTF-8 em suas requisições, você não apenas evita potenciais problemas de exibição de caracteres, mas também promove a interoperabilidade e a inclusão de uma variedade de idiomas em suas aplicações. Certifique-se de fazer dessa prática uma parte essencial de suas diretrizes de desenvolvimento.

Olá desenvolvedor! Quando se trata de integrações e desenvolvimento web, deparar-se com o código de erro HTTP 500, também conhecido como "Erro Interno do Servidor", pode ser desafiador. Neste post, vamos desvendar o significado desse código e oferecer dicas úteis para resolver problemas relacionados. Vamos explorar esse cenário complexo: Entendendo o Código de Erro 500: "Erro Interno do Servidor" O código de erro 500 é uma resposta genérica do servidor para indicar que algo deu errado, mas não especifica a natureza exata do problema. Pode ser causado por diversas razões, desde falhas na lógica do aplicativo até problemas nos servidores. Dicas Cruciais para Solução de Problemas: Logs de Erro: Analise os logs de erro do servidor para identificar mensagens específicas que detalham a causa do problema. Requisições Recentes: Verifique se houve alterações recentes no código ou na configuração do servidor que possam ter desencadeado o erro. Recursos Insuficientes: Certifique-se de que o servidor possui recursos suficientes, como espaço em disco e memória disponível. Atualizações de Software: Garanta que todos os softwares e dependências estejam atualizados para evitar incompatibilidades. Exceções de Código: Revise o código-fonte em busca de exceções não tratadas que possam levar a um colapso interno. Por que Essas Dicas São Importantes? A abordagem sistemática dessas dicas pode ajudar a localizar e corrigir rapidamente problemas associados ao código de erro 500. Ao fornecer informações detalhadas ao suporte, você aumenta as chances de uma resolução eficiente. Dúvidas ou Precisa de Assistência Adicional: Se, após seguir essas dicas, o problema persistir, não hesite em entrar em contato com nosso suporte. Ao fornecer detalhes específicos sobre as verificações realizadas, podemos oferecer assistência personalizada e direcionada. Esperamos que este guia sobre o código de erro 500 seja valioso em sua jornada de resolução de problemas. Se precisar de mais esclarecimentos ou suporte, estamos à disposição para ajudar.

Olá desenvolvedor! No universo das integrações e APIs, deparar-se com códigos de erro é uma parte inevitável do processo. Neste post, vamos esclarecer o significado do código de erro 403 e fornecer dicas valiosas sobre as informações que você deve verificar antes de contatar o suporte. Vamos mergulhar nesse tema importante: O Mistério por Trás do Código de Erro 403: Entendendo o "Acesso Proibido" O código de erro HTTP 403, também conhecido como "Acesso Proibido", indica que o servidor entende a requisição do cliente, mas este não tem permissão para acessar o recurso solicitado. Entender por que você está recebendo esse código é crucial para resolver o problema efetivamente. Verificações Essenciais Antes de Contatar o Suporte: Credenciais de Autenticação: Certifique-se de que as credenciais de autenticação fornecidas na requisição são corretas e têm as permissões necessárias. Configurações de Autorização: Verifique se as configurações de autorização estão configuradas corretamente para o endpoint ou recurso específico que está sendo acessado. Tokens de Acesso: Caso a autenticação envolva tokens de acesso, verifique se eles estão válidos e não expiraram. Firewall e Restrições IP: Confira se o servidor que está fazendo a requisição não está sendo bloqueado por firewalls ou restrições de IP. Permissões do Usuário: Analise as permissões do usuário ou conta associada à requisição para garantir que ela tenha as autorizações adequadas. Por que Essas Verificações são Importantes? Realizar uma análise minuciosa das informações acima antes de entrar em contato com o suporte pode acelerar significativamente o processo de resolução. Muitas vezes, problemas relacionados ao código de erro 403 podem ser corrigidos ajustando configurações, atualizando permissões ou renovando credenciais. Dúvidas ou Necessita de Mais Informações: Se, após realizar essas verificações, o problema persistir, estamos aqui para ajudar. Ao entrar em contato com o suporte, fornecer detalhes sobre as verificações realizadas facilitará uma assistência mais rápida e eficiente. Esperamos que este guia sobre o código de erro 403 e as verificações associadas seja útil em seu processo de resolução de problemas. Não hesite em nos contatar se precisar de mais esclarecimentos ou suporte adicional.

Olá desenvolvedor! Neste post, abordaremos um aspecto crucial do processo de emissão de boletos: a validação ativa realizada pela API do Plugboleto antes de enviar a requisição para o banco. Entender como essa validação funciona é essencial para garantir a integridade e o sucesso das transações. Vamos explorar: Validação Ativa: Prevenindo Falhas na Requisição A validação ativa é uma etapa fundamental no ciclo de vida de um boleto antes de ser enviado ao banco. Diferentemente da validação passiva, que ocorre apenas no banco, a validação ativa acontece no momento em que você cria a requisição na API do Plugboleto. O objetivo principal dessa validação é antecipar possíveis problemas na requisição, evitando que o boleto seja rejeitado pelo banco. Caso haja algum erro detectado durante a pré-validação, o boleto será marcado como FALHA, indicando que existe um problema que precisa ser corrigido antes do envio final ao banco. Por que é Importante? A validação ativa desempenha um papel crucial na eficiência do processo. Ao identificar antecipadamente inconsistências ou erros na requisição, você tem a oportunidade de corrigi-los antes que o boleto seja registrado no banco. Isso não apenas economiza tempo, mas também evita situações em que o boleto é rejeitado, proporcionando uma experiência mais suave para o usuário final. Como Realizar a Validação Ativa: A API do Plugboleto oferece recursos específicos para realizar a validação ativa. Certifique-se de seguir as orientações detalhadas na documentação para garantir uma implementação correta. Este processo não apenas aprimora a eficiência, mas também contribui para a confiabilidade das transações geradas pela sua aplicação. Dúvidas ou Mais Informações: Se surgir alguma dúvida durante o processo de validação ativa ou se você estiver interessado em explorar mais a fundo nossas soluções, estamos à disposição para ajudar. Garantir uma integração fluida e eficiente é nossa prioridade, e estamos aqui para fornecer todo o suporte necessário. Esperamos que este guia sobre a validação ativa no Plugboleto seja útil em sua jornada de desenvolvimento. Caso tenha alguma pergunta ou feedback, não hesite em entrar em contato!

Olá desenvolvedor tudo bem? Neste post iremos disponibilizar à você algumas informações adicionais sobre como realizar a impressão do boleto sem a linha digitavel e o código de barras. Atualmente a impressão do boleto padrão acaba trazendo as informações comuns como a linha digitavel e também o código de barras conforme exemplo abaixo: Porém atualmente foi implementado na API a funcionalidade de realizar a ocultação tanto da linha digitavel quanto o código de barras, e para realizar este processo basta realizar o processo de impressão do boleto porém com as seguintes diferenças: Json original: { "TipoImpressao" : "99", "Boletos" : [ "IdIntegracao1", ] } Com isso a única informação a ser adicionada para que as informações constem como ocultas, seria o campo booleano "OcultarLinhaCodigo": true conforme Exemplo abaixo: { "TipoImpressao" : "99", "Boletos" : [ "IdIntegracao1", ], "OcultarLinhaCodigo": true } Com isso, ao consultar o protocolo de impressão é possível obter o boleto sem as determinadas informações conforme o exemplo de impressão abaixo: Atualmente este processo funciona para todos os bancos que possuímos homologados até o momento. Viu só como é simples realizar este processo de ocultação da linha numérica e código de barras? Caso tenha qualquer dúvida sobre o cenário explicado ou se quiser conhecer nossas soluções , estaremos sempre à disposição e será um prazer ajudar!

Olá desenvolvedor! Neste post iremos disponibilizar à você algumas informações adicionais, referentes as diferenças a baixa e o descarte do boleto. Quando se trata de lidar com boletos bancários, dois termos frequentemente usados são "descarte" e "baixa". Ambos estão relacionados ao processo de "cancelamento" sobre um boleto, mas têm significados diferentes. Vamos explorar a diferença entre eles: Descarte de Boleto: Descartar um boleto significa simplesmente "apagar" ele dentro da API, porém este processo é recomendo apenas quando o boleto não possui uma remessa gerada ou o mesmo consta com o status FALHA / REJEITADO, pois assim evitamos possíveis problemas de apagar o boleto na API, mas o mesmo constar como REGISTRADO no banco. O descarte do boleto via API é realizado conforme a doc: Descartando um boleto Baixa do boleto: Diferentemente do descarte do boleto, a baixa é recomendada a ser realizada quando o boleto consta como REGISTRADO no banco. A baixa nada mais é de que um "cancelamento" do boleto no banco no qual irá acabar incapacitando o cliente de realizar o pagamento do mesmo. Este processo de baixa é realizado através do arquivo de remessa de baixa via API conforme as docs: Solicitando a baixa e Realizando a consulta da baixa ou diretamente através da API do banco. Caso tenha qualquer dúvida sobre o cenário explicado ou se quiser conhecer nossas soluções , estaremos sempre à disposição e será um prazer ajudar!

Olá, nessa documentação iremos mostrar o passo a passo de como fazemos para liberar as credenciais de integração no site do BB, e como correlacionar essas credenciais na API do PIX na Tecnospeed. Essa documentação será separada em duas etapas, a primeira etapa é relacionada nos procedimentos relacionados no lado do Banco do Brasil, onde são descritos o passo a passo para auxiliar você a cadastrar a integração no painel do Banco do Brasil e pegar as suas credenciais de integração de produção. A segunda parte já entramos na parte de integração dentro da plataforma da Tecnospeed, onde iremos cadastrar os dados da integração que foram entregues pelo banco, e por final iremos entrar no fluxo de emissão do PIX, e como é feito sua conciliação. Porém antes de entrarmos no passo a passo, o cliente que quer começar a sua emissão usando o BB, deve ter os seguintes requisitos mínimos para conseguir fazer todos os procedimentos na API da Tecnospeed e no BB. Conta ativa no Banco do Brasil Um contrato ativo com a API do PIX da Tecnospeed Acesso ao portal do desenvolvedor do Banco do Brasil (https://developers.bb.com.br/home) Como todos os requisitos mínimos liberados, você já está apto a começar a sua emissão de PIX dinâmicos e estáticos pelo BB. Primeira etapa (Texto retirado do manual do banco BB 13-05-2021) 1) Acesse e cadastre-se no Portal BB for Developers É muito simples. Na landing page do Portal BB for Developers (se preferir, acesse Aqui) acione a transação Cadastre-se e preencha os seguintes dados: CPF, nome da mãe, data de nascimento, endereço de e-mail e número de celular válidos. Desconsidere acentuação e caracteres especiais. Será remetido um código de confirmação para o número de telefone cadastrado no Banco. Informe o código recebido e cadastre uma senha conforme instruções indicadas em tela. Caso você tenha recebido um e-mail com convite do BB para primeiro ingresso no Portal BB for Developers, após o primeiro acesso, informe a chave/código indicada na mensagem. Leia e assine eletronicamente o Termo para Uso da Plataforma. Você aproveitará um ambiente super seguro para desenvolver a sua aplicação. 2) Criando sua aplicação Uma vez cadastrado no Portal BB for Developers será exigida a criação de uma aplicação. Acesse o contêiner (“+ Nova Aplicação”) e atribua as seguintes informações: nome da aplicação, descrição, URL de imagem para ícone da área de desenvolvimento (não obrigatório) e URL de call-back. Os campos Ícone da aplicação e URL de callback, ambos são opcionais e especialmente a URL de callback não devem ser preenchido, por que a API da Tecnospeed utiliza a autenticação via client_credentials e necessita apenas o client_id e client_secret, a URL de callback pertence a outro fluxo de autenticação que não será utilizado. Criada a aplicação, clique sobre o contêiner do app para acessar a área do desenvolvedor. As credenciais necessárias para realização dos testes são geradas automaticamente neste momento e poderão ser identificadas na opção Credenciais do menu lateral esquerdo. 3) Pegando suas credenciais Ao acessar sua aplicação, será disponibilizado um menu lateral esquerdo, escolha a opção "Credenciais''. Após o cadastro das credenciais, apenas a opção Teste irá se encontrar selecionada em azul. Em ambiente de Teste, o primeiro item disponibilizado, o “developer_application_key”, deverá ser informado como parâmetro clientKey na API da Tecnospeed e logo abaixo, seguem as credenciais OAuth, que serão cadastrados no client_id e client_secret. 4) Enviando a sua aplicação para Produção Para utilizar as APIs do BB para a emissão do PIX, é necessário o envio da sua aplicação para Produção para que sejam geradas chaves compatíveis com o ambiente produtivo. Passo 4.1 Selecione qual aplicação você deseja enviar para produção. É importante lembrar que a aplicação deverá estar com status "Em desenvolvimento". Passo 4.2 No menu lateral, selecione a opção "Produção" e siga os passos: Informe o CNPJ da empresa responsável. Revise as informações da sua aplicação. Caso a sua aplicação tenha a API de Cobrança vinculada, a contratação poderá ser feita de 2 formas: com ou sem o contato do BB. A contratação é feita sem a interferência do BB, caso a empresa já possua contratado um convênio de cobrança e este esteja ativo. Caso não tenha, aguarde o Banco do Brasil entrar em contato com você para finalizar a contratação, e sua aplicação ficará com o status de "Aguardando aprovação". Após o envio da sua aplicação para produção o status será alterado para "Aprovado". 6) Gerando credenciais para produção A decisão de subir a aplicação para o ambiente de produção é responsabilidade exclusiva da empresa contratante do serviço financeiro integrado pela API, assim recomendamos que os desenvolvedores e os responsáveis administrativos certifiquem-se de que todos os cenários e adequações inerentes ao modelo de negócio ao qual a API será utilizada foram testados suficiente e satisfatoriamente. Os efeitos da integração dos sistemas por API somente ocorrerão a partir da disponibilização da aplicação em produção. Selecione qual aplicação você deseja enviar para produção. É importante lembrar que a aplicação deve estar com seu status “Em desenvolvimento”. Na área do desenvolvedor, acesse a transação Produção no menu lateral esquerdo, informe o CNPJ da empresa responsável, revise os dados da aplicação e comande a disponibilização. Neste meio tempo sua aplicação permanecerá com status Aguardando aprovação. Após envio da aplicação para produção e retirada de pendência pelos outorgados, o status será alterado para Aprovado. Verifique se o item Produção ficou selecionado em azul. 7) Cadastrando suas credenciais na API da Tecnospeed Com as credenciais geradas no painel do Banco do Brasil e com acesso às suas credenciais de produção, agora iremos cadastrar os dados na API da Tecnospeed, para assim podermos gerar os PIX usando a integração da API do PIX. Passo 7.1 Cadastro de uma Company (Empresa) O primeiro passo é o cadastro da Company (Dados da sua empresa), que será onde você vai cadastrar os dados cadastrais da empresa que é titular da conta do BB, e também é a empresa que será usada para emitir as cobranças via PIX. { "zipcode": "87045410", "name": "Usuario de testes", "email": "xxxxx@gmail.com", "cpfCnpj": "xxxxxxxxx", "city": "Maringa", "state": "PR" } Nessa parte é muito importante cadastrar os dados iguais as que estão no registro do Banco, por que essas informações vai ser usado para registrar o PIX, e também será usado para gerar o EMV do PIX, e qualquer diferença entre os dados cadastros pode gerar rejeição ou falha de leitura do PIX em alguns bancos. Você consegue consultar o formato da resposta e requisição da rota de cadastro junto com os tipos de dados nesse link da documentação. Passo 7.2 Cadastro de uma account (Conta BB) Com a sua company criada, agora iremos cadastrar a conta do BB na plataforma de PIX da Tecnospeed, nessa conta iremos informar o código do banco em formato numérico, no caso do BB é o código 001, e também iremos cadastrar as credenciais geradas no painel BB, seguindo o mapeamento abaixo. { "bankCode": "001", "clientId": "client_id", "clientSecret": "client_secret", "clientKey": "developer_application_key" } Caso tenha alguma dúvida temos a documentação em formato OPENAPI 3 nesse link, exemplificando todos os campos da requisição junto com a resposta que deve ser esperada. Com esses passos feitos, você já está pronto para começar a emitir PIX dinâmicos e estáticos para o BB usando a API da Tecnospeed de PIX. Avisos importantes Para integrar com o BB no momento é necessário um certificado digital. No momento o webservice do PIX não tem suporte para Webhook, por esse motivo a aplicação faz um pooling de 30 minutos com um intervalo de 10 segundos a cada consulta, com isso se o PIX não for pago nas primeiros 30 minutos, será necessário consultar manualmente o PIX na aplicação, para que a mesma faça uma nova consulta no webservice do BB, e faça a sincronização do status do PIX. Documentação foi criada usando trechos da documentação oficial do Banco do Brasil. Bibliografia Documento de primeiro passos no BB (https://apoio.developers.bb.com.br/referency/post/5f4f8129b71fb5001268c99d) Documentação OPENAPI 3 da API do PIX (https://docs.pix.tecnospeed.com.br/)

Olá desenvolvedor! Neste post iremos disponibilizar à você algumas informações adicionais referentes a mensagem de erro: “Erro: Error: write EPROTO 139745506958664:error:14094412:SSL routines:ssl3_read_bytes:sslv3 alert bad certificate:../deps/openssl/openssl/ssl/record/r”, apresentado ao realizar a tentativa de geração de boleto através do Web Service do banco Santander. Mensagem de erro Este erro “Erro: Error: write EPROTO 139745506958664:error:14094412:SSL routines:ssl3_read_bytes:sslv3 alert bad certificate:../deps/openssl/openssl/ssl/record/r" está diretamente ligado as credencias do Web Service sobre o banco, ou seja algum problemas com o código de estação ou com o certificado digital. Como corrigir: Para corrigir o erro acima basta realizar a confirmação do código de estação incluso na API e também confirmar se o certificado digital incluso realmente acabou sendo homologado pelo banco conforme informado na documentação Utilizando o registro via Web Service Bancário com o Santander. Caso tenha qualquer dúvida sobre o cenário explicado ou se quiser conhecer nossas soluções , estaremos sempre à disposição e será um prazer ajudar!

Boa tarde Jairo tudo bem? Localizei e constatei que o cedente de ID 3462 realmente possui o certificado incluso recentemente e possui e também localizei o IDintegração com falha gerado. Verifiquei também que a mensagem de erro acabou sendo retornada diretamente pelo Web Service do banco Santander. Porém esta mensagem de erro geralmente está atrelada a, quando é realizado a nova inclusão do certificado na plataforma mas o mesmo acabou não sendo homologado pelo banco. Recomendo realizar o envio do certificado digital para o banco realizar a homologação do mesmo, assim como acabou sendo realizado no inicio da integração do Web Service conforme a doc https://atendimento.tecnospeed.com.br/hc/pt-br/articles/360015311773-Utilizando-o-registro-via-Web-Service-Bancário-com-o-Santander Qualquer dúvida estou a disposição.

Olá desenvolvedor! Neste post, estarei compartilhando algumas informações adicionais relacionadas à mensagem de erro: "Excedido o número máximo de requisições por minuto, por favor, aguarde 1 minuto antes de tentar novamente..." Isso ocorre quando são feitas mais de 5 requisições idênticas para a API em menos de 1 minuto A API Plugboletos atualmente possui uma validação para a quantidade de requisições idênticas realizadas, especificamente aquelas que envolvem a geração de protocolos. Mas por que foi necessário fazer esse ajuste na API? Essa otimização foi implementada porque a geração repetida de protocolos em um mesmo cenário pode impactar a integridade da API. Imagine um loop de código em que é necessário fazer repetidas inclusões de arquivos de retorno, com a lógica a seguir: ENQUANTO consultaDoProtocoloDeInclusaoDeRetorno <> "PROCESSADO" gerarNovoProtocoloDeInclusaoDeRetorno FIMENQUANTO Essa abordagem pode resultar em uma enxurrada de requisições à API, prejudicando o desempenho geral 😞 Como posso solucionar essa situação? No entanto, para resolver essa questão, sugiro fazer uma pequena alteração no loop, conforme exemplificado abaixo: SE consultaDoProtocoloDeInclusaoDeRetorno <> "PROCESSADO" realizarUmaNovaConsultaEmCincoSegundos = true Dessa maneira, o loop gerará apenas um novo protocolo, que será consultado na API após um intervalo de 5 segundos, até que o estado seja atualizado para "PROCESSADO". Isso evita a criação de múltiplos protocolos desnecessários e elimina o risco de bloqueio na API. Resumindo ... Em resumo, compreendemos a importância da limitação de requisições idênticas na API Plugboletos para evitar sobrecarregar o sistema e preservar seu desempenho. O ajuste implementado, embora possa parecer uma pequena alteração, desempenha um papel crucial na manutenção da integridade da API. Ao adotar a abordagem de consultar o estado do protocolo após um intervalo de 5 segundos, em vez de gerar repetidamente novos protocolos, garantimos não apenas a eficiência do sistema, mas também evitamos bloqueios indesejados na API. Caso tenha qualquer dúvida sobre o cenário explicado ou se quiser conhecer nossas soluções , estaremos sempre à disposição e será um prazer ajudar!

Olá desenvolvedor! Neste post iremos disponibilizar à você algumas informações adicionais referentes a mensagem de erro: “Pagamento não encontrado”, apresentado ao consultar um pagamento bancário através da API. Mensagem de erro Esta mensagem “Pagamento não encontrado” está diretamente ligado a quando o pagamento que estaria consultando através do uniqueID não existe mais na API, ou seja o ou no momento da consulta o uniqueID acabou sendo informado de forma incorreta ou o uniqueID deixo de existir após ser realizado a solicitação de descarte do mesmo através da rota de Exclusão de pagamento. Existe alguma maneira de corrigir? Caso o pagamento tenha sido realmente descartado na API, não teria como recupera-lo, pois ao ser solicitado esta movimentação a API acaba descartando informações importantes sobre o pagamento, onde assim acaba sendo necessário realizar a geração de um novo pagamento (uniqueID). Caso não seja o cenário acima, é necessário apenas confirmar o preenchimento do uniqueID do pagamento juntamente com os Headers da requisição. Caso tenha qualquer dúvida sobre o cenário explicado ou se quiser conhecer nossas soluções , estaremos sempre à disposição e será um prazer ajudar!

Olá desenvolvedor! Neste post iremos disponibilizar à você algumas informações adicionais referentes a mensagem de erro: “Software cliente não identificado.”, apresentado ao gerar o PIX bancário. Mensagem de erro Este erro “Software cliente não identificado.” está diretamente ligado as credencias de segurança do PIX, ela está ligada aos campos "clientId", "clientSecret" , "clientKey" e certificado digital, ou seja tudo que acaba passando por uma "validação" para a geração do PIX. Como corrigir: Para corrigir o erro acima basta realizar a confirmação dos campos "clientId", "clientSecret" , "clientKey" e também do certificado digital junto ao banco, além disso, confirme também se a API PIX e as credenciais geradas pelo banco estariam autorizadas a realizar os processos de geração do PIX. Caso tenha qualquer dúvida sobre o cenário explicado ou se quiser conhecer nossas soluções , estaremos sempre à disposição e será um prazer ajudar!

Olá desenvolvedor! Neste post iremos disponibilizar à você algumas informações adicionais, sobre como resolver o erro PROBLEM WITH TLHE LOCAL SSL CERTIFICATE. O que seria este erro? O Erro PROBLEM WITH TLHE LOCAL SSL CERTIFICATE seria um erro que é causado por uma configuração incorreta ao enviar o certificados raiz para o servidor da web entre o cliente e o servidor. Como eu consigo corrigir este problema? Para corrigir este problema é recomendo seguir os seguintes passos abaixo sobre a inclusão e exportação do certificado digital atentando-se as opções selecionadas no processo: O processo seria a inclusão e exportação do certificado digital no computador no computador porém durante o processo, realizando as seguintes marcações: Inclusão: Exportação: Após realizar este processo de importação e exportação, recomendo realizar um novo teste em sua requisição com o novo certificado exportado. Este problema quanto a validação errônea no certificado digital pode ocorrer justamente por conta da criptografia do certificado incluso, onde os servidores da AWS podem pensar que existe algum erro e por conta disso ocorre o erro PROBLEM WITH TLHE LOCAL SSL CERTIFICATE, porém realizando este processo e importando o certificado novamente na plataforma, o erro é corrigido. Viu só como é simples realizar a correção deste cenário? Caso tenha qualquer dúvida sobre o cenário explicado ou se quiser conhecer nossas soluções , estaremos sempre à disposição e será um prazer ajudar!

Olá desenvolvedor! Neste post iremos disponibilizar à você algumas informações adicionais, sobre o que seria o erro 403 e como corrigi-lo caso no processo envolva um certificado digital. O que seria este erro? O Erro 403 seria uma falha de permissão de acesso ao conteúdo, ou seja uma falha nas credenciais de autenticação da rota ou processo que está realizando. Como por exemplo os Headers da requisição e também autenticações até mesmo do banco sobre a utilização de um certificado digital ou ClientID e Secret. Como eu consigo corrigir este problema? A primeira questão que deve ser analisada, seria se todas as informações de autenticação que encaminhou na requisição, estão sendo passadas corretamente, e também conforme o banco espera, ou seja, é recomendado realizar uma confirmação das credenciais juntamente ao Internet Banking. Caso todas as credenciais estejam corretas, mas mesmo assim um certificado digital é necessário para autenticar, recomendo realizar o seguinte processo com o mesmo atentando-se as opções selecionadas no processo : O processo seria a inclusão e exportação do certificado digital no computador no computador porém durante o processo, realizando as seguintes marcações: Inclusão: Exportação: Após realizar este processo de importação e exportação, recomendo realizar um novo teste em sua requisição com o novo certificado exportado. Este problema quanto a validação errônea no certificado digital pode ocorrer justamente por conta da criptografia do certificado incluso, onde os servidores da AWS podem pensar que existe algum erro e por conta disso ocorre o erro 403, porém realizando este processo e importando o certificado novamente na plataforma, o erro é corrigido. Viu só como é simples realizar a correção deste cenário? Caso tenha qualquer dúvida sobre o cenário explicado ou se quiser conhecer nossas soluções , estaremos sempre à disposição e será um prazer ajudar!