Boas Práticas no desenvolvimento da Integração

Está página tem o intuito de apresentar dicas do Time de Integração com base em experiências prévias. Nada apresentado aqui é uma regra, apenas sugestões para que a Integração funcione de uma maneira mais otimizada e minimize erros e necessidade de suporte.

• IP Fixo e Geolocalização: Para garantir a segurança e a continuidade das integrações, orientamos que, sempre que forem utilizados serviços em nuvem, plataformas de terceiros ou datacenters que possam ter pontos de presença em países diferentes dos Estados Unidos ou Brasil, sejam adotados IPs fixos e dedicados, além de comunicar previamente esse cenário ao nosso time de integração.

  O uso de IPs dinâmicos, variáveis ou originados de países diferentes dos permitidos (EUA e Brasil) poderá resultar no bloqueio das requisições, conforme nossas políticas de segurança e geolocalização, que visam proteger nossos ambientes e nossos clientes.

• Alteração de token: A possibilidade do usuário final ou usuário do TI alterar o token deve ser considerado para que seja facilitada a alteração no caso de mudanças entre Homologação e Produção bem como mudança de CNPJ ou usuário atrelado ao token.

• Adição de token: Cada token da Integração é associado a um CNPJ, portanto em caso de empresas com múltiplos CNPJs é necessário prever a possibilidade de mais de um token ser cadastrado ou posteriormente adicionado.

• Reenvio em caso de erro na criação da cobrança ou faturamento: Em caso de falha no envio de uma cobrança (API - Enviar Cobrança) e envio de faturamento (API - Enviar Faturamento) deve haver a possibilidade do usuário reenviar a cobrança em caso de retorno de erro que indique a não criação da cobrança ou faturamento. Vale ressaltar que caso no caso do reenvio de uma cobrança já criada haverá o retorno do uuid da cobrança existente no portal Blu. Esta funcionalidade possibilita salvar o uuid que apresentou erro anteriormente e dar prosseguimento com o processo de integração.

• Múltiplos envios em caso do cobrado (lojista) não utilizar Blu: No caso do envio de uma cobrança em que o retorno é “Charged não encontrado.” não deve ser realizado o reenvio da cobrança, pois esta mensagem significa que o cobrado (lojista) não possui conta Blu. Para mapear quais cobrados (lojistas) possuem conta Blu é possível utilizar a API - Verifica Lojista/Cobrado Blu.

• Reutilização do document_number em casos de pedido cancelado ou recusado: Quando um pedido é cancelado pelo cobrado (fornecedor) ou recusado pelo cobrado (lojista) é possível envia-lo novamente com os mesmo dados originais, não sendo necessário criar um novo pedido no ERP.

• Alteração de uuid pelo usuário: Em caso de falha por parte da Blu e não retorno do uuid para o usuário na chamada, mas criação do mesmo o usuário deve ser capaz de associar o uuid ao pedido no ERP para que ele passe a ser consultado e seu status verificado.

• Teste de regra de arredondamento: Um teste importante e recomendado é validar a regra de arredondamento das parcelas do PagBlu. Vale frisar que a regra de arredondamento é igual para todos os cliente Blu e não é possível modificá-la.