Comparação de conteúdo

Resolução Conjunta Nº 1, Versão vigente compilada (v7)

Dispõe sobre a implementação do Open Finance.

Instrução Normativa BCB Nº 512

Dispõe sobre os limites de valor para as transações no âmbito do Pix.

Instrução Normativa BCB Nº 513

Estabelece os procedimentos operacionais relativos ao Pix Automático.

Diretrizes Técnicas e Operacionais do Open Finance

Dispõe sobre procedimentos técnicos e operacionais aos quais as instituições devem adotar (Inclui orientações para reportes à PCM, o Guia De Experiencia, entre outros).

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.Não, sendo o pagamento imediato (da adesão) ou agendado (da adesão ou recorrência). Diferente do arranjo Pix, onde, em algumas das jornadas, a falha no pagamento da adesão resulta no cancelamento da autorização

Listagem das informações do pagamento

Busca por id do consentimento e por id de pagamento

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

A data do primeiro pagamento (agendado ou imediata) da contratação do serviço (adesão) pode ser posterior ou igual à data do agendamento da primeira recorrência?

Não, a data prevista para a primeira recorrência deve ser posterior (no mínimo D+1, onde D é a data de agendamento do primeiro pagamento) à data do agendamento do primeiro pagamento (adesão)A data da primeira ocorrência de um pagamento associado a um ciclo de cobrança deve ser posterior a data de liquidação do pagamento da adesão ao serviço. Em outras palavras, só pode haver cobrança de recorrência após a data de liquidação da adesão.

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

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

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.
Antes do envio o iniciador deve realizar a solicitação de token de acesso. Grant-type e scopes podem ser encontrado na especificação da API.

8

Iniciador

Comunicação

Envia solicitação de criação de consentimento de longa duração para o Detentor.

9

PSP Pagador (Detentor)

AçãoComunicação

Processa Recebe a solicitação de access_token para criação de consentimento de longa duração enviada pelo Iniciador.

10

PSP Pagador (Detentor)

Comunicação

Ação

Processa a solicitação de consentimento recorrente.

11

IniciadorPSP Pagador (Detentor)

Comunicação

Recebe o access_token enviado pelo DetentorRetorna sucesso na criação do consentimento de longa duração para o Iniciador junto a URL de redirecionamento.

12

Iniciador

AçãoComunicação

Iniciador prepara o payload de envio Recebe o sucesso na criação do consentimento de longa duração atentando-se ao produto para o qual este consentimento está sendo criadoe URL de redirecionamento.

13

Iniciador

Comunicação

Ação

Processa o retorno da solicitação de criação de do consentimento de longa duração para o Detentor.

14

PSP Pagador (Detentor)Iniciador

Comunicação

Recebe a solicitação de criação de consentimento de longa duração enviada pelo IniciadorRedireciona o pagador para autenticação no Detentor.

15

PSP Usuário Pagador (Detentor)

Ação

Processa a solicitação de consentimento de longa duraçãoEm ambiente do PSP Pagador: Realiza a autenticação.

16

PSP Usuário 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.

Ação

Em ambiente do PSP Pagador: Autoriza o consentimento.

17

Usuário Pagador

Ação

Em ambiente do PSP Pagador: PSP Pagador muda o consentimento para o status AUTHORISED.

18

Usuário Pagador

Ação

Em ambiente do PSP Pagador: Realiza a autenticação.

PSP Pagador notifica os demais aprovadores solicitando a aprovação em caso de múltiplas alçadas.

19

Usuário Pagador

AçãoComunicação

Em ambiente do PSP Pagador: Autoriza o consentimentoPSP Pagador redireciona o usuário pagador para o ambiente do Iniciador.

2220

Usuário PagadorIniciador

AçãoComunicaçã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

Recebe informações do redirecionamento.

21

Iniciador

Ação

Valida informações recebidas.

22

Iniciador

Ação

Realiza consulta ao PSP do Pagador para verificar o estado do consentimento. AUTHORISED indica que o consentimento foi autorizado pelo cliente. Porém, caso a consulta retorne o valor REJECTED, deve-se abortar o processo de consentimento e o recebedor deve ser comunicado da falha.

23

Iniciador

Comunicação

Notifica o recebedor do resultado do processo de consentimento (adesão do pagador ao serviço de cobranças recorrentes).

24

Recebedor

Comunicação

Recebe notificação do sucesso da adesão.

do resultado do processo de consentimento do pagador

25

PSP Pagador (Detentor)

ComunicaçãoAção

Notifica o pagador do sucesso na adesão.

Aguarda até que o(s) usuário pagador tenha realizado a aprovação do consentimento para notifica-lo do sucesso no processo de adesão.

26

PSP Pagador (Detentor)

Comunicação

Notifica o Pagador do resultado da adesão/consentimento

27

Usuário Pagador

Comunicação

Recebe a notificação de sucesso.notificação do resultado da adesão/consentimento

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

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.

8

Iniciador

Comunicação

Envia solicitação de criação de

consentimento de longa duração

para o Detentor (POST /consents).
Deve possuir o objeto “/data/recurringConfiguration/automatic/firstPayment” preenchido.
Antes do envio o iniciador deve realizar a solicitação de token de acesso. “Grant-type” e “scopes” podem ser encontrado na especificação da API.

9

PSP Pagador (Detentor)

Comunicação

Recebe a solicitação de criação de consentimento de longa duração enviada pelo Iniciador.

10

PSP Pagador (Detentor)

Ação

Processa a solicitação de consentimento de longa duração.

11

PSP Pagador (Detentor)

Comunicação

Retorna sucesso na criação do consentimento de longa duração para o Iniciador junto a URL de redirecionamento.

12

Iniciador

Comunicação

Recebe o sucesso na criação do consentimento de longa duração

e URL de redirecionamento.

13

Iniciador

Ação

Processa o retorno da solicitação de criação

do consentimento de longa duração

.

14

Iniciador

Comunicação

Redireciona o pagador para autenticação no Detentor.

15

Usuário Pagador

Ação

Em ambiente do PSP Pagador: Realiza a autenticação.

16

Usuário Pagador

Ação

Em ambiente do PSP Pagador: Autoriza o consentimento. É vetada a edição dos dados da recorrência pelo usuário pagador. Os dados que podem ser editados durante a autorização podem ser encontrados no guia de experiência do usuário do Open Finance Brasil

17

Usuário Pagador

Ação

Em ambiente do PSP Pagador:

PSP Pagador muda o consentimento para o status AUTHORISED.

18

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.

19

Usuário Pagador

Comunicação

Em ambiente do PSP Pagador: PSP Pagador redireciona o usuário

pagador ambiente do Iniciador.

20

Iniciador

Comunicação

Recebe informações do redirecionamento.

21

Iniciador

Ação

Valida informações recebidas.

22

Iniciador

Ação

Realiza consulta ao PSP do Pagador para verificar o estado do consentimento. AUTHORISED indica que o consentimento foi autorizado pelo cliente. Porém, caso a consulta retorne o valor REJECTED, deve-se abortar o processo de consentimento e o recebedor deve ser comunicado da falha.

23

Iniciador

Ação

Monta o payload com a ordem de pagamento que faz parte da adesão ao serviço

. O payload deve conter os dados do pagamento da adesão dentro do objeto “/data/recurringConfiguration/automatic/firstPayment”. A conta de crédito informada neste objeto etapa deverá ser a mesma utilizada durante a criação do pagamento referente a adesão. A consistência de titularidade será realizada pelo arranjo Pix, exceto para os casos em que o PSP do Pagador e PSP do recebedor sejam a mesma instituição.

24

Iniciador

Comunicação

Envia requisição para criação da ordem de pagamento

(POST /pix/recurring-payments)

25

PSP Pagador (Detentor)

Comunicação

Recebe solicitação para criação da ordem de pagamento

26

PSP Pagador (Detentor)

Ação

Valida solicitação de pagamento recebida pelo Iniciador.

27

PSP Pagador (Detentor)

Ação

Cria a solicitação de pagamento conforme solicitado pelo Iniciador e autorizado pelo usuário pagador durante o processo de autorização do consentimento recorrente.

28

PSP Pagador (Detentor)

Comunicação

Retorna o resultado da solicitação de pagamento imediato/agendado para o Iniciador

29

Iniciador

Comunicação

Recebe o sucesso na criação do pagamento

30

Iniciador

Comunicação

Notifica o recebedor do resultado

31

Recebedor

Comunicação

Recebe a notificação do resultado

. Caso o resultado não atenda as expectativas para o serviço sendo contratado, o recebedor pode solicitar o cancelamento do pagamento agendado (quando aplicável) e/ou a revogação do consentimento.

32

PSP Pagador (Detentor)

Comunicação

Notifica o pagador do resultado

. Se for um pagamento imediato, deve ser informado o resultado da tentativa de liquidação. Caso seja agendado, deve-se notificar sobre o agendamento. Independente do resultado do pagamento imediato ou da solicitação de agendamento, o consentimento não deve ser revogado pelo PSP do Pagador.

33

Usuário Pagador

Comunicação

Recebe a notificação do resultado

1

Empresa Recebedora

Ação

Inicia processo de cobrança.

2

Empresa Recebedora

Ação

Busca informações de pagamento do usuário dentro da sua base.

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

Ação

Cria a solicitação de pagamento.

7

Iniciador

Comunicação

Envia solicitação de pagamento.

8

PSP Pagador (Detentor)

Comunicação

Recebe solicitação de pagamento.

9

PSP Pagador (Detentor)

Ação

Processa a solicitação de pagamento.

10

PSP Pagador (Detentor)

Ação

Agenda o pagamento futuro conforme solicitado. Deve validar as regras aplicáveis para primeira tentativa de um ciclo, como, por exemplo, o prazo mínimo de agendamento, 10 a 2 dias de antecedência, conforme IN BCB 513.

11

PSP Pagador (Detentor)

Comunicação

Retorna sucesso na solicitação de agendamento de pagamento.

12

Iniciador

Comunicação

Recebe sucesso na solicitação de agendamento de pagamento.

13

Iniciador

Ação

Processa o retorno da criação de pagamento.

14

Iniciador

Ação

Consulta informações do pagamento até que ele esteja no status ACSC. Consideramos aqui o sucesso do pagamento como o estado objetivo de finalização da operação de pagamento. Caso deseje notificar o sucesso do agendamento, o Iniciador pode considerar o estado SCHD e proceder com a notificação junto ao recebedor.

15

Iniciador

Comunicação

Notifica ao recebedor sucesso no pagamento.

16

Empresa Recebedora

Comunicação

Recebe notificação de sucesso no pagamento.

17

Empresa Recebedora

Comunicação

Notifica pagador do sucesso no pagamento.

18

Usuário Pagador

Comunicação

Recebe notificação de sucesso no pagamento.

19

PSP Pagador (Detentor)

Comunicação

Notifica o pagador de novo agendamento na sua conta. Notificação desabilitada por padrão, porém, caso ativada pelo pagador, deve ser enviada.

20

Usuário Pagador

Comunicação

Recebe notificação de sucesso no agendamento.

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

Para decidir como prosseguir, o Iniciador precisa se atentar a três pontos.
1 - Caso o erro seja referente a primeira tentativa de liquidação realizada pelo detentor entre 00h~08h, o Iniciador deve conferir qual o motivo de rejeição associado ao pagamento solicitado. Se o motivo de rejeição for algum dos que, conforme a tabela presente na página “Tentativas Intradia e Extradia para Pix Automático”, exige um novo endToEndId, este deve ser enviado através de um novo pagamento até as 12h do mesmo dia;
2 - Caso o erro não exija um novo endToEndId, o ITP deve aguardar a nova tentativa de liquidação que será realizada pelo detentor sem necessidade de sensibilização do detentor pelo ITP;
3 - Caso o erro seja relacionado a segunda tentativa de liquidação prevista para o dia (independente de ter sido criada pelo Iniciador até as 12h daquele dia ou ser a cobrança original que falhou), se permitido pelo usuário em seu consentimento e a critério do recebedor, o Iniciador pode criar uma nova tentativa de liquidação em até 7 dias posteriores a falha da cobrança original. Essa cobrança deve ocorrer, obrigatoriamente, com a data de liquidação sendo D+1, onde D é o dia da solicitação.

A partir da análise dos pontos acima, o Iniciador pode montar o payload de requisição que será repassado ao detentor, onde deve ser informado, no campo originalRecurringPaymentId, o identificador(recurringPaymentId) da tentativa original de pagamento que não foi liquidada com sucesso. Além de que, caso ocorra o descrito no item 2, não há ação prevista para o Iniciador e o fluxo não deve prosseguir.

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 4.

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 itemcampo originalRecurringPaymentId esta preenchido. Também realiza as validações síncronas previstas na criação de pagamentos.

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 lastRetryRecurringPaymentIdscampo originalRecurringPaymentId, 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 originalRecurringPaymentId 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 - Valida se o payload possui as mesmas informações da solicitação original, exceto endToEndId e possível originalRecurringPaymentId

12

PSP Pagador (Detentor)

Ação

Aplica as validações para agendamento de pagamentos extradiaagendamento de pagamentos extradia - Valida se o payload possui as mesmas informações da solicitação original, exceto endToEndId, data e originalRecurringPaymentId

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 notificação ao recebedor informando-o sobre 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

do agendamento do pagamento solicitado

22

Empresa Recebedora

Comunicação

Recebe notificação do ITP/PSP Recebedor informando o sucesso do agendamento do pagamento solicitado

23

Iniciador

Comunicação

Envia a notificação à Empresa Recebedora com o falha no agendamento

notificação ao recebedor informando-o sobre a falha do agendamento do pagamento solicitado

24

Empresa Recebedora

Comunicação

Recebe a notificação de falha no novo agendamento.notificação do ITP/PSP Recebedor informando a falha do agendamento do pagamento solicitado