0

CONVÊNIO PIX
AUTOMÁTICO
Documento Técnico – VERSÃO 1.0

16 DE JUNHO DE 2025
CAIXA ECONOMICA FEDERAL

MO38503 - Documento Técnico - Convênio Pix Automático

 1

SUMÁRIO
1 HISTÓRICO DE REVISÃO ........................................................................................ 2
2 INFORMAÇÕES TÉCNICAS COMPLEMENTARES DO CONVÊNIO PIX
AUTOMÁTICO .............................................................................................................. 4
Campos da Tarifa Simulada................................................................................... 4
Campos do Convênio Cadastrado ......................................................................... 4
3 OBJETIVO ................................................................................................................. 5
PARTE 1 – ORIENTAÇÕES GERAIS........................................................................... 5
4 DEFINIÇÕES ............................................................................................................. 5
5 O QUE É O CONVÊNIO PIX AUTOMÁTICO CAIXA .............................................. 7
6 CONTRATAÇÃO ................................................................................................ 7
RESUMO TÉCNICO DO SERVIÇO .......................................................................... 8
7 CONCEITO ......................................................................................................... 8
8 VANTAGENS ......................................................................................................... 8
9 JORNADAS PARA AUTORIZAÇÃO .......................................................................... 9
9.1 JORNADA 1 DE AUTORIZAÇÃO DO CLIENTE PAGADOR ......................... 10
9.1.1 RESUMO TÉCNICO DA JORNADA 1 ........................................................ 11
9.2 JORNADA 2 DE AUTORIZAÇÃO DO CLIENTE PAGADOR ......................... 12
9.2.1 RESUMO TÉCNICO DA JORNADA 2 ........................................................ 12
9.3 JORNADA 3 DE AUTORIZAÇÃO DO CLIENTE PAGADOR ......................... 12
9.3.1 RESUMO TÉCNICO DA JORNADA 3 ........................................................ 13
9.4 JORNADA 4 DE AUTORIZAÇÃO DO CLIENTE PAGADOR ......................... 14
9.4.1 RESUMO TÉCNICO DA JORNADA 4 ........................................................ 14
10 JORNADAS PARA AGENDAMENTO DO DÉBITO................................................ 15
10.1 ANTES DE GERAR O AGENDAMENTO É PRECISO QUE............................ 16
10.1.1 RESUMO TÉCNICO DO AGENDAMENTO .............................................. 17
10.2 CICLO DE RECORRÊNCIA ............................................................................ 18
11 LIQUIDAÇÃO, REPASSE E TARIFA ..................................................................... 20
12 RETENTATIVA................................................................................................... 21
13 REPASSE .............................................................................................................. 21
14 TARIFA .................................................................................................................. 22
PARTE 2 - PRAZOS, CAMPOS, PARAMETROS TÉCNICOS, TRATAMENTO DE
ERROS E DEMAIS ORIENTAÇÕES .......................................................................... 22
15 PRAZOS E PARÂMETROS GERAIS..................................................................... 22
16 CAMPOS E PARÂMETROS DO ARQUIVO CNAB 750 ......................................... 23
16.1 CAMPOS DO HEADER DO ARQUIVO REMESSA ......................................... 23
16.2 CAMPOS DO REC REMESSA ........................................................................ 24
16.3 CAMPOS DO SOLICREC REMESSA ............................................................. 25

MO38503 - Documento Técnico - Convênio Pix Automático

 2

16.4 CAMPOS DO COBR REMESSA ..................................................................... 25

16.5 CAMPOS COMPLEMENTARES DO COBR REMESSA ................................. 26
16.6 CAMPOS DO TRAILLER REMESSA .............................................................. 26
17 CAMPOS E PARÂMETROS DA API...................................................................... 26
17.1 API PIX............................................................................................................ 26
FONTE: GITHUB BACEN (2.8.1) e MANUAL DE PADRÕES PARA INICIAÇÃO DO
PIX .......................................................................................................................... 26
17.2 TAGS DA API PIX – FONTE: BACEN ............................................................. 27
17.3 TRATAMENTO DE ERROS ............................................................................ 31
FONTE: GITHUB BACEN (2.8.1) ............................................................................ 31
18 DEMAIS ORIENTAÇÕES ...................................................................................... 47
18.1 CRIAÇÃO DA RECORRÊNCIA (AUTORIZAÇÃO) .......................................... 47
18.1.1 CAMPOS DEFINIDOS NO MOMENTO DA CRIAÇÃO DA RECORRÊNCIA
............................................................................................................................ 47
18.1.2 CRIAÇÃO DA SOLICITAÇÃO DE CONFIRMAÇÃO DE RECORRÊNCIA. 48
18.1.3 STATUS RETORNADOS ETAPA DA RECORRÊNCIA: ........................... 48
18.1.4 APÓS A CRIAÇÃO DA AUTORIZAÇÃO ................................................... 48
18.1.5 PROCESSAMENTO E CONFIRMAÇÃO DA AUTORIZAÇÃO .................. 48
18.2 ALTERAÇÃO DA RECORRÊNCIA.................................................................. 49
18.3 CANCELAMENTO DA RECORRÊNCIA PELO CLIENTE PAGADOR ............. 49
18.4 CANCELAMENTO DA RECORRÊNCIA PELO CONTRATANTE RECEBEDOR
................................................................................................................................ 49
18.5 INFORMAÇÕES PARA GERAR O AGENDAMENTO ..................................... 50
18.5.1 STATUS RETORNADOS ETAPA DO AGENDAMENTO .......................... 50
18.5.2 PROCESSAMENTO DO AGENDAMENTO .............................................. 50
18.5.3 REJEIÇÃO DE AGENDAMENTOS PELO PSP RECEBEDOR. ................ 51
18.5.4 CANCELAMENTO DO AGENDAMENTO ................................................. 51
19 INTEGRAÇÃO – MEIOS DE TRANSMISSÃO ....................................................... 51
PARTE 3 – RESUMO E LINKS TÉCNICOS ............................................................... 53
21 SWAGGER ........................................................................................................ 53
22 LEIAUTE ARQUIVO CNAB 750 ......................................................................... 54
23 GERENCIADOR FINANCEIRO .......................................................................... 54

1 HISTÓRICO DE REVISÃO
Versão Data Descrição das alterações
V1.0 16/06/2025 Versão inicial do
Documento Técnico do
Convênio Pix Automático

MO38503 - Documento Técnico - Convênio Pix Automático

 3

MO38503 - Documento Técnico - Convênio Pix Automático

 4

2 INFORMAÇÕES TÉCNICAS
COMPLEMENTARES DO CONVÊNIO PIX
AUTOMÁTICO

Campos da Tarifa Simulada

Opções de excepcionalização da simulação de tarifa:
Conta para débito da tarifa diferente da conta de repasse
Inibir retentativa
Minuta contratual fora do padrão
Minuta edital de credenciamento
Outro

Estimativa Pix:
Agendamentos Mês
Ticket Médio

Campos do Convênio Cadastrado

Número do Convênio
Troca de Informações (permite múltipla seleção):
Via Gerenciador Financeiro
Via API
Via VAN
VAN selecionada (Opcional - se selecionada a opção VAN):

Apelido (Opcional):

As alterações dessas informações no sistema da CAIXA não necessitam de Termo

Aditivo.

MO38503 - Documento Técnico - Convênio Pix Automático

 5

3 OBJETIVO
Este documento tem como objetivo orientar sobre o Convênio Pix Automático, auxiliando
a entender conceitos, jornadas, prazos e procedimentos para a Empresa ou o Governo
aproveitar ao máximo o novo serviço disponibilizado pela CAIXA.
Para facilitar seu uso, o documento está dividido em 3 Partes:
- Parte 1: apresentação do serviço, com conceitos e jornadas
- Parte 2: apresentação técnica, com prazos e procedimentos
- Parte 3: Swagger, arquivo e gerenciador financeiro

PARTE 1 – ORIENTAÇÕES GERAIS

4 DEFINIÇÕES
AGENDAMENTO: Encaminhamento de instrução de pagamento pelo PSP
RECEBEDOR ao PSP PAGADOR na recorrência definida na Autorização. O
agendamento deverá apresentar os dados do cliente, valor e data. Após o recebimento
da instrução de pagamento, o PSP PAGADOR efetua o agendamento na conta do
cliente.
API: Interface de Programação de Aplicação. Em outras palavras, a API é uma forma
de a Empresa/Governo se conectar com a CAIXA para a troca de informações de
autorizações e agendamentos. Além da API, a Empresa/Governo pode se comunicar
com a CAIXA por arquivo ou pelo Gerenciador Financeiro.
ARQUIVO: Interface para envio de informações necessárias para a geração de
solicitações de autorizações e agendamentos, a qual utiliza o leiaute CNAB 750. Em
outras palavras, o Arquivo é uma forma de a Empresa/Governo se conectar com a
CAIXA para a troca de informações de autorizações e agendamentos. Além do arquivo,
a Empresa/Governo pode se comunicar com a CAIXA por API ou pelo Gerenciador
Financeiro.
ARRANJO DE PAGAMENTOS PIX: Arranjo de pagamento instituído pelo Banco Central
do Brasil que disciplina a prestação de serviços de pagamentos instantâneos - PIX
AUTORIZAÇÃO: É a concessão efetuada pelo Cliente Pagador ao seu PSP PAGADOR
para que este tenha legitimidade de iniciar um PIX a partir da conta transacional deste
usuário, devido ao recebimento periódico de instruções de Pagamento pelo PSP
RECEBEDOR. Em outras palavras, é o “de acordo” expresso fornecido pelo cliente
previamente ao recebimento de qualquer agendamento. A Autorização é realizada
apenas uma vez para cada contrato firmado entre Cliente Pagador e Contratante
Recebedor
CLIENTE PAGADOR: O cliente do Contratante Recebedor. Em outras palavras, é quem
vai ter a conta periodicamente debitada de forma automática para creditar a
Empresa/Governo, sendo, portanto, o titular da conta indicada para receber o
agendamento e o débito do Pix

MO38503 - Documento Técnico - Convênio Pix Automático

 6

CONTRATANTE RECEBEDOR: Empresa/Governo contratante do serviço de Convênio

Pix Automático. Em outras palavras, é quem vai receber os valores debitados em conta,
sendo, portanto, o credor da obrigação
GERENCIADOR FINANCEIRO: canal disponibilizado à Empresa/Governo que possui
funcionalidades de contratação do serviço Convênio Pix Automático e de
operacionalização a partir da geração de solicitação de autorizações e envio de
agendamentos.
INSTRUÇÃO DE PAGAMENTO: Conjunto de informações enviadas pela
Empresa/Governo, por intermédio da CAIXA, para que este prestador de serviços tenha
condições de iniciar uma transação do serviço Convênio Pix Automático.
JORNADA DE AUTORIZAÇÃO: Conjunto específico de rotinas e procedimentos
padronizados pelo Banco Central do Brasil e relacionados à concessão de autorização
e à experiência do Cliente Pagador no serviço Convênio PIX Automático. Em outras
palavras, é a forma como a Empresa/Governo vai acionar o cliente para obter dele a
Autorização.
PSP PAGADOR: É a instituição que detém a conta do Cliente Pagador que será
debitada após receber o agendamento do débito periódico e que presta serviços
financeiros como Provedor de Serviços de Pagamento (PSP) na conta do Cliente
Pagador do serviço
PSP RECEBEDOR: É a instituição contratada pela Empresa/Governo para prestar
serviços financeiros e atuar como Provedor de Serviços de Pagamento (PSP) na conta
do Contratante Recebedor
RETENTATIVA: Reenvio da tentativa de débito original, com mesmos valores, em outras
janelas de processamento intradia ou em dias subsequentes, sendo que será realizada
caso a tentativa original não tenha sido finalizada. A ocorrência em dias subsequentes
está prevista para as situações em que há Autorização do Cliente Pagador com esse
parâmetro. Em outras palavras, a retentativa é a “teimosinha” automática que facilita o
recebimento de valores pela Empresa/Governo e que evita o transtorno pelo não
pagamento no prazo dos valores devidos pelo Cliente Pagador. Eventuais encargos
(multa, juros, mora) poderão ser inseridos pela Empresa/Governo em agendamento
futuro.
STATUS: Campo que contém as informações de autorizações e agendamentos e que é
constantemente atualizado pela CAIXA de forma automática, de acordo com o meio de
integração do cliente, para API via Webhook e para arquivo via Arquivo Retorno. Em
outras palavras, é pelo status que a Empresa/Governo consegue verificar se o Cliente
Pagador autorizou, cancelou a autorização, etc
VAN: Rede privada que permite a troca de informações seguras entre empresas. Na
CAIXA, as VANs são contratadas pela CAIXA e disponibilizam seus serviços aos
contratantes dos serviços. Em outras palavras, a VAN é a empresa que recebe o Arquivo
da Empresa/Governo com as informações de autorizações e agendamentos e envia
para a CAIXA para ser processado. Além do arquivo via VAN, a Empresa/Governo pode
se comunicar com a CAIXA por API ou pelo Gerenciador Financeiro.

MO38503 - Documento Técnico - Convênio Pix Automático

 7

5 O QUE É O CONVÊNIO PIX AUTOMÁTICO CAIXA

O Convênio Pix Automático é um serviço de recebimento que a CAIXA disponibiliza para
contratação por Empresa ou Governo.

6 CONTRATAÇÃO
A contratação pode ser de forma digital, no Gerenciador Financeiro; ou na Agência da
CAIXA.
Fluxograma da Contratação Digital

Fluxograma da Contratação em Agência

A partir desse convênio, os pagamentos recorrentes e periódicos dos Clientes

Pagadores da Empresa/Governo podem ser efetuados de forma automática nas contas
em qualquer instituição financeira.
A Empresa/Governo contrata a CAIXA e então poderá debitar contas em vários bancos,
deixando de ser necessário que a Empresa/Governo realize diversos contratos com
cada banco.

MO38503 - Documento Técnico - Convênio Pix Automático

 8

Basta a Empresa/Governo contratar a CAIXA que o banco conectará a

Empresa/Governo a todos os seus Clientes Pagadores para debitar de forma automática
e fazer com que seus valores sejam recebidos em dia, sem atrasos.
Em contrapartida, a CAIXA recebe a tarifa pela prestação do serviço, conforme tarifa do
Convênio publicada na Tabela da CAIXA ou a negociada no momento da contratação.

RESUMO TÉCNICO DO SERVIÇO

7 CONCEITO
O Convênio Pix Automático é voltado para o recebimento de valores pelo
CONTRATANTE RECEBEDOR por meio de envio de instrução de pagamento mediante
autorização para a conta do CLIENTE PAGADOR, referente a compromisso firmado
entre eles, o qual será prestado pela CAIXA como Provedor de Serviços de Pagamentos
Recebedor (PSP RECEBEDOR) de autorização. A autorização possibilita ao
CONTRATANTE RECEBEDOR comandar o débito na conta de CLIENTE PAGADOR e
efetuar o repasse do valor para a conta do CONTRATANTE RECEBEDOR, a partir da
cobrança da(s) tarifa(s) previstas no Termo de Adesão.
____
Neste serviço, o Contratante Recebedor (Empresa/Governo), firma um contrato com a
Caixa para que ela atue como o seu PSP RECEBEDOR.
A CAIXA, como PSP Recebedor, intermediará as transações que possibilitarão o débito
na conta de Cliente Pagador após ele conceder à Empresa/Governo a Autorização para
Agendamento.
Após o agendamento ocorre o débito com Pix e o valor é repassado à Empresa/Governo
de acordo com o parâmetro contratado por ela para forma de repasse.
A tarifa da CAIXA é debitada automaticamente e pronto!
Fácil assim!

8 VANTAGENS
O Convênio Pix Automático é uma solução moderna que facilita os pagamentos
recorrentes, oferecendo mais rapidez, clareza, controle e gestão.
Entre as principais vantagens estão:
 Recebimentos rápidos, com créditos efetivados na conta da Empresa/Governo
(Contratante Recebedor) em D0, em qualquer dia da semana, inclusive finais de
semana e feriados;

MO38503 - Documento Técnico - Convênio Pix Automático

 9

 Eficiência operacional, com simplificação dos processos de cobrança e

conciliação de pagamentos, além da obtenção de informações de recebimentos
em tempo real através do Webhook (API) e Arquivo Retorno (Arquivo CNAB);
 Melhor controle financeiro e previsibilidade de entradas, com visibilidade
completa sobre os pagamentos a serem recebidos e suas datas;
 Redução de inadimplência, com a automatização dos pagamentos recorrentes,
diminuindo o risco de atrasos e falta de pagamento;
 Centralização da troca de informações e dos recebimentos, tendo em vista que
o débito pode ocorrer em qualquer instituição a partir de integração com a CAIXA

9 JORNADAS PARA AUTORIZAÇÃO

Fluxograma da Jornada de Autorização

A Jornada de Autorização do Convênio Pix Automático é iniciada a partir da

disponibilização, pela Empresa/Governo (Contratante Recebedor), das informações
necessárias à geração da solicitação de autorização do Cliente Pagador.
A solicitação de autorização criada pela Empresa/Governo, a partir do convênio firmado
com a CAIXA, segue uma das 4 Jornadas de Autorização disponibilizadas.

MO38503 - Documento Técnico - Convênio Pix Automático

 10

A Empresa/Governo pode utilizar a Jornada mais aderente a seu modelo de negócio. É

possível, inclusive, que utilize as Jornadas 1 e 3, por exemplo, sem risco de duplicidade
do débito visto que a autorização será concedida em apenas uma jornada, passando a
jornada não utilizada a não permitir a autorização do Cliente Pagador para o mesmo
contrato.
Essa vinculação é feita a partir do campo ID do Contrato – que é único.

9.1 JORNADA 1 DE AUTORIZAÇÃO DO CLIENTE PAGADOR

A Jornada de Autorização 1 tem início em um contato direto entre Empresa/Governo e
Cliente Pagador.
Esse contato poderá ser pessoalmente, por telefone, email, chat ou qualquer outro canal
de atendimento disponibilizado pela Empresa/Governo a seu Cliente Pagador.
Nesse atendimento, a Empresa/Governo irá receber a manifestação do Cliente Pagador
e as informações bancárias necessárias à criação e envio da solicitação de autorização.
O Cliente Pagador deverá ser orientado pela Empresa/Governo a acompanhar o
recebimento de PUSH/SMS ou a acessar a área de gestão do Pix da conta indicada por
ele na manifestação de interesse realizada à Empresa/Governo.
As informações necessárias à Jornada de Autorização 1 estão na Parte 2 deste
documento.
De posse da manifestação de interesse, do contrato firmado e dos dados bancários e
CPF/CNPJ do Cliente Pagador, a Empresa/Governo inicia a Jornada de Autorização 1
na CAIXA.

Dica
Outra opção é a Empresa/Governo gerar as informações para a criação
da solicitação de autorização a partir da base de clientes que possui,
podendo utilizar, por exemplo, a cadastrada para o débito automático e

MO38503 - Documento Técnico - Convênio Pix Automático

 11

aguardar a autorização do Cliente Pagador. Essa Jornada de

Autorização é a ideal para a Empresa/Governo que se utiliza de
promoções de adesão com desconto em mensalidades (ex. se aderir
até o dia 3 tem desconto de 5% nas mensalidades por Pix Automático)
visto a possibilidade de inserir a data máxima para o Cliente Pagador
autorizar.
De posse dessas informações, realiza a troca de informações com a CAIXA por meio de
API, Arquivo ou Gerenciador Financeiro.
A CAIXA enviará para cada banco indicado por cada Cliente Pagador a solicitação de
Autorização criada pela Empresa/Governo.
O Cliente Pagador receberá um PUSH/SMS e/ou acessará a área de gestão no seu
banco para acessar a solicitação, adicionar parâmetros e confirmar ou rejeitar a
autorização.
Os parâmetros estão descritos na Parte 2.
Se desejar, a Empresa/Governo pode estabelecer que o Cliente Pagador pode autorizar
uma data específica, desde que essa data respeite o prazo máximo de 30 dias, podendo
ser inferior a esse prazo máximo se a Empresa/Governo desejar.
As rejeições serão acompanhadas de modo a evitar ações massificadas por parte do
contratante Empresa/Governo aos Clientes Pagadores.
A ocorrência de ações massificadas indesejadas pelos Clientes Pagadores podem
ensejar à suspensão do convênio.

9.1.1 RESUMO TÉCNICO DA JORNADA 1

A Jornada de Autorização 1 é iniciada a partir da negociação externa ao ambiente de
intermediação financeira entre o Contratante Recebedor e o Cliente Pagador referente
a cobrança recorrente por meio de Convênio Pix Automático.
O Contratante Recebedor encaminha notificação ao PSP RECEBEDOR acerca das
instruções de agendamento, em seguida, o PSP RECEBEDOR notifica o PSP
PAGADOR que solicita a confirmação ao pagador acerca da adesão ao Convênio Pix
Automático para a cobrança.
Ao utilizar a jornada 1, o Contratante Recebedor deverá estruturar e transmitir à CAIXA
as informações de pagamentos com a antecedência mínima estipulada pelo float
negociado no Termo de Adesão pelo meio de troca de informações desejado.
O Contratante Recebedor pode definir um prazo para expiração da solicitação; caso
contrário, a CAIXA assumirá um prazo máximo de 30 dias para a autorização da
recorrência pelo Cliente Pagador.
O Cliente Pagador receberá uma solicitação de confirmação no aplicativo do seu banco
e analisará as informações fornecidas pelo Contratante Recebedor, podendo autorizar
o consentimento em até 30 dias.
Se o Cliente Pagador rejeitar o pedido, o Contratante Recebedor não poderá enviar
novas solicitações de recorrência por 30 dias.

MO38503 - Documento Técnico - Convênio Pix Automático

 12

9.2 JORNADA 2 DE AUTORIZAÇÃO DO CLIENTE PAGADOR

A Jornada de Autorização 2 tem início a partir da geração de um QR Code pela
Empresa/Governo.
Para gerar o QR Code, a empresa realizará a troca de informações com a CAIXA a partir
de API, Arquivo ou Gerenciador Financeiro.
As informações necessárias a essa geração de QR Code estão na Parte 2 deste
documento.
Após gerar o QR Code, a Empresa/Governo o disponibiliza ao Cliente Pagador para que
ele possa ler o QR Code e autorizar.

Dica
Essa Jornada de Autorização é a ideal para a Empresa/Governo que tem valor
fixo de pagamento/transferência e/ou que deseja disponibilizar o QR Code no
balcão, em formulários pré-impressos de compra, em folders, embalagens de
produtos, cartazes, folhetos, materiais de marketing, vitrines, páginas da web
e redes sociais, fichas de inscrição, etc. São inúmeras possibilidades de uso.
O Cliente Pagador irá ler o QR Code, estabelecer os parâmetros e autorizar.
Esse QR Code contém somente autorização, sem pagamento vinculado.
A Empresa/Governo recebe a confirmação da autorização pela mesma forma que
enviou os dados para a troca de informações com a CAIXA, ou seja, por API, Arquivo
ou Gerenciador Financeiro.

9.2.1 RESUMO TÉCNICO DA JORNADA 2

A jornada 2 é efetuada mediante a disponibilização de QR CODE Dinâmico que
apresente os dados da recorrência encaminhados pelo Contratante Recebedor ao
Cliente Pagador a partir da adesão ao convênio Pix Automático para a cobrança.
O Cliente Pagador efetua a leitura do QR Code e autoriza a recorrência.
Durante essa jornada, o Contratante Recebedor criará uma recorrência (Rec) para a
formatação do QR Code de autorização.
Esse QR Code deverá ser escaneado pelo Cliente Pagador.

9.3 JORNADA 3 DE AUTORIZAÇÃO DO CLIENTE PAGADOR

A Jornada de Autorização 3 tem início a partir da geração de um QR Code pela
Empresa/Governo.
Para gerar o QR Code, a empresa realizará a troca de informações com a CAIXA a partir
de API, Arquivo ou Gerenciador Financeiro.
As informações necessárias a essa geração de QR Code estão na Parte 2 deste
documento.

MO38503 - Documento Técnico - Convênio Pix Automático

 13

Esse QR Code possui duas informações que o diferenciam dos demais e para as quais
o Cliente Pagador dará a Autorização a partir de um comando único: um
pagamento/transferência de natureza inicial e a autorização para o débito por Pix
Automático dos períodos subsequentes.
Dessa forma, o Cliente Pagador autorizará ao mesmo tempo em que realizará o
pagamento inicial, não sendo possível separar o pagamento e a autorização para os
agendamentos futuros.
Após gerar o QR Code, a Empresa/Governo disponibiliza ao Cliente Pagador para que
ele possa pagar e autorizar.

Dica
Essa Jornada de Autorização é a ideal para situações de adesão a serviços
pré-pagos, valores de entrada em compras, de matrículas, de promoções de
adesão com desconto em mensalidades (ex. se aderir até o dia 3 tem
desconto de 5% nas mensalidades por Pix Automático), serviços pré-pagos,
de streaming, clubes, revistas, jornais, aplicativos e planos de saúde, pacotes
de viagem, consórcios, seguros, com valor de entrada para liberar o uso ao
Cliente Pagador, a Empresa/Governo que tem valor fixo de
pagamento/transferência e/ou que deseja disponibilizar o QR Code no balcão,
em formulários pré-impressos de compra, em folders, embalagens de
produtos, cartazes, folhetos, materiais de marketing, vitrines, páginas da web
e redes sociais, fichas de inscrição, etc. São inúmeras possibilidades de uso.
O Cliente Pagador irá ler o QR Code, realizar o pagamento (imediato ou agendado),
estabelecer parâmetros e autorizar.
O cliente Pagador poderá agendar o pagamento.
A Empresa/Governo recebe a confirmação da autorização pela mesma forma que
enviou os dados para a troca de informações com a CAIXA, ou seja, por API, Arquivo
ou Gerenciador Financeiro.

9.3.1 RESUMO TÉCNICO DA JORNADA 3

A jornada 3 é efetuada a partir da disponibilização, pelo Contratante Recebedor, de QR
Code dinâmico que apresenta um pagamento imediato e os dados da recorrência.
Nessa jornada, o Cliente Pagador efetua a leitura do QR Code e autoriza o pagamento
inicial, que pode ser imediato ou agendado pelo Cliente Pagador, e a recorrência.
Durante essa jornada, o Cliente Pagador criará uma recorrência (Rec) para associá-la
a uma cobrança imediata (Cob) e formatar o QR Code com a taxa e os dados da
autorização.
É importante ressaltar que, para vincular a recorrência à cobrança inicial, deve ser
determinado um TXID (identificador da cobrança) comum nas duas operações.

MO38503 - Documento Técnico - Convênio Pix Automático

 14

9.4 JORNADA 4 DE AUTORIZAÇÃO DO CLIENTE PAGADOR

A Jornada de Autorização 4 tem início a partir da geração de um QR Code pela
Empresa/Governo.
Para gerar o QR Code, a empresa realizará a troca de informações com a CAIXA a partir
de API, Arquivo ou Gerenciador Financeiro.
As informações necessárias a essa geração de QR Code estão na Parte 2 deste
documento.
Esse QR Code possui duas informações que o diferenciam dos demais: um
pagamento/transferência de natureza inicial e uma oferta para que o cliente autorize o
débito por Pix Automático dos períodos subsequentes.
Dessa forma, o Cliente Pagador realizará o pagamento normalmente a partir da leitura
do QR Code, pagamento imediato ou agendado; e, após, será apresentada ao Cliente
Pagador a opção de autorizar o débito para os agendamentos futuros.
Ou seja, não há vinculação direta e obrigatória entre o pagamento que está sendo
realizado e a autorização, podendo ela acontecer ou não.
Após gerar o QR Code, a Empresa/Governo disponibiliza ao Cliente Pagador para que
ele possa pagar e autorizar.

Dica
Essa Jornada de Autorização é a ideal para situações de manutenção de
serviços: serviços pós pagos (concessionárias, condomínios, escolas,
faculdades, aluguéis, planos de saúde, faturas de cartão de crédito,
consórcios, seguros, pacotes de beleza, pacotes de viagem), etc. São
inúmeras possibilidades de uso.
O Cliente Pagador irá ler o QR Code, realizar o pagamento (imediato ou agendado),
estabelecer parâmetros e autorizar.
A Empresa/Governo recebe a confirmação da autorização pela mesma forma que
enviou os dados para a troca de informações com a CAIXA, ou seja, por API, Arquivo
ou Gerenciador Financeiro.

9.4.1 RESUMO TÉCNICO DA JORNADA 4

A jornada 4 é efetuada por meio da disponibilização, pelo Contratante Recebedor, de
QR Code dinâmico que apresenta um pagamento inicial (imediato ou agendado) e
possibilita uma recorrência, caso o Cliente Pagador efetue a autorização. Ao autorizar,
concorda que as cobranças futuras sejam pagas por meio do convênio Pix Automático
conforme as instruções de pagamento encaminhadas pelo Contratante Recebedor.
Assim, após a liquidação do pagamento inicial, é oferecido ao cliente a opção de
autorizar o Pix Automático para as próximas cobranças, sendo facultativa a sua adesão
de forma que ele pode autorizar ou não sem prejuízo ao pagamento inicial.
Durante essa jornada, o Contratante Recebedor criará uma recorrência (Rec) para
associá-la a uma cobrança com vencimento (CobV) e formatar o QR Code com os dados
de pagamento da cobrança.

MO38503 - Documento Técnico - Convênio Pix Automático

 15

Posteriormente, o Cliente Pagador avaliará se aceita a oferta de adesão ao Pix

Automático.
O Cliente Pagador irá ler o QR Code, realizar o pagamento, receber a oferta de
autorização, estabelecer parâmetros e autorizar, se desejar aceitar a oferta.
A Empresa/Governo recebe a confirmação da autorização pela mesma forma que
enviou os dados para a troca de informações com a CAIXA, ou seja, por API, Arquivo
ou Gerenciador Financeiro.

Independentemente da Jornada escolhida, a Empresa/Governo pode reduzir custos ou

melhorar a adimplência da carteira, por exemplo, a partir do incentivo à adesão dos seus
Clientes Pagadores ao Pix Automático utilizando uma ou várias das jornadas de adesão de
forma combinada.

10 JORNADAS PARA AGENDAMENTO DO

DÉBITO
Fluxograma da Jornada de Agendamento

O processo de criação do agendamento deve ser realizado pela Empresa/Governo,

após a autorização pelo Cliente Pagador.
Para o agendamento ser aceito, a autorização deverá estar com status autorizado.
As informações necessárias sobre o agendamento estão na Parte 2 deste documento.

MO38503 - Documento Técnico - Convênio Pix Automático

 16

10.1 ANTES DE GERAR O AGENDAMENTO É PRECISO

QUE
• o Cliente Pagador tenha dado a Autorização no aplicativo do banco dele (PSP
Pagador) após a Empresa/Governo ter gerado a solicitação de autorização
• a confirmação de autorização tenha sido enviada de um banco para outro por
meio do ecossistema do Pix
• o status da autorização tenha sido atualizado tanto no sistema do banco do
Cliente Pagador quanto na CAIXA

A Jornada de Agendamento tem início a partir do momento em que o Cliente Pagador

autorizou.
O agendamento é simples e a Empresa/Governo pode realizar o agendamento por API,
Arquivo ou Gerenciador Financeiro.
Para gerar o agendamento é necessário respeitar os parâmetros que a
Empresa/Governo colocou na solicitação de autorização e, também, os parâmetros
adicionais que o Cliente Pagador cadastrou.

Exemplo
Ao solicitar a autorização do Cliente Pagador, a Empresa/Governo informou
que seria uma autorização para debitar um valor variável, de periodicidade
mensal, cujo mínimo é R$30,00. O Cliente Pagador, por sua vez, informou
que o máximo a debitar seria R$50,00 e que a autorização teria validade de
3 meses.
O agendamento que a Empresa/Governo vai mandar agora deve acontecer
apenas uma vez no mês, pode ser de qualquer valor entre R$30,00 e R$50,00
e não será agendado após o 3º mês.
Além disso, o agendamento possui como regra geral a possibilidade de postergar o
vencimento para o primeiro dia útil quando ocorrer o vencimento nos finais de semana
ou feriados.
Contudo, existe uma possibilidade opcional de que o débito ocorra no próprio feriado ou
final de semana visto que é uma transação Pix, que pode acontecer em qualquer horário
e em qualquer dia da semana.
Essa escolha é da Empresa/Governo no momento de enviar cada agendamento de cada
Cliente Pagador, em um campo de preenchimento opcional e a CAIXA assume que
“sim”, se o vencimento cair em um final de semana ou feriado, deverá ser postergado.

Exemplos

MO38503 - Documento Técnico - Convênio Pix Automático

 17

Exemplo 1: Se para a Empresa/Governo o débito acontecer em um domingo

ou em uma segunda-feira é indiferente pois o serviço é pós pago, poderá ser
informado pela Empresa/Governo que há ajuste para dia útil.
Exemplo 2: Se para a Empresa/Governo o débito precisa acontecer na data
prevista pois o serviço é pré pago e o aluno só terá o acesso à academia
liberado após o pagamento, poderá ser informado pela Empresa/Governo que
não há ajuste para dia útil.
Agendamento pronto e enviado, ocorre uma nova etapa que é a validação na CAIXA
das informações recebidas.
A validação abrange verificar se foram respeitados no agendamento enviado os
parâmetros que a Empresa/Governo colocou na solicitação de autorização e, também,
os parâmetros adicionais que o Cliente Pagador cadastrou.
Após a CAIXA validar, o agendamento é enviado ao ecossistema e o banco do Cliente
Pagador faz nova verificação antes de agendar na conta do Cliente Pagador.
Estando tudo de acordo com o autorizado pelo Cliente Pagador, ao consultar sua conta
aparecerá previsto o débito que a Empresa/Governo enviou.
O Cliente Pagador poderá, caso deseje, cancelar o agendamento e, nesse caso, a
Empresa/Governo recebe essa atualização de status em um dos meios indicados para
a troca de informações com a CAIXA e negocia diretamente com o cliente uma forma
de recebimento.
Mantido o agendamento na conta, na data definida pela Empresa/Governo terá início a
Liquidação do Pix.
As informações sobre agendamentos e cancelamentos estão disponíveis na Parte 2
desse documento.

10.1.1 RESUMO TÉCNICO DO AGENDAMENTO

Após a autorização, o PSP RECEBEDOR encaminha as instruções de agendamento
recorrente recebidas do contratante para débito por meio do Convênio Pix Automático
conforme a Autorização válida.

• Os agendamentos devem seguir as periodicidades (frequências) definidas na

autorização de cada cobrança. Lembrando que na autorização a periodicidade
pode ter sido definida como semanal, mensal, trimestral, semestral ou anual,
dependendo do que foi acordado entre o Cliente Pagador e o Contratante
Recebedor
• O Contratante Recebedor deve respeitar o ciclo da recorrência para
agendamento
• O Contratante Recebedor envia o agendamento podendo, a critério dele, indicar
se o débito será efetuado em dia útil ou não.
• O Contratante Recebedor envia o agendamento com antecedência mínima de 2
dias da data prevista para a liquidação e com antecedência máxima de 10 dias
antes da data prevista para a liquidação
O Recebedor realizará o agendamento e o Pagador será notificado sobre o
agendamento programado.
As informações necessárias sobre o agendamento estão na Parte 2 deste documento.

MO38503 - Documento Técnico - Convênio Pix Automático

 18

10.2 CICLO DE RECORRÊNCIA

Cada agendamento está vinculado a uma autorização na qual foi estabelecida entre as
partes, dentre outros parâmetros, a recorrência com que os valores serão debitados da
conta do Cliente Pagador.
Há a validação desse parâmetro quando um agendamento é enviado.
A validação desse parâmetro consiste na verificação de existência ou não de
agendamento dentro do mesmo ciclo.
Se ainda não há agendamento ocorrido nesse ciclo, o agendamento está válido e ocorre
na conta do Cliente Pagador.
Se, dentro desse ciclo, já houve um agendamento para esse Cliente Pagador então não
poderá haver um novo agendamento.
O objetivo é evitar um débito em duplicidade na conta do Cliente Pagador.
O ciclo tem a duração de intervalo entre uma periodicidade e a outra.

Exemplo
A Empresa/Governo inseriu na autorização a periodicidade semanal e o
Cliente Pagador autorizou. Na semana do dia 16 JUN 25, a Empresa/Governo
enviou um agendamento e o Cliente Pagador já pode consultar no aplicativo
do seu banco. Na mesma semana do dia 16 JUN 25, a Empresa/Governo
tenta enviar um novo agendamento para o Cliente Pagador relacionado à
mesma autorização para debitar na mesma semana. Esse segundo
agendamento não vai acontecer na conta do Cliente Pagador pois não
respeita o ciclo mínimo necessário de intervalo entre um agendamento e
outro.
Dessa forma, o ciclo de recorrência no Pix Automático é definido pela data de início
estabelecida na criação da recorrência e, que representa a data do primeiro pagamento.
A partir dessa data, os ciclos são contados conforme a periodicidade escolhida.
Destaca-se que cada ciclo de pagamento se estende até D-1 do próximo ciclo, ou seja,
o período de um ciclo termina um dia antes do início do próximo.
Isso garante que a lógica da recorrência seja previsível.
É importante ressaltar que, quando a data esperada para finalização do ciclo não existir
no calendário, será utilizada a data imediatamente anterior.

Exemplos
Exemplo 1: Para cobranças recorrentes com vencimento no dia 30 de cada
mês, em meses que não possuem essa data, como fevereiro, a cobrança será
ajustada para o dia 28 (ou 29, em anos bissextos).

MO38503 - Documento Técnico - Convênio Pix Automático

 19

Exemplo 2 Ciclo Semanal: Se a recorrência for iniciada em 05 de março, o

primeiro ciclo será de 05 a 11 de março, e o próximo ciclo começará em 12
de março, seguindo essa lógica semanalmente.
Exemplo 3 Ciclo Mensal: Para uma recorrência com início em 10 de abril, o
primeiro ciclo vai de 10 de abril a 09 de maio, e o próximo ciclo começa em
10 de maio.
Exemplo 4 Ciclo Trimestral: Se a data de início for 15 de janeiro, o primeiro
ciclo será de 15 de janeiro a 14 de abril, e o próximo começará em 15 de abril.
Exemplo 5 Ciclo Semestral: Uma recorrência iniciada em 01 de junho terá
seu primeiro ciclo de 01 de junho a 30 de novembro, com o próximo
começando em 01 de dezembro.
Exemplo 6 Ciclo Anual: Para um início em 20 de julho de 2025, o primeiro
ciclo será de 20 de julho de 2025 a 19 de julho de 2026, com o próximo ciclo
iniciando no dia 20 de julho de 2026.
Ressalta-se que, no ciclo de recorrência do Pix Automático, quando uma recorrência
está configurada para ter retentativa, as tentativas de pagamento devem ocorrer dentro
do mesmo ciclo, sendo que, se uma cobrança falhar, as novas tentativas devem ser
feitas dentro do período do ciclo vigente e não podem ultrapassar para o próximo ciclo.
Caso contrário, a cobrança não será processada.
Independentemente da periodicidade escolhida (semanal, mensal, trimestral, semestral
ou anual), todas as retentativas devem respeitar o intervalo entre a data de início da
recorrência e D-1 do próximo ciclo.
Não há obrigatoriedade de envio de agendamento no ciclo pela Empresa/Governo e, se
o pagamento não for concluído dentro desse ciclo, a recorrência segue para o próximo
ciclo normalmente, sem carregar pendências da cobrança anterior.
Se a Empresa/Governo não enviar o agendamento dentro do ciclo, não poderá utilizar
o ciclo seguinte para enviar dois agendamentos como forma de compensação.

MO38503 - Documento Técnico - Convênio Pix Automático

 20

11 LIQUIDAÇÃO, REPASSE E TARIFA

Fluxograma da Jornada de Liquidação

Agora que a Empresa/Governo enviou o agendamento e ele aparece na conta do Cliente

Pagador, o banco do Cliente Pagador, na data prevista, realizará o débito do Pix na
conta do Cliente Pagador e enviará o recurso para a CAIXA.
Esse débito na conta do Cliente Pagador acontecerá em janelas de processamento,
sendo obrigatória a tentativa de débito ao menos uma vez em cada janela obrigatória,
podendo ocorrer em dias úteis ou não úteis.
São duas as janelas obrigatórias diárias:
o A primeira janela de processamento tem início às 00h do dia do débito e finaliza
às 8h da manhã do dia do débito
o A segunda janela de processamento tem início às 18h do dia do débito e finaliza
às 21h do dia do débito
No dia da liquidação, o débito será realizado automaticamente e o Cliente Pagador
receberá uma notificação via PUSH/SMS informando sobre o débito.
O banco do Cliente Pagador pode, a seu critério, tentar enviar a ordem de pagamento
para liquidação múltiplas vezes, em outros horários desde que as tentativas mínimas
previstas sejam respeitadas, e a última tentativa ocorra até as 21 horas do dia previsto
para liquidação.
Havendo o débito na data original prevista, a CAIXA iniciará a etapa de repasse do
recurso para a Empresa/Governo.
Caso não seja efetivado o débito do Pix na conta do Cliente Pagador na data original
prevista, além das notificações obrigatórias aos envolvidos, poderá ter início a etapa de
retentativa.

MO38503 - Documento Técnico - Convênio Pix Automático

 21

12 RETENTATIVA
A retentativa é um parâmetro que é cadastrado na Jornada de Autorização e que terá
um custo adicional à empresa no caso de incidência.
A Empresa/Governo pode estabelecer que todas as autorizações de todos os seus
Clientes Pagadores terão o parâmetro de retentativa ou pode limitar esse parâmetro a
determinado grupo de clientes (que costumam atrasar os pagamentos, por exemplo).
A decisão de constar esse parâmetro na autorização é da Empresa/Governo e cabe ao
Cliente Pagador autorizar ou não.
Se autorizar, a retentativa acontecerá para as autorizações com esse parâmetro da
Empresa/Governo quando não ocorrer o débito do Pix na data original.
As informações necessárias sobre a retentativa estão na Parte 2 deste documento.

Exemplos
Exemplo 1: A autorização tem periodicidade semanal e o parâmetro “com
retentativa” e no dia 15 não aconteceu o débito apesar de estar agendado
na conta do Cliente Pagador. Mantidos os valores originais de pagamento,
podem ser enviadas tentativas de débito do Pix na conta do Cliente Pagador
para os dias seguintes ao dia 15 (data original). A nova tentativa de débito
poderá acontecer em até 3 dias diferentes desde que respeite o intervalo
máximo aplicável. Em outras palavras, se o débito original era dia 15 e a
periodicidade era semanal, as 3 retentativas poderão acontecer entre os dias
16 e 20.
Exemplo 2: A autorização tem periodicidade mensal e o parâmetro “com
retentativa” e no dia 15 não aconteceu o débito apesar de estar agendado
na conta do Cliente Pagador. Mantidos os valores originais de pagamento,
podem ser enviadas tentativas de débito do Pix na conta do Cliente Pagador
para os dias seguintes ao dia 15 (data original). A nova tentativa de débito
poderá acontecer em até 3 dias diferentes desde que respeite o intervalo
máximo aplicável. Em outras palavras, se o débito original era dia 15 e a
periodicidade era semanal, as 3 retentativas poderão acontecer entre os dias
16 e 22.
Exemplo 3: A autorização tem periodicidade mensal e o parâmetro “sem
retentativa” e no dia 15 não aconteceu o débito apesar de estar agendado
na conta do Cliente Pagador. Não haverá nova tentativa de débito referente
ao mesmo ciclo e a Empresa/Governo deverá buscar receber o valor
diretamente com o Cliente Pagador.

13 REPASSE
O recurso chegou na CAIXA e é repassado para a conta da Empresa/Governo conforme
parâmetros cadastrados na contratação do serviço Convênio Pix Automático.

MO38503 - Documento Técnico - Convênio Pix Automático

 22

14 TARIFA
Após o crédito do recurso na conta da Empresa/Governo, a CAIXA debita
automaticamente a tarifa conforme parâmetros cadastrados na contratação.

PARTE 2 - PRAZOS, CAMPOS,

PARAMETROS TÉCNICOS, TRATAMENTO DE
ERROS E DEMAIS ORIENTAÇÕES

15 PRAZOS E PARÂMETROS GERAIS

• Periodicidade:
o Semanal
o Mensal
o Trimestral
o Semestral
o Anual

• Prazo máximo para o Cliente Pagador Autorizar:

o Jornada 1 de Autorização: 30 dias
 A Empresa/Governo pode estabelecer um prazo máximo inferior
a 30 dias. Ex. Solicitar autorização com prazo máximo de 7 dias
para o Cliente Pagador se manifestar
o Demais Jornadas de Autorização: não há
o A solicitação para autorização permanece em aberto até a confirmação
ou recusa do Cliente Pagador; até o Contratante Recebedor
(Empresa/Governo) solicitar o cancelamento; ou o fim do prazo previsto
para o Cliente Pagador autorizar.

• Prazo de antecedência para envio de agendamento pela Empresa/Governo:

o No mínimo 2 dias corridos antes da data prevista para débito
o No máximo 10 dias corridos antes da data prevista para débito
o Agendamentos enviados para a CAIXA fora desses prazos serão
rejeitados

• Momento da liquidação do Pix na conta do Cliente Pagador na data agendada:

o Janela Prioritária: das 00h às 8h
o Caso não haja recursos suficientes, o Cliente Pagador é notificado e é
realizada, no mínimo, uma nova tentativa no mesmo dia na Janela de
18h às 21h

• Prazo para retentativa de liquidação do Pix na conta do Cliente Pagador:

o Pode acontecer em até 3 dias diferentes além da data original

MO38503 - Documento Técnico - Convênio Pix Automático

 23

o Os 3 dias indicados devem estar dentro do período máximo de 7 dias

após a data inicial prevista para liquidação
 Se for periodicidade semanal, o período máximo é de 5 dias

• Prazo de antecedência para envio de cancelamento pela Empresa/Governo:

o Até às 22h da data anterior à data prevista para débito

• Prazo de antecedência para envio de cancelamento pelo Cliente Pagador:

o Até às 23:59 da data anterior à data prevista para débito

• Prazo para PSP Recebedor reenviar instrução de pagamento para uma mesma
cobrança, mediante comando do usuário recebedor
o Até 2 dias antes da data prevista para a liquidação

• Data a ser informada para a Liquidação do Pix:

o anterior à data de início do próximo ciclo; e/ou
o anterior ao término da recorrência

• Prazo para o PSP Pagador agendar a ordem de pagamento na conta do Cliente

Pagador:
o Até 2h após o recebimento da instrução de pagamento

16 CAMPOS E PARÂMETROS DO ARQUIVO

CNAB 750
Os detalhes do leiaute, contemplando a informação de quais são os campos
obrigatórios, tamanho de cada campo, conteúdo previsto e esclarecimentos estão na
Parte 3 desse documento.

16.1 CAMPOS DO HEADER DO ARQUIVO REMESSA

NOME DO CAMPO SIGNIFICADO

TIPO DE REGISTRO Identificação do registro header

CÓDIGO OPERAÇÃO Tipo de operação - remessa

LITERAL DE REMESSA Identificação por extenso do movimento

CÓDIGO DO SERVIÇO Identificação do tipo do serviço

LITERAL DO SERVIÇO Identificação por extenso do tipo de serviço

ISBP DO PSP RECEBEDOR Código do ISPB do Banco do Usuário Recebedor

TIPO DE INSCRIÇÃO DO RECEBEDOR Identifica o tipo de inscrição do Usuário Recebedor

Nº INSCRIÇÃO DO RECEBEDOR Identifica o número da inscrição do Recebedor

AGÊNCIA DO RECEBEDOR Agência do Usuário Recebedor

CONTA DO RECEBEDOR Conta do Usuário Recebedor

MO38503 - Documento Técnico - Convênio Pix Automático

 24

TIPO DE CONTA Tipo de conta do Usuário Recebedor

CHAVE PIX Identifica a chave pix para recebimento nas jornadas 3 e 4

DATA DE GERAÇÃO Data de geração do arquivo

CÓDIGO DO CONVÊNIO Código que identifica o número do convênio

EXCLUSIVO PSP RECEBEDOR Exclusivo PSP Recebedor

NOME DO RECEBEDOR Nome do Usuário Recebedor

BRANCOS Brancos

NÚMERO SEQUENCIAL DA REMESSA Número sequencial do arquivo

VERSÃO DO ARQUIVO Versão do layout do arquivo

NÚMERO SEQUENCIAL DO REGISTRO Número sequencial do registro

16.2 CAMPOS DO REC REMESSA

NOME DO CAMPO SIGNIFICADO

TIPO DE REGISTRO Identificação do registro header

CÓDIGO DE OCORRÊNCIA Identifica a ocorrência do arquivo remessa

TIPO DE COBRANÇA RECORRENTE Identifica o tipo de cobrança recorrente que será emitida.

TIPO DE INSCRIÇÃO DO DEVEDOR Identifica o tipo de inscrição do Devedor

Nº INSCRIÇÃO DO DEVEDOR Identifica o número da inscrição do Devedor

NOME DO DEVEDOR Nome do Usuário Devedor

TXID Identificador da cobrança imediata

Identifica o número do contrato da cobrança recorrente

CONTRATO
entre o Usuário Recebedor e Pagador
OBJETO Descrição do contrato do Pix Automático

PERIODICIDADE Identifica a frequência das cobranças recorrentes

Identifica se a recorrência terá um prazo determinado ou

INDICADOR DO PRAZO DA RECORRÊNCIA
indeterminado.
DATA INICIAL Identifica a data inicial da recorrência

DATA FINAL Identifica a data final da recorrência

INDICADOR TIPO DE VALOR DA RECORRÊNCIA Identifica o tipo de recorrência, se é valor fixo ou variável.
Identifica o valor de recorrências com valores fixos. Para
VALOR DA RECORRÊNCIA as cobranças de valor variável, não é necessário o
preenchimento.
INDICADOR VALOR MÍNIMO DO RECEBEDOR Identifica o valor mínimo do recebedor

VALOR MÍNIMO DO RECEBEDOR Identifica o valor mínimo da cobrança recorrente.

Identifica se a recorrência permitirá novas tentativas após
POLÍTICA RETENTATIVA
a data de vencimento

MO38503 - Documento Técnico - Convênio Pix Automático

 25

Deve ser preenchido em situações que o Usuário

ID DA RECORRÊNCIA
Recebedor deseja cancelar uma recorrência.

Utilizado nas situações que os Usuários queiram vincular a

LOCATION
location de um QR Code já gerado em uma recorrência.
EXCLUSIVO PSP RECEBEDOR Exclusivo PSP Recebedor

BRANCOS Branco.

NÚMERO SEQUENCIAL Identifica o número sequencial do registro

16.3 CAMPOS DO SOLICREC REMESSA

NOME DO CAMPO SIGNIFICADO

TIPO DE REGISTRO Identificação do registro header

CÓDIGO DE OCORRÊNCIA Identifica a ocorrência do arquivo remessa

ID DA RECORRÊNCIA Identificador da recorrência gerado no segmento Rec

Identifica a data/hora de expiração da solicitação de

DATA/HORA EXPIRAÇÃO DA RECORRÊNCIA recorrência via Push. Pode ser uma definida uma data até 30
dias.

TIPO DE INSCRIÇÃO DO PAGADOR Identifica o tipo de inscrição do Usuário Pagador

Nº INSCRIÇÃO DO PAGADOR Identifica o número da inscrição do Pagador

AGÊNCIA DO PAGADOR Identifica a agência do Usuário Pagador

CONTA DO PAGADOR Identifica a conta do Usuário Pagador

ISPB DO PSP PAGADOR Identifica o ISPB do Usuário Pagador

ID SOLICITAÇÃO DA RECORRÊNCIA Identificador da solicitação da recorrência

EXCLUSIVO PSP RECEBEDOR Exclusivo PSP Recebedor

BRANCOS Uso reservado do Banco

NÚMERO SEQUENCIAL Identifica o número sequencial do registro

16.4 CAMPOS DO COBR REMESSA

NOME DO CAMPO SIGNIFICADO

TIPO DE REGISTRO Identificação do registro header

CÓDIGO DE OCORRÊNCIA Identifica a ocorrência do arquivo remessa

AGÊNCIA DO RECEBEDOR Agência do Usuário Recebedor

CONTA DO RECEBEDOR Conta do Usuário Recebedor

ID DA RECORRÊNCIA Identificador único da recorrência

IDENTIFICADOR DA COBRANÇA (TXID) Identificador único do agendamento

VALOR Valor do agendamento

DATA DE VENCIMENTO Data de vencimento da cobrança

Identifica se a cobrança terá o ajuste para liquidação em
AJUSTE DIA ÚTIL
dias úteis

MO38503 - Documento Técnico - Convênio Pix Automático

 26

Campo de texto livre para troca de informações entre o

INFORMAÇÕES ENTRE USUÁRIOS
Usuário Recebedor e Usuário Pagador

EXCLUSIVO PSP RECEBEDOR Exclusivo PSP Recebedor

BRANCOS Uso reservado do Banco

NÚMERO SEQUENCIAL Identifica o número sequencial do registro

16.5 CAMPOS COMPLEMENTARES DO COBR REMESSA

NOME DO CAMPO SIGNIFICADO

TIPO DE REGISTRO Identificação do registro header

IDENTIFICADOR DA COBRANÇA (TXID) Identificador único do agendamento

CEP DO DEVEDOR Identifica o CEP do Usuário Devedor

CIDADE DO DEVEDOR Identifica a cidade do Usuário Devedor

E-MAIL DO DEVEDOR Identifica o e-mail do Usuário Devedor

LOGRADOURO DO DEVEDOR Identifica o logradouro do Usuário Devedor

UF DO DEVEDOR Identifica a UF do Usuário Devedor

EXCLUSIVO PSP RECEBEDOR Exclusivo PSP Recebedor

BRANCOS Uso reservado do Banco

NÚMERO SEQUENCIAL Identifica o número sequencial do registro

16.6 CAMPOS DO TRAILLER REMESSA

NOME DO CAMPO SIGNIFICADO

TIPO DE REGISTRO Identificação do registro header

BRANCOS Uso reservado do Banco

VALOR TOTAL Valor total de registros

QUANTIDADE DE REGISTROS Quantidade total de registros

NÚMERO SEQUENCIAL Número sequencial do registro no arquivo

17 CAMPOS E PARÂMETROS DA API

17.1 API PIX
FONTE: GITHUB BACEN (2.8.1) e MANUAL DE PADRÕES PARA INICIAÇÃO DO PIX
A API Pix busca respeitar SemVer. Nesse sentido, mudanças compatíveis não devem
gerar nova versão major.
A versão da API é composta por 4 elementos: major, minor, patch e release candidate.

MO38503 - Documento Técnico - Convênio Pix Automático

 27

A versão v[x] que consta no path da URL é o elemento major da versão da API. A
evolução da versão se dá seguinte forma:
• Major: alterações incompatíveis, com quebra de contrato (v1.0.0 → v2.0.0)
• Minor: alterações compatíveis, sem quebra de contrato (v1.1.0 → v1.2.0)
• Patch: bugfixes, esclarecimentos às especificações, sem alterações funcionais
(v1.1.1 → v1.1.2)
• Release candidate: versões de pré-lançamento de qualquer patch futuro, minor
ou major (v1.0.0-rc.1 → v1.0.0-rc.22)
Alterações sem quebra de contrato e esclarecimentos às especificações podem ocorrer
a qualquer momento. Clientes devem estar preparados para lidar com essas mudanças
sem quebrar.
As seguintes mudanças são esperadas e consideradas retrocompatíveis:
• Adição de novos recursos na API Pix;
• Adição de novos parâmetros opcionais;
• Adição de novos campos em respostas da API Pix;
• Alteração da ordem de campos;
• Adição de novos elementos em enumerações.

17.2 TAGS DA API PIX – FONTE: BACEN

Funcionalidades obrigatórias para o Pix Automático:

tags Pix Automático

Cob Apenas para a Jornada 3 de autorização.
CobV Apenas para a Jornada 4 de autorização.
Pix Sim
PayloadLocation Apenas para as jornadas 3 e 4 de autorização.
PayloadLocationRec Para as jornadas 2, 3 e 4 de autorização.
CobPayload Apenas para as jornadas 3 e 4 de autorização.
Webhook Apenas para a Jornada 3 de autorização.
WebhookRec Sim
WebhookCobR Sim
Rec Sim
CobR Sim
SolicRec Apenas para a jornada 1 de autorização.
RecPayload Para as jornadas 2, 3 e 4 de autorização.

A API Pix está estruturada em torno de algumas entidades de negócio, que agrupam
conjuntos de atributos, conforme definido abaixo:
I - Cobrança (/cob e /cobv): representa cada uma das cobranças geradas por meio da
API Pix, a fim de permitir que o usuário pagador efetue um pagamento identificado para
o usuário recebedor. A cobrança é caracterizada por um conjunto de informações que
são utilizadas para que o usuário pagador execute um pagamento por meio do Pix,
geralmente, em função de acordo comercial entre o usuário pagador e o usuário

MO38503 - Documento Técnico - Convênio Pix Automático

 28

recebedor, sem se confundir com o pagamento Pix em si. A cobrança se subdivide em

duas espécies: cobranças para pagamento imediato e cobranças para pagamento com
vencimento.
Estados da cobrança:
a) ATIVA: indica que a cobrança foi gerada e pronta para ser paga;
b) CONCLUÍDA: indica que a cobrança já foi paga e, por conseguinte, não pode
acolher outro pagamento75;
c) REMOVIDO_PELO_USUARIO_RECEBEDOR: indica que o usuário
recebedor solicitou a remoção da cobrança; e
d) REMOVIDO_PELO_PSP: indica que o PSP Recebedor solicitou a remoção
da cobrança.
II - Pix (/pix): representa um pagamento recebido por meio do arranjo de pagamentos
Pix.
III - Devolução (devolução): representa uma solicitação de devolução de um Pix
realizado, cujos fundos já se encontrem disponíveis na conta transacional do usuário
recebedor.
Estados da devolução:
a) EM_PROCESSAMENTO: indica que a devolução foi solicitada, mas ainda
está em processamento no SPI;
b) DEVOLVIDO: indica que a devolução foi liquidada pelo SPI; e
c) NAO_REALIZADO: indica que a devolução não pode ser realizada em função
de algum erro durante a liquidação (exemplo: saldo insuficiente).
IV – Webhook (/webhook): é um recurso técnico que permite que o PSP Recebedor
informe diretamente o usuário recebedor quando um Pix associado a um txid foi
creditado na sua conta transacional. Nesse caso, a lógica do processo é invertida em
relação ao funcionamento padrão da API, para garantir uma melhor performance ao
processo. O usuário recebedor deixa de consultar o PSP Recebedor a todo momento
(polling) e passa a ser informado na ocorrência de uma liquidação. Somente Pix
associados a um txid serão informados via a funcionalidade webhook.
V – PayloadLocation) (/loc): é um recurso que permite ao PSP Recebedor reusar uma
URL, retornando diferentes cobranças (payloads JSON) ao longo do tempo, mas apenas
uma por vez. Tipicamente, é utilizado quando o usuário recebedor precisa apresentar
um QR Code impresso, mas que seja dinâmico.
VI – CobPayload: utilizado pelo software do PSP pagador para recuperar o payload
JSON que representa uma cobrança imediata ou com vencimento.
VII – Recorrência (/rec): contém informações da recorrência, utilizada no contexto do
Pix Automático.
Estados da recorrência:
a) CRIADA: indica que a recorrência foi criada pelo usuário recebedor;
b) APROVADA: indica que a recorrência foi aceita pelo usuário pagador;

MO38503 - Documento Técnico - Convênio Pix Automático

 29

c) REJEITADA: indica que a recorrência foi rejeitada pelo usuário pagador

(ocorre apenas na Jornada 1 de autorização);
d) EXPIRADA: indica que a data final da recorrência já passou;
e) CANCELADA: indica que a recorrência foi cancelada pelo usuário recebedor
ou pelo usuário pagador.
VIII – Solicitação de confirmação de recorrência (/solicrec): representa uma
solicitação de confirmação de recorrência do Pix Automático, enviada nos casos da
Jornada 1 de autorização.
Estados da solicitação de confirmação de recorrência:
a) CRIADA: indica que a solicitação foi criada pelo usuário recebedor;
b) ENVIADA: indica que o PSP Recebedor enviou a solicitação para o PSP
Pagador;
c) RECEBIDA: indica que o PSP Pagador recebeu a solicitação de confirmação
de recorrência e ela está aguardando a ação do usuário pagador;
d) REJEITADA: indica que a solicitação foi rejeitada pelo PSP Pagador por
algum erro (como conta inexistente) ou que foi rejeitada pelo usuário pagador no
momento da oferta de adesão ao Pix Automático;
e) ACEITA: indica que o usuário pagador aceitou a solicitação de confirmação
de recorrência;
f) EXPIRADA: indica que a data de expiração da solicitação de confirmação de
recorrência já passou, sem que ela tenha tido uma resposta do usuário pagador;
g) CANCELADA: indica que a solicitação foi cancelada por algum dos seguintes
motivos:
1 – a recorrência à qual ela está associada foi cancelada;
2 – a recorrência à qual ela está associada foi confirmada por alguma
outra jornada de adesão ao Pix Automático;
3 – o recebedor solicitou o cancelamento por algum erro, caso ela ainda
não tenha sido confirmada ou rejeitada pelo usuário pagador; ou
4 – PSP recebedor solicita cancelamento por timeout: o PSP recebedor
não recebeu a confirmação do recebimento da mensagem com a
solicitação dentro do prazo limite de 1 minuto.
IX – Cobrança recorrente (/cobr): representa uma cobrança recorrente do Pix
Automático.
Estados da cobrança recorrente:
a) CRIADA: indica que a cobrança foi criada pelo usuário recebedor;
b) ATIVA: indica que a cobrança foi enviada pelo PSP Recebedor ao PSP
Pagador;
c) CONCLUIDA: indica que a cobrança foi paga;

MO38503 - Documento Técnico - Convênio Pix Automático

 30

d) EXPIRADA: indica que a cobrança não foi quitada após expiradas todas as
tentativas de pagamento permitidas pela política vigente;
e) REJEITADA: indica que a cobrança foi rejeitada pelo PSP Pagador;
f) CANCELADA: indica que a cobrança foi cancelada pelo usuário recebedor ou
pelo usuário pagador.
X – WebhookRec (/webhookrec): é um recurso técnico que permite que o PSP
Recebedor informe diretamente ao usuário recebedor informações sobre as
recorrências. Assim como no Webhook para as cobranças, aqui se aplicam as
notificações como forma de evitar polling em cima dos dados de recorrência.
XI – WebhookCobR (/webhookcobr): é um recurso técnico que permite que o PSP
Recebedor informe diretamente ao usuário recebedor informações sobre as cobranças
recorrentes. Assim como no Webhook para as cobranças, aqui se aplicam as
notificações como forma de evitar polling em cima dos dados das cobranças recorrentes.
XII – PayloadLocationRec (/locRec): é um recurso que permite ao PSP Recebedor
reusar uma URL, retornando diferentes parâmetros de recorrência (payloads JSON) ao
longo do tempo, mas apenas uma por vez. É utilizado quando o usuário recebedor
precisa gerar um novo QR Code composto ou reutilizar um existente.
XIII – RecPayload: utilizado pelo software do PSP pagador para recuperar o payload
JSON que representa uma recorrência.

IMPORTANTE!
I – Uma Cobrança pode estar associada a um ou mais Pix (mesmo
txid);
II – Um Pix pode estar associado a uma única Cobrança. O Pix, no
entanto, pode existir independentemente da existência de uma
Cobrança;
III – Um Pix pode ter uma ou mais Devoluções associadas a ele. Uma
Devolução está sempre associada a um Pix;
IV – Uma Cobrança somente pode estar associada a um
PayloadLocation e, em um determinado momento, o
PayloadLocation só pode estar associado a uma Cobrança;
V – Uma Recorrência pode estar associada a uma ou mais
Solicitações de Recorrência;
VI – Uma Solicitação de Recorrência está associada a uma única
Recorrência;
VII – Uma Recorrência pode estar associada a várias Cobranças
Recorrentes;
VIII – Uma Cobrança Recorrente está associada a uma única
Recorrência;

MO38503 - Documento Técnico - Convênio Pix Automático

 31

IX – Uma Cobrança Recorrente pode estar associada a um ou mais

Pix (mesmo txid);
X – Uma Recorrência somente pode estar associada a um
PayloadLocationRec e, em um determinado momento, o
PayloadLocationRec só pode estar associado a uma Recorrência.

17.3 TRATAMENTO DE ERROS

FONTE: GITHUB BACEN (2.8.1)

A API Pix retorna códigos de status HTTP para indicar sucesso ou falhas das
requisições, são eles:
• Códigos 2xx indicam sucesso;
• Códigos 4xx indicam falhas causadas pelas informações enviadas pelo cliente
ou pelo estado atual das entidades e;
• Códigos 5xx indicam problemas no serviço no lado da API Pix.
As respostas de erro incluem no corpo detalhes do erro seguindo o schema da RFC
7807.
O campo type identifica o tipo de erro e na API Pix segue o padrão:
https://pix.bcb.gov.br/api/v2/error/<TipoErro>
O padrão acima listado, referente ao campo type, não consiste, necessariamente, em
uma URL que apresentará uma página web válida, ou um endpoint válido, embora
possa, futuramente, ser exatamente o caso. O objetivo primário é apenas e tão somente
identificar o tipo de erro.
Convém reforçar que a API Pix contempla uma lista de produtos e respectivas
funcionalidades ofertadas pelo PSP recebedor. Cabe à relação contratual com cada
usuário recebedor a concessão da totalidade ou de um subconjunto de acessos
relacionados aos produtos ofertados. Por exemplo, o usuário recebedor, ao acessar uma
funcionalidade não contemplada no seu escopo contratual, receberá o erro
geral AcessoNegado descrito na próxima seção.
Abaixo estão listados os tipos de erro e possíveis violações da API Pix.
Gerais
Esta seção reúne erros que poderiam ser retornados por quaisquer endpoints listados
na API Pix.
RequisicaoInvalida
• Significado: Requisição inválida.
• HTTP Status Code: 400 Bad Request.
AcessoNegado

MO38503 - Documento Técnico - Convênio Pix Automático

 32

• Significado: Requisição de participante autenticado que viola alguma regra de

autorização.
• HTTP Status Code: 403 Forbidden.
NaoEncontrado
• Significado: Entidade não encontrada.
• HTTP Status Code: 404 Not Found.
PermanentementeRemovido
• Significado: Indica que a entidade existia, mas foi permanentemente removida.
• HTTP Status Code: 410 Gone.
ErroInternoDoServidor
• Significado: Condição inesperada ao processar requisição.
• HTTP Status Code: 500 Internal Server Error.
ServicoIndisponivel
• Significado: Serviço não está disponível no momento. Serviço solicitado pode
estar em manutenção ou fora da janela de funcionamento.
• HTTP Status Code: 503 Service Unavailable.
IndisponibilidadePorTempoEsgotado
• Significado: Indica que o serviço demorou além do esperado para retornar.
• HTTP Status Code: 504 Gateway Timeout.
Tag CobPayload
Esta seção reúne erros retornados pelos endpoints organizados sob a tag CobPayload.
Estes erros indicam problemas na tentativa de recuperação, via location, do Payload
JSON que representa a cobrança.
CobPayloadNaoEncontrado
• Significado: a cobrança em questão não foi encontrada para a location
requisitada.
• HTTP Status Code: 404 ou 410.
• endpoints: GET /{pixUrlAccessToken}, GET /cobv/{pixUrlAccessToken}.
Se a presente location exibia uma cobrança, mas não a exibirá mais de maneira
permanentemente, pode-se aplicar o HTTP status code 410. Se a presente location não
está exibindo nenhuma cobrança, pode-se utilizar o HTTP status code 404.
Uma cobrança pode estar "expirada" (calendario.expiracao), "vencida", "Concluida",
entre outros estados em que não poderia ser efetivamente paga. Nesses casos, é uma
liberalidade do PSP recebedor retornar o presente código de erro ou optar por servir o
payload de qualquer maneira, objetivando fornecer uma informação adicional ao usuário
pagador final a respeito da cobrança.

MO38503 - Documento Técnico - Convênio Pix Automático

 33

CobPayloadOperacaoInvalida
• Significado: a cobrança existe, mas a requisição é inválida.
• HTTP Status Code: 400.
• endpoints: GET /cobv/{pixUrlAccessToken}.
Violações:
• codMun não respeita o schema.
• codMun não é um código válido segundo a tabela de municípios do IBGE.
• DPP não respeita o schema.
• DPP anterior ao momento presente.
• DPP superior à validade da cobrança em função dos
parâmetros calendario.dataDeVencimento e calendario.validadeAposVenci
mento. Exemplo: dataDeVencimento => 2020-12-
25, validadeAposVencimento => 10, DPP => 2021-01-05. Neste exemplo, o
parâmetro DPP é inválido considerando o contexto apresentado porque é uma
data em que a cobrança não poderá ser paga. A cobrança, neste exemplo, não
será considerada válida a partir da data 2021-01-05.
Tag RecPayload
Esta seção reúne erros retornados pelos endpoints organizados sob a tag RecPayload.
Estes erros indicam problemas na tentativa de recuperação, via location, do Payload
JSON que representa a recorrência.
RecPayloadNaoEncontrado
• Significado: a recorrência em questão não foi encontrada para a location
requisitada.
• HTTP Status Code: 404 ou 410.
• endpoint: GET /rec/{recUrlAccessToken}.
Se a presente location exibia uma recorrência, mas não a exibirá mais de maneira
permanentemente, pode-se aplicar o HTTP status code 410. Se a presente location não
está exibindo nenhuma recorrência, pode-se utilizar o HTTP status code 404.
Uma recorrência pode estar encerrada, cancelada ou rejeitada, nesses casos, é uma
liberalidade do PSP recebedor retornar o presente código de erro ou optar por servir o
payload de qualquer maneira, objetivando fornecer uma informação adicional ao usuário
pagador final a respeito da recorrência.
RecPayloadOperacaoInvalida
• Significado: a recorrência em questão encontra-se em encerrada, rejeitada ou
cancelada para a location requisitada.
• HTTP Status Code: 400.
• endpoint: GET /rec/{recUrlAccessToken}.
Violações para o endpoint GET /rec/{recUrlAccessToken}:

MO38503 - Documento Técnico - Convênio Pix Automático

 34

• O campo recUrlAccessToken referencia uma recorrência encerrada, rejeitada

ou cancelada.
Tag Rec
Esta seção reúne erros retornados pelos endpoints organizados sob a tag Rec. Esses
erros indicam problemas no gerenciamento de uma recorrência.
RecNaoEncontrada
• Significado: Recorrência não encontrada para o idRec informado.
• HTTP Status Code: 404.
• endpoints: [GET|PATCH] /rec/{idRec}.
RecOperacaoInvalida
• Significado: a requisição que busca alterar ou criar uma recorrência não
respeita o schema ou está semanticamente errada.
• HTTP Status Code: 400.
• endpoints: POST /rec e PATCH /rec/{idRec}.
Violações para o endpoint POST /rec:
• O objeto rec.vinculo não respeita o schema.
• O campo rec.calendario.dataInicial é anterior à data de criação da recorrência.
• O campo rec.calendario.dataFinal é anterior ao
campo rec.calendario.dataInicial.
• O campo rec.calendario.periodicidade não respeita o schema.
• O objeto rec.valor não respeita o schema.
• O campo rec.valor.valorRec não respeita o schema.
• O campo rec.valor.valorMinimoRecebedor não respeita o schema.
• Ambos os
campos rec.valor.valorRec e rec.valor.valorMinimoRecebedor estão
preenchidos.
• O objeto rec.recebedor não respeita o schema.
• O campo rec.politicaRetentativa não respeita o schema.
• O location referenciado por rec.loc inexiste.
• O location referenciado por rec.loc já está sendo utilizado por outra recorrência.
• O valor do campo rec.recebedor.convenio não é aceito pelo PSP Recebedor.
Violações para o endpoint PATCH /rec/{idRec}:
• O campo rec.calendario.dataInicial é anterior à data de criação da recorrência.
• O location referenciado por rec.loc inexiste.

MO38503 - Documento Técnico - Convênio Pix Automático

 35

• O location referenciado por rec.loc já está sendo utilizado por outra recorrência.
• O campo rec.status não respeita o schema.
• A recorrência encontra-se encerrada.
• O campo rec.loc somente pode ser alterado quando a recorrência apresentar-
se com o status CRIADA.
• O campo rec.calendario.dataInicial somente pode ser alterado quando a
recorrência apresentar-se com o status CRIADA.
• O campo rec.dadosJornada.txid não pode ser alterado quando a recorrência
apresentar-se com o status REJEITADA ou CANCELADA.
RecConsultaInvalida
• Significado: os parâmetros de consulta à lista de recorrências que não
respeitam o schema ou não fazem sentido semanticamente.
• HTTP Status Code: 400.
• endpoints: GET /rec e GET /rec/{idRec}.
Violações específicas para o endpoint GET /rec:
• algum dos parâmetros informados para a consulta não respeita o schema.
• o timestamp representado pelo parâmetro fim é anterior ao timestamp
representado pelo parâmetro inicio.
• ambos os parâmetros cpf e cnpj estão preenchidos.
• o parâmetro paginacao.paginaAtual é negativo.
• o parâmetro paginacao.itensPorPagina é negativo.
Violações específicas para o endpoint GET /rec/{idRec}:
• o parâmetro txid não corresponde a uma cobrança compatível com o
campo ativacao.tipoJornada. (Exemplo: txid correspondente a uma CobV
e ativação.tipoJornada igual a JORNADA_3.)
• o parâmetro txid corresponde a uma cobrança imediata diferente da informada
no campo ativação.dadosJornada.txid. Esta violação não ocorre caso o
parâmetro txid corresponda a uma cobrança com vencimento.
Tag SolicRec
Esta seção reúne erros retornados pelos endpoints organizados sob a tag SolicRec.
Esses erros indicam problemas no gerenciamento de uma solicitação de confirmação
de recorrência.
SolicRecNaoEncontrada
• Significado: Solicitação de recorrência não encontrada para o idSolicRec
informado.
• HTTP Status Code: 404.
• endpoints: [GET] /solicrec/{idSolicRec}.

MO38503 - Documento Técnico - Convênio Pix Automático

 36

SolicRecOperacaoInvalida
• Significado: a requisição que busca criar ou alterar uma solicitação de
confirmação de recorrência não respeita o schema ou está semanticamente
errada.
• HTTP Status Code: 400.
• endpoints: [POST] /solicrec e PATCH /solicrec/{idSolicRec}.
Violações para o endpoint POST /solicrec:
• O objeto solicrec.calendario não respeita o schema.
• O campo solicrec.calendario.dataExpiracaoSolicitacao é anterior à data de
criação da solicitação da recorrência.
• O objeto solicrec.destinatario não respeita o schema.
• Existe uma solicitação ativa referente ao mesmo solicrec.idRec.
Violações para o endpoint PATCH /solicrec/{idSolicRec}:
• Não é possível cancelar uma solicitação de recorrência com o status diferente
de CRIADA, ENVIADA ou RECEBIDA.
Tag CobR
Esta seção reúne erros retornados pelos endpoints organizados sob a tag CobR. Esses
erros indicam problemas no gerenciamento de uma cobrança recorrente.
CobRNaoEncontrado
• Significado: Cobrança não encontrada para o txid informado.
• HTTP Status Code: 404.
• endpoints: [GET|PATCH] /cobr/{txid} e [POST]
/cobr/{txid}/retentativa/{data}.
CobROperacaoInvalida
• Significado: a requisição que busca alterar ou criar uma cobrança recorrente
não respeita o schema ou está semanticamente errada.
• HTTP Status Code: 400.
• endpoints: [POST|PUT|PATCH] /cobr/{txid} e [POST]
/cobr/{txid}/retentativa/{data}.
Violações para o endpoint POST|PUT /cobr/{txid}:
• O campo cobr.infoAdicional não respeita o schema.
• O campo cobr.status não respeita o schema.
• O objeto cobr.calendario não respeita o schema.
• O campo cobr.calendario.dataDeVencimento é anterior à data de criação da
cobrança.
• O campo cobr.valor não respeita o schema.

MO38503 - Documento Técnico - Convênio Pix Automático

 37

• O objeto cobr.recebedor não respeita o schema.

• Os campos cobr.recebedor.conta e cobr.recebedor.agencia correspondem a
uma conta que não pertence a este usuário recebedor.
• O objeto cobr.devedor não respeita o schema.
• O campo cobr.txid encontra-se em uso.
• Existe uma CobR com status diferente de REJEITADA e CANCELADA referente
ao mesmo cobr.idRec com calendario.dataDeVencimento no mesmo ciclo.
Violações para o endpoint PATCH /cobr/{txid}:
• Não é possível cancelar uma cobrança em uma data igual ou maior que a data
prevista da primeira tentativa de liquidação.
Violações para o endpoint POST /cobr/{txid}/retentativa/{data}:
• Existe uma tentativa com status SOLICITADA ou AGENDADA.
• Existe uma tentativa em andamento.
• Existe uma tentativa ativa.
• Existe uma tentativa não finalizada.
• Existe uma tentativa vigente para a data informada.
• O parâmetro data não corresponde a uma data futura.
• A política configurada na recorrência não permite retentativa de cobrança.
CobRConsultaInvalida
• Significado: os parâmetros de consulta à lista de cobranças que não respeitam
o schema ou não fazem sentido semanticamente.
• HTTP Status Code: 400.
• endpoints: GET /cobr e GET /cobr/{txid}.
Violações específicas para o endpoint GET /cobr:
• algum dos parâmetros informados para a consulta não respeita o schema.
• o timestamp representado pelo parâmetro fim é anterior ao timestamp
representado pelo parâmetro inicio.
• ambos os parâmetros cpf e cnpj estão preenchidos.
• o parâmetro paginacao.paginaAtual é negativo.
• o parâmetro paginacao.itensPorPagina é negativo.
Tag Cob
Esta seção reúne erros retornados pelos endpoints organizados sob a tag Cob. Esses
erros indicam problemas no gerenciamento de uma cobrança para pagamento imediato.
CobNaoEncontrado

MO38503 - Documento Técnico - Convênio Pix Automático

 38

• Significado: Cobrança não encontrada para o txid informado.

• HTTP Status Code: 404.
• endpoints: [GET|PATCH] /cob/{txid}.
CobOperacaoInvalida
• Significado: a requisição que busca alterar ou criar uma cobrança para
pagamento imediato não respeita o schema ou está semanticamente errada.
• HTTP Status Code: 400.
• endpoints: [POST|PUT|PATCH] /cob/{txid}.
Violações para os endpoints PUT|PATCH /cob/{txid}:
• O campo cob.calendario.expiracao é igual ou menor que zero.
• O campo cob.valor.original não respeita o schema.
• O campo cob.valor.original é zero.
• O objeto cob.devedor não respeita o schema.
• O campo cob.chave não respeita o schema.
• O campo cob.chave corresponde a uma conta que não pertence a este usuário
recebedor.
• O campo solicitacaoPagador não respeita o schema.
• O objeto infoAdicionais não respeita o schema.
• O location referenciado por loc.id inexiste.
• O location referenciado por loc.id já está sendo utilizado por outra cobrança.
• O location referenciado por cob.loc.id apresenta tipo "cobv" (deveria ser
"cob").
Violações específicas para o endpoint PUT /cob/{txid}:
• A cobrança já existe, não está no status ATIVA, e a presente requisição busca
alterá-la.
Violações específicas para o endpoint PATCH /cob/{txid}:
• A cobrança não está ATIVA, e a presente requisição busca alterá-la.
• A cobrança está ATIVA, e a presente requisição propõe alterar seu status
para REMOVIDA_PELO_USUARIO_RECEBEDOR juntamente com outras
alterações (não faz sentido remover uma cobrança ao mesmo tempo em que se
realizam alterações que não serão aproveitadas).
• o campo cob.status não respeita o schema.
CobConsultaInvalida
• Significado: os parâmetros de consulta à lista de cobranças para pagamento
imediato não respeitam o schema ou não fazem sentido semanticamente.

MO38503 - Documento Técnico - Convênio Pix Automático

 39

• HTTP Status Code: 400.

• endpoints: GET /cob e GET /cob/{txid}.
Violações específicas para o endpoint GET /cob:
• algum dos parâmetros informados para a consulta não respeita o schema.
• o timestamp representado pelo parâmetro fim é anterior ao timestamp
representado pelo parâmetro inicio.
• ambos os parâmetros cpf e cnpj estão preenchidos.
• o parâmetro paginacao.paginaAtual é negativo.
• o parâmetro paginacao.itensPorPagina é negativo.
Violações específicas para o endpoint GET /cob/{txid}:
• o parâmetro revisao corresponde a uma revisão inexistente para a cobrança
apontada pelo parâmetro txid.
Tag CobV
Esta seção reúne erros retornados pelos endpoints organizados sob a tag CobV. Esses
erros indicam problemas no gerenciamento de uma cobrança com vencimento.
CobVNaoEncontrada
• Significado: Cobrança com vencimento não encontrada para o txid informado.
• HTTP Status Code: 404.
• endpoints: [GET|PATCH] /cobv/{txid}.
CobVOperacaoInvalida
• Significado: a requisição que busca alterar ou criar uma cobrança com
vencimento não respeita o schema ou está semanticamente errada.
• HTTP Status Code: 400.
• endpoints: [PUT|PATCH] /cobv/{txid}.
Violações para os endpoints PUT|PATCH /cobv/{txid}:
• Este txid está associado a um lote e no referido lote, o status desta cobrança
está atribuído como "EM_PROCESSAMENTO" ou "NEGADA".
• O campo cobv.calendario.dataDeVencimento é anterior à data de criação da
cobrança.
• O campo cobv.calendario.validadeAposVencimento é menor do que zero.
• O objeto cobv.devedor não respeita o schema.
• O objeto cobv.devedor não respeita o schema.
• O campo cobv.chave não respeita o schema.
• O campo cobv.chave corresponde a uma conta que não pertence a este usuário
recebedor.

MO38503 - Documento Técnico - Convênio Pix Automático

 40

• O campo solicitacaoPagador não respeita o schema.

• O objeto infoAdicionais não respeita o schema.
• O location referenciado por cobv.loc.id inexiste.
• O location referenciado por cobv.loc.id já está sendo utilizado por outra
cobrança.
• O location referenciado por cobv.loc.id apresenta tipo "cob" (deveria ser
"cobv").
• O campo cobv.valor.original não respeita o schema.
• O campo cobv.valor.original apresenta o valor zero.
• O objeto cobv.valor.multa não respeita o schema.
• O objeto cobv.valor.juros não respeita o schema.
• O objeto cobv.valor.abatimento não respeita o schema.
• O objeto cobv.valor.desconto não respeita o schema.
• O objeto cobv.valor.abatimento representa um valor maior ou igual ao valor da
cobrança original ou maior ou igual a 100%.
• O objeto cobv.valor.desconto apresenta algum elemento de desconto que
representa um valor maior ou igual ao valor da cobrança original ou maior ou
igual a 100%.
• O objeto cobv.valor.desconto apresenta algum elemento cuja data seja
posterior à data de vencimento representada
por calendario.dataDeVencimento.
• O objeto cobv.valor.desconto apresenta modalidade no valor 1 ou 2,
porém cobv.valor.desconto.valorPerc encontra-se preenchido
• O objeto cobv.valor.desconto apresenta modalidade no valor 1 ou 2, porém o
array cobv.valor.desconto.descontoDataFixa está vazio ou nulo.
• O objeto cobv.valor.desconto apresenta modalidade nos valores de 3 a 6,
porém o elemento cobv.valor.desconto.valorPerc não está preenchido.
• O objeto cobv.valor.desconto apresenta modalidade nos valores de 3 a 6,
porém o elemento cobv.valor.desconto.descontoDataFixa está preenchido ou
não nulo.
Violações específicas para o endpoint PUT /cobv/{txid}:
• A cobrança já existe, não está ATIVA, e a presente requisição busca alterá-la
Violações específicas para o endpoint PATCH /cobv/{txid}:
• A cobrança não está ATIVA, e a presente requisição busca alterá-la
• A cobrança está ATIVA, e a presente requisição propõe alterar seu status
para REMOVIDA_PELO_USUARIO_RECEBEDOR juntamente com outras
alterações (não faz sentido remover uma cobrança ao mesmo tempo em que se
realizam alterações que não serão aproveitadas).

MO38503 - Documento Técnico - Convênio Pix Automático

 41

• o campo cob.status não respeita o schema.

CobVConsultaInvalida
• Significado: os parâmetros de consulta à lista de cobranças com vencimento
não respeitam o schema ou não fazem sentido semanticamente.
• HTTP Status Code: 400.
• endpoints: GET /cobv e GET /cobv/{txid}.
Violações específicas para o endpoint GET /cobv:
• algum dos parâmetros informados para a consulta não respeita o schema.
• o timestamp representado pelo parâmetro fim é anterior ao timestamp
representado pelo parâmetro inicio.
• ambos os parâmetros cpf e cnpj estão preenchidos.
• o parâmetro paginacao.paginaAtual é negativo.
• o parâmetro paginacao.itensPorPagina é negativo.
Violações específicas para o endpoint GET /cobv/{txid}:
• o parâmetro revisao corresponde a uma revisão inexistente para a cobrança
apontada pelo parâmetro txid.
Tag LoteCobV
Esta seção reúne erros referentes a endpoints que tratam do gerenciamento de lotes de
cobrança.
LoteCobVNaoEncontrado
• Significado: Lote não encontrado para o id informado.
• HTTP Status Code: 404.
• endpoints: [GET|PATCH] /lotecobv/{id}.
LoteCobVOperacaoInvalida
• Significado: a requisição que busca alterar ou criar um lote de cobranças com
vencimento não respeita o schema ou está semanticamente errada.
• HTTP Status Code: 400.
• endpoints: [PUT|PATCH] /lotecobv/{id}.
Violações para os endpoints PUT|PATCH /lotecobv/{id}:
• O campo loteCobV.descricao não respeita o schema.
• O objeto loteCobV.cobsV não respeita o schema.
Violações para o endpoint PUT /lotecobv/{id}:
• a presente requisição tenta criar um conjunto de cobranças dentre as quais pelo
menos uma cobrança já encontra-se criada.

MO38503 - Documento Técnico - Convênio Pix Automático

 42

• a presente requisição busca alterar um lote já existente, entretanto contém um

array de solicitações de alteração de cobranças que não referencia exatamente
as mesmas cobranças referenciadas pela requisição original que criou o lote.
Uma vez criado um lote, não se pode remover ou adicionar solicitações de
criação ou alteração de cobranças a este lote.
Violações para o endpoint PATCH /lotecobv/{id}:
• a presente requisição busca alterar um lote já existente e contém, no array de
cobranças representado por cobsv, uma cobrança não existente no array de
cobranças atribuído pela requisição original que criou o lote. Uma vez criado um
lote, não se pode remover ou adicionar cobranças a este lote.
Violações para os endpoints GET /lotecobv/{id}:
• observação: para cada elemento do array cobsv, retornado por este endpoint,
caso a requisição de criação de cobrança esteja em status "NEGADA", o
atributo problema deste elemento deve ser preenchido respeitando
o schema referenciado pela API Pix.
• o preenchimento do atributo problema, conforme descrito acima, segue o
mesmo regramento dos erros especificados para os endpoints [PUT/PATCH
/cobv/{txid}], de maneira a possibilitar, ao usuário recebedor, entender qual foi
a violação cometida ao se tentar criar a cobrança referenciada por este elemento
do array cobsv.
LoteCobVConsultaInvalida
• Significado: os parâmetros de consulta à lista de lotes de cobrança com
vencimento não respeitam o schema ou não fazem sentido semanticamente.
• HTTP Status Code: 400.
• endpoints: GET /lotecobv e GET /lotecobv/{id}.
Violações específicas para o endpoint GET /lotecobv:
• algum dos parâmetros informados para a consulta não respeitam o schema.
• o timestamp representado pelo parâmetro fim é anterior ao timestamp
representado pelo parâmetro inicio.
• o parâmetro paginacao.paginaAtual é negativo.
• o parâmetro paginacao.itensPorPagina é negativo.
Tag PayloadLocation
Esta seção reúne erros referentes a endpoints que tratam do gerenciamento
de locations.
PayloadLocationNaoEncontrado
• Significado: Location não encontrada para o id informado.
• HTTP Status Code: 404.
• endpoints: [GET|PATCH] /loc/{id}, DELETE /loc/{id}/txid.
PayloadLocationOperacaoInvalida

MO38503 - Documento Técnico - Convênio Pix Automático

 43

• Significado: a presente requisição busca criar uma location sem respeitar

o schema estabelecido.
• HTTP Status Code: 400.
• endpoints: POST /loc.
Violações para o endpoint POST /loc:
• o campo tipoCob não respeita o schema.
PayloadLocationConsultaInvalida
• Significado: os parâmetros de consulta à lista de locations não respeitam
o schema ou não fazem sentido semanticamente.
• HTTP Status Code: 400.
• endpoints: GET /loc e GET /loc/{id}.
Violações específicas para o endpoint GET /loc:
• algum dos parâmetros informados para a consulta não respeitam o schema.
• o timestamp representado pelo parâmetro fim é anterior ao timestamp
representado pelo parâmetro inicio.
• o parâmetro paginacao.paginaAtual é negativo.
• o parâmetro paginacao.itensPorPagina é negativo.
Tag PayloadLocationRec
Esta seção reúne erros referentes a endpoints que tratam do gerenciamento
de locations de uma recorrência.
PayloadLocationRecNaoEncontrado
• Significado: Location não encontrada para o id informado.
• HTTP Status Code: 404.
• endpoints: [GET] /locrec/{id}, DELETE /locrec/{id}/idRec.
PayloadLocationRecConsultaInvalida
• Significado: os parâmetros de consulta à lista de locations não respeitam
o schema ou não fazem sentido semanticamente.
• HTTP Status Code: 400.
• endpoints: GET /locrec e GET /locrec/{id}.
Violações específicas para o endpoint GET /locrec:
• algum dos parâmetros informados para a consulta não respeitam o schema.
• o timestamp representado pelo parâmetro fim é anterior ao timestamp
representado pelo parâmetro inicio.
• o parâmetro paginacao.paginaAtual é negativo.

MO38503 - Documento Técnico - Convênio Pix Automático

 44

• o parâmetro paginacao.itensPorPagina é negativo.

Tag Pix
Reúne erros em endpoints de gestão de Pix recebidos e solicitação de devoluções.
PixNaoEncontrado
• Significado: pix não encontrada para o e2eid informado.
• HTTP Status Code: 404.
• endpoints: GET /pix/{e2eid}
PixDevolucaoNaoEncontrada
• Significado: devolução representada por {id} não encontrada para
o e2eid informado.
• HTTP Status Code: 404.
• endpoints: GET /pix/{e2eid}/devolucao/{id}
PixConsultaInvalida
• Significado: os parâmetros de consulta à lista de pix recebidos não respeitam o
schema ou não fazem sentido semanticamente.
• HTTP Status Code: 400.
• endpoints: GET /pix.
Violações específicas para o endpoint GET /pix:
• algum dos parâmetros informados para a consulta não respeita o schema.
• o timestamp representado pelo parâmetro fim é anterior ao timestamp
representado pelo parâmetro inicio.
• ambos os parâmetros cpf e cnpj estão preenchidos.
• o parâmetro paginacao.paginaAtual é negativo.
• o parâmetro paginacao.itensPorPagina é negativo.
PixDevolucaoInvalida
• Significado: a presente requisição de devolução não respeita o schema ou não
faz sentido semanticamente.
• HTTP Status Code: 400.
• endpoints: PUT /pix/{e2eid}/devolucao/{id}.
Violações específicas para o endpoint PUT /pix/{e2eid}/devolucao/{id}:
• O campo devolucao.valor não respeita o schema.
• A presente requisição de devolução, em conjunto com as demais prévias
devoluções, se aplicável, excederia o valor do pix originário.

MO38503 - Documento Técnico - Convênio Pix Automático

 45

• A presente requisição de devolução apresenta um {id} já utilizado por outra

requisição de devolução para o {e2eid} em questão.
• A presente requisição de devolução viola a janela de tempo permitida para
solicitações de devoluções de um pix (hoje estabelecida como 90 dias desde a
data de liquidação original do pix).
Tag Webhook
Reúne erros dos endpoints que tratam do gerenciamento dos Webhooks da API Pix.
WebhookOperacaoInvalida
• Significado: a presente requisição busca criar um webhook sem respeitar
o schema ou, ainda, apresenta semântica inválida.
• HTTP Status Code: 400.
• endpoints: PUT /webhook/{chave}.
Violações para o endpoint PUT /webhook/{chave}:
• o parâmetro {chave} não corresponde a uma chave DICT válida.
• o parâmetro {chave} não corresponde a uma chave DICT pertencente a este
usuário recebedor.
• Campo webhook.webhookUrl não respeita o schema.
WebhookNaoEncontrado
• Significado: o webhook denotado por {chave} não encontra-se estabelecido.
• HTTP Status Code: 404.
• endpoints: GET /webhook/{chave}, DELETE /webhook/{chave}
WebhookConsultaInvalida
• Significado: os parâmetros de consulta à lista de webhooks ativados não
respeitam o schema ou não fazem sentido semanticamente.
• HTTP Status Code: 400.
• endpoints: GET /webhook.
Violações específicas para o endpoint GET /webhook:
• algum dos parâmetros informados para a consulta não respeita o schema.
• o timestamp representado pelo parâmetro fim é anterior ao timestamp
representado pelo parâmetro inicio.
• o parâmetro paginacao.paginaAtual é negativo.
• o parâmetro paginacao.itensPorPagina é negativo.
Tag WebhookRec
Reúne erros dos endpoints que tratam do gerenciamento dos Webhooks de recorrências
da API Pix.

MO38503 - Documento Técnico - Convênio Pix Automático

 46

WebhookRecOperacaoInvalida
• Significado: a presente requisição busca criar um webhook sem respeitar
o schema ou, ainda, apresenta semântica inválida.
• HTTP Status Code: 400.
• endpoints: PUT /webhookrec.
Violações para o endpoint PUT /webhookrec:
• o campo webhookUrl não respeita o schema.
WebhookRecConsultaInvalida
• Significado: os parâmetros de consulta à lista de webhooks ativados não
respeitam o schema ou não fazem sentido semanticamente.
• HTTP Status Code: 400.
• endpoints: GET /webhookrec.
Violações específicas para o endpoint GET /webhookrec:
• algum dos parâmetros informados para a consulta não respeita o schema.
• o timestamp representado pelo parâmetro fim é anterior ao timestamp
representado pelo parâmetro inicio.
• o parâmetro paginacao.paginaAtual é negativo.
• o parâmetro paginacao.itensPorPagina é negativo.
Tag WebhookCobR
Reúne erros dos endpoints que tratam do gerenciamento dos Webhooks de cobranças
recorrentes da API Pix.
WebhookCobROperacaoInvalida
• Significado: a presente requisição busca criar um webhook sem respeitar
o schema ou, ainda, apresenta semântica inválida.
• HTTP Status Code: 400.
• endpoints: PUT /webhookcobr.
Violações para o endpoint PUT /webhookcobr:
• o campo webhookUrl não respeita o schema.
WebhookCobRConsultaInvalida
• Significado: os parâmetros de consulta à lista de webhooks ativados não
respeitam o schema ou não fazem sentido semanticamente.
• HTTP Status Code: 400.
• endpoints: GET /webhookcobr.
Violações específicas para o endpoint GET /webhookcobr:

MO38503 - Documento Técnico - Convênio Pix Automático

 47

• algum dos parâmetros informados para a consulta não respeita o schema.

• o timestamp representado pelo parâmetro fim é anterior ao timestamp
representado pelo parâmetro inicio.
• o parâmetro paginacao.paginaAtual é negativo.
• o parâmetro paginacao.itensPorPagina é negativo.

18 DEMAIS ORIENTAÇÕES
Os Schemas e os exemplos para cada Tag da API Pix estão disponíveis no GitHub do
Bacen.

18.1 CRIAÇÃO DA RECORRÊNCIA (AUTORIZAÇÃO)

O Contratante Recebedor cria a solicitação de autorização para o pagamento
recorrente, escolhendo o canal mais adequado ao seu negócio.

• API Pix
• Arquivo Eletrônico CNAB 750
• Gerenciador Financeiro
No Piloto, não está disponível a troca de informações com a CAIXA por arquivo.

18.1.1 CAMPOS DEFINIDOS NO MOMENTO DA CRIAÇÃO DA

RECORRÊNCIA
• Dados do devedor
• Contrato (informação para identificar o devedor)
• Objeto da cobrança
• Valor fixo ou variável
• Valor mínimo do recebedor (piso de valor)
• Data prevista do primeiro pagamento
• Prazo da recorrência (determinado ou indeterminado)
• Periodicidade da cobrança (semanal, mensal, trimestral, semestral, anual)
• Novas tentativas
• Convênio

 Endpoint (post/api/rec) para solicitar a inclusão de recorrência fornecendo os

dados inerentes ao Cliente Pagador, sendo pré-requisito para todas as jornadas.
Para criar a recorrência das Jornadas 2, 3 e 4, que envolvem QR Codes, é necessário
que o usuário forneça o id da Location criado no endpoint PayloadLocationRec, sendo
obrigatório o preenchimento do campo loc.
Obs: É importante ressaltar que, quando se trata de Jornada 1, não é necessário o
preenchimento do campo loc, a não ser que o Usuário tenha intenções futuras de vincular a
recorrência com jornadas de QR Code.

MO38503 - Documento Técnico - Convênio Pix Automático

 48

18.1.2 CRIAÇÃO DA SOLICITAÇÃO DE CONFIRMAÇÃO DE

RECORRÊNCIA
 Endpoint (post/api/solicrec) para solicitar confirmação de recorrência através da
solicRec provocando o envio de uma mensagem 'PUSH' ao Usuário Pagador, solicitando
a sua autorização.
o A solicRec só poderá ser enviada após a criação da recorrência no endpoint Rec.

o Obs:É importante ressaltar que esta solicitação ficará atrelada ao fluxo de

aprovação chamado de Jornada 1.

o Pode ser utilizado ao mesmo tempo que a jornada 2, jornada 3 ou jornada 4.

18.1.3 STATUS RETORNADOS ETAPA DA RECORRÊNCIA:

• CRIADA: indica que a recorrência foi criada pelo usuário recebedor;
• APROVADA: indica que a recorrência foi aceita pelo usuário pagador;
• REJEITADA: indica que a recorrência foi rejeitada pelo usuário pagador (ocorre
apenas na Jornada 1 de autorização);
• EXPIRADA: indica que a data final da recorrência já passou;
• CANCELADA: indica que a recorrência foi cancelada pelo usuário recebedor ou
pelo usuário pagador.

18.1.4 APÓS A CRIAÇÃO DA AUTORIZAÇÃO

O PSP do Recebedor intermedia a operação e transmite o pedido de recorrência ao
PSP do Pagador.
O PSP do PAGADOR notifica o Cliente Pagador sobre a solicitação de recorrência.
O Cliente Pagador recebe a notificação no aplicativo de seu banco podendo:

• Aceitar, recusar ou cancelar no momento da solicitação, se o pedido foi realizado

via Push.
• Escanear um QR Code para conferir os detalhes e autorizar a recorrência, se
deseja iniciar o processo de autorização via QR Code.

IMPORTANTE!
A autorização do cliente pagador pode conter:

• Teto de valor para as transações

• Definição de Prazo Máximo para uso da Autorização
• Indicação sobre a utilização de cheque especial em caso de saldo
insuficiente para o débito do Pix

18.1.5 PROCESSAMENTO E CONFIRMAÇÃO DA AUTORIZAÇÃO

• O PSP do Pagador processa a autorização e comunica o Banco do Recebedor
sobre a aprovação ou recusa da recorrência.
• O PSP do Recebedor informa o Cliente Recebedor sobre o status da recorrência.

MO38503 - Documento Técnico - Convênio Pix Automático

 49

18.2 ALTERAÇÃO DA RECORRÊNCIA

No presente momento, a regra geral é que qualquer alteração em uma recorrência
(confirmada ou não) deve ser feita através do seu cancelamento e criação de uma nova
recorrência com as informações alteradas, que deve ser confirmada pelo Cliente
Pagador.
No entanto, em algumas situações específicas é possível alterar os dados da
recorrência.
Quando a recorrência ainda não tiver sido confirmada pelo Cliente Pagador, o
Contratante Recebedor pode alterar algumas de suas informações:

• Data inicial (data prevista para o primeiro pagamento)

• Dados do devedor
• Txid

18.3 CANCELAMENTO DA RECORRÊNCIA PELO

CLIENTE PAGADOR
O Cliente Pagador pode cancelar a recorrência, o que implica o cancelamento
automático de todos os agendamentos vinculados à recorrência cancelada.
O cancelamento deve ser iniciado pelo canal do banco do Cliente Pagador, e o PSP do
Recebedor avisará o Contratante Recebedor para evitar novas cobranças via Pix
automático.

18.4 CANCELAMENTO DA RECORRÊNCIA PELO

CONTRATANTE RECEBEDOR
O Contratante Recebedor pode cancelar a recorrência das cobranças do Pix Automático
por iniciativa própria ou a pedido do Cliente Pagador feita diretamente à
Empresa/Governo.
Para isso, ele solicita ao PSP do Recebedor o cancelamento da recorrência.
 Endpoint (patch/api/rec/{idRec}) para Alterar ou Cancelar uma Recorrência
através de um determinado idRec.
o Para usar a funcionalidade de Cancelamento, a Recorrência tem que
obrigatoriamente estar com status 'CRIADA' ou 'APROVADA'.

o Obs: O cancelamento da recorrência pelo CONTRATANTE

RECEBEDOR não cancela automaticamente as cobranças agendadas
para liquidação no dia seguinte ao cancelamento (D+1) ou em datas
posteriores, onde D é a data de recebimento da mensagem de
cancelamento pelo CLIENTE PAGADOR.

o Quando o consentimento (autorização) é cancelado, todos os

agendamentos futuros vinculados a ele serão cancelados.

 Exceção: Pagamentos que já estavam agendados para o mesmo

dia do cancelamento ainda serão processados normalmente.

MO38503 - Documento Técnico - Convênio Pix Automático

 50

 Endpoint (patch/api/solicrec/{idSolicRec}) para Cancelar uma Solicitação de

Autorização através de um determinado id de solicitação.
o Para este serviço não existe a funcionalidade de alteração.
o Para usar a funcionalidade de Cancelamento, a Solicitação tem que
obrigatoriamente estar com status: "CRIADA", "ENVIADA" ou
"RECEBIDA".

18.5 INFORMAÇÕES PARA GERAR O AGENDAMENTO

• Txid (Identificador da cobrança, alfanumérico de 26 a 35 caracteres sem nenhum
caracter especial ou espaço em branco)
• Data de vencimento
• Valor (No caso de valor fixo, manter o valor da recorrência. No caso de valor
variável, informar nesta etapa o valor)
• Ajuste dia útil (se habilitado, as cobranças serão processadas em dias úteis)
• Dados do devedor (opcional)
• Dados do Contratante Recebedor (agência, conta e tipo de conta)
Para que o Banco do Pagador possa processar a cobrança, é necessário que o
Contratante Recebedor envie as informações da cobrança com antecedência, conforme
acordado entre as partes, garantindo que tudo seja realizado dentro do prazo
estabelecido.
 Endpoint (put/api/cobr/{txid}) para criar o agendamento para a data/ciclo
definido na recorrência.
o Obrigatoriamente deve ser informado um txid para definir unicamente a
cobrança recorrente.

18.5.1 STATUS RETORNADOS ETAPA DO AGENDAMENTO

• CRIADA: indica que a cobrança foi criada pelo usuário recebedor
• ATIVA: indica que a cobrança foi enviada pelo PSP Recebedor ao PSP Pagador
• CONCLUIDA: indica que a cobrança foi paga
• EXPIRADA: indica que a cobrança não foi quitada após expiradas todas as
tentativas de pagamento permitidas pela política vigente
• REJEITADA: indica que a cobrança foi rejeitada pelo PSP Pagador
• CANCELADA: indica que a cobrança foi cancelada pelo Contratante Recebedor
ou pelo Cliente Pagador

18.5.2 PROCESSAMENTO DO AGENDAMENTO

Após receber as informações da cobrança, o Banco do Cliente Pagador tem até 2 horas
para processar e efetivar o agendamento.

• Notificação ao Cliente Pagador: O pagador deve ser notificado em várias

situações, tais como:
 Quando o agendamento foi realizado com sucesso
 Quando houve sucesso ou falha no cancelamento do agendamento

• Notificação ao Contratante Recebedor: A Empresa será informada sobre o

sucesso ou falha do agendamento e, posteriormente, sobre a liquidação, para
que possa acompanhar a situação.

MO38503 - Documento Técnico - Convênio Pix Automático

 51

18.5.3 REJEIÇÃO DE AGENDAMENTOS PELO PSP RECEBEDOR.

• O PSP RECEBEDOR rejeitará agendamentos com instruções de pagamento
que apresentem valor superior ao valor máximo autorizado pelo Cliente Pagador,
nos casos de autorizações que contenham valores variáveis.

• O PSP RECEBEDOR rejeitará agendamentos com instruções de pagamento

que apresentem valor divergente do valor fixo nos casos de autorizações
efetuadas com marcação de valor fixo.

• O PSP RECEBEDOR rejeitará agendamentos com instruções de pagamento

que sejam enviadas em periodicidade incompatível com a recorrência prevista
na Autorização.

• O PSP RECEBEDOR rejeitará agendamentos com instruções de pagamento

que apresentem Contratante Recebedor divergente do Contratante Recebedor
apresentado na autorização.

• O PSP RECEBEDOR rejeitará agendamentos com instruções de pagamento

que não sejam enviadas entre 2 (dois) e 10 (dez) dias corridos anteriores a data
prevista do agendamento.

• O PSP RECEBEDOR rejeitará agendamentos com instruções de pagamento

que não apresentem autorizações vigentes concedidas pelo Cliente Pagador.

18.5.4 CANCELAMENTO DO AGENDAMENTO

O cancelamento do agendamento é possível de ser realizado tanto pelo Contratante
Recebedor quanto pelo Cliente Pagador.

• Cancelamento pelo CLIENTE PAGADOR: O Cliente Pagador pode cancelar o

agendamento até às 23h59 do dia anterior à data programada para o
pagamento.

• Cancelamento pelo CLIENTE RECEBEDOR: O Contratante Recebedor pode

cancelar o agendamento até às 22h do dia anterior à data de liquidação da
cobrança.

 Endpoint (patch/api/cobr/{txid}) para Cancelar uma Solicitação de Cobrança

Recorrente através de um determinado txid de agendamento.
o Para este serviço não existe a funcionalidade de alteração.
o Para usar a funcionalidade de Cancelamento, a Cobrança Recorrente
tem que obrigatoriamente estar com status: "CRIADA" ou "ATIVA".

19 INTEGRAÇÃO – MEIOS DE TRANSMISSÃO

O Contratante Recebedor poderá escolher que a troca de informações com a CAIXA
seja efetuada mediante as seguintes opções: API Pix, Arquivo ou Gerenciador
Financeiro.

MO38503 - Documento Técnico - Convênio Pix Automático

 52

 API Pix Automático: Interface de programação de aplicações que facilita e

automatiza a interação entre as instituições financeiras e de pagamentos que
ofertam o Pix e os usuários que recebem pagamentos.
o A API Pix contempla funcionalidades como criação e gestão de
cobranças, permitindo a geração de cobranças por meio de QR Codes
estáticos ou dinâmicos; verificação de liquidação, facilitando a
confirmação de que os pagamentos foram efetivamente realizados; e
integração com sistemas de automação, permitindo a geração
automática de QR Codes e a conciliação de pagamentos.

o Ideal para empresas que necessitam de uma integração direta com seus
sistemas, a API Pix oferece uma solução robusta e eficiente. A integração
com a API Pix permite que o Contratante Recebedor automatize e
simplifique o processo de recebimento de pagamentos, garantindo
praticidade e agilidade além de toda segurança do arranjo pix.

o A documentação técnica concernente a API do Pix Automático está

disponível para consulta no USER GUIDE do produto
https://github.com/bacen/pix-api.

 Arquivo CNAB 750 posições: A CAIXA disponibiliza a transmissão via VAN

para convenentes/recebedoras que utilizam o arquivo CNAB de 750 para
agendamentos de cobranças recorrentes no convênio Pix Automático.
o A integração via arquivo CNAB 750 oferece para a Empresa/Governo
uma comunicação eficiente para envio organizado de lotes massivos de
agendamentos, gerenciamento e controle de fluxos, interação com
sistemas próprios e uma baixa intervenção manual, proporcionando
celeridade e assertividade no processo.

o Essa opção permite também o envio de remessas e o recebimento de

retornos de maneira segura e eficiente.

o Ao contratar o Convênio Pix Automático a empresa recebe o leiaute

necessário para a correta parametrização sistêmica.

 Gerenciador Financeiro: A CAIXA oferece o canal Gerenciador Financeiro

https://gerenciador.caixa.gov.br/ para que as empresas possam solicitar as
autorizações e realizar seus agendamentos de cobranças recorrentes no
convênio Pix Automático CAIXA, além de possibilitar a manutenção, gestão e
controle desses agendamentos.
o Ideal para empresas que não possuem sistemas próprios mas desejam
ter uma experiência completa de gestão com um sistema moderno,
eficiente, simples e descomplicado, que permite desde a criação das
cobranças até o monitoramento dos pagamentos.

MO38503 - Documento Técnico - Convênio Pix Automático

 53

PARTE 3 – RESUMO E LINKS TÉCNICOS

21 SWAGGER
O Convênio Pix Automático ofertado pela CAIXA disponibiliza para o contratante a
melhor forma de se comunicar: API Pix Bacen.
O uso dessa API facilita o desenvolvimento pela equipe de tecnologia da sua empresa
visto que não há necessidade de adaptações exclusivas para a CAIXA para uso do
serviço.
Para o desenvolvimento da API, deverão ser seguidas as orientações do GitHub do
Bacen, cujos link disponibilizamos:
 GitHub - bacen/pix-api: API Pix: a API do Arranjo de Pagamentos Instantâneos
Brasileiro, Pix, criado pelo Banco Central do Brasil.
 Swagger UI
Além das APIs, o desenvolvimento deve contemplar as orientações técnicas contidas
na documentação disponibilizada pelo Bacen para o Pix Automático, das quais
destacamos:
1. Manual de Uso da Marca
2. Manual de Padrões para Iniciação do Pix
3. Manual de Fluxos do Processo de Efetivação do Pix
4. Requisitos Mínimos para a Experiência do Usuário
5. Manual de Redes do SFN
6. Manual de Segurança do SFN
7. Catálogo de Serviços do SFN
8. Manual das Interfaces de Comunicação
9. Manual de Tempos do Pix
10. Manual Operacional do DICT
11. Manual de Resolução de Disputas
12. Manual de Penalidades
13. Guia de Implementação do Pix Automático
ATENÇÃO!!!
Para o serviço funcionar na CAIXA, o campo “Convênio” é de
preenchimento obrigatório!
Esse número será fornecido à Empresa/Governo após a contratação do
serviço Convênio Pix Automático.

MO38503 - Documento Técnico - Convênio Pix Automático

 54

22 LEIAUTE ARQUIVO CNAB 750

Após o período de piloto, o Convênio Pix Automático ofertado pela CAIXA disponibilizará
para o contratante a integração com a CAIXA por Arquivo CNAB 750.
O uso desse Leiaute facilita o desenvolvimento pela equipe de tecnologia da sua
empresa visto que não há necessidade de adaptações exclusivas para a CAIXA para
uso do serviço.
Documentação para Leiaute do Arquivo CNAB 750 referente ao Pix Automático:
Fonte: Bacen

1. Orientações sobre o Arquivo Padronizado para o Pix Automático

2. Leiaute do arquivo de remessa
3. Leiaute do arquivo de retorno

ATENÇÃO!!!
Para o serviço funcionar na CAIXA, o campo “Convênio” é de
preenchimento obrigatório!
Esse número será fornecido à Empresa/Governo após a contratação do
serviço Convênio Pix Automático.

23 GERENCIADOR FINANCEIRO
O Convênio Pix Automático ofertado pela CAIXA disponibiliza a seus contratantes o
Gerenciador Financeiro como canal para contratação e troca de informações referentes
a Autorizações e Agendamentos.
A utilização do Gerenciador Financeiro facilita o acesso pelo contratante às
funcionalidades e um uso disponível imediatamente após a contratação no Gerenciador,
dispensando a necessidade de desenvolvimento de um front próprio do contratante ou
de um desenvolvimento da integração por API para começar a operar.
O Gerenciador conta com as mesmas facilidades da API Pix em uma jornada fluida para
o usuário.
São funcionalidades no Gerenciador Financeiro:
 aderir ao serviço (contratação com poucos cliques!)
 fazer a gestão de clientes pagadores
 fazer a gestão de recebíveis
Dessa forma, logo após a contratação, o sistema habilita a possibilidade de envio de
solicitações de autorização e agendamentos, conforme o caso; e de acordo com a
jornada escolhida pelo contratante.
A solução está disponível a todos os clientes Pessoa Jurídica mas é especialmente
relevante para o contratante que não pretende desenvolver a comunicação por API ou
Arquivo visto ser a solução mais adequada por não demandar desenvolvimento pela
equipe de tecnologia da Empresa previamente ao uso.

MO38503 - Documento Técnico - Convênio Pix Automático

 55

Em caso de dúvidas, nossa equipe estará à disposição para esclarecer e orientar o seu
desenvolvimento.
Encaminhe a dúvida e o contato para retorno que repassaremos a orientação.

SAC CAIXA: 0800 726 0101 (informações, reclamações, sugestões e elogios)

Para pessoas com deficiência auditiva ou de fala: 0800 726 2492
Ouvidoria: 0800 725 7474
caixa.gov.br

MO38503 - Documento Técnico - Convênio Pix Automático