Procedimento Técnico de Callback
Para nós a conexão entre sistemas é primordial para garantir que a performance de nossas aplicações, entreguem o resultado pretendido pelos nossos parceiros.A implementação de Callback se torna indispensável, uma vez que possibilita uma gama de vantagens significativas.
Por meio das chamadas de call-back, é possível promover uma comunicação assertiva entre todas as áreas envolvidas no processo. Com isso não é necessário uma consulta incessante a API , por meio dos call-backs enviamos as informações, atualizações e notificações de maneira precisa. Dessa forma reduzimos o volume de requisições promovendo um fluxo mais eficiente no que diz respeito a performance do sistema em geral.
O call-back para acompanhamento dos status das propostas, deve ser enviado, tanto para o ambiente de homologação quanto para o ambiente de produção, se possível serem URLs diferentes. Esse call-back, é enviado via Query Parameter.
Métodos de autenticação aceitos pelo callback
| Autenticação | Chave | |
|---|---|---|
| Bearer Token | Authorization | Bearer <token> |
| API Key | API-Key | <sua_chave_de_api> |
| Basic Authentication | Authorization | Basic <base64_encoded_username:password> |
| X-API-Key | X-API-Key | <sua_chave_de_api> |
| Digest Authentication | Authorization | Digest <digest_hash> |
| JWT (JSON Web Token) | Authorization | Bearer <JWT_token> |
| HMAC (Hash-based Message Authentication Code) | Authorization | HMAC <hash_value> |
| OAuth Tokens | Authorization | Bearer <OAuth_token> |
| AWS Signature | Authorization | AWS <signature> |
| Client Certificates | Certificate | <client_certificate> |
Exemplo de callback de proposta
Segue exemplo de URL e como parametrizamos para recebimento: xxxxxxxxxx.com.br?proposta=&situacao=&identificador=
Sendo:
Proposta: GUID único da proposta gerado no response no momento da inclusão da proposta.
Situação: ID da situação da proposta em nosso sistema.
Identificador: Caso seja enviado, esse campo representa o código da operação enviado na inclusão da proposta.
Tabela de Ids
| ID | Descrição | Objetivo |
|---|---|---|
| 0 | Em Digitação | Proposta encontra-se em digitação |
| 1 | Em Análise | Proposta foi enviada para fila de análise |
| 2 | Aprovada | Proposta foi aprovada pela área de análise de crédito |
| 3 | Recusada | Proposta foi recusada pela área de análise de crédito |
| 4 | Cancelada | Proposta foi cancelada pela área de análise de crédito |
| 5 | Pendente | Proposta foi marcada como pendente pela área de análise de crédito, necessita de intervenção do integrador para retornar à fila de análise |
| 6 | Finalizada | Proposta foi finalizada |
| 7 | Conferida | Proposta foi conferida pela área de formalização |
| 8 | Liberada | Proposta foi liberada pela área de formalização para pagamento |
| 9 | Paga | Proposta foi paga pela área financeira |
| 10 | Cedida | Proposta foi cedida ao fundo |
| 11 | Pendente Pagamento | Proposta foi marcada como pendente de pagamento devido à inconsistência em dados bancários, necessita intervenção do integrador para informar os dados corretos de pagamento e retornar para a fila de pagamento |
Observação: Além dos dados já enviados na Query (Guid da Proposta, Status e Identificador), os call-backs de Pago “9” e Pendente pagamento “11” possuem um body com o campo “Descrição da ocorrência”, que informa o motivo da pendência do pagamento quando for um status “11” e quando for status “9” retorna com o texto “Crédito ou débito efetivado”. Segue abaixo exemplos de retorno:
Status 09:
Status 11:
Considerações Finais
Recomenda-se que o endpoint configurado para receber os callbacks funcione principalmente como um repositório, minimizando o processamento no momento da recepção para evitar atrasos. Implementar processos complexos durante o recebimento dos callbacks pode resultar em timeouts e falhas na comunicação, comprometendo a eficiência do sistema. Opte por processar as mensagens recebidas de forma assíncrona para melhorar a performance e confiabilidade do seu sistema de callbacks.
Esta página foi útil?