1 - Introdução
Bem-vindo ao guia do Pix Automático, exploraremos a funcionalidades no cenário do Open Finance Brasil. Este guia auxiliará os implementadores a compreenderem as funcionalidades de criação do consentimento com pagamento imediato, sem o pagamento imediato e com agendamento do pagamento no momento da contratação do serviço. Para o processo de liquidação dos pagamentos, abordaremos o funcionamento da primeira ordem de pagamento de um ciclo de cobrança e quando houver a situação de falha do pagamento, também há uma seção sobre as tentativas que podem ser realizadas pelo recebedor em casos de falha da tentativa original de pagamento.
...
Essa funcionalidade está presente na API de pagamentos automáticos, a partir de sua versão 2.0.0. O link para a API pode ser encontrado abaixo.
2 - Regras de negócios para Pix Automático no OFB
No quadro abaixo podemos observar as regras de negócio definidas para o produto Pix Automático no âmbito do Open Finance.
Cenários | Pix Automático |
|---|---|
Casos de uso | Utilities/serviços públicos, assinaturas, escolas, academias, aluguel, seguros, cobranças de pagamento de operação de crédito |
Configurações de recorrência | |
Motor de recorrência | Criação de um consentimento para recorrência com limites de valores e prazos, e definição de periodicidade |
Valor | Fixo ou variável |
Modelo de recorrência, intervalos de pagamentos | Semanal, mensal, trimestral, semestral e anual |
Gestão da Agenda | Compartilhada: Iniciador tem visibilidade completa, PSP pagador tem visibilidade com antecedência de 2 a 10 dias das próximas incidências |
Comanda o pagamento | Iniciador |
Recebedor | PJ |
Primeiro pagamento | Imediato ou Agendado |
Demais pagamentos | Agendado |
Permite pagamentos imediatos | Sim, para adesão |
Definição do final do período da recorrência | Opcional |
Prazo máximo de duração para recorrência do consentimento | Opcional |
Permite a configurar data de início do consentimento? | Sim |
Permite a configurar data de expiração do consentimento? | Sim |
Permite limites globais do consentimento?¹ | Não |
Permite limites periódicos por consentimento? | Sim, uma transação liquidada com sucesso por período de recorrência. |
Permite limites por transação? | Sim. Recebedor pode definir valor mínimo. Pagador pode definir um valor máximo. O valor definido pelo Pagador não pode ser menor que o valor definido pelo Recebedor. |
Processo de adesão | |
Fluxo de adesão | Consentimento FAPI long-lived tokens |
Role no diretório | CONTA, PAGTO |
Será possível editar configurações de recorrência no processo de adesão no Detentor? | Não |
Cancelamento do fluxo da adesão | Via Iniciador ou Detentor |
Permite múltiplas alçadas? | Sim |
Iniciador terá acesso aos status do processo de adesão via Webhook? | Sim |
Adesão tem id de contrato? | Sim |
Gestão de adesão | |
Permite edição técnica dos dados do consentimento pós adesão²? | Sim, verificar no /wiki/spaces/~63778624fde064eda2ecf538/pages/540220558 link |
Cancelamento da adesão | Pelo pagador, no ambiente da iniciadora ou detentora. Recebedor pode acionar o Iniciador para o cancelamento. |
Revogação da adesão | Iniciador ou Detentor poderão revogar a adesão por motivos de fraude |
Consumação³ da adesão? | Detentor, apenas para recorrências com data de expiração definidas. |
Processo de liquidação | |
Canal para liquidação | Serão utilizados os canais primário e secundário (obedecendo as regras da trilha Pix). Quem deverá criar o E2EID com a data da liquidação é o Iniciador. |
Dispara o pagamento⁴ | Detentor |
Onde o cliente cancela o pagamento? | Iniciadora ou Detentora |
Erros de saldo insuficiente modificam o status do consentimento? | Se pagamento imediato falhar, simnão. |
Listagem das informações do pagamento | Busca por id do consentimento |
Iniciador é responsável pelo envio da ocorrência do pagamento? | Sim, no prazo de 2 a 10 dias anteriores a data de vencimento da cobrança |
Quem avisa o pagador sobre pagamento com falha? | Iniciador e Detentor¹. Detentor deverá notificar o iniciador e o iniciador decidir se e como notificar o pagador |
Responsável pela geração do endToEndId | Iniciador |
Podem ocorrer liquidação em dias não úteis? | Sim, em casos em que a data de vencimento ocorra durante finais de semana, feriados e dias inexistentes(29, 30, 31), a data pode ser alterada, a critério do recebedor, para o dia útil seguinte. |
Qual é o localInstrument utilizado na liquidação? | MANU |
Outras informações | |
É possível habilitar crédito? | Seguir a regra do arranjo. Habilitar na detentora no momento da adesão do consentimento. Na confirmação do consentimento é necessário um aviso ao cliente que o uso de linha de crédito pré-aprovada na instituição detentora de conta está habilitado e poderá ser alterado na detentora em ambiente de gestão do Pix Automático. |
Tentativas para pagamentos que falharam
| Detentor realiza primeira tentativa das 0h – 8h. Segunda tentativa entre 18h – 21h. Caso de falha, recebedor pode solicitar ao iniciador envio de novas tentativas (contando que o pagador tenha aceito e o motivo do erro permita). Novas tentativas de liquidação devem ocorrer em até 7 dias corridos após a primeira tentativa. São permitidas no máximo 3 retentativas, totalizando 4 tentativas de liquidação para um mesmo pagamento. Iniciador deve informar ao detentor que o recebedor deseja ativar as retentativas, pagador deve autorizar em momento de consentimento. |
Funcionalidade de contestação | Contestação está disponível no arranjo Pix automático, conforme pode ser visto na Página 84, Requisito 4, Requisitos Mínimos para Experiencia do Usuário, versão 7.0 |
Legenda
1 - Limite específico para um determinado consentimento, por exemplo, limite de R$100 por dia (periódico) ou R$300 para o intervalo do consentimento (global)
2 - O GT questionou o BC sobre o comportamento esperado quando houver a edição –se o usuário deverá ser redirecionado para a detentora ou não para confirmar os novos dados do consentimento
3 - Entende-se como consumação a mudança do estado, por exemplo, após 10/10 parcelas o estado será alterado de aprovado para consumido
4 - Responsável por garantir que no momento do agendamento a liquidação ocorra
5 - GT está avaliando se existe alguma normativa que obrigue uma das partes avisar ao pagador
3 - Descrição de fluxos
3.1- Para criação do consentimento:
Diferente dos pagamentos realizados via agendamento recorrente ou pagamentos imediatos, o Pix Automático possui consentimentos de longa duração, os quais poderão ser editados ao longo da sua vida útil. Entraremos mais no detalhe do processo de criação do consentimento a seguir.
3.1.1 - Jornada 1 - Fluxo da criação do consentimento sem pagamento de adesão
ID | CAMADA | TIPO | DESCRIÇÃO |
|---|---|---|---|
1 | Usuário Pagador | Ação | Pagador acessa ambiente do recebedor e manifesta a intenção de contratar um dos serviços ofertados. |
2 | Usuário Pagador | Ação | Em ambiente do Recebedor: Pagador seleciona Pix Automático via Open Finance como forma de pagamento pelo serviço. |
3 | Usuário Pagador | Ação | Em ambiente do Recebedor: Pagador informa seus dados de pagamento e, opcionalmente, configura parâmetros de limite para a transação. |
4 | Usuário Pagador | Comunicação | Em ambiente do Recebedor: Dados são repassados ao Iniciador. |
5 | Iniciador | Comunicação | Recebe os dados enviados do Recebedor e inicia o processo de criação do consentimento. |
6 | Iniciador | Ação | Valida as informações recebidas do Recebedor. |
7 | Iniciador | Comunicação | Solicita ao Detentor o access_token para a criação do consentimento. |
8 | PSP Pagador (Detentor) | Comunicação | Recebe a solicitação de criação de access_token para criação de consentimento de longa duração enviada pelo Iniciador. |
9 | PSP Pagador (Detentor) | Ação | Processa a solicitação de access_token para criação de consentimento de longa duração enviada pelo Iniciador. |
10 | PSP Pagador (Detentor) | Comunicação | Retorna ao Iniciador o access_token solicitado. |
11 | Iniciador | Comunicação | Recebe o access_token enviado pelo Detentor. |
12 | Iniciador | Ação | Iniciador prepara o payload de envio do consentimento de longa duração atentando-se ao produto para o qual este consentimento está sendo criado. |
13 | Iniciador | Comunicação | Envia solicitação de criação de consentimento de longa duração para o Detentor. |
14 | PSP Pagador (Detentor) | Comunicação | Recebe a solicitação de criação de consentimento de longa duração enviada pelo Iniciador. |
15 | PSP Pagador (Detentor) | Ação | Processa a solicitação de consentimento de longa duração. |
16 | PSP Pagador (Detentor) | Comunicação | Retorna sucesso na criação do consentimento de longa duração para o Iniciador junto a URL de redirecionamento. |
17 | Iniciador | Comunicação | Recebe o sucesso na criação do consentimento de longa duração e URL de redirecionamento. |
18 | Iniciador | Ação | Processa o retorno da solicitação de criação do consentimento de longa duração. |
19 | Iniciador | Comunicação | Redireciona o pagador para autenticação no Detentor. |
20 | Usuário Pagador | Ação | Em ambiente do PSP Pagador: Realiza a autenticação. |
21 | Usuário Pagador | Ação | Em ambiente do PSP Pagador: Autoriza o consentimento. |
22 | Usuário Pagador | Ação | Em ambiente do PSP Pagador: PSP Pagador muda o consentimento para o status AUTHORISED. |
23 | Usuário Pagador | Ação | Em ambiente do PSP Pagador: PSP Pagador notifica os demais aprovadores solicitando a aprovação em caso de múltiplas alçadas. |
24 | Usuário Pagador | Comunicação | Redireciona o usuário para a aplicação do Iniciador. |
25 | Iniciador | Comunicação | Recebe informações do redirecionamento. |
26 | Iniciador | Ação | Valida informações recebidas. |
27 | Iniciador | Ação | Consulta status do consentimento. |
28 | Iniciador | Comunicação | Notifica o recebedor do sucesso na adesão. |
29 | PSP Recebedor | Comunicação | Recebe notificação do sucesso da adesão. |
30 | PSP Pagador (Detentor) | Comunicação | Notifica o pagador do sucesso na adesão. |
31 | Usuário Pagador | Comunicação | Recebe a notificação de sucesso. |
3.1.2 - Jornada 2 - Fluxo da criação do consentimento com pagamento imediato da adesão
ID | CAMADA | TIPO | DESCRIÇÃO | ||||||
|---|---|---|---|---|---|---|---|---|---|
1 | Usuário Pagador | Ação | Pagador acessa ambiente do recebedor e manifesta a intenção de contratar um dos serviços ofertados. | ||||||
2 | Usuário Pagador | Ação | Em ambiente do Recebedor: Pagador seleciona Pix Automático via Open Finance como forma de pagamento pelo serviço. | ||||||
3 | Usuário Pagador | Ação | Em ambiente do Recebedor: Pagador informa seus dados de pagamento e, opcionalmente, configura parâmetros de limite para a transação. | ||||||
4 | Usuário Pagador | Comunicação | Em ambiente do Recebedor: Dados são repassados ao Iniciador. | ||||||
5 | Iniciador | Comunicação | Recebe os dados enviados do Recebedor e inicia o processo de criação do consentimento. | ||||||
6 | Iniciador | Ação | Valida as informações recebidas do Recebedor. | ||||||
7 | Iniciador | Comunicação | Solicita ao Detentor o access_token para a criação do consentimento. | ||||||
8 | PSP Pagador (Detentor) | Comunicação | Recebe a solicitação de criação de access_token para criação de consentimento de longa duração enviada pelo Iniciador. | ||||||
9 | PSP Pagador (Detentor) | Ação | Processa a solicitação de access_token para criação de consentimento de longa duração enviada pelo Iniciador. | ||||||
10 | PSP Pagador (Detentor) | Comunicação | Retorna ao Iniciador o access_token solicitado. | ||||||
11 | Iniciador | Comunicação | Recebe o access_token enviado pelo Detentor. | ||||||
12 | Iniciador | Ação | Iniciador prepara o payload de envio do consentimento de longa duração atentando-se ao produto para o qual este consentimento está sendo criado. | ||||||
13 | Iniciador | Comunicação | Envia solicitação de criação de consentimento de longa duração para o Detentor. | ||||||
14 | PSP Pagador (Detentor) | Comunicação | Recebe a solicitação de criação de consentimento de longa duração enviada pelo Iniciador. | ||||||
15 | PSP Pagador (Detentor) | Ação | Processa a solicitação de consentimento de longa duração. | ||||||
16 | PSP Pagador (Detentor) | Comunicação | Retorna sucesso na criação do consentimento de longa duração para o Iniciador junto a URL de redirecionamento. | ||||||
17 | Iniciador | Comunicação | Recebe o sucesso na criação do consentimento de longa duração e URL de redirecionamento. | ||||||
18 | Iniciador | Ação | Processa o retorno da solicitação de criação do consentimento de longa duração. | ||||||
19 | Iniciador | Comunicação | Redireciona o pagador para autenticação no Detentor. | ||||||
20 | Usuário Pagador | Ação | Em ambiente do PSP Pagador: Realiza a autenticação. | ||||||
21 | Usuário Pagador | Ação | Em ambiente do PSP Pagador: Autoriza o consentimento. | ||||||
22 | Usuário Pagador | Ação | Em ambiente do PSP Pagador: PSP Pagador muda o consentimento para o status AUTHORISED. | ||||||
23 | Usuário Pagador | Ação | Em ambiente do PSP Pagador: PSP Pagador notifica os demais aprovadores solicitando a aprovação em caso de múltiplas alçadas. | ||||||
24 | Usuário Pagador | Comunicação | Redireciona o usuário para a aplicação do Iniciador. | ||||||
25 | Iniciador | Comunicação | Recebe informações do redirecionamento. | ||||||
26 | Iniciador | Ação | Valida informações recebidas. | ||||||
27 | Iniciador | Ação | Consulta status do consentimento. | ||||||
28 | Iniciador | Ação | Monta o payload com a ordem de pagamento que faz parte da adesão ao serviço | ||||||
29 | Iniciador | Comunicação | Envia requisição para criação da ordem de pagamento (POST /pix/recurring-payments) | ||||||
30 | PSP Pagador (Detentor) | Comunicação | Recebe solicitação para criação da ordem de pagamento | ||||||
31 | PSP Pagador (Detentor) | Ação | Valida informações recebidas (validações síncronas previstas na API) | ||||||
32 | PSP Pagador (Detentor) | Comunicação | Retorna HTTP 201 para a solicitação do Iniciador | ||||||
33 | Iniciador | Comunicação | Recebe o sucesso na criação do pagamento | ||||||
34 | Iniciador | Ação | Valida o payload recebebido | ||||||
35 | Iniciador | Ação | Loop para consulta o estado do pagamento até que o mesmo encontre-se em ACSC ou RJCT | ||||||
36 | Iniciador | Comunicação | Notifica o recebedor da falha na liquidação do pagamento imediato|||||||
37 | Recebedor | Comunicação | Recebe notificação sobre a falha na liquidação do pagamento imediato | ||||||
38 | Iniciador | Comunicação | Notifica o recebedor do sucesso na liquidação do pagamento imediato | ||||||
39 | Recebedor | Comunicação | Recebe notificação sobre o sucesso na liquidação do pagamento imediato | ||||||
40 | PSP Pagador (Detentor) | Ação | O pagamento representativo a adesão ao serviço não foi concluído com sucesso e o consentimento deve ser rejeitado. | 41 | PSP Pagador (Detentor) | Comunicação | Notifica o Pagador da falha na liquidação do pagamento imediato | 42 | Pagador o recebedor do resultado |
37 | Recebedor | Comunicação | Recebe a notificação sobre a falha na liquidação do pagamento imediato | 43do resultado | |||||
38 | PSP Pagador (Detentor) | Comunicação | Notifica o Pagador do sucesso na liquidação do pagamento imediato | 44 | pagador do resultado | ||||
39 | Usuário Pagador | Comunicação | Recebe a notificação sobre o sucesso na liquidação do pagamento imediatodo resultado |
3.1.3 - Jornada 3 - Fluxo da criação do consentimento com pagamento agendado da adesão
...
ID | CAMADA | TIPO | DESCRIÇÃO |
|---|---|---|---|
1 | Usuário Pagador | Ação | Pagador acessa ambiente do recebedor e manifesta a intenção de contratar um dos serviços ofertados. |
2 | Usuário Pagador | Ação | Em ambiente do Recebedor: Pagador seleciona Pix Automático via Open Finance como forma de pagamento pelo serviço. |
3 | Usuário Pagador | Ação | Em ambiente do Recebedor: Pagador informa seus dados de pagamento e, opcionalmente, configura parâmetros de limite para a transação. |
4 | Usuário Pagador | Comunicação | Em ambiente do Recebedor: Dados são repassados ao Iniciador. |
5 | Iniciador | Comunicação | Recebe os dados enviados do Recebedor e inicia o processo de criação do consentimento. |
6 | Iniciador | Ação | Valida as informações recebidas do Recebedor. |
7 | Iniciador | Comunicação | Solicita ao Detentor o access_token para a criação do consentimento. |
8 | PSP Pagador (Detentor) | Comunicação | Recebe a solicitação de criação de access_token para criação de consentimento de longa duração enviada pelo Iniciador. |
9 | PSP Pagador (Detentor) | Ação | Processa a solicitação de access_token para criação de consentimento de longa duração enviada pelo Iniciador. |
10 | PSP Pagador (Detentor) | Comunicação | Retorna ao Iniciador o access_token solicitado. |
11 | Iniciador | Comunicação | Recebe o access_token enviado pelo Detentor. |
12 | Iniciador | Ação | Iniciador prepara o payload de envio do consentimento de longa duração atentando-se ao produto para o qual este consentimento está sendo criado. |
13 | Iniciador | Comunicação | Envia solicitação de criação de consentimento de longa duração para o Detentor. |
14 | PSP Pagador (Detentor) | Comunicação | Recebe a solicitação de criação de consentimento de longa duração enviada pelo Iniciador. |
15 | PSP Pagador (Detentor) | Ação | Processa a solicitação de consentimento de longa duração. |
16 | PSP Pagador (Detentor) | Comunicação | Retorna sucesso na criação do consentimento de longa duração para o Iniciador junto a URL de redirecionamento. |
17 | Iniciador | Comunicação | Recebe o sucesso na criação do consentimento de longa duração e URL de redirecionamento. |
18 | Iniciador | Ação | Processa o retorno da solicitação de criação do consentimento de longa duração. |
19 | Iniciador | Comunicação | Redireciona o pagador para autenticação no Detentor. |
20 | Usuário Pagador | Ação | Em ambiente do PSP Pagador: Realiza a autenticação. |
21 | Usuário Pagador | Ação | Em ambiente do PSP Pagador: Autoriza o consentimento. |
22 | Usuário Pagador | Ação | Em ambiente do PSP Pagador: PSP Pagador muda o consentimento para o status AUTHORISED. |
23 | Usuário Pagador | Ação | Em ambiente do PSP Pagador: PSP Pagador notifica os demais aprovadores solicitando a aprovação em caso de múltiplas alçadas. |
24 | Usuário Pagador | Comunicação | Redireciona o usuário para a aplicação do Iniciador. |
25 | Iniciador | Comunicação | Recebe informações do redirecionamento. |
26 | Iniciador | Ação | Valida informações recebidas. |
27 | Iniciador | Ação | Consulta status do consentimento até que ele esteja em AUTHORISED, alternativamente, o ITP pode aguardar notificação de mudança de estado via Webhook e realizar a consulta posteriormente. |
28 | Iniciador | Ação | Cria a solicitação de pagamento agendada. A data da solicitação deve ser a mesma enviada dentro do objeto referente ao primeiro pagamento, presente na estrutura de consentimento para Pix Automático. Outras validações se aplicam e podem ser encontradas na especificação. |
29 | Iniciador | Comunicação | Envia a requisição com solicitação de pagamento para o PSP Pagador (Detentor). |
30 | PSP Pagador (Detentor) | Comunicação | Recebe a requisição com solicitação de pagamento. |
31 | PSP Pagador (Detentor) | Ação | Realiza as validações síncronas no pagamento e começa as validações assíncronas. |
32 | PSP Pagador (Detentor) | Comunicação | Retorna o sucesso (HTTP 201) para o Iniciador na criação do pagamento. |
33 | Iniciador | Comunicação | Recebe o sucesso (HTTP 201) na criação do pagamento. |
34 | Iniciador | Ação | Valida o payload de resposta, recupera o recurringPaymentId |
35 | Iniciador | Ação | Consulta status do pagamento até que ele esteja em SCHD, alternativamente, o ITP pode aguardar notificação de mudança de estado via Webhook e realizar a consulta (HTTP |
36 | Iniciador | Comunicação | Notifica o recebedor do sucesso no agendamento do pagamento |
37 | Recebedor | Comunicação | Recebe a notificação do sucesso no agendamento do pagamento |
38 | PSP Pagador (Detentor) | Comunicação | Notifica o Usuário pagador do sucesso no agendamento do pagamento |
39 | Usuário pagador | Comunicação | Recebe a notificação do sucesso no agendamento do pagamento |
3.2 - Para edição do consentimento:
Instruções recebidas na consulta pública do Pix Automático deixaram claro a necessidade de permissão da edição de alguns parâmetros do consentimento tanto no ambiente do iniciador quanto no ambiente do PSP Pagador. A edição deverá ser feita via endpoint PATCH /recurring-consents/{recurringConsentId}. As regras para edição podem ser encontradas na descrição do endpoint. Atentem que os campos que permitem edição poderão ser modificados, cabendo a cada instituições acompanhar a página referenciada na descrição do endpoint PATCH /recurring-consents/{recurringConsentId}.
3.3 - Para revogação do consentimento:
Tratando agora dos motivos de revogação, uma regra é que: Para um consentimento de longa duração ser revogado, primeiro ele precisou ser aprovado. Apenas consentimentos no status “AUTHORISED”, são passíveis de revogação, vamos trazer os motivos de revogação e como eles se aplicam.
REVOGADO_RECEBEDOR: O recebedor pode solicitar, via Iniciador, a revogação de um consentimento. Um exemplo seria o termino de um contrato de streaming, onde o provedor do serviço de streaming (recebedor) poderia solicitar a revogação quando o usuário logado em algum de seus canais solicitar o cancelamento do serviço.
REVOGADO_USUARIO: Por definição, toda primeira solicitações de cobrança de uma recorrência, no Pix Automático, precisam ser agendadas com 2 a 10 dias de antecedência e o usuário pagador pode cancelar qualquer pagamento agendado na sua conta até as 23h59 do dia anterior ao dia definido para liquidação. Sendo assim, caso um usuário solicite a revogação um consentimento e este possua um pagamento associado já agendado para ocorrer, deve-se então validar a data de solicitação da revogação e a data de liquidação do pagamento. Caso a data de revogação do consentimento seja a mesma de liquidação do pagamento, o pagamento será liquidado normalmente e o consentimento de longa duração será revogado, não permitindo novos agendamentos de cobrança e qualquer pagamento agendado para datas posteriores devem ser cancelados.
NAO_INFORMADO: Deve ser utilizado para motivos de revogação que envolvam informações que não devem ser compartilhadas no ecossistema por respeito a privacidade do usuário. Ex: Suspeita de Fraude, Bloqueio Judicial.
3.4 - Do processo de liquidação
Neste capítulo, veremos como fica o fluxo de liquidação para o Pix Automático. Serão dois fluxos, um tratando da criação do primeiro agendamento por ciclo de cobrança, enquanto o segundo tratará das novas tentativas de liquidação, caso o pagamento original do ciclo falhe.
3.4.1 - Fluxo para criação da primeira ordem de pagamento de um ciclo de cobrança
...
ID | CAMADA | TIPO | DESCRIÇÃO |
|---|---|---|---|
1 | Empresa Recebedora | Ação | Inicia processo de cobrança. |
2 | Empresa Recebedora | Ação | Busca informações de pagamento do usuário. |
3 | Empresa Recebedora | Comunicação | Envia cobrança para o Iniciador. |
4 | Iniciador | Comunicação | Recebe solicitação de cobrança. |
5 | Iniciador | Ação | Valida informações recebidas. |
6 | Iniciador | Comunicação | Envia solicitação de access_token. |
7 | PSP Pagador (Detentor) | Comunicação | Recebe solicitação de access_token. |
8 | Detentor | Ação | Processa solicitação de access_token. |
9 | Detentor | Comunicação | Retorna acess_token. |
10 | Iniciador | Comunicação | Recebe access_token. |
11 | Iniciador | Ação | Processa retorno da solicitação de access_token. |
12 | Iniciador | Ação | Cria a solicitação de pagamento. |
13 | Iniciador | Comunicação | Envia solicitação de pagamento. |
14 | PSP Pagador (Detentor) | Comunicação | Recebe solicitação de pagamento. |
15 | PSP Pagador (Detentor) | Ação | Processa a solicitação de pagamento. |
16 | PSP Pagador (Detentor) | Ação | Realiza a cobrança na conta de débito do pagador. |
17 | PSP Pagador (Detentor) | Ação | Agenda o pagamento futuro conforme solicitado. |
18 | PSP Pagador (Detentor) | Comunicação | Retorna sucesso na solicitação de pagamento e/ou agendamento de pagamento. |
19 | Iniciador | Comunicação | Recebe sucesso na solicitação de pagamento e/ou agendamento de pagamento. |
20 | Iniciador | Ação | Processa o retorno da criação de pagamento. |
21 | Iniciador | Ação | Consulta informações do pagamento. |
22 | Iniciador | Comunicação | Notifica ao recebedor sucesso na transferência. |
23 | Empresa Recebedora | Comunicação | Recebe notificação de sucesso na transferência. |
24 | Empresa Recebedora | Ação | Processamento interno do pagamento. |
25 | Empresa Recebedora | Comunicação | Notifica pagador do sucesso na transferência. |
26 | Usuário Pagador | Comunicação | Recebe notificação de sucesso na transferência. |
3.4.2 - Fluxo para criação de novas tentativas de liquidação para uma cobrança original que falhou
...
ID | CAMADA | TIPO | DESCRIÇÃO |
|---|---|---|---|
1 | Empresa Recebedora | Ação | Identifica que o pagamento original ou uma nova tentativa não foi liquidada com sucesso |
2 | Empresa Recebedora | Comunicação | Notifica o Iniciador para iniciar uma nova tentativa de pagamento para liquidação da cobrança |
3 | Iniciador | Comunicação | Recebe a notificação da Empresa Recebedora para uma nova tentativa de liquidação para a cobrança |
4 | Iniciador | Ação | Monta o payload de requisição que será repassado ao detentor. Deve ser informado, no array |
5 | Iniciador | Ação | Cria a solicitação de pagamento agendado para a nova tentativa de liquidação. |
6 | Iniciador | Comunicação | Realiza a chamada ao endpoint |
7 | PSP Pagador (Detentor) | Comunicação | Recebe a solicitação de criação de uma nova tentativa de pagamento agendado |
8 | PSP Pagador (Detentor) | Ação | Avalia as informações recebidas no payload. Deve identificar que é uma nova tentativa, uma vez que o array |
9 | PSP Pagador (Detentor) | Ação | Processa o pedido de agendamento realizando as validações assíncronas |
10 | PSP Pagador (Detentor) | Decisão | Detentor deve avaliar se o caso informado é uma tentativa intradia ou extradia. Para as tentativas intradia, além de possuir o item no array |
11 | PSP Pagador (Detentor) | Ação | Aplica as validações para pagamentos intradia |
12 | PSP Pagador (Detentor) | Ação | Aplica as validações para agendamento de pagamentos extradia |
13 | PSP Pagador (Detentor) | Ação | Cria o débito na conta do usuário pagador |
14 | PSP Pagador (Detentor) | Ação | Prepara notificação para o pagador, informando que um novo débito foi agendado na sua conta |
15 | PSP Pagador (Detentor) | Comunicação | Envia a notificação para o usuário pagador sobre o novo débito agendado na sua conta |
16 | Usuário Pagador | Comunicação | Recebe a notificação com a informação do débito agendado na sua conta |
17 | PSP Pagador (Detentor) | Comunicação | Retorna HTTP 201 de criação da ordem de pagamento ao iniciador |
18 | Iniciador | Comunicação | Recebe o sucesso na criação da nova tentativa de pagamento para a cobrança |
19 | Iniciador | Ação | Processa o retorno da solicitação, recuperando o |
20 | Iniciador | Ação | Loop para consulta do estado do pagamento na instituição detentora até que o mesmo encontre-se em SCHD |
21 | Iniciador | Ação | Pagamento encontra-se em SCHD, Iniciador prepara notificação de sucesso do agendamento para a Empresa recebedora |
22 | Iniciador | Comunicação | Envia a notificação à Empresa Recebedora com o sucesso no agendamento |
23 | Empresa Recebedora | Comunicação | Recebe a notificação de sucesso no novo agendamento e aguarda a data de liquidação prevista para validar o recebimento ou não |
24 | Iniciador | Ação | Pagamento falhou o agendamento, Iniciador prepara notificação de erro do agendamento para a Empresa recebedora |
25 | Iniciador | Comunicação | Envia a notificação à Empresa Recebedora com o falha no agendamento |
26 | Empresa Recebedora | Comunicação | Recebe a notificação de falha no novo agendamento. |
Maiores detalhes sobre o fluxo de novas tentativas para um mesmo ciclo podem ser encontrados na página <inserir_link_pagina_tentativas>. Tentativas Intradia e Extradia para Pix automático - v2.0.0-beta.1 - [SV] Pagamentos Automáticos