Jump to content

Eduardo_Montanhole

Pessoal da TecnoSpeed
  • Contagem de Conteúdo

    57
  • Ingressou

  • Última visita

  • Dias Ganhos

    2

Eduardo_Montanhole ganhou o dia em Fevereiro 5

Eduardo_Montanhole teve o conteúdo mais curtido!

Informações Pessoais

  • Cidade
    Paranavaí
  • Estado
    Paraná (PR)

Clientes & Parceiros

  • Você é um cliente TecnoSpeed?
    Não
  • Você é um parceiro da Casa do Desenvolvedor?
    Sim

Visitantes Recentes do Perfil

O bloco de visitantes recentes está desativado e não está sendo mostrado a outros usuários.

Conquistas de Eduardo_Montanhole

  1. Olá Desenvolvedor! Este post explicará o motivo da rejeição retornada pelo WEBSERVICE da Caixa Econômica Federal: (BK76) ERRO NA FORMATACAO DA MENSAGEM Essa rejeição do Webservice da Caixa faz referência à mensagem como um todo, ou seja, ao “XML” que enviamos em nossa requisição. Sendo assim, qualquer campo fora do padrão de estrutura esperado pode ter esse tipo de rejeição. #ATENÇÃO: Apesar de retornar mensagens/críticas diferente, esse tipo de validação é realizada por outros bancos como: SICOOB, BANCO DO BRASIL, BRADESCO além de outros. Mensagem de erro: (BK76) ERRO NA FORMATACAO DA MENSAGEM Como corrigir: Verifique seu XML como um todo, mas alguns campos já foram catalogados por nossa equipe como sendo os "mais problemáticos", e são eles: <NUMERO_DOCUMENTO> com mais campos do que o previsto no manual (11 dígitos); <ACAO> é um campo que passa despercebido, e faz referência à BAIXA(DEVOLUÇÃO) ou PROTESTO e a Caixa obriga que seja informado; <ENDERECO> esse campo compreende outros 5 campos e em caso de não preenchimento de qualquer um deles, o XML será rejeitado (Essa regra se aplica em caso de protesto, que ocorre na maioria dos casos). Como corrigir nas soluções Tecnospeed: Verifique as dicas sobre os campos abaixo no seu JSON de envio: "TituloNumeroDocumento" = Campo onde pode ser informado um valor para controle interno, mas a CAIXA aceita apenas 11 dígitos, o que pode invalidar o envio para o WebService. Baixa ou Protesto = a Caixa obriga que seja informado uma das duas opções (Baixar ou Protestar o título após o vencimento) Endereço do Sacado = Se atente para o preenchimento de todos os campos de endereço, a caixa obriga o preenchimento desse campo em caso de protesto Todos os campos citados acima podem ser encontrados em: https://atendimento.tecnospeed.com.br/hc/pt-br/articles/360014943693-Campos-utilizados-para-inclusão Se houver 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!
  2. Olá desenvolvedor(a), Neste post conversaremos sobre dois campos muito importantes do processo de emissão emissão de boletos. Estamos falando do “Nosso número” e “Número do documento”, e falaremos também sobre a principal rejeição que ocorre relacionada a estes campos. Os dois campos são utilizados para a identificação dos boletos emitidos, porém há diferenças importantes entre eles. Referente ao “Nosso número”, se trata de uma identificação obrigatória para cada boleto emitido. Ou seja, é a numeração única que cada boleto possuirá junto ao banco, e é utilizado para identificar seu boleto no momento da cobrança e do pagamento. É um dos campos mais importantes no momento da emissão, e é fundamental que você sempre o incremente a cada boleto gerado, para que esta numeração não se repita. Caso ocorra uma duplicidade de “Nosso Número”, o banco irá rejeitar o boleto com a seguinte mensagem: “Entrada de Título já cadastrado” (ou similar, dependendo de cada banco), e o boleto em questão não será registrado e portanto, ficará impossibilitado de ser pago. Como corrigir esta rejeição? Para corrigir a mensagem de erro citada, é preciso utilizar um “Nosso Número” novo e único para o boleto. Se você não possuir uma relação sobre as numerações já utilizadas, é importante solicitar ao banco qual o último “Nosso Número” utilizado, e prosseguir a emissão a partir dele. Na API de Boletos da Tecnospeed nós fazemos uma validação sobre esta numeração e te avisamos caso você emita um boleto com numeração já utilizada em nosso sistema! Também fazemos todos os tratamentos sobre o sequencial do “Nosso Número” para que este fique no formato em que os bancos esperam. Desta forma, diminui-se o risco de problemas e rejeições que podem ocorrer no momento de enviar a remessa ao banco. Já o campo “Número do documento” é um identificador livre, que você pode utilizar para referenciar o boleto a qualquer outra informação que seja pertinente à sua necessidade. Citamos como exemplo o uso do “Número do documento” para referenciar a numeração de uma nota fiscal, onde em uma compra parcelada em 3 vezes, seriam gerados 3 boletos distintos, com 3 “Nosso Número” diferentes, mas em ambos os boletos o “Número do documento” seria o mesmo, pois estaria referenciando à mesma nota fiscal. Caso queira conhecer nossos produtos voltados à Cobrança Bancária entre em contato conosco! Será um prazer te atender! E restando qualquer dúvida estamos à disposição!
  3. Olá desenvolvedor! Neste post iremos te mostrar as vantagens em personalizar o cabeçalho de seus boletos, sem interferir no padrão exigido pelos bancos! O que é a personalização? A personalização dos boletos é bastante útil quando queremos inserir informações mais diretas junto ao boleto do cliente, como por exemplo uma propaganda de sua empresa citando novos produtos, ou um detalhamento maior referente ao que está sendo cobrado. Este recurso pode ter diversas vantagens para os clientes, como por exemplo: Desenvolver um recibo do pagador próprio e adicionar informações personalizadas para que seja visível a data de vencimento ou a linha digitável do boleto, como também os dados do pagador, entre outras informações; Inserir uma logomarca da empresa emitente dos boletos, com isso você pode deixar as suas impressões com o layout da empresa. Ou quem sabe uma propaganda, conforme já comentamos, e inserir junto a estas informações os meios para contato com a empresa. Como a Tecnospeed trabalha com estas personalizações? No PlugBoleto, nossa API para a emissão de boletos de cobrança, possuímos todos estes exemplos citados, onde você pode personalizar o topo da sua impressão da maneira que achar melhor através de um HTML que você mesmo pode definir o layout. A partir daí, poderá optar em inserir esta personalização em todas as suas impressões. Deixamos abaixo um exemplo de um boleto com o cabeçalho personalizado, para que você possa visualizar a forma como trabalhamos e as possibilidades de personalização existentes. Em boletos de cobrança o layout de impressão (e PDF) é um dos pontos mais importantes do fluxo de emissão, pois é a interface que os clientes finais utilizam para efetuar os pagamentos. Então, caso tenha qualquer dúvida sobre este tema fique a vontade para nos chamar! Para qualquer dúvida, estamos a total disposição!
  4. Olá desenvolvedor! Neste post iremos disponibilizar à você, algumas informações adicionais referente a mensagem de rejeição: “erro na chave de autenticação” do banco Sicredi (748), que pode ocorrer nas emissões de boletos via Web Service (Registro Online). Mensagem de erro A mensagem de rejeição “erro na chave de autenticação”, geralmente ocorre por conta de alguma alteração ou desativação da chave de segurança do responsável pela conta, ou seja, qualquer alteração realizada nesta chave, pode acabar atrapalhando no momento da emissão do boleto, fazendo com que esta mensagem de rejeição seja apresentada. Como corrigir: Para corrigir o erro, o primeiro ponto é entrar em contato com o gerente da conta no banco para verificar se a chave está ativa e qual seria a chave correta. Depois disso com a chave ativada ou corrigida basta utiliza-la para autenticar a requisição http. Ou seja, caso enfrente este problema, é necessário verificar no sistema do banco se as chaves estão ativas. Caso tenha qualquer dúvida sobre o cenário explicado, estaremos sempre à disposição, será um prazer ajudar!
  5. Olá desenvolvedor(a), Neste post conversaremos sobre dois campos muito importantes do processo de emissão emissão de boletos. Estamos falando do “Nosso número” e “Número do documento”, e falaremos também sobre a principal rejeição que ocorre relacionada a estes campos. Os dois campos são utilizados para a identificação dos boletos emitidos, porém há diferenças importantes entre eles. Referente ao “Nosso número”, se trata de uma identificação obrigatória para cada boleto emitido. Ou seja, é a numeração única que cada boleto possuirá junto ao banco, e é utilizado para identificar seu boleto no momento da cobrança e do pagamento. É um dos campos mais importantes no momento da emissão, e é fundamental que você sempre o incremente a cada boleto gerado, para que esta numeração não se repita. Caso ocorra uma duplicidade de “Nosso Número”, o banco irá rejeitar o boleto com a seguinte mensagem: “Entrada de Título já cadastrado” (ou similar, dependendo de cada banco), e o boleto em questão não será registrado e portanto, ficará impossibilitado de ser pago. Como corrigir esta rejeição? Para corrigir a mensagem de erro citada, é preciso utilizar um “Nosso Número” novo e único para o boleto. Se você não possuir uma relação sobre as numerações já utilizadas, é importante solicitar ao banco qual o último “Nosso Número” utilizado, e prosseguir a emissão a partir dele. Na API de Boletos da Tecnospeed nós fazemos uma validação sobre esta numeração e te avisamos caso você emita um boleto com numeração já utilizada em nosso sistema! Também fazemos todos os tratamentos sobre o sequencial do “Nosso Número” para que este fique no formato em que os bancos esperam. Desta forma, diminui-se o risco de problemas e rejeições que podem ocorrer no momento de enviar a remessa ao banco. Já o campo “Número do documento” é um identificador livre, que você pode utilizar para referenciar o boleto a qualquer outra informação que seja pertinente à sua necessidade. Citamos como exemplo o uso do “Número do documento” para referenciar a numeração de uma nota fiscal, onde em uma compra parcelada em 3 vezes, seriam gerados 3 boletos distintos, com 3 “Nosso Número” diferentes, mas em ambos os boletos o “Número do documento” seria o mesmo, pois estaria referenciando à mesma nota fiscal. Caso queira conhecer nossos produtos voltados à Cobrança Bancária entre em contato conosco! Será um prazer te atender! E restando qualquer dúvida estamos à disposição!
  6. Olá desenvolvedor! Neste post iremos disponibilizar à você algumas informações adicionais referentes ao erro “00422 - Certificado inconsistente”, apresentado pelo WebService do banco Santander (033). Este erro será apresentado quando a requisição que for recebida pelo banco identificar falhas no certificado digital que foi previamente cadastrado e validado, e também quando o certificado utilizado no sistema que esta disparando as requisições possuir algum problema. Mensagem de erro: A mensagem de erro “00422 - Certificado inconsistente” ocorre quando o certificado utilizado para encaminhar a requisição ao banco possui divergências no cadastro junto ao banco de dados do Santander, e geralmente é devolvida após a data de vencimento do certificado ter sido ultrapassada. Como corrigir: Para corrigir o erro acima basta reenviar o certificado ao Santander, para que o banco realize o procedimento de validação e dê disponibilidade novamente ao certificado, e este deverá ser utilizado novamente nas próximas requisições. Como corrigir nas soluções Tecnospeed: O primeiro passo é confirmar se o certificado do cedente responsável pela conta está vencido, e caso esteja, providenciar um novo certificado digital. Após isso, realize o encaminhamento do mesmo para o Santander, para que o procedimento de validação seja iniciado. Após o procedimento junto ao banco ser finalizado, cadastre novamente o certificado no ambiente do cedente no PlugBoleto e verifique se a opção de “registro instantâneo” está selecionada no respectivo convênio do cedente, e dê sequência nas emissões. Caso você tenha interesse, a Tecnospeed possui uma solução voltada à emissão de certificados digitais, clique aqui 1 para mais informações e conhecer nossos produtos. Se houver 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!
  7. Olá desenvolvedor(a), Neste post conversaremos sobre dois campos muito importantes do processo de emissão emissão de boletos. Estamos falando do “Nosso número” e “Número do documento”, e falaremos também sobre a principal rejeição que ocorre relacionada a estes campos. Os dois campos são utilizados para a identificação dos boletos emitidos, porém há diferenças importantes entre eles. Referente ao “Nosso número”, se trata de uma identificação obrigatória para cada boleto emitido. Ou seja, é a numeração única que cada boleto possuirá junto ao banco, e é utilizado para identificar seu boleto no momento da cobrança e do pagamento. É um dos campos mais importantes no momento da emissão, e é fundamental que você sempre o incremente a cada boleto gerado, para que esta numeração não se repita. Caso ocorra uma duplicidade de “Nosso Número”, o banco irá rejeitar o boleto com a seguinte mensagem: “Entrada de Título já cadastrado” (ou similar, dependendo de cada banco), e o boleto em questão não será registrado e portanto, ficará impossibilitado de ser pago. Como corrigir esta rejeição? Para corrigir a mensagem de erro citada, é preciso utilizar um “Nosso Número” novo e único para o boleto. Se você não possuir uma relação sobre as numerações já utilizadas, é importante solicitar ao banco qual o último “Nosso Número” utilizado, e prosseguir a emissão a partir dele. Na API de Boletos da Tecnospeed nós fazemos uma validação sobre esta numeração e te avisamos caso você emita um boleto com numeração já utilizada em nosso sistema! Também fazemos todos os tratamentos sobre o sequencial do “Nosso Número” para que este fique no formato em que os bancos esperam. Desta forma, diminui-se o risco de problemas e rejeições que podem ocorrer no momento de enviar a remessa ao banco. Já o campo “Número do documento” é um identificador livre, que você pode utilizar para referenciar o boleto a qualquer outra informação que seja pertinente à sua necessidade. Citamos como exemplo o uso do “Número do documento” para referenciar a numeração de uma nota fiscal, onde em uma compra parcelada em 3 vezes, seriam gerados 3 boletos distintos, com 3 “Nosso Número” diferentes, mas em ambos os boletos o “Número do documento” seria o mesmo, pois estaria referenciando à mesma nota fiscal. Caso queira conhecer nossos produtos voltados à Cobrança Bancária entre em contato conosco! Será um prazer te atender! E restando qualquer dúvida estamos à disposição!
  8. Olá Desenvolvedor! Neste post iremos conversar sobre o erro “Tamanho do registro 1 inválido” que pode ocorrer ao fazer o upload de arquivos de remessa no site do Itaú. Geralmente, este erro é apresentado caso o seu arquivo de remessa possua alguma quebra de layout, ou seja se ele ultrapassar a quantidade de caracteres definidos por linha (que podem ser 240 ou 400, dependendo do layout utilizado). O que causa este problema? Esta quebra de layout pode ocorrer por diversos motivos, porém o que mais ocorre são: Passar as informações na remessa usando o “copiar e colar”: Caso estes caracteres copiados estejam com uma formatação diferente, pode ocasionar na quebra dos caracteres no layout da remessa, que é o que chamamos de “caracteres ocultos”, que geralmente não são visíveis em editores de texto mais simples e aparecem apenas quando o arquivo é processado ou quando a remessa é aberta em um editor de texto mais robusto; Edições equivocadas no arquivo de remessa: Caso seja necessário a abertura do arquivo para confirmar alguma informação, certifique-se de que nenhum campo ou coluna será alterado, como a adição de espaços ou caracteres, apagar um dígito, entre outros, pois qualquer edição equivocada no arquivo poderá causar a quebra de layout do arquivo, e isso poderá motivar o erro de “Tamanho do registro 1 inválido”. Este erro também pode ser apresentado caso a remessa seja gerada em um layout diferente do que for esperado pelo banco, como por exemplo, se a conta estiver cadastrada junto ao banco no CNAB 400, mas a remessa for enviada no CNAB 240, ou vice-versa. Isso pode ocasionar na divergência de layout esperado pelo banco, pois estará encaminhando com um tipo de layout, e o banco estará aguardando outro. Como corrigir? O primeiro passo é selecionar a remessa que ocasionou o problema e fazer a abertura em um editor de texto como o Visual Code ou NotePad++. Na sequência basta conferir se cada linha possui a quantidade correta de caracteres esperada pelo banco. Algo que pode ser útil também é alterar a codificação do arquivo (de UTF-8 para ANSI, por exemplo), e verificar se ocorrerá alguma falha, aumentando assim a quantidade de caracteres por linha do arquivo. Caso existam caracteres ocultos, com este processo eles aparecerão no arquivo. Há alguma aplicação que realiza estes tratamentos? A TecnoSpeed desenvolveu a aplicação para emissão de boletos que pode fazer a entrega destas remessas ao banco, recurso que chamamos de “Transmissão Automática das remessas e retornos”. Utilizando este recurso, diminuímos drasticamente a possibilidade de edições equivocadas no arquivo, e falhas no momento de fazer o upload no sistema do banco. Além de podermos oferecer aos clientes um nível de automatização bastante alto, pois os usuários não precisarão mais manipular suas remessas. Caso tenha qualquer dúvida sobre os pontos que explicamos, ou se quiser conhecer mais os nossos serviços fique a vontade para comentar este post, será um prazer ajudar!
  9. Olá DEV! Algumas Software House's relatam muitos problemas com o não recebimento de e-mails da parte de seus usuários finais por caírem na caixa de SPAM, o intuito desse material hoje é pontuar algumas dicas gerais sobre boas praticas na criação da estrutura de seus HTML. Aqui estão algumas dicas para criar e-mails HTML que tenham uma melhor chance de chegar à caixa de entrada do destinatário: Evite palavras de spam: Evite o uso de palavras que são comumente associadas a e-mails de spam, como "grátis", "oferta especial", "ganhe dinheiro rapidamente", entre outras. Essas palavras podem acionar os filtros de spam e diminuir a chance de seu e-mail ser entregue. Otimize o código HTML: Certifique-se de que o código HTML do seu e-mail está corretamente estruturado e otimizado. Utilize tags HTML adequadas, evite aninhamento excessivo de tabelas e mantenha o código limpo. Isso ajuda os servidores de e-mail a interpretar corretamente o conteúdo. Evite excesso de imagens: Embora as imagens possam melhorar a aparência do seu e-mail, é importante não exagerar. Muitas imagens podem acionar filtros de spam. Além disso, muitos clientes de e-mail bloqueiam automaticamente o carregamento de imagens por padrão. Portanto, sempre forneça um conteúdo legível mesmo sem o carregamento das imagens. Tenha um equilíbrio entre texto e imagens: É recomendável que seu e-mail tenha um equilíbrio adequado entre texto e imagens. Inclua conteúdo de texto significativo e relevante para complementar suas imagens. Isso ajuda a evitar que seu e-mail pareça suspeito ou enganoso para os filtros de spam. Personalize o remetente: Use um nome de remetente personalizado e um endereço de e-mail confiável para enviar seus e-mails. Isso pode aumentar a credibilidade e a confiança do destinatário em relação ao seu e-mail. Teste antes de enviar: Antes de enviar um e-mail em massa, teste-o em diferentes clientes de e-mail e serviços de webmail para garantir que ele seja exibido corretamente e não seja marcado como spam. Verifique se os links estão funcionando corretamente e se o conteúdo é legível em diferentes dispositivos e tamanhos de tela. Utilize serviços de envio confiáveis: Se você enviar grandes volumes de e-mails regularmente, considere usar serviços de envio confiáveis e especializados em e-mail marketing. Esses serviços têm conhecimento sobre as melhores práticas para evitar filtros de spam e têm relacionamentos estabelecidos com provedores de e-mail, o que pode melhorar a entrega dos seus e-mails. Como o PLUBOLETO trabalha com o serviço de envio de e-mails? Em nossa API Plugboleto possuímos uma rota de envio de e-mail onde a Software House define quais infos serão enviadas e fica livre para criação de HTML personalizado e anexos ao e-mail, conforme exemplo abaixo: { "IdIntegracao": ["eSaG3t3"], "TipoImpressao":"2", "EmailNomeRemetente": "Empresa Exemplo", "EmailRemetente": "exemplo@remetente.com.br", "EmailAssunto": "Boleto para pagamento", "EmailConteudoHtml": true, "EmailMensagem": "Segue o link do boleto:<br> ${linkBoleto}<br>Considere não imprimir este email.<br><b>Código HTML dentro da Tag</b>", "EmailDestinatario": [ "teste@tecnospeed.com.br","teste2@tecnospeed.com.br" ], "EmailAnexarBoleto": true, "Anexos": [ { "Arquivo": "iVBORw0KGgoAAAANSUhEUgAAAJIAAACSCAYAAACue5OOAAAKN2lDQ1BzUkdCIElFQzYxOTY2LTIuMQAAeJydlndUU9kWh8+9N71QkhCKlNBraFICSA29SJEuKjEJEErAkAAiNkRUcERRkaYIMijggKNDkbEiioUBUbHrBBlE1HFwFBuWSWStGd+8ee/Nm98f935rn73P3Wfvfda6AJD8gwXCTFgJgAyhWBTh58WIjYtnYAcBDPAAA2wA4HCzs0IW+EYCmQJ82IxsmRP4F726DiD5+yrTP4zBAP+flLlZIjEAUJiM5/L42VwZF8k4PVecJbdPyZi2NE3OMErOIlmCMlaTc/IsW3z2mWUPOfMyhDwZy3PO4mXw5Nwn4405Er6MkWAZF+cI+LkyviZjg3RJhkDGb+SxGXxONgAoktwu5nNTZGwtY5IoMoIt43kA4EjJX/DSL1jMzxPLD8XOzFouEiSniBkmXFOGjZMTi+HPz03ni8XMMA43jSPiMdiZGVkc4XIAZs/8WRR5bRmyIjvYODk4MG0tbb4o1H9d/JuS93aWXoR/7hlEH/jD9ld+mQ0AsKZltdn6h21pFQBd6wFQu/2HzWAvAIqyvnUOfXEeunxeUsTiLGcrq9zcXEsBn2spL+jv+p8Of0NffM9Svt3v5WF485M4knQxQ143bmZ6pkTEyM7icPkM5p+H+B8H/nUeFhH8JL6IL5RFRMumTCBMlrVbyBOIBZlChkD4n5r4D8P+pNm5lona+BHQllgCpSEaQH4eACgqESAJe2Qr0O99C8ZHA/nNi9GZmJ37z4L+fVe4TP7IFiR/jmNHRDK4ElHO7Jr8WgI0IABFQAPqQBvoAxPABLbAEbgAD+ADAkEoiARxYDHgghSQAUQgFxSAtaAYlIKtYCeoBnWgETSDNnAYdIFj4DQ4By6By2AE3AFSMA6egCnwCsxAEISFyBAVUod0IEPIHLKFWJAb5AMFQxFQHJQIJUNCSAIVQOugUqgcqobqoWboW+godBq6AA1Dt6BRaBL6FXoHIzAJpsFasBFsBbNgTzgIjoQXwcnwMjgfLoK3wJVwA3wQ7oRPw5fgEVgKP4GnEYAQETqiizARFsJGQpF4JAkRIauQEqQCaUDakB6kH7mKSJGnyFsUBkVFMVBMlAvKHxWF4qKWoVahNqOqUQdQnag+1FXUKGoK9RFNRmuizdHO6AB0LDoZnYsuRlegm9Ad6LPoEfQ4+hUGg6FjjDGOGH9MHCYVswKzGbMb0445hRnGjGGmsVisOtYc64oNxXKwYmwxtgp7EHsSewU7jn2DI+J0cLY4X1w8TogrxFXgWnAncFdwE7gZ" Para utilização correta desse serviço é necessário que a Software House utilize as boas práticas citadas no inicio do material visando evitar o não recebimento do e-mail por conta de ser caracterizado pelo provedor do serviço como SPAM.
  10. Olá Dev ! Hoje falaremos um pouco sobre o que é WEBHOOK e como podemos otimizar nossas implementações o utilizando para evitar consumos desnecessários de infra em consultas. O que é WEBHOOK ? No mundo da programação e desenvolvimento de aplicativos, você provavelmente já ouviu falar sobre webhooks. Eles desempenham um papel crucial na comunicação entre diferentes sistemas e serviços na web. Então, o que exatamente é um webhook? Um webhook é uma forma de comunicação automatizada que permite que um aplicativo ou serviço envie informações em tempo real para outro aplicativo ou serviço. É uma maneira eficiente de transmitir dados entre diferentes partes, sem a necessidade de consultas ou verificações constantes. Na maioria dos casos, o processo de webhook envolve uma solicitação HTTP (geralmente um POST) que é enviada por um aplicativo para um URL específico. O aplicativo receptor, que está "ouvindo" no URL do webhook, recebe a solicitação e processa os dados enviados. Os webhooks são amplamente utilizados em diversas áreas, como integração de sistemas, notificações em tempo real, automação de tarefas e muito mais. Aqui estão alguns exemplos práticos de como os webhooks são usados: Integração de aplicativos: Os webhooks permitem que diferentes aplicativos ou serviços se comuniquem entre si de forma contínua. Por exemplo, um aplicativo de comércio eletrônico pode enviar automaticamente detalhes de pedidos para um sistema de gerenciamento de estoque sempre que uma nova compra for feita. Notificações em tempo real: Muitos serviços utilizam webhooks para enviar notificações em tempo real para os usuários. Por exemplo, um aplicativo de mensagens instantâneas pode usar webhooks para enviar notificações sobre novas mensagens recebidas. Automação de tarefas: Os webhooks são frequentemente usados para automatizar tarefas e fluxos de trabalho. Por exemplo, um serviço de monitoramento de mídia social pode acionar um webhook sempre que uma determinada hashtag for mencionada, permitindo que um aplicativo ou serviço responda automaticamente a essas menções. Ao configurar um webhook, é importante fornecer um URL válido para o aplicativo receptor e definir as informações e a estrutura dos dados que serão enviados. Além disso, a segurança é uma consideração importante ao trabalhar com webhooks, e muitas vezes são usados mecanismos de autenticação, como tokens ou chaves, para garantir que apenas solicitações legítimas sejam processadas. Como otimizar implementações de nossas APIS utilizando o WEBHOOK? Em nossas API's contamos com disparos de WEBHOOK's para notificação de atualizações de status nos documentos de COBRANÇA, PAGAMENTOS e PIX, sendo assim desnecessário a consulta da base completa do cliente para buscar atualizações. Bastando assim apenas a Software House configurar uma URL de recebimento e caso necessário HEADERS para autenticação então enviaremos uma requisição HTTP POST com os dados necessários para atualização de dados, minimizando assim o uso de infra com consultas e ajudando na performance do sistema.
  11. API Pix TECNOSPEED A API Pix da TecnoSpeed é uma solução desenvolvida para permitir que os desenvolvedores integrem pagamentos via PIX em suas tecnologias. Com a nossa API, é possível implementar o PIX de forma fácil e segura, personalizando a tela de pagamento e garantindo a confiabilidade das transações. Uma das principais vantagens da API é a facilidade de integração. Com uma documentação completa, é possível implementá-la rapidamente. Além disso, a TecnoSpeed oferece suporte técnico especializado, garantindo que os desenvolvedores tenham todo o suporte necessário durante o processo de integração. Consulta dos endpoints na API PlugPIX Uma grande fonte de dúvida entre desenvolvedores que implementam o pagamento via PIX em seus produtos é entender como funciona cada status e como mapeá-los corretamente. Segue abaixo os possíveis STATUS da cobrança via PIX: SAVED (Salvo): Quando uma transação do PIX está no status "Saved", significa que ela foi salva como uma transação em andamento, mas ainda não foi enviada para processamento. Com esta situação ainda não é possível gerar o QR Code. ACTIVE: Quando uma transação do PIX está no status "Active", significa que ela está REGISTRADA e disponível para pagamento. LIQUIDATED: O status "Liquidated" indica que a transação do PIX foi concluída com sucesso. Isso significa que o valor foi transferido da conta do pagador para a conta do recebedor de forma instantânea e a operação foi finalizada com sucesso. REJECTED: Quando uma transação do PIX é marcada como "Rejected", significa que ela foi recusada e não pôde ser processada. Isso pode ocorrer por diversos motivos, como dados inválidos da transação e questões técnicas no processamento. USER_REMOVED: O status "User Removed" ocorre quando uma transação do PIX não pode ser concluída porque um dos usuários envolvidos foi removido do sistema. PSP_REMOVED: O status "PSP Removed" indica que uma Cobrança removida pelo PSP(Prestador de Serviço de Pagamento), motivado por suspeita de fraude ou outros critérios não informados. EXPIRED: Uma transação do PIX pode expirar se não for concluída dentro de um determinado período de tempo. Esse status ocorre quando o pagamento não é aceito ou processado pelo recebedor dentro do prazo estabelecido. Tendo o entendimento de quais situações são retornadas os status acima, passamos a fase de como obter os status das cobranças, em nossa API PlugPIX centralizamos a consulta dos STATUS em dois end-points distintos que são /pix para consulta unitária utilizando o id da cobrança como parâmetro de busca, conforme exemplo abaixo: E também existe o segundo end-point /pix/query complementar ao anterior onde é possível listar todos as cobranças geradas com base em filtros pré definidos que são: date,betweenDateStart/betweenDateEnd, status, payerCpfCnpj, emv bem como parâmetros de ordenação e paginação, segue exemplo abaixo: Neste endpoint será retornado a listagem de id’s para posterior consulta no end-point /pix. Notificação via WEBHOOK Nossos produtos contam com notificações via WEBHOOK para otimização da automação em seu sistema onde após configurar um servidor de recebimento de WEBHOOK notificaremos instantâneamente a atualização de status das cobranças para melhor visualização abaixo de seu funcionamento segue exemplos de notificações via WEBHOOK. Disparado quando identificamos que um PIX foi gerado com sucesso: {"event": "PIX_SUCCESSFUL","id": "290a8557-35fa-4f14-860b-fbc0eb897e63","tags": ['tag 1', 'tag 2']} Disparado quando identificamos que um PIX foi pago: {"event": "PIX_PAID","id": "290a8557-35fa-4f14-860b-fbc0eb897e63","tags": ['tag 1', 'tag 2']} Disparado quando identificamos que um PIX foi rejeitado pelo banco: {"event": "PIX_BANK_REJECTED","id": "290a8557-35fa-4f14-860b-fbc0eb897e63","tags": ['tag 1', 'tag 2']} Disparado quando identificamos que um pagamento de PIX está sendo processado (Somente para banco Tecnopay): {"event": "PAYMENT_PROCESSING","id": "290a8557-35fa-4f14-860b-fbc0eb897e63"} Disparado quando identificamos que um pagamento de PIX falhou (Somente para banco Tecnopay): {"event": "PAYMENT_FAILED","id": "290a8557-35fa-4f14-860b-fbc0eb897e63"} Disparado quando identificamos que um pagamento de PIX foi atualizado (Somente para banco Tecnopay): {"event": "PAYMENT_UPDATED","id": "290a8557-35fa-4f14-860b-fbc0eb897e63"} Onde saber mais sobre desenvolvimento Pix? Se você tem curiosidade em saber mais sobre as novidades do Pix que estão ativas, ou as que estão em testes e ainda estão por vir, que tal dar o play no vídeo abaixo e acompanhar todo o conteúdo específico para desenvolvedores que rolou no Guia da Software House 2023? https://www.youtube.com/watch?v=2T4M_ci9dzo&t=329s No Webinar exibido no vídeo acima, você terá explicações muito claras e concisas sobre os meios de pagamento, com destaque para o QRCode Pix, boleto híbrido e a Tecnologia ITP, proveniente do pix e que irá trazer um futuro para as transações digitais. [Quero conhecer a API Pix] A API Pix da TecnoSpeed oferece segurança e confiabilidade nas transações, já que a TecnoSpeed é uma empresa reconhecida no mercado de tecnologia, com anos de experiência em soluções de pagamentos eletrônicos. Investir nessa solução é uma excelente opção para oferecer aos seus clientes uma forma rápida, segura e eficiente de realizar pagamentos via PIX, garantindo a satisfação e fidelizando cada vez mais a sua carteira de clientes.
  12. Olá desenvolvedor. Hoje abordaremos um assunto que em teoria parece ser simples porém ainda gera bastante duvida no momento da integração inicial de uma API ou sistemas de gerenciamento em geral que são as diferenças entre ambientes de SANDBOX e HOMOLOGAÇÃO. Quando se trabalha com integração de sistemas por meio de APIs (Application Programming Interfaces), é comum encontrar termos como "ambiente sandbox" e "homologação". Embora ambos estejam relacionados à etapa de testes e validação de uma API, cada um desempenha um papel distinto. Neste texto, vamos explorar as diferenças entre esses dois ambientes, destacando suas características e propósitos. Ambiente Sandbox O ambiente sandbox é um ambiente de teste isolado e simulado, projetado para permitir que desenvolvedores realizem experimentos, verifiquem o funcionamento de uma API e criem aplicações sem afetar o ambiente de produção. Algumas características do ambiente sandbox incluem: Simulação de ambiente de produção: O ambiente sandbox simula o comportamento da API em um ambiente controlado, permitindo que os desenvolvedores testem diferentes cenários sem riscos. O ambiente sandbox geralmente opera com dados fictícios ou de teste, garantindo que informações confidenciais ou reais não sejam expostas durante os testes. Ambiente de Homologação O ambiente de homologação, por sua vez, é uma etapa mais avançada na validação de uma API. Ele tem como objetivo garantir que a API esteja pronta para ser integrada ao ambiente de produção, avaliando sua funcionalidade e desempenho em condições reais. As principais características do ambiente de homologação incluem: Replica o ambiente de produção: O ambiente de homologação é configurado de forma semelhante ao ambiente de produção, incluindo infraestrutura, configurações e dados reais (ou pelo menos dados de teste realistas). Testes de integração: Nesse ambiente, são realizados testes de integração mais abrangentes, nos quais a API é testada quanto à sua interoperabilidade com outros sistemas, segurança, escalabilidade e conformidade com os requisitos técnicos. Validação de requisitos: Durante a homologação, a API é avaliada em relação aos requisitos estabelecidos, como especificações funcionais, desempenho esperado e conformidade com padrões e protocolos específicos. Em resumo, o ambiente sandbox é um ambiente de teste isolado e simulado, onde desenvolvedores podem experimentar e verificar o funcionamento básico de uma API, enquanto o ambiente de homologação é uma etapa mais avançada, onde a API é validada em relação a requisitos específicos e testada em condições próximas às do ambiente de produção. Como trabalhamos com os ambientes nos produtos Plugbank? Em nossos produtos PLUGBOLETO e PAGAMENTOS optamos por trabalhar apenas com ambiente de HOMOLOGAÇÃO para testes de integração, portanto as respostas de requisições são devolvidas considerando os dados "reais" previamente cadastrados em nosso banco de dados, já no PLUGPIX disponibilizamos apenas o ambiente de SANDBOX onde as requisições são respondidas com dados fictícios para validação de estruturas de resposta e comportamento da API.
  13. Ola, o erro 403 aconteceu por falta de credenciais ativas para o disparo da requisição.
  14. Bom dia Ernadnes! O certificado utilizado pelo banco itau não é o A1 tradicional para emissão de NF-e, é um certificado gerado direto com o banco a partir de uma chave publica conforme o procedimento desta doc Att.
  15. Olá desenvolvedor! Hoje conversaremos a respeito da mensagem de erro “Payload Too Large” que acontece no momento de enviar uma requisição HTTP/HTTPS para o servidor de recebimento. Mensagem de erro: A mensagem de erro “Payload Too Large”, que pode sofrer variações como por exemplo “Request Entity Too Large” acontece quando a requisição enviada, geralmente uma requisição GET, extrapola o limite máximo de caracteres em sua chamada, ou seja, quando a querystring fica muito grande, o tamanho maximo é de 2.083 caracteres. Como corrigir: Para corrigir o erro acima basta diminuir o tamanho da queryString, para que a chamada da requisição HTTP fique com um tamanho menor. Como corrigir nas soluções Tecnospeed: Na API de Boletos este erro pode ocorre por exemplo, quando é utilizada a rota de consulta dos boletos (rota GET), e nela é informado um número muito grande de idIntegracao (boletos a consultar). Isso faz com que a requisição fique demasiadamente grande, e o erro ocorra devido a uma limitação do próprio Node.js, que possui um limite máximo para o tamanho das requisições. Para corrigir, conforme citado, basta dividir a chamada em 2 ou mais requisições separadas. Caso tenha qualquer dúvida sobre os pontos que explicamos ou queira conhecer nossas soluções voltadas a automatização na geração de boletos, entre em contato conosco, será um prazer ajudar!
×
×
  • Create New...