Pesquise na Comunidade

Olá, pessoal. Devido a dificuldades de alguns clientes para gerar o certificado do Itaú para PIX e Boleto Webservice, irei disponibilizar um vídeo para auxiliar junto da nossa documentação já existente: Logo abaixo, temos o vídeo disponibilizado. Caso tenha alguma dúvida, entre em contato conosco. 2074281436_DescriptografiaItuv2-PIX.mkv

Olá Devs, como estão? Para este post, estarei demonstrando como podemos estar realizando a ativação do WebService bancário junto ao banco Itaú. Precisamos realizar algumas etapas antes de estarmos ativando este processo de comunicação. Para isso, seguem as orientações. Instalações: 1 - Ter em sua máquina o OpenSLL instalado Precisamos dele para rodarmos alguns comandos para a geração do nosso certificado. 2- Instalar o GitBash em sua máquina. Estaremos utilizando este terminal, pois foi o que mais apresentou sucesso nas gerações de certificados. 3 - Baixar a collection do postman disponibilizado pelo Itaú: https://devportal.itau.com.br/assets/certificado_dinamico_postman_fa4467d91c.zip Com as instalações, podemos seguir para a próxima etapa. Solicitar as credenciais ao banco Itaú: Para que a nossa aplicação consiga se comunicar junto a API do banco Itaú precisamos de algumas chaves de autenticação. Para ter acesso às informações será necessário acessar os canais de suporte, combinados com o seu representante comercial Itaú. Solicite ao suporte bancário os seguintes dados: ClientID : Chave utilizada para autenticar na API do Itáu Token temporário: Chave que será utilizada para gerarmos um certificado digital OBS: Caso o representante comercial disponibilize as seguintes chaves: ClientID; Token temporário; Chave Sessão; Solicite que seja realizada a descriptografia destas informações; Para que o banco realize a geração das credenciais, será solicitado ao titular da conta dois arquivos private.pem public.pem Estes arquivos podem ser gerados utilizando o seguinte comando openssl genpkey -out private.pem -algorithm RSA -pkeyopt rsa_keygen_bits:2048 openssl rsa -in private.pem -pubout -out public.pem Na etapa de descriptografia, caso o representante informe que desconhece este passo, apresente a documentação abaixo na sessão: 1.2 - Decifrar credenciais https://devportal.itau.com.br/certificado-dinamico#obter-chaves Como segunda opção de descriptografia realize estes passos: Será necessário: Script para ser executado script.rar Ter o JAVA instalado em sua máquina. CMD para a execução do script. Tendo todos os itens instalados, execute o seu CMD dentro da pasta onde se encontra o script com o comando java -cp . Criptografia Ao executar, será solicitado os seguintes dados ClientId: <ClientId presente no e-mail> Token temporário: <Token temporário presente no e-mail> Chave sessão: <Chave sessão presente no e-mail> Caminho absoluto da chave privada: <C:/Users/.../.../private.pem> (obtida através do procedimento de geração de par de chaves (public.pem e private.pem)> finalizando o script será apresentados o ClientID e o Token Temporário Ao solicitar, será encaminhado no e-mail contendo os seguintes dados Processo de Decriptografia Client id decifrada com a chave de sessao AES: [e26f2f89-0ead-4ca6-8bc3-dd44b4ab3cc7] Token decifrado com a chave de sessao AES: [eyJraWQiOiJhZTYxYWIxZi0yNTRhLTQ5ZWQtODMzNC05ZDJlN2E0MzZiNGQuaG9tLmdlbi4xNTk3NjAwMzM2OTkyLmp3dCIsImFsZyI6IlJTMjU2In0.eyJzdWIiOiJlMjZmMmY4OS0wZWFkLTRjYTYtOG JjMy1kZDQ0YjRhYjNjYzciLCJhdXQiOiJNQVIiLCJ2ZXIiOiJ2MS4wIiwiaXNzIjoiaHR0cHM6XC9cL29wZW5pZC5pdGF1LmNvbS5iclwvYXBpXC9vYXV0aFwvdG9rZW4iLCJBY2Nlc3NfVG9rZW4iOiIyY WEzZmU5NS43OGM2YjhmNS1lZWJjLTQxMzQtYmJlZS1hZDAzMjZmMTRmM2EiLCJzb3VyY2UiOiJFWFQiLCJlbnYiOiJIIiwic2l0ZSI6ImRldiIsInVzciI6Im51bGwiLCJtYmkiOiJ0cnVlIiwidXNlcl9p ZCI6ImUyNmYyZjg5LTBlYWQtNGNhNi04YmMzLWRkNDRiNGFiM2NjNyIsInNjb3BlIjoiZXNjb3BvX2RlZmF1bHQiLCJleHAiOjE2MTg5NDIyMTIsImlhdCI6MTYxODUxMDIxMiwiZmxvdyI6IkNDIn0.ZEI GYAUu-8-aCirhuClcp4F4qpL9L0KFh0pQJggXieUSCEasX-3I5QLvp5BkKcE2RhwvRfW2dUuiXJGaDqK_Mri6wZ8gVVdeHaP3ctwm8_4WBdHzxVPsAQKv2MAi8IWvHaFLFLUFcF7Z9- fpTkve_8SBnnJb4L_O7SYzXgxg3zpYSCFwMr4SrBvidq2plajEbytcDXikAXyibAWr2OH5Aijq8yfIc6dbMbH2ueA1V3mft7b_eueBQlihF1PHbytVWah6RleR5He9FLbjygcZ-F- 1ygx5yTSl_DMCGn4uCYmH5IfkZa9jC9A2-t4jlIlvFZHeGVl_c2-xaWFBd_9ryQ] Gerando um certificado CSR e KEY com o OpenSLL: Ótimo, se chegou até aqui, provavelmente possui as credenciais disponibilizadas pelo banco, agora precisamos gerar um certificado para que possamos ter acesso a outros dados que o banco estará disponibilizando. Certificado CRT ClientSecret Para recebermos este dados, estaremos utilizando as seguintes ferramentas; GitBash OpenSLL Collection do Postman Crie uma pasta para salvarmos os arquivos que serão gerados, após isso, abra o seu terminal GItBash e execute o seguinte comando: openssl req -new -subj "//CN=CLIENTID\OU=tecnospeed\L=CIDADE\ST=ESTADO\C=BR" -out ARQUIVO_REQUEST_CERTIFICADO.csr -nodes -sha512 -newkey rsa:2048 -keyout ARQUIVO_CHAVE_PRIVADA.key Lembre-se de alterar alguns dados conforme os dados do titular da conta CN = ClientID disponibilizado via e-mail OU = Deixe preenchido como tecnospeed L = Cidade onde se localiza a Agência do cliente ESTADO = onde se localiza a Agência do cliente C = País onde se localiza a Agência do cliente ARQUIVO_REQUEST_CERTIFICADO.csr = Dê um nome ao seu certificado csr que será gerado ARQUIVO_CHAVE_PRIVADA = Dê um nome a chave Key vinculada ao certificado Ao executar o comando em seu terminal, temos os seguintes arquivos gerados em sua pasta Perfeito, temos nosso certificado gerado, agora estaremos utilizando a collection do postman que baixamos no início deste post. Assim que importar, iremos acessar a pasta Ativação Certificado Dinâmico e utilizaremos o methodo POST 3 - Envio de arquivo .csr No body da requisição, insira o certificado.csr em formato texto que foi gerado anteriormente. Para ter o texto deste certificado, abra em um editor de texto de sua preferência. Exemplo de como precisa estar na requisição para o banco Na mesma requisição, adicione também o token temporário retornado pelo banco Como resposta teremos os seguintes dados Tendo estes dados, salve o campo Secret separado do certificado em sua pasta com a extensão .txt e o conteúdo do certificado salve com a extensão .crt Ao realizar todos os passos, precisamos realizar a conversão para .pfx. Com isso, voltamos ao nosso terminal e executaremos o seguinte comando: openssl pkcs12 -export -out certificado_convertido.pfx -inkey certificadoKey.key -in certificadoGerado.crt OBS: como recomendação, acesse a documentação: Nela, demonstramos como converter utilizando o Ubuntu Após isso, siga com a nossa documentação para realizar os cadastros em nossa API: https://atendimento.tecnospeed.com.br/hc/pt-br/articles/4413913645591-Utilizando-o-registro-via-Web-Service-Bancário-com-o-Itaú-v2

Olá desenvolvedor(a) Neste post estaremos comentando sobre a rejeição apontada no registro via webservice do banco Sicredi: 20001 - ORA-20001: ECCRL0238 : Título já cadastrado Como já comentado em outros post relacionado ao banco Sicredi para o tratamento do nosso número no banco. Este sequencial se relaciona ao identificador único de um boleto que esta sendo registrado junto ao sistema bancário, ou seja, este sequencial precisa ser único e exclusivo do boleto. Para mais detalhes, clique aqui Tendo as informações do que é o nosso número, o banco possui algumas validações para impedir que o mesmo boleto seja registrado. Junto a utilização do registro via webservice do Sicredi, quando retornado a rejeição, estará informando da seguinte forma: 20001 - ORA-20001: ECCRL0238 : Título já cadastrado Apesar do tamanho da rejeição, o banco esta apenas retornando para o emissor, de que este boleto não pode ser registrado, pois um boleto com o mesmo nosso número foi registrado no sistema bancário. Para evitar esta rejeição junto ao banco, é aconselhado a verificações de qual sequencial do nosso número esta aguardando, e a partir deste valor, os próximos boletos tenham o valor incrementado. evitando assim a rejeição de duplicidade do boleto. Em caso de dúvidas, estamos a total disposição.

Olá desenvolvedor! Neste post iremos disponibilizar à você algumas informações adicionais referentes a mensagem de erro: “(640) OPERACAO NAO PERMITIDA - CEDENTE INFORMADO NAO POSSUI AUTORIZACAO PARA UTILIZAR SERVICO WEBSERVICE”, apresentado pelo WebService bancário da Caixa. Este erro será apresentado quando o cedente que disparou a requisição de REGISTRO via WEBSERVICE ainda não finalizou o processo de ativação do registro via WS junto ao banco , ou seja, não possui liberação do banco para registrar via WebService, ou mesmo por alguma divergência nos dados de cedente declarados na requisição com os dados cadastrados no banco. Mensagem de erro A mensagem de erro “OPERACAO NAO PERMITIDA - CEDENTE INFORMADO NAO POSSUI AUTORIZACAO PARA UTILIZAR SERVICO WEBSERVICE” ocorre quando os dados de cedente enviados na requisição de registro possui divergências no cadastro junto ao banco ou o mesmo não possui a liberação para utilização do WEBSERVICE. Como corrigir: Para corrigir o erro acima basta entrar em contato com o banco, e realizar o alinhamento das informações enviadas na requisição junto aos dados cadastrados no banco caso os dados estejam corretos deve-se conferir junto ao gerente se a conta do cedente realmente possui a liberação para utilização do WEBSERVICE. Como corrigir nas soluções Tecnospeed: Em nossa plataforma, identifique a conta que foi previamente cadastrada , e realize a conferencia de acordo com os dados fornecidos pelo banco, verifique se a opção de “registro instantâneo” está selecionada no respectivo convênio do cedente, e dê inicio nas emissões com este novo serviço. Motivos para utilizar o WebService O recurso da transmissão instantânea (WebService) é um método de comunicação direta com as APIs dos bancos, tendo assim uma resposta instantânea sobre a situação de seu boleto, ou seja, já no momento da emissão é feita uma comunicação com os servidores bancários, e os boletos já são autorizados ou rejeitados, permitindo assim que os clientes façam o pagamento logo após a emissão dos títulos, sem precisar aguardar o dia útil padrão de processamento de remessas, pois este serviço não utiliza o arquivo de remessa para o registro do boleto. Caso queira conhecer como fazer a configuração no ambiente da Tecnospeed, clique aqui e conheça nossos produtos! Caso tenha qualquer dúvida sobre o cenário explicado ou se quiser conhecer nossas soluções voltadas a automatização na geração de boletos, estaremos sempre à disposição, será um prazer ajudar!

Ola Desenvolvedor! Muitas empresas têm problemas com o tempo de registro de seus boletos, pois no processo tradicional de REGISTRO de títulos com as instituições bancarias existe o tempo de espera entre o envio arquivo de REMESSA que é feito pelo cedente e a espera do processamento por parte do banco para assim conseguir a recepção do arquivo de RETORNO, por esse motivo seus boletos ficam disponíveis para pagamento com o mínimo 1 dia útil, impossibilitando assim o pagamento do boleto na mesma data de sua emissão. O que é o Registro instantâneo ou registro via WEB SERVICE ? O termo TRÂNSMISSÃO INSTANTÂNEA refere-se ao registro online de boleto, esse processo também é conhecido como registro via webservice bancário, nesta modalidade de envio é disparada uma requisição com os dados do título a ser registrado pelo banco e imediatamente é devolvido a resposta via API com o aceite do título ou rejeição, caso a resposta da API bancaria seja positiva para o registro o título já estará disponível para pagamento imediatamente. A transmissão instantânea pode ser chamada também de registro online, registro e-commerce ou registro via webservice. Como a TECNOSPEED utiliza essa funcionalidade em sua API. Nossa API de emissão de boletos PlugBoleto envia uma requisição para a API do banco com os dados informados pelo cedente e em poucos segundos recebemos via webservice a devolutiva do banco com a instrução de REGISTRO ou REJEIÇÃO. Simples assim! Depois do retorno positivo do banco, o boleto já pode ser enviado para o cliente ou impresso e ele estará pronto para ser pago.