Pix Automático

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.

Pix Automático

É uma solução que facilita o pagamento de cobranças recorrentes de maneira automatizada. Isso ocorre após o usuário pagador conceder permissão ao recebedor no contexto do serviço contratado. A funcionalidade possibilita que o recebedor PJ envie regularmente os detalhes das cobranças recorrentes ao PSP do Pagador. Este, por sua vez, agenda o débito e efetua a liquidação automaticamente na data programada, conforme o contrato de serviços estabelecido entre usuário pagador e recebedor. O Pix Automático tem implementação obrigatória para os detentores e oferta obrigatório para pessoas físicas, enquanto para pessoa jurídica, caso a instituição não deseje ofertar o produto, é necessário realizar o opt-out junto ao arranjo Pix.

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.

Pagamentos automáticos

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

Cenários	Pix Automático
Casos de uso (Sugestões BC)	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 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, não. Se agendamento de cobrança, nã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

3.1.1 - AdesaoPixAutomatico_corrigido_autenticacao.png

ID	CAMADA	TIPO	DESCRIÇÃ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

3.1.2 - ConsentimentoPixAutomaticoComAdesaoImediata_corrigido.png

ID	CAMADA	TIPO	DESCRIÇÃ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 do resultado
37	Recebedor	Comunicação	Recebe a notificação do resultado
38	PSP Pagador (Detentor)	Comunicação	Notifica o pagador do resultado
39	Usuário Pagador	Comunicação	Recebe a notificação do resultado

3.1.3 - Jornada 3 - Fluxo da criação do consentimento com pagamento agendado da adesão

ID	CAMADA	TIPO	DESCRIÇÃ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 `GET` com `recurringPaymentId`) posteriormente.
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

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

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 `lastRetryRecurringPaymentIds`, o identificador(`recurringPaymentId`) de cada uma das tentativas de pagamento que não foram liquidadas com sucesso.
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 `POST /pix/recurring-payments`, passando o payload montado na etapa anterior .
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 `lastRetryRecurringPaymentIds` deve estar preenchido com, no mínimo, um item. Também realiza as validações síncronas
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 `lastRetryRecurringPaymentIds`, o pagamento recebido terá a data do dia atual, do recebimento da requisição. Já as tentativas em dias diferente devem possuir a data de liquidação D+1, ou seja, além do campo `lastRetryRecurringPaymentIds` estar presente, a data de liquidação é para um dia posterior ao dia atual. Independente de ser tentativa intradia ou extradia, o detentor deverá mover o pagamento para SCHD antes de seguir as demais etapas da máquina.
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 `recurringPaymentId`
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>.