Pular para o conteúdo principal

Notificações

Saiba mais sobre como funciona o sistema de Notificações da Efí


Recebendo as notificações​

As notificações permitem que você receba informações quando o status de uma transação for alterado, como quando um boleto for pago, por exemplo.

Quando uma transação possui uma URL de notificação cadastrada (atributo notification_url), a Efí dispara um POST para esta URL a cada mudança no status da cobrança. Essa notificação possui um token específico, que será o mesmo durante todo o "ciclo de alterações" da transação. Por exemplo:

  • Foi gerada uma cobrança. Seu sistema recebe um POST da Efí contendo o token de notificação 09027955-5e06-4ff0-a9c7-46b47b8f1b27 e informando o status da transação - neste caso, new;

  • Essa mesma cobrança teve o método de pagamento definido, então seu status mudou para waiting e, em seguida, enviaremos uma nova notificação para seu sistema contendo o mesmo token 09027955-5e06-4ff0-a9c7-46b47b8f1b27;

  • Posteriormente, essa mesma cobrança teve o pagamento confirmado, então, o status muda para paid e novamente seu sistema recebe uma notificação, ainda com o mesmo token 09027955-5e06-4ff0-a9c7-46b47b8f1b27.

banner

Exemplo de como simular a requisição de envio do token via Postman

Um POST vai conter apenas uma informação: um token de notificação. Esse token é enviado quando ocorre uma alteração no status da cobrança. Para receber essas notificações, você precisa cadastrar uma URL de notificação na cobrança e prepará-la para ler o token na variável $_POST['notification'].

Por segurança, as informações da transação serão enviadas somente quando seu sistema consultá-las utilizando o token de notificação recebido.

A qualquer momento que o integrador consultar esse token de notificação, irá obter as informações mais atuais da cobrança, todas ordenadas de acordo com os acontecimentos. Toda alteração em status gera uma notificação.

Na aba Histórico de Notificações é possível acompanhar todos os POST de notificação enviados pelo nosso sistema. Quando a pessoa integradora consulta o token enviado, consideramos que a notificação foi recebida com sucesso. Caso não seja consultado, tentaremos enviar novamente a notificação.

Para obter detalhes sobre a implementação e os procedimentos necessários, você pode encontrar mais informações em nossa documentação e instalar uma de nossas bibliotecas em seu servidor para executar os códigos de exemplo.


Definindo a URL para recebimento de notificações​

Você poderá definir uma URL que receberá as notificações durante a criação da cobrança (createCharge) ou posteriormente (updateChargeMetadata).

Uma transação gerada por meio da API pode passar por diversas alterações de status conforme interações do pagador, da pessoa integradora ou das operadoras e instituições bancárias envolvidas. Para acompanhar essas mudanças, é necessário preparar seu sistema para receber as notificações enviadas pela Efí.

Ao definir os parâmetros para a criação da transação, você pode informar uma URL de notificação. Essa URL receberá um token sempre que ocorrer uma alteração de status na transação. Com esse token, sua aplicação poderá consultar nosso webservice para obter o status atualizado da transação.

$options = [
  'client_id' => $clientId,
  'client_secret' => $clientSecret,
  'sandbox' => true
],

$metadata = array('notification_url'=>'http://sua_url_aqui');

$body = [
  'items' => $items,
  'metadata' => $metadata
];

try {
  $api = new Efí($options);
  $charge = $api->createCharge([], $body);
}

DICA PARA TESTAR AS NOTIFICAÇÕES (CALLBACKS) FACILMENTE COM O WEBHOOKINBOX

Para testar as notificações, sugerimos a utilização do WebhookInbox, um serviço gratuito para inspecionar requisições HTTP. Com ele, você pode criar uma URL temporária para utilizar no atributo notification_url, permitindo visualizar de forma fácil e amigável os POSTs enviados para sua aplicação. Para gerar a URL de recebimento da requisição, basta acessar o WebhookInbox e clicar em Create An Inbox.

O WebhookInbox irá gravar as solicitações HTTP e permitir inspecioná-las para verificar Headers e Body das requisições. Dessa forma, você poderá começar a desenvolver sua integração com a Efí e testar os recursos de URL de notificação (callbacks) mesmo se ainda não tiver uma URL pública disponível.


Caso você não cadastre uma URL no momento de criação da transação, poderá fazê-lo através do método de alteração de metadata, por meio de requisição PUT para a rota /v1/charge/:id/metadata.

O processo de notificação é realizado em duas etapas para garantir a segurança dos dados informados:

  1. Na primeira etapa, seu sistema é avisado que houve uma alteração relacionada a uma transação (o webservice envia um POST com um token pra você);

  2. Na segunda etapa, seu sistema consulta - passando o token que você recebeu como parâmetro para a Efí para saber detalhes sobre essa alteração.

Consultando detalhes de uma notificação​

A Efí considera que uma notificação foi realizada com sucesso apenas após essa consulta. Enquanto seu sistema não consultar os detalhes da notificação, ele continuará sendo notificado:

<?php
 
require __DIR__.'/../../vendor/autoload.php'; // caminho relacionado a SDK
 
use Efí\Exception\EfíException;
use Efí\Efí;
 
$clientId = 'informe_seu_client_id'; // insira seu Client_Id, conforme o ambiente (Des ou Prod)
$clientSecret = 'informe_seu_client_secret'; // insira seu Client_Secret, conforme o ambiente (Des ou Prod)
 
$options = [
  'client_id' => $clientId,
  'client_secret' => $clientSecret,
  'sandbox' => true // altere conforme o ambiente (true = desenvolvimento e false = producao)
];
 
/*
* Este token será recebido em sua variável que representa os parâmetros do POST
* Ex.: $_POST['notification']
*/
$token = $_POST["notification"];
 
$params = [
  'token' => $token
];
 
try {
    $api = new Efí($options);
    $chargeNotification = $api->getNotification($params, []);
  // Para identificar o status atual da sua transação você deverá contar o número de situações contidas no array, pois a última posição guarda sempre o último status. Veja na um modelo de respostas na seção "Exemplos de respostas" abaixo.
  
  // Veja abaixo como acessar o ID e a String referente ao último status da transação.
    
    // Conta o tamanho do array data (que armazena o resultado)
    $i = count($chargeNotification["data"]);
    // Pega o último Object chargeStatus
    $ultimoStatus = $chargeNotification["data"][$i-1];
    // Acessando o array Status
    $status = $ultimoStatus["status"];
    // Obtendo o ID da transação    
    $charge_id = $ultimoStatus["identifiers"]["charge_id"];
    // Obtendo a String do status atual
    $statusAtual = $status["current"];
    
    // Com estas informações, você poderá consultar sua base de dados e atualizar o status da transação especifica, uma vez que você possui o "charge_id" e a String do STATUS
  
    echo "O id da transação é: ".$charge_id." seu novo status é: ".$statusAtual;
 
    //print_r($chargeNotification);
} catch (EfíException $e) {
    print_r($e->code);
    print_r($e->error);
    print_r($e->errorDescription);
} catch (Exception $e) {
    print_r($e->getMessage());
}

Exemplos de respostas:​

A seguir, alguns exemplos de respostas de notificações para transações, assinaturas, carnês e link de pagamento:

{
    "code": 200, // retorno HTTP "200" informando que o pedido foi bem sucedido
    "data": [
        {
            "created_at": "2022-02-20 09:12:23", // data da alteração do status do array "id 1"
            "custom_id": null,
            "id": 1, // indicador de ordem, iniciado em 1. É incrementado para cada mudança de um token de notificação. Isso é útil se você precisar manter o controle sobre qual alteração você já processou
            "identifiers": { // identificadores que representam a cobrança
                "charge_id": 24342333
            },
            "status": {
                "current": "new",
                "previous": null
            },
            "type": "charge" // tipo da cobrança que sofreu a alteração (neste caso, "charge" quer dizer que a alteração ocorreu em uma transação)
        },
        {
            "created_at": "2022-02-20 09:12:23", // data da alteração do status do array "id 2"
            "custom_id": null, // identificador da cobrança definido pelo integrador, se existir
            "id": 2,
            "identifiers": { // identificadores que representam a cobrança
                "charge_id": 24342333
            },
            "status": {
                "current": "waiting",
                "previous": "new"
            },
            "type": "charge" // tipo da cobrança que sofreu a alteração (neste caso, "charge" quer dizer que a alteração ocorreu em uma transação)
        },
        {
            "created_at": "2022-03-31 09:14:34", // data da alteração do status do array "id 3"
            "custom_id": null, // identificador da cobrança definido pelo integrador, se existir
            "id": 3,
            "identifiers": { // identificadores que representam a cobrança
                "charge_id": 24342333
            },
            "status": {
                "current": "unpaid",
                "previous": "waiting"
            },
            "type": "charge" // tipo da cobrança que sofreu a alteração (neste caso, "charge" quer dizer que a alteração ocorreu em uma transação)
        },
        {
            "created_at": "2022-04-03 07:33:30", // data da alteração do status do array "id 4"
            "custom_id": null, // identificador da cobrança definido pelo integrador, se existir
            "id": 4,
            "identifiers": { // identificadores que representam a cobrança
                "charge_id": 24342333
            },
            "received_by_bank_at": "2022-04-02", // data do pagamento da cobrança
            "status": {
                "current": "paid", // status ATUAL da transação: paid ("pago")
                "previous": "unpaid" // status ANTERIOR da transação: unpaid ("não pago")
            },
            "type": "charge", // tipo da cobrança que sofreu a alteração (neste caso, "charge" quer dizer que a alteração ocorreu em uma transação)
            "value": 6990 // valor que acompanha a alteração. Esta tag existirá quando a alteração for uma confirmação de pagamento, informando o valor pago que foi confirmado
        }
    ]
}


// Todas as transações possuem status, que representa a situação dessa transação. Confira a relação completa para tratativas em seu sistema

Relação de todos os possíveis status de transações, carnês e assinaturas

Todas as transações, carnês e assinaturas possuem status que representam suas "situações". Portanto, é importante conhecer os possíveis status na API para fornecer as devidas tratativas em seu sistema.


Ordem das notificações (callbacks)

Em resumo, a ordem das notificações sempre segue a sequência dos acontecimentos.

Por exemplo: no caso de carnês, se a parcela 1 teve seu pagamento confirmado primeiro, depois a parcela 2 e, por fim, a parcela 3. Nessa situação, teremos um array de 3 posições onde a primeira apresenta a confirmação da parcela 1, a segunda a confirmação da parcela 2 e a última a confirmação da parcela 3.

Para saber a situação mais recente da parcela, você pode percorrer o array e verificar até qual "acontecimento" foi sincronizado, pois uma notificação pode trazer 2 ou 3 atualizações, por exemplo. Portanto, não podemos presumir que a última posição do array é sempre a que precisa ser sincronizada.


Explicação dos parâmetros de resposta:​

A resposta de uma notificação será sempre um array contendo as mudanças que ocorreram em uma transação comum, assinatura, carnê, transação de assinatura ou transação de carnê nos últimos 6 meses.

Note que notificações relacionadas a assinatura e carnê podem ser acompanhadas também de alterações em suas transações (ou parcelas).

Tags de resposta
Aqui você encontra uma breve descrição sobre os atributos presentes nas notificações.



Status da fila de notificações (callback)​

A Efí notifica os sistemas integrados a cada mudança no status de uma determinada cobrança por meio de sua URL de notificação associada.

As notificações são processadas e enviadas sempre através de uma fila de envios. Caso o callback seja rejeitado pelo sistema de destino, ele automaticamente retorna para a fila e é reagendado para uma nova tentativa de entrega. Os callbacks são dinâmicos e podem ocorrer ao longo de todo o dia.

Pensando em oferecer novos meios de consultar o processamento desta fila, a Efí disponibiliza uma tela que permite consultar o status de consumo da fila de notificações (callbacks) já processados. Desta forma, caso o cliente esteja em dúvidas se um callback já foi enviado ou não, poderá acompanhar o processamento diário desta fila.

Para consultar o status e o processamento da fila, confira o status das confirmações de pagamentos - Efí.

Vídeos: Notificações​

Pensando em oferecer novos meios de transmitir informações, a Efí disponibiliza o vídeo a seguir com o objetivo de explicar, de maneira clara e objetiva, como Configurar sua URL de notificação para recebimento de callbacks.

Configurando sua URL de notificações (integração API Efí)​



Endereços IPs da Efí para entrega dos callbacks​

Algumas aplicações e serviços podem filtrar nossas comunicações por meio dos nossos endereços de IP. Por isso, recomendamos conferir através da lista dos endereços utilizados pela Efí. Confira na íntegra em nossa FAQ.

Próximos Passos​

Agora que você implementou o recurso de URL de notificação, pode conferir mais detalhes sobre como interpretar os cenários pertinentes a notificações (callbacks), como em situações em que uma cobrança em seu sistema não foi baixada, ou quando o callback foi disparado para uma URL que você definiu previamente mas que não é mais válida, entre outros casos.


Entendendo o fluxo das notificações​

Esta seção tem como objetivo apresentar o Histórico de Notificações. Este recurso está disponível na API de sua conta Efí e permite visualizar os POSTs que a Efí dispara para a URL de notificação definida pela pessoa integradora. Essas informações são enviadas em formato de POST e contêm apenas um token de notificação.

Ao concluir essa leitura, você poderá entender melhor os diferentes cenários relacionados às notificações (callbacks). Isso inclui situações em que uma cobrança em seu sistema não foi processada corretamente, ou quando o callback foi enviado para uma URL que você havia definido anteriormente, mas essa URL não é mais válida, entre outros casos.

Conhecendo mais sobre o fluxo de notificações​

O fato de receber um POST bem-sucedido (código 200) na sua URL de notificação não garante que o processo tenha sido concluído corretamente. Após receber o POST, é importante que você venha aqui e consulte as informações.

IMPORTANTE

O POST que a Efí envia para sua URL não contém as informações da cobrança, apenas o token de notificação. Todas as informações sobre a cobrança em questão serão fornecidas quando você acessar o endpoint GET /notification/:token.


Na verdade, o processo funciona como uma "via de mão dupla". Isso significa que a Efí envia um POST para a sua URL de notificação sempre que há uma mudança no status da cobrança. Em seguida, o seu sistema, com o token de notificação recebido, faz uma requisição para consumir informações através do endpoint GET /notification/:token, onde ":token" é o token de notificação contido no POST enviado.

Dessa forma, podemos considerar que:

  • Sub-aba Histórico de Notificações : indica os POSTs que a Efí dispara para a URL de notificação cadastrada.

  • Sub-aba Histórico de Requisições : ao receber com sucesso em sua URL o POST da Efí, seu sistema consultará o endpoint GET /notification/:token.

GET /v1/notification/:token
Retorna o histórico de notificações enviados a uma determinada transação.


A seguir, um JSON simples que pode ser utilizado para retornar o histórico de notificações enviadas a uma determinada transação. Além disso, é possível observar a saída prevista. Lembrando que também é preciso informar o parâmetro de entrada "token" da notificação desejada:

Parâmetro de entrada: informe o "token" da notificação desejada

Respostas

A resposta abaixo representa Sucesso(200) do consumo.

{
  "code": 200,
  "data": [
    {
      "id": 1,
      "type": "carnet",
      "custom_id": "25452545",
      "status": {
        "current": "active",
        "previous": null
      },
      "identifiers": {
        "carnet_id": 8647
      },
      "created_at": "2016-06-28 13:28:21"
    },
    {
      "id": 2,
      "type": "carnet_charge",
      "custom_id": "25452545",
      "status": {
        "current": "canceled",
        "previous": "waiting"
      },
      "identifiers": {
        "carnet_id": 8647,
        "charge_id": 70712
      },
      "created_at": "2016-06-28 14:21:37"
    }
  ]
}

O fluxo é determinado pela seguinte ordem:

  1. A Efí dispara o POST contendo o token de notificação para a URL de notificação cadastrada sempre que houver uma mudança no status da cobrança. Detalhes podem ser observados na sub-aba Histórico de Notificações;

  2. Sua URL recebeu o POST, fazendo com que seu sistema envie uma requisição GET para a rota /notification/:token, em que :token será o token de notificação que enviamos para você. Você pode visualizar esta requisição na sub-aba Histórico de Requisições.

IMPORTANTE

Se a pessoa integradora consulta o token enviado, consideramos que a notificação foi realizada com sucesso. Caso não consulte, tentamos novamente por até 3 dias.

Ou seja, se houver uma requisição ao endpoint GET /notification/:token, entendemos que você recebeu o POST com o token de notificação e que o consultou, recebendo como resposta todos os dados informativos sobre a alteração sofrida pela cobrança, como o status anterior e atual da cobrança.

Esta informação pode ser visualizada na sub-aba Histórico de Requisições, buscando pelo token de notificação em questão.


Vamos a alguns exemplos:

Exemplo 1: Notificação com "Sucesso (200)"​

Pense em um cenário em que a pessoa integradora recebeu com sucesso o POST enviado pela Efí em sua URL de notificação. Em seguida, ela consulta nosso webservice para obter o conteúdo desse token de notificação.

Para que você possa analisar, siga estes passos:

  1. Acesse a sub-aba Histórico de Notificações para ver os POSTs recebidos na sua URL de notificação;
  2. Com o token de notificação da cobrança que você deseja verificar, acesse a sub-aba Histórico de Requisições.
  3. Pesquise pelo token mencionado e, ao encontrá-lo, clique no ícone de um "olho" na última coluna.
  4. Dessa forma, você poderá visualizar todas as informações relacionadas à cobrança que o seu sistema consultou (leu)
INFORMAÇÃO

Na sub-aba Histórico de Notificações, a exibição da resposta Sucesso (200) indica apenas que o POST foi enviado com sucesso para sua URL de notificação, mas não garante que o seu sistema foi capaz de ler e gravar as informações do seu lado. Para isso, é necessário acessar a sub-aba Histórico de Requisições e localizar a linha contendo o consumo do GET /notification/:token.


Resumo das etapas seguidas:

  • Efí enviou com sucesso uma notificação (POST) para sua URL de notificação (verifique na sub-aba Histórico de Notificações);

    • Este POST contém apenas o token de notificação, que é 7dd52fed-3d0a-42c8-b3fb-fc24f1d75303;

  • Assim que a URL recebeu a notificação, seu sistema enviou uma requisição GET para a rota /notification/7dd52fed-3d0a-42c8-b3fb-fc24f1d75303 (verifique na sub-aba Histórico de Requisições);

    • Neste momento, seu sistema recebeu como resposta um JSON com todos os dados informativos sobre a alteração ocorrida na cobrança;

  • Para este exemplo, todo o fluxo foi realizado com sucesso: disparamos a notificação contendo o token de notificação e, em seguida, seu sistema consultou nosso webservice para saber (ler) as informações da referida cobrança.


Exemplo 2: Notificação com "Falha (404)"​

Pense em cenário no qual a Efí efetuou o envio do POST (notificação), mas em Histórico de Notificações está sendo exibida a resposta Falha (404).

Esta Falha (404) indica que o recurso requisitado não foi encontrado. Você deve certificar que sua URL está correta, pois tentamos entregar a notificação na URL que você nos forneceu, mas o endereço não foi localizado.

Portanto, como o seu sistema não conseguiu receber o nosso callback, você não verá o consumo do GET /notification/:token na sub-aba Histórico de Requisições.

Soluções Sugeridas:

  • Você poderá ajustar o caminho da URL no lado de seu servidor;

  • Atualizar a URL de notificação para o novo (e correto) endereço. Para isso, você poderá enviar requisições PUT para a rota adequada da API, atentando-se ao limite de até 7.500 requisições a cada 24 hs para este endpoint.

    • Após alterar a URL de notificação, vamos continuar disparando a notificação da cobrança, mas agora para a nova URL fornecida, desde que nosso primeiro envio não tenha sido há mais de 3 dias. Neste caso, você poderá reenviar os callbacks da API seguindo orientações de nossa FAQ.

Exemplo 3: Notificação com "Falha (301)" ou "Falha (302)"​

Agora, um cenário no qual a Efí efetuou o envio do POST (notificação), mas em Histórico de Notificações está sendo exibida a resposta Falha (301) ou Falha (302).

Estas situações ocorrem quando existe um redirecionamento permanente (301) ou temporário (302) em seu servidor, afetando especificamente a entrega da notificação para a URL de notificação que você definiu previamente. Alguns exemplos comuns de quando isto ocorre:

  • Você definiu sua URL de notificação como http://www.meusite.com.br, mas posteriormente instalou HTTPS/SSL em seu servidor e seu endereço ficou como https://www.meusite.com.br;

  • Sua URL de notificação era https://www.meusite.com.br, mas posteriormente você criou regras em seu servidor (via htaccess, web.config, etc) e o endereço passou a responder apenas como https://meusite.com.br.

Soluções Sugeridas:

  • Ajustar melhor a regra do redirecionamento 301 e/ou 302 em seu servidor;

  • Atualizar a URL de notificação para o novo (e correto) endereço. Para isso, você poderá enviar requisições PUT para a rota adequada da API, atentando-se ao limite de até 7.500 requisições a cada 24 hs para este endpoint.

    • Após alterar a URL de notificação, vamos continuar disparando a notificação da cobrança, mas agora para a nova URL fornecida, desde que nosso primeiro envio não tenha sido há mais de 3 dias. Neste caso, você poderá reenviar os callbacks da API seguindo orientações de nossa FAQ.

Exemplo 4: Notificação com "Falha (500)"​

Por fim, um cenário no qual a Efí efetuou o envio do POST (notificação), mas em Histórico de Notificações está sendo exibida a resposta Falha (500).

Respostas contendo Falha (500) ou 500 Internal Server Error são um status de erro HTTP que indica que o servidor encontrou uma condição inesperada e que o impediu de atender à solicitação.

O erro, no entanto, é uma mensagem genérica e abrangente que indica uma dificuldade no processamento em seu servidor e pode ocorrer por diversos fatores.

Por isso, às vezes, os arquivos de log de seu servidor podem responder com um status code 500 acompanhado de mais detalhes sobre o request para evitar que no futuro erros desse tipo possam voltar a acontecer. Por isso, é sempre de extrema importância que você veja a mensagem de erro do log de seu servidor para ajudá-lo a resolver.

A seguir, listamos as possíveis causas que você pode explorar para solucionar o erro:

  • Arquivo de configuração em seu servidor, como .htaccess, php.ini ou web.config pode conter parâmetros inválidos;

  • Bloqueio em seu servidor (rede, firewall, políticas, etc): algumas aplicações e serviços podem ter determinados filtros, por isso, assegure-se que nossos endereços IP's estejam liberados.

  • Alto consumo de recursos em seu servidor ou limite de processos: hosts compartilhados são mais suscetíveis a este tipo de situação.

  • Timeout em seu servidor.

  • Permissões incorretas no servidor em arquivos e/ou pastas.

  • Limite de memória e diretivas do PHP setadas no arquivo php.ini.

  • Conflito entre versões de PHP em seu host.

  • Possibilidade de plugins, módulos, extensões ou temas terem causado o erro por incompatibilidade ou atualizações automáticas.

Dica

Por se tratar de um erro genérico, é importante que você consulte e interprete os logs de erros do seu servidor:

  1. Apache: /var/log/apache2/error.log
  2. NGINX: /var/log/nginx/error.log

Caso não tenha acesso a tais informações, entre em contato com o seu provedor de hospedagem ou sua equipe técnica responsável pela infraestrutura de rede.


Códigos de status HTTP (2xx, 3xx, 4xx e 5xx)​

A Efí utiliza respostas HTTP para indicar sucesso ou falha nas requisições. Geralmente, você consegue visualizá-los através da sub-aba Histórico de Notificações.

Comumente, quando retornamos respostas com status 2xx significa que houve sucesso na requisição; status 3xx indicam redirecionamento; status 4xx indicam falhas no envio de dados por parte do cliente; status 5xx indicam erros internos de servidor.

Códigos de status HTTP
Descrição dos códigos HTTP das respostas mais comuns, bem como suas explicações e soluções:


NOTA

Caso se depare com algum código de resposta diferente dos citados acima, recomendamos que acesse a relação de códigos de estado HTTP da Wikipedia e confira.


Arquivos de confirmações​

A Efí, com o intuito de diversificar ainda mais suas soluções, adotou o Intercâmbio Eletrônico de Arquivos para fornecer informações referente a cobranças para clientes que não podem (ou não desejam) realizar o uso das notificações automáticas entre sistemas (callbacks através de URL de notificação).

O Arquivo de Confirmações possui todos os pagamentos confirmados da sua conta Efí, ou seja, todas as transações com o status paid (pago). O arquivo inclui transações realizadas através da integração (API) e/ou pela plataforma Efí.

IMPORTANTE:

Transações confirmadas manualmente (status settled) não serão incluídas neste arquivo.


Antes de continuar, é importante estar ciente de que esta página é de natureza técnica. Esta documentação fornece orientações técnicas sobre como utilizar os recursos dos Arquivos de Confirmações de Cobranças e estabelece as condições básicas para sua utilização.

Download do Arquivo de Confirmações​

Você pode baixar o arquivo e importá-lo em seu sistema para conciliar os boletos pagos. Para gerar o arquivo, siga as instruções a seguir:

  • Faça login em sua conta Efí e acesse Receber(Cobranças) > Automatizações > Arquivos de confirmação;

  • Selecione uma data específica para gerar um arquivo contendo as confirmações ocorridas neste dia;

  • O arquivo será gerado. Faça o download e importe-o em seu sistema.

NOTA

Certifique-se de que seu sistema esteja preparado para importar e interpretar o layout do Arquivo de Confirmações.


A seguir, o layout com a apresentação dos campos, descrição, posições iniciais e finais, tipo, tamanho e outras informações:
banner

Layout Arquivo Retorno da Efí


Exemplo de retorno do Arquivo de Confirmações:​

banner

Exemplo Arquivo de Confirmação


Requisições​

As requisições de callback aguardam uma resposta com status HTTP 2XX. Caso o servidor do cliente retorne um status diferente, a Efí fará até 10 novas tentativas de notificação. A primeira nova tentativa será feita 5 minutos após a falha do envio do callback. Persistindo o erro, as tentativas subsequentes serão enviadas em intervalos de tempo cada vez maiores, conforme mostra a tabela abaixo.

Importante!

Em casos onde o servidor do cliente retorna o status HTTP 429 (too many requests), os servidores da Efí tentarão enviar a notificação até 10 vezes também de acordo com a tabela abaixo.


N° da tentativaTempo (em minutos)
15
210
320
440
580
6160
7320
8640
91280
1052560
Última atualização em