Pix Cobrança

O usuário confere recebedor e valores antes de confirmar. Agendamento, pagamento e autorização futura têm avisos próprios; a experiência deve conservar as diferenças e o efeito dos cancelamentos.

• O manual 2.1 separa gerar ordem, efetivar pagamento e devolver valores. Para Automático acrescenta autorização, agenda e cancelamento. Confirmar dados ou criar agenda não é concluir liquidação; o caminho depende de acesso DICT, participação SPI e relação entre as instituições. Manual de Fluxos 2.1, p. 4Manual de Fluxos 2.1, p. 29Manual de Fluxos 2.1, p. 34Manual de Fluxos 2.1, p. 41Manual de Fluxos 2.1, p. 45Manual de Fluxos 2.1, p. 57
• Chave informada demanda consulta DICT; inserção manual de dados bancários dispensa essa consulta, mas o prestador valida dados e apresenta recebedor para confirmação. Acesso indireto consulta por participante direto. QR estático também consulta DICT antes da confirmação. Manual de Fluxos 2.1, p. 5Manual de Fluxos 2.1, p. 6Manual de Fluxos 2.1, p. 7Manual de Fluxos 2.1, p. 8Manual de Fluxos 2.1, p. 11Manual de Fluxos 2.1, p. 12
• Quando PSI inicia por chave/dados, ele valida recebedor e obtém consentimento; depois envia dados pela API Open Finance ao PSP pagador, que solicita autenticação/confirmação no fluxo descrito. Quando PSI já possui todos os dados, também obtém consentimento e envia pela API. O manual remete detalhamento de jornadas ao arcabouço Open Finance. Manual de Fluxos 2.1, p. 9Manual de Fluxos 2.1, p. 10Manual de Fluxos 2.1, p. 23Manual de Fluxos 2.1, p. 24
• QR dinâmico requer identificar location e obter payload da cobrança no PSP recebedor; depois consulta chave no DICT e apresenta dados para confirmação. Na cobrança com vencimento, mudar a data pretendida leva à nova consulta do payload e apresentação do valor com principal, multa, juros, descontos/abatimentos calculados para essa data. Manual de Fluxos 2.1, p. 13Manual de Fluxos 2.1, p. 14Manual de Fluxos 2.1, p. 15Manual de Fluxos 2.1, p. 16Manual de Fluxos 2.1, p. 17
• No Agendado único/recorrente, data pode ser pedida no início ou após dados do recebedor, sempre antes da confirmação. E2EId da consulta inicial de agendamento serve apenas à consulta DICT; nova consulta antes da liquidação gera identificador informado na pacs.008 para reposição de fichas. Manual de Fluxos 2.1, p. 18Manual de Fluxos 2.1, p. 19Manual de Fluxos 2.1, p. 21Manual de Fluxos 2.1, p. 33Manual de Fluxos 2.1, p. 39
• Antes de liquidar Agendado por chave, PSP consulta novamente e compara existência/titularidade com o agendamento; inexistência ou titular diferente cancela a ordem e notifica insucesso. Dados bancários manuais dispensam essa nova consulta. Nos livros do próprio PSP, chave que saiu da instituição por portabilidade/reivindicação conduz a consulta DICT e verificação da titularidade. Manual de Fluxos 2.1, p. 32Manual de Fluxos 2.1, p. 33Manual de Fluxos 2.1, p. 38Manual de Fluxos 2.1, p. 39Manual de Fluxos 2.1, p. 43Manual de Fluxos 2.1, p. 44Manual de Fluxos 2.1, p. 48Manual de Fluxos 2.1, p. 49
• Aproximação NFC obtém dados de pagamento, mas continua interpretação, obtenção de payload, identificação e confirmação. Fluxograma exemplifica QR dinâmico imediato; também admite cobrança com vencimento e QR estático. Na transação por aproximação iniciada por PSI (2.6.2), ele deve utilizar as APIs do Open Finance para enviar a ordem ao PSP do pagador; na iniciada pelo próprio PSP do pagador (2.6.1) não há PSI. Manual de Fluxos 2.1, p. 24Manual de Fluxos 2.1, p. 25Manual de Fluxos 2.1, p. 26Manual de Fluxos 2.1, p. 27Manual de Fluxos 2.1, p. 28
• Liquidação imediata entre diretos bloqueia valor na conta do usuário e Conta PI pagadora; recebedor valida conta e anota crédito provisório. SPI troca saldos PI e confirma, então PSPs efetivam crédito/débito e avisam usuários. Anotação provisória não é crédito definitivo. Manual de Fluxos 2.1, p. 31Manual de Fluxos 2.1, p. 32
• Quando pagador e recebedor usam o mesmo PSP, liquidação ocorre nos seus livros: verifica saldo/conta, debita e credita se válidos e notifica ambos. O manual descreve esse caminho independentemente de participação direta ou indireta no SPI. Manual de Fluxos 2.1, p. 41Manual de Fluxos 2.1, p. 42
• Devolução inverte papéis: recebedor original é remetente e pagador original é destinatário. PSP destinatário recupera transação pelo EndToEndId e valida prazo de noventa dias, cliente, valor e conta ativa. Fluxos diretos/indiretos separam bloqueio, crédito provisório, transferência, efetivação e avisos; liquidante participa quando há indiretos. Manual de Fluxos 2.1, p. 50Manual de Fluxos 2.1, p. 52Manual de Fluxos 2.1, p. 53Manual de Fluxos 2.1, p. 55Manual de Fluxos 2.1, p. 56
• Na autorização sem QR entre instituições, recebedor envia dados, PSPs armazenam recorrência e trocam PAIN.009/012 para recebimento; pagador é solicitado a autorizar. A confirmação pelo usuário atualiza status, circula PAIN.012 e retorno; recebedor e pagador recebem confirmação final. Quando PSP é o mesmo, armazenamento, status e avisos ficam internos. Manual de Fluxos 2.1, p. 58Manual de Fluxos 2.1, p. 59Manual de Fluxos 2.1, p. 60Manual de Fluxos 2.1, p. 61Manual de Fluxos 2.1, p. 62Manual de Fluxos 2.1, p. 63
• QR só de recorrência leva à consulta da location e apresentação dos dados ao pagador. Depois do aceite, status são atualizados e PAIN.012 circula com retorno entre PSPs antes do aviso final. No mesmo PSP, carregamento e atualização são internos. Entregar QR por fora do ecossistema não substitui a confirmação no app. Manual de Fluxos 2.1, p. 63Manual de Fluxos 2.1, p. 65Manual de Fluxos 2.1, p. 66Manual de Fluxos 2.1, p. 67Manual de Fluxos 2.1, p. 68
• Primeiro pagamento imediato e autorização são confirmados juntos, mas o fluxo de autorização só prossegue após sucesso na liquidação usual do primeiro Pix: entre PSPs diferentes usa canal primário; no mesmo PSP segue liquidação nos seus livros. Fracasso interrompe e avisa que pagamento/autorização não se efetivaram. PSP recebedor também aguarda conclusão antes de atualizar status. Aviso de pagamento pode ser agrupado ao aviso final da autorização. Manual de Fluxos 2.1, p. 70Manual de Fluxos 2.1, p. 71Manual de Fluxos 2.1, p. 72Manual de Fluxos 2.1, p. 73Manual de Fluxos 2.1, p. 74Manual de Fluxos 2.1, p. 75
• Na jornada de oferta posterior, pagador confirma pagar ou agendar a cobrança; só depois recebe oferta do Automático, manifesta interesse e confirma recorrência. Quando cobrança já está no QR como dados estáticos, apenas recorrência vem de location. Modelos com instituições distintas sincronizam PAIN.012 e retorno; mesmo PSP registra internamente. Manual de Fluxos 2.1, p. 76Manual de Fluxos 2.1, p. 78Manual de Fluxos 2.1, p. 79Manual de Fluxos 2.1, p. 80Manual de Fluxos 2.1, p. 81Manual de Fluxos 2.1, p. 82Manual de Fluxos 2.1, p. 83
• Cancelamento da autorização pelo pagador cancela internamente e confirma ao usuário, informa recorrência por PAIN.011 e recebe PAIN.012 entre PSPs; recebedor é avisado. Se há agendas atingidas a cancelar, PSP pagador executa também o fluxo de cancelamento de débito. No mesmo PSP, cancela autorização e atualiza recorrência sem troca interinstitucional. Manual de Fluxos 2.1, p. 84Manual de Fluxos 2.1, p. 85Manual de Fluxos 2.1, p. 86
• Cancelamento da recorrência pelo recebedor registra estado, comunica PAIN.011 e retorno PAIN.012 e avisa partes, cancelando autorização associada. Também serve para cancelar solicitação pendente confirmada por outra jornada. Agendas pendentes atingidas demandam fluxo próprio. No mesmo PSP, recorrência e autorização são canceladas internamente. Manual de Fluxos 2.1, p. 87Manual de Fluxos 2.1, p. 88Manual de Fluxos 2.1, p. 89
• Agenda Automático entre instituições exige validar cobrança contra recorrência no PSP recebedor e contra autorização no pagador; PAIN.013 leva cobrança e PAIN.014 retorna resultado, com armazenamento e aviso ao recebedor. Aviso de agendamento ao pagador pode ser desabilitado, e somente essas etapas são omitidas. Mesmo PSP compara, agenda e comunica internamente. Manual de Fluxos 2.1, p. 90Manual de Fluxos 2.1, p. 91Manual de Fluxos 2.1, p. 92
• Cancelar débito específico pelo pagador cancela internamente e avisa; entre PSPs usa CAMT.055 e retorno CAMT.029, com registro e aviso ao recebedor. Cancelamento pelo recebedor antes de enviar dados é interno; após envio comunica pagador, cancela agenda e confirma às partes com CAMT.055/029. Mesmo PSP cancela cobrança/débito e comunica ambos. Manual de Fluxos 2.1, p. 97Manual de Fluxos 2.1, p. 98Manual de Fluxos 2.1, p. 100Manual de Fluxos 2.1, p. 101

O que esta leitura não diz. Não prescreve layout ou posição de controles ausentes no texto extraído; desabilitar aviso de agenda não dispensa todos os avisos.

A forma de iniciar muda a coleta e confirmação dos dados; a relação entre instituições muda a efetivação. Automático acrescenta estados que precisam acompanhar autorização, cobrança e agenda.

• O manual 2.1 separa gerar ordem, efetivar pagamento e devolver valores. Para Automático acrescenta autorização, agenda e cancelamento. Confirmar dados ou criar agenda não é concluir liquidação; o caminho depende de acesso DICT, participação SPI e relação entre as instituições. Manual de Fluxos 2.1, p. 4Manual de Fluxos 2.1, p. 29Manual de Fluxos 2.1, p. 34Manual de Fluxos 2.1, p. 41Manual de Fluxos 2.1, p. 45Manual de Fluxos 2.1, p. 57
• Chave informada demanda consulta DICT; inserção manual de dados bancários dispensa essa consulta, mas o prestador valida dados e apresenta recebedor para confirmação. Acesso indireto consulta por participante direto. QR estático também consulta DICT antes da confirmação. Manual de Fluxos 2.1, p. 5Manual de Fluxos 2.1, p. 6Manual de Fluxos 2.1, p. 7Manual de Fluxos 2.1, p. 8Manual de Fluxos 2.1, p. 11Manual de Fluxos 2.1, p. 12
• Quando PSI inicia por chave/dados, ele valida recebedor e obtém consentimento; depois envia dados pela API Open Finance ao PSP pagador, que solicita autenticação/confirmação no fluxo descrito. Quando PSI já possui todos os dados, também obtém consentimento e envia pela API. O manual remete detalhamento de jornadas ao arcabouço Open Finance. Manual de Fluxos 2.1, p. 9Manual de Fluxos 2.1, p. 10Manual de Fluxos 2.1, p. 23Manual de Fluxos 2.1, p. 24
• QR dinâmico requer identificar location e obter payload da cobrança no PSP recebedor; depois consulta chave no DICT e apresenta dados para confirmação. Na cobrança com vencimento, mudar a data pretendida leva à nova consulta do payload e apresentação do valor com principal, multa, juros, descontos/abatimentos calculados para essa data. Manual de Fluxos 2.1, p. 13Manual de Fluxos 2.1, p. 14Manual de Fluxos 2.1, p. 15Manual de Fluxos 2.1, p. 16Manual de Fluxos 2.1, p. 17
• No Agendado único/recorrente, data pode ser pedida no início ou após dados do recebedor, sempre antes da confirmação. E2EId da consulta inicial de agendamento serve apenas à consulta DICT; nova consulta antes da liquidação gera identificador informado na pacs.008 para reposição de fichas. Manual de Fluxos 2.1, p. 18Manual de Fluxos 2.1, p. 19Manual de Fluxos 2.1, p. 21Manual de Fluxos 2.1, p. 33Manual de Fluxos 2.1, p. 39
• Antes de liquidar Agendado por chave, PSP consulta novamente e compara existência/titularidade com o agendamento; inexistência ou titular diferente cancela a ordem e notifica insucesso. Dados bancários manuais dispensam essa nova consulta. Nos livros do próprio PSP, chave que saiu da instituição por portabilidade/reivindicação conduz a consulta DICT e verificação da titularidade. Manual de Fluxos 2.1, p. 32Manual de Fluxos 2.1, p. 33Manual de Fluxos 2.1, p. 38Manual de Fluxos 2.1, p. 39Manual de Fluxos 2.1, p. 43Manual de Fluxos 2.1, p. 44Manual de Fluxos 2.1, p. 48Manual de Fluxos 2.1, p. 49
• Aproximação NFC obtém dados de pagamento, mas continua interpretação, obtenção de payload, identificação e confirmação. Fluxograma exemplifica QR dinâmico imediato; também admite cobrança com vencimento e QR estático. Na transação por aproximação iniciada por PSI (2.6.2), ele deve utilizar as APIs do Open Finance para enviar a ordem ao PSP do pagador; na iniciada pelo próprio PSP do pagador (2.6.1) não há PSI. Manual de Fluxos 2.1, p. 24Manual de Fluxos 2.1, p. 25Manual de Fluxos 2.1, p. 26Manual de Fluxos 2.1, p. 27Manual de Fluxos 2.1, p. 28
• Liquidação imediata entre diretos bloqueia valor na conta do usuário e Conta PI pagadora; recebedor valida conta e anota crédito provisório. SPI troca saldos PI e confirma, então PSPs efetivam crédito/débito e avisam usuários. Anotação provisória não é crédito definitivo. Manual de Fluxos 2.1, p. 31Manual de Fluxos 2.1, p. 32
• Com indiretos e liquidantes distintos, mensagens SPI passam pelos liquidantes, mas validação de conta, anotação provisória e crédito/débito dos usuários são dos PSPs. SPI transfere entre Contas PI dos liquidantes. Com mesmo liquidante, ele ajusta saldos internos dos PSPs; não há etapa descrita de troca entre Contas PI distintas. Manual de Fluxos 2.1, p. 36Manual de Fluxos 2.1, p. 37Manual de Fluxos 2.1, p. 46Manual de Fluxos 2.1, p. 47
• Quando pagador e recebedor usam o mesmo PSP, liquidação ocorre nos seus livros: verifica saldo/conta, debita e credita se válidos e notifica ambos. O manual descreve esse caminho independentemente de participação direta ou indireta no SPI. Manual de Fluxos 2.1, p. 41Manual de Fluxos 2.1, p. 42
• Devolução inverte papéis: recebedor original é remetente e pagador original é destinatário. PSP destinatário recupera transação pelo EndToEndId e valida prazo de noventa dias, cliente, valor e conta ativa. Fluxos diretos/indiretos separam bloqueio, crédito provisório, transferência, efetivação e avisos; liquidante participa quando há indiretos. Manual de Fluxos 2.1, p. 50Manual de Fluxos 2.1, p. 52Manual de Fluxos 2.1, p. 53Manual de Fluxos 2.1, p. 55Manual de Fluxos 2.1, p. 56
• Na autorização sem QR entre instituições, recebedor envia dados, PSPs armazenam recorrência e trocam PAIN.009/012 para recebimento; pagador é solicitado a autorizar. A confirmação pelo usuário atualiza status, circula PAIN.012 e retorno; recebedor e pagador recebem confirmação final. Quando PSP é o mesmo, armazenamento, status e avisos ficam internos. Manual de Fluxos 2.1, p. 58Manual de Fluxos 2.1, p. 59Manual de Fluxos 2.1, p. 60Manual de Fluxos 2.1, p. 61Manual de Fluxos 2.1, p. 62Manual de Fluxos 2.1, p. 63
• QR só de recorrência leva à consulta da location e apresentação dos dados ao pagador. Depois do aceite, status são atualizados e PAIN.012 circula com retorno entre PSPs antes do aviso final. No mesmo PSP, carregamento e atualização são internos. Entregar QR por fora do ecossistema não substitui a confirmação no app. Manual de Fluxos 2.1, p. 63Manual de Fluxos 2.1, p. 65Manual de Fluxos 2.1, p. 66Manual de Fluxos 2.1, p. 67Manual de Fluxos 2.1, p. 68
• Primeiro pagamento imediato e autorização são confirmados juntos, mas o fluxo de autorização só prossegue após sucesso na liquidação usual do primeiro Pix: entre PSPs diferentes usa canal primário; no mesmo PSP segue liquidação nos seus livros. Fracasso interrompe e avisa que pagamento/autorização não se efetivaram. PSP recebedor também aguarda conclusão antes de atualizar status. Aviso de pagamento pode ser agrupado ao aviso final da autorização. Manual de Fluxos 2.1, p. 70Manual de Fluxos 2.1, p. 71Manual de Fluxos 2.1, p. 72Manual de Fluxos 2.1, p. 73Manual de Fluxos 2.1, p. 74Manual de Fluxos 2.1, p. 75
• Na jornada de oferta posterior, pagador confirma pagar ou agendar a cobrança; só depois recebe oferta do Automático, manifesta interesse e confirma recorrência. Quando cobrança já está no QR como dados estáticos, apenas recorrência vem de location. Modelos com instituições distintas sincronizam PAIN.012 e retorno; mesmo PSP registra internamente. Manual de Fluxos 2.1, p. 76Manual de Fluxos 2.1, p. 78Manual de Fluxos 2.1, p. 79Manual de Fluxos 2.1, p. 80Manual de Fluxos 2.1, p. 81Manual de Fluxos 2.1, p. 82Manual de Fluxos 2.1, p. 83
• Cancelamento da autorização pelo pagador cancela internamente e confirma ao usuário, informa recorrência por PAIN.011 e recebe PAIN.012 entre PSPs; recebedor é avisado. Se há agendas atingidas a cancelar, PSP pagador executa também o fluxo de cancelamento de débito. No mesmo PSP, cancela autorização e atualiza recorrência sem troca interinstitucional. Manual de Fluxos 2.1, p. 84Manual de Fluxos 2.1, p. 85Manual de Fluxos 2.1, p. 86
• Cancelamento da recorrência pelo recebedor registra estado, comunica PAIN.011 e retorno PAIN.012 e avisa partes, cancelando autorização associada. Também serve para cancelar solicitação pendente confirmada por outra jornada. Agendas pendentes atingidas demandam fluxo próprio. No mesmo PSP, recorrência e autorização são canceladas internamente. Manual de Fluxos 2.1, p. 87Manual de Fluxos 2.1, p. 88Manual de Fluxos 2.1, p. 89
• Agenda Automático entre instituições exige validar cobrança contra recorrência no PSP recebedor e contra autorização no pagador; PAIN.013 leva cobrança e PAIN.014 retorna resultado, com armazenamento e aviso ao recebedor. Aviso de agendamento ao pagador pode ser desabilitado, e somente essas etapas são omitidas. Mesmo PSP compara, agenda e comunica internamente. Manual de Fluxos 2.1, p. 90Manual de Fluxos 2.1, p. 91Manual de Fluxos 2.1, p. 92
• Entre PSPs diferentes, com erro no fluxo de liquidação, o PSP do pagador registra o insucesso e cancela a PAIN.013 original por CAMT.055, que o PSP do recebedor confirma com CAMT.029; em seguida, o PSP do recebedor valida novamente a cobrança com a recorrência e deve enviar nova PAIN.013, para que o PSP do pagador gere nova PACS.008 com novo E2EId, a ser liquidada na mesma data. Identificador de ordem não liquidada não é reutilizado; notificações ao pagador do fluxo de cancelamento não se aplicam nessa correção. Retentativa após vencimento tem nova instrução e novo agendamento; não é o mesmo fluxo intradia. No mesmo PSP, registra insucesso, compara cobrança com autorização e agenda nova ordem para o mesmo dia em seus sistemas, sem o roteiro de mensageria entre instituições. Manual de Fluxos 2.1, p. 93Manual de Fluxos 2.1, p. 94Manual de Fluxos 2.1, p. 95
• Cancelar débito específico pelo pagador cancela internamente e avisa; entre PSPs usa CAMT.055 e retorno CAMT.029, com registro e aviso ao recebedor. Cancelamento pelo recebedor antes de enviar dados é interno; após envio comunica pagador, cancela agenda e confirma às partes com CAMT.055/029. Mesmo PSP cancela cobrança/débito e comunica ambos. Manual de Fluxos 2.1, p. 97Manual de Fluxos 2.1, p. 98Manual de Fluxos 2.1, p. 100Manual de Fluxos 2.1, p. 101

O que esta leitura não diz. Não define preço do produto nem permite representar crédito provisório, consentimento ou agenda como pagamento concluído.

Acompanhar uma ordem exige distinguir bloqueio, crédito provisório, transferência e confirmação. Agenda, devolução e correção de falha envolvem validações e sincronização entre os participantes.

• O manual 2.1 separa gerar ordem, efetivar pagamento e devolver valores. Para Automático acrescenta autorização, agenda e cancelamento. Confirmar dados ou criar agenda não é concluir liquidação; o caminho depende de acesso DICT, participação SPI e relação entre as instituições. Manual de Fluxos 2.1, p. 4Manual de Fluxos 2.1, p. 29Manual de Fluxos 2.1, p. 34Manual de Fluxos 2.1, p. 41Manual de Fluxos 2.1, p. 45Manual de Fluxos 2.1, p. 57
• Chave informada demanda consulta DICT; inserção manual de dados bancários dispensa essa consulta, mas o prestador valida dados e apresenta recebedor para confirmação. Acesso indireto consulta por participante direto. QR estático também consulta DICT antes da confirmação. Manual de Fluxos 2.1, p. 5Manual de Fluxos 2.1, p. 6Manual de Fluxos 2.1, p. 7Manual de Fluxos 2.1, p. 8Manual de Fluxos 2.1, p. 11Manual de Fluxos 2.1, p. 12
• No Agendado único/recorrente, data pode ser pedida no início ou após dados do recebedor, sempre antes da confirmação. E2EId da consulta inicial de agendamento serve apenas à consulta DICT; nova consulta antes da liquidação gera identificador informado na pacs.008 para reposição de fichas. Manual de Fluxos 2.1, p. 18Manual de Fluxos 2.1, p. 19Manual de Fluxos 2.1, p. 21Manual de Fluxos 2.1, p. 33Manual de Fluxos 2.1, p. 39
• Antes de liquidar Agendado por chave, PSP consulta novamente e compara existência/titularidade com o agendamento; inexistência ou titular diferente cancela a ordem e notifica insucesso. Dados bancários manuais dispensam essa nova consulta. Nos livros do próprio PSP, chave que saiu da instituição por portabilidade/reivindicação conduz a consulta DICT e verificação da titularidade. Manual de Fluxos 2.1, p. 32Manual de Fluxos 2.1, p. 33Manual de Fluxos 2.1, p. 38Manual de Fluxos 2.1, p. 39Manual de Fluxos 2.1, p. 43Manual de Fluxos 2.1, p. 44Manual de Fluxos 2.1, p. 48Manual de Fluxos 2.1, p. 49
• Liquidação imediata entre diretos bloqueia valor na conta do usuário e Conta PI pagadora; recebedor valida conta e anota crédito provisório. SPI troca saldos PI e confirma, então PSPs efetivam crédito/débito e avisam usuários. Anotação provisória não é crédito definitivo. Manual de Fluxos 2.1, p. 31Manual de Fluxos 2.1, p. 32
• Com indiretos e liquidantes distintos, mensagens SPI passam pelos liquidantes, mas validação de conta, anotação provisória e crédito/débito dos usuários são dos PSPs. SPI transfere entre Contas PI dos liquidantes. Com mesmo liquidante, ele ajusta saldos internos dos PSPs; não há etapa descrita de troca entre Contas PI distintas. Manual de Fluxos 2.1, p. 36Manual de Fluxos 2.1, p. 37Manual de Fluxos 2.1, p. 46Manual de Fluxos 2.1, p. 47
• Quando pagador e recebedor usam o mesmo PSP, liquidação ocorre nos seus livros: verifica saldo/conta, debita e credita se válidos e notifica ambos. O manual descreve esse caminho independentemente de participação direta ou indireta no SPI. Manual de Fluxos 2.1, p. 41Manual de Fluxos 2.1, p. 42
• Ordens de Automático, Agendado único/recorrente e Cobrança com vencimento quando agendada, e mensagens do ciclo de liquidação, usam canal secundário com NORM/PAGAGD. Demais ordens usam primário. No Automático, PAIN.009/011/012 e CAMT.055/029 de autorização/cancelamento vão pelo primário; PAIN.013/014 e PACS.008/002 de agenda/liquidação vão pelo secundário. Manual de Fluxos 2.1, p. 29Manual de Fluxos 2.1, p. 34Manual de Fluxos 2.1, p. 57
• Devolução inverte papéis: recebedor original é remetente e pagador original é destinatário. PSP destinatário recupera transação pelo EndToEndId e valida prazo de noventa dias, cliente, valor e conta ativa. Fluxos diretos/indiretos separam bloqueio, crédito provisório, transferência, efetivação e avisos; liquidante participa quando há indiretos. Manual de Fluxos 2.1, p. 50Manual de Fluxos 2.1, p. 52Manual de Fluxos 2.1, p. 53Manual de Fluxos 2.1, p. 55Manual de Fluxos 2.1, p. 56
• Na autorização sem QR entre instituições, recebedor envia dados, PSPs armazenam recorrência e trocam PAIN.009/012 para recebimento; pagador é solicitado a autorizar. A confirmação pelo usuário atualiza status, circula PAIN.012 e retorno; recebedor e pagador recebem confirmação final. Quando PSP é o mesmo, armazenamento, status e avisos ficam internos. Manual de Fluxos 2.1, p. 58Manual de Fluxos 2.1, p. 59Manual de Fluxos 2.1, p. 60Manual de Fluxos 2.1, p. 61Manual de Fluxos 2.1, p. 62Manual de Fluxos 2.1, p. 63
• Primeiro pagamento imediato e autorização são confirmados juntos, mas o fluxo de autorização só prossegue após sucesso na liquidação usual do primeiro Pix: entre PSPs diferentes usa canal primário; no mesmo PSP segue liquidação nos seus livros. Fracasso interrompe e avisa que pagamento/autorização não se efetivaram. PSP recebedor também aguarda conclusão antes de atualizar status. Aviso de pagamento pode ser agrupado ao aviso final da autorização. Manual de Fluxos 2.1, p. 70Manual de Fluxos 2.1, p. 71Manual de Fluxos 2.1, p. 72Manual de Fluxos 2.1, p. 73Manual de Fluxos 2.1, p. 74Manual de Fluxos 2.1, p. 75
• Cancelamento da autorização pelo pagador cancela internamente e confirma ao usuário, informa recorrência por PAIN.011 e recebe PAIN.012 entre PSPs; recebedor é avisado. Se há agendas atingidas a cancelar, PSP pagador executa também o fluxo de cancelamento de débito. No mesmo PSP, cancela autorização e atualiza recorrência sem troca interinstitucional. Manual de Fluxos 2.1, p. 84Manual de Fluxos 2.1, p. 85Manual de Fluxos 2.1, p. 86
• Cancelamento da recorrência pelo recebedor registra estado, comunica PAIN.011 e retorno PAIN.012 e avisa partes, cancelando autorização associada. Também serve para cancelar solicitação pendente confirmada por outra jornada. Agendas pendentes atingidas demandam fluxo próprio. No mesmo PSP, recorrência e autorização são canceladas internamente. Manual de Fluxos 2.1, p. 87Manual de Fluxos 2.1, p. 88Manual de Fluxos 2.1, p. 89
• Agenda Automático entre instituições exige validar cobrança contra recorrência no PSP recebedor e contra autorização no pagador; PAIN.013 leva cobrança e PAIN.014 retorna resultado, com armazenamento e aviso ao recebedor. Aviso de agendamento ao pagador pode ser desabilitado, e somente essas etapas são omitidas. Mesmo PSP compara, agenda e comunica internamente. Manual de Fluxos 2.1, p. 90Manual de Fluxos 2.1, p. 91Manual de Fluxos 2.1, p. 92
• Entre PSPs diferentes, com erro no fluxo de liquidação, o PSP do pagador registra o insucesso e cancela a PAIN.013 original por CAMT.055, que o PSP do recebedor confirma com CAMT.029; em seguida, o PSP do recebedor valida novamente a cobrança com a recorrência e deve enviar nova PAIN.013, para que o PSP do pagador gere nova PACS.008 com novo E2EId, a ser liquidada na mesma data. Identificador de ordem não liquidada não é reutilizado; notificações ao pagador do fluxo de cancelamento não se aplicam nessa correção. Retentativa após vencimento tem nova instrução e novo agendamento; não é o mesmo fluxo intradia. No mesmo PSP, registra insucesso, compara cobrança com autorização e agenda nova ordem para o mesmo dia em seus sistemas, sem o roteiro de mensageria entre instituições. Manual de Fluxos 2.1, p. 93Manual de Fluxos 2.1, p. 94Manual de Fluxos 2.1, p. 95
• Cancelar débito específico pelo pagador cancela internamente e avisa; entre PSPs usa CAMT.055 e retorno CAMT.029, com registro e aviso ao recebedor. Cancelamento pelo recebedor antes de enviar dados é interno; após envio comunica pagador, cancela agenda e confirma às partes com CAMT.055/029. Mesmo PSP cancela cobrança/débito e comunica ambos. Manual de Fluxos 2.1, p. 97Manual de Fluxos 2.1, p. 98Manual de Fluxos 2.1, p. 100Manual de Fluxos 2.1, p. 101
• Histórico documenta alterações de versões, incluindo NFC e distribuição por canais. Manual de Fluxos 2.1, p. 102Manual de Fluxos 2.1, p. 103

O que esta leitura não diz. Não garante devolução, saldo ou sucesso de retentativa e não substitui os manuais de tempos e regras operacionais dos produtos.

A implementação segue caminhos distintos para DICT direto/indireto, SPI, livros internos e mesmo liquidante. Canais e E2EIds precisam preservar as etapas de consulta, agenda e liquidação.

• O manual 2.1 separa gerar ordem, efetivar pagamento e devolver valores. Para Automático acrescenta autorização, agenda e cancelamento. Confirmar dados ou criar agenda não é concluir liquidação; o caminho depende de acesso DICT, participação SPI e relação entre as instituições. Manual de Fluxos 2.1, p. 4Manual de Fluxos 2.1, p. 29Manual de Fluxos 2.1, p. 34Manual de Fluxos 2.1, p. 41Manual de Fluxos 2.1, p. 45Manual de Fluxos 2.1, p. 57
• Chave informada demanda consulta DICT; inserção manual de dados bancários dispensa essa consulta, mas o prestador valida dados e apresenta recebedor para confirmação. Acesso indireto consulta por participante direto. QR estático também consulta DICT antes da confirmação. Manual de Fluxos 2.1, p. 5Manual de Fluxos 2.1, p. 6Manual de Fluxos 2.1, p. 7Manual de Fluxos 2.1, p. 8Manual de Fluxos 2.1, p. 11Manual de Fluxos 2.1, p. 12
• Quando PSI inicia por chave/dados, ele valida recebedor e obtém consentimento; depois envia dados pela API Open Finance ao PSP pagador, que solicita autenticação/confirmação no fluxo descrito. Quando PSI já possui todos os dados, também obtém consentimento e envia pela API. O manual remete detalhamento de jornadas ao arcabouço Open Finance. Manual de Fluxos 2.1, p. 9Manual de Fluxos 2.1, p. 10Manual de Fluxos 2.1, p. 23Manual de Fluxos 2.1, p. 24
• QR dinâmico requer identificar location e obter payload da cobrança no PSP recebedor; depois consulta chave no DICT e apresenta dados para confirmação. Na cobrança com vencimento, mudar a data pretendida leva à nova consulta do payload e apresentação do valor com principal, multa, juros, descontos/abatimentos calculados para essa data. Manual de Fluxos 2.1, p. 13Manual de Fluxos 2.1, p. 14Manual de Fluxos 2.1, p. 15Manual de Fluxos 2.1, p. 16Manual de Fluxos 2.1, p. 17
• No Agendado único/recorrente, data pode ser pedida no início ou após dados do recebedor, sempre antes da confirmação. E2EId da consulta inicial de agendamento serve apenas à consulta DICT; nova consulta antes da liquidação gera identificador informado na pacs.008 para reposição de fichas. Manual de Fluxos 2.1, p. 18Manual de Fluxos 2.1, p. 19Manual de Fluxos 2.1, p. 21Manual de Fluxos 2.1, p. 33Manual de Fluxos 2.1, p. 39
• Antes de liquidar Agendado por chave, PSP consulta novamente e compara existência/titularidade com o agendamento; inexistência ou titular diferente cancela a ordem e notifica insucesso. Dados bancários manuais dispensam essa nova consulta. Nos livros do próprio PSP, chave que saiu da instituição por portabilidade/reivindicação conduz a consulta DICT e verificação da titularidade. Manual de Fluxos 2.1, p. 32Manual de Fluxos 2.1, p. 33Manual de Fluxos 2.1, p. 38Manual de Fluxos 2.1, p. 39Manual de Fluxos 2.1, p. 43Manual de Fluxos 2.1, p. 44Manual de Fluxos 2.1, p. 48Manual de Fluxos 2.1, p. 49
• Aproximação NFC obtém dados de pagamento, mas continua interpretação, obtenção de payload, identificação e confirmação. Fluxograma exemplifica QR dinâmico imediato; também admite cobrança com vencimento e QR estático. Na transação por aproximação iniciada por PSI (2.6.2), ele deve utilizar as APIs do Open Finance para enviar a ordem ao PSP do pagador; na iniciada pelo próprio PSP do pagador (2.6.1) não há PSI. Manual de Fluxos 2.1, p. 24Manual de Fluxos 2.1, p. 25Manual de Fluxos 2.1, p. 26Manual de Fluxos 2.1, p. 27Manual de Fluxos 2.1, p. 28
• Liquidação imediata entre diretos bloqueia valor na conta do usuário e Conta PI pagadora; recebedor valida conta e anota crédito provisório. SPI troca saldos PI e confirma, então PSPs efetivam crédito/débito e avisam usuários. Anotação provisória não é crédito definitivo. Manual de Fluxos 2.1, p. 31Manual de Fluxos 2.1, p. 32
• Com indiretos e liquidantes distintos, mensagens SPI passam pelos liquidantes, mas validação de conta, anotação provisória e crédito/débito dos usuários são dos PSPs. SPI transfere entre Contas PI dos liquidantes. Com mesmo liquidante, ele ajusta saldos internos dos PSPs; não há etapa descrita de troca entre Contas PI distintas. Manual de Fluxos 2.1, p. 36Manual de Fluxos 2.1, p. 37Manual de Fluxos 2.1, p. 46Manual de Fluxos 2.1, p. 47
• Quando pagador e recebedor usam o mesmo PSP, liquidação ocorre nos seus livros: verifica saldo/conta, debita e credita se válidos e notifica ambos. O manual descreve esse caminho independentemente de participação direta ou indireta no SPI. Manual de Fluxos 2.1, p. 41Manual de Fluxos 2.1, p. 42
• Ordens de Automático, Agendado único/recorrente e Cobrança com vencimento quando agendada, e mensagens do ciclo de liquidação, usam canal secundário com NORM/PAGAGD. Demais ordens usam primário. No Automático, PAIN.009/011/012 e CAMT.055/029 de autorização/cancelamento vão pelo primário; PAIN.013/014 e PACS.008/002 de agenda/liquidação vão pelo secundário. Manual de Fluxos 2.1, p. 29Manual de Fluxos 2.1, p. 34Manual de Fluxos 2.1, p. 57
• Devolução inverte papéis: recebedor original é remetente e pagador original é destinatário. PSP destinatário recupera transação pelo EndToEndId e valida prazo de noventa dias, cliente, valor e conta ativa. Fluxos diretos/indiretos separam bloqueio, crédito provisório, transferência, efetivação e avisos; liquidante participa quando há indiretos. Manual de Fluxos 2.1, p. 50Manual de Fluxos 2.1, p. 52Manual de Fluxos 2.1, p. 53Manual de Fluxos 2.1, p. 55Manual de Fluxos 2.1, p. 56
• Na autorização sem QR entre instituições, recebedor envia dados, PSPs armazenam recorrência e trocam PAIN.009/012 para recebimento; pagador é solicitado a autorizar. A confirmação pelo usuário atualiza status, circula PAIN.012 e retorno; recebedor e pagador recebem confirmação final. Quando PSP é o mesmo, armazenamento, status e avisos ficam internos. Manual de Fluxos 2.1, p. 58Manual de Fluxos 2.1, p. 59Manual de Fluxos 2.1, p. 60Manual de Fluxos 2.1, p. 61Manual de Fluxos 2.1, p. 62Manual de Fluxos 2.1, p. 63
• QR só de recorrência leva à consulta da location e apresentação dos dados ao pagador. Depois do aceite, status são atualizados e PAIN.012 circula com retorno entre PSPs antes do aviso final. No mesmo PSP, carregamento e atualização são internos. Entregar QR por fora do ecossistema não substitui a confirmação no app. Manual de Fluxos 2.1, p. 63Manual de Fluxos 2.1, p. 65Manual de Fluxos 2.1, p. 66Manual de Fluxos 2.1, p. 67Manual de Fluxos 2.1, p. 68
• Primeiro pagamento imediato e autorização são confirmados juntos, mas o fluxo de autorização só prossegue após sucesso na liquidação usual do primeiro Pix: entre PSPs diferentes usa canal primário; no mesmo PSP segue liquidação nos seus livros. Fracasso interrompe e avisa que pagamento/autorização não se efetivaram. PSP recebedor também aguarda conclusão antes de atualizar status. Aviso de pagamento pode ser agrupado ao aviso final da autorização. Manual de Fluxos 2.1, p. 70Manual de Fluxos 2.1, p. 71Manual de Fluxos 2.1, p. 72Manual de Fluxos 2.1, p. 73Manual de Fluxos 2.1, p. 74Manual de Fluxos 2.1, p. 75
• Na jornada de oferta posterior, pagador confirma pagar ou agendar a cobrança; só depois recebe oferta do Automático, manifesta interesse e confirma recorrência. Quando cobrança já está no QR como dados estáticos, apenas recorrência vem de location. Modelos com instituições distintas sincronizam PAIN.012 e retorno; mesmo PSP registra internamente. Manual de Fluxos 2.1, p. 76Manual de Fluxos 2.1, p. 78Manual de Fluxos 2.1, p. 79Manual de Fluxos 2.1, p. 80Manual de Fluxos 2.1, p. 81Manual de Fluxos 2.1, p. 82Manual de Fluxos 2.1, p. 83
• Cancelamento da autorização pelo pagador cancela internamente e confirma ao usuário, informa recorrência por PAIN.011 e recebe PAIN.012 entre PSPs; recebedor é avisado. Se há agendas atingidas a cancelar, PSP pagador executa também o fluxo de cancelamento de débito. No mesmo PSP, cancela autorização e atualiza recorrência sem troca interinstitucional. Manual de Fluxos 2.1, p. 84Manual de Fluxos 2.1, p. 85Manual de Fluxos 2.1, p. 86
• Cancelamento da recorrência pelo recebedor registra estado, comunica PAIN.011 e retorno PAIN.012 e avisa partes, cancelando autorização associada. Também serve para cancelar solicitação pendente confirmada por outra jornada. Agendas pendentes atingidas demandam fluxo próprio. No mesmo PSP, recorrência e autorização são canceladas internamente. Manual de Fluxos 2.1, p. 87Manual de Fluxos 2.1, p. 88Manual de Fluxos 2.1, p. 89
• Agenda Automático entre instituições exige validar cobrança contra recorrência no PSP recebedor e contra autorização no pagador; PAIN.013 leva cobrança e PAIN.014 retorna resultado, com armazenamento e aviso ao recebedor. Aviso de agendamento ao pagador pode ser desabilitado, e somente essas etapas são omitidas. Mesmo PSP compara, agenda e comunica internamente. Manual de Fluxos 2.1, p. 90Manual de Fluxos 2.1, p. 91Manual de Fluxos 2.1, p. 92
• Entre PSPs diferentes, com erro no fluxo de liquidação, o PSP do pagador registra o insucesso e cancela a PAIN.013 original por CAMT.055, que o PSP do recebedor confirma com CAMT.029; em seguida, o PSP do recebedor valida novamente a cobrança com a recorrência e deve enviar nova PAIN.013, para que o PSP do pagador gere nova PACS.008 com novo E2EId, a ser liquidada na mesma data. Identificador de ordem não liquidada não é reutilizado; notificações ao pagador do fluxo de cancelamento não se aplicam nessa correção. Retentativa após vencimento tem nova instrução e novo agendamento; não é o mesmo fluxo intradia. No mesmo PSP, registra insucesso, compara cobrança com autorização e agenda nova ordem para o mesmo dia em seus sistemas, sem o roteiro de mensageria entre instituições. Manual de Fluxos 2.1, p. 93Manual de Fluxos 2.1, p. 94Manual de Fluxos 2.1, p. 95
• Cancelar débito específico pelo pagador cancela internamente e avisa; entre PSPs usa CAMT.055 e retorno CAMT.029, com registro e aviso ao recebedor. Cancelamento pelo recebedor antes de enviar dados é interno; após envio comunica pagador, cancela agenda e confirma às partes com CAMT.055/029. Mesmo PSP cancela cobrança/débito e comunica ambos. Manual de Fluxos 2.1, p. 97Manual de Fluxos 2.1, p. 98Manual de Fluxos 2.1, p. 100Manual de Fluxos 2.1, p. 101
• Histórico documenta alterações de versões, incluindo NFC e distribuição por canais. Manual de Fluxos 2.1, p. 102Manual de Fluxos 2.1, p. 103

O que esta leitura não diz. Não fornece todos schemas do catálogo ou regras Open Finance e não autoriza reutilizar identificador de ordem não liquidada.

Os fluxos atribuem ações aos usuários, PSPs, liquidantes e infraestrutura. Esta leitura destaca quem valida, confirma e comunica, sem confundir autorização, agendamento e conclusão de pagamento.

• O manual 2.1 separa gerar ordem, efetivar pagamento e devolver valores. Para Automático acrescenta autorização, agenda e cancelamento. Confirmar dados ou criar agenda não é concluir liquidação; o caminho depende de acesso DICT, participação SPI e relação entre as instituições. Manual de Fluxos 2.1, p. 4Manual de Fluxos 2.1, p. 29Manual de Fluxos 2.1, p. 34Manual de Fluxos 2.1, p. 41Manual de Fluxos 2.1, p. 45Manual de Fluxos 2.1, p. 57
• Chave informada demanda consulta DICT; inserção manual de dados bancários dispensa essa consulta, mas o prestador valida dados e apresenta recebedor para confirmação. Acesso indireto consulta por participante direto. QR estático também consulta DICT antes da confirmação. Manual de Fluxos 2.1, p. 5Manual de Fluxos 2.1, p. 6Manual de Fluxos 2.1, p. 7Manual de Fluxos 2.1, p. 8Manual de Fluxos 2.1, p. 11Manual de Fluxos 2.1, p. 12
• Quando PSI inicia por chave/dados, ele valida recebedor e obtém consentimento; depois envia dados pela API Open Finance ao PSP pagador, que solicita autenticação/confirmação no fluxo descrito. Quando PSI já possui todos os dados, também obtém consentimento e envia pela API. O manual remete detalhamento de jornadas ao arcabouço Open Finance. Manual de Fluxos 2.1, p. 9Manual de Fluxos 2.1, p. 10Manual de Fluxos 2.1, p. 23Manual de Fluxos 2.1, p. 24
• No Agendado único/recorrente, data pode ser pedida no início ou após dados do recebedor, sempre antes da confirmação. E2EId da consulta inicial de agendamento serve apenas à consulta DICT; nova consulta antes da liquidação gera identificador informado na pacs.008 para reposição de fichas. Manual de Fluxos 2.1, p. 18Manual de Fluxos 2.1, p. 19Manual de Fluxos 2.1, p. 21Manual de Fluxos 2.1, p. 33Manual de Fluxos 2.1, p. 39
• Antes de liquidar Agendado por chave, PSP consulta novamente e compara existência/titularidade com o agendamento; inexistência ou titular diferente cancela a ordem e notifica insucesso. Dados bancários manuais dispensam essa nova consulta. Nos livros do próprio PSP, chave que saiu da instituição por portabilidade/reivindicação conduz a consulta DICT e verificação da titularidade. Manual de Fluxos 2.1, p. 32Manual de Fluxos 2.1, p. 33Manual de Fluxos 2.1, p. 38Manual de Fluxos 2.1, p. 39Manual de Fluxos 2.1, p. 43Manual de Fluxos 2.1, p. 44Manual de Fluxos 2.1, p. 48Manual de Fluxos 2.1, p. 49
• Liquidação imediata entre diretos bloqueia valor na conta do usuário e Conta PI pagadora; recebedor valida conta e anota crédito provisório. SPI troca saldos PI e confirma, então PSPs efetivam crédito/débito e avisam usuários. Anotação provisória não é crédito definitivo. Manual de Fluxos 2.1, p. 31Manual de Fluxos 2.1, p. 32
• Com indiretos e liquidantes distintos, mensagens SPI passam pelos liquidantes, mas validação de conta, anotação provisória e crédito/débito dos usuários são dos PSPs. SPI transfere entre Contas PI dos liquidantes. Com mesmo liquidante, ele ajusta saldos internos dos PSPs; não há etapa descrita de troca entre Contas PI distintas. Manual de Fluxos 2.1, p. 36Manual de Fluxos 2.1, p. 37Manual de Fluxos 2.1, p. 46Manual de Fluxos 2.1, p. 47
• Quando pagador e recebedor usam o mesmo PSP, liquidação ocorre nos seus livros: verifica saldo/conta, debita e credita se válidos e notifica ambos. O manual descreve esse caminho independentemente de participação direta ou indireta no SPI. Manual de Fluxos 2.1, p. 41Manual de Fluxos 2.1, p. 42
• Ordens de Automático, Agendado único/recorrente e Cobrança com vencimento quando agendada, e mensagens do ciclo de liquidação, usam canal secundário com NORM/PAGAGD. Demais ordens usam primário. No Automático, PAIN.009/011/012 e CAMT.055/029 de autorização/cancelamento vão pelo primário; PAIN.013/014 e PACS.008/002 de agenda/liquidação vão pelo secundário. Manual de Fluxos 2.1, p. 29Manual de Fluxos 2.1, p. 34Manual de Fluxos 2.1, p. 57
• Devolução inverte papéis: recebedor original é remetente e pagador original é destinatário. PSP destinatário recupera transação pelo EndToEndId e valida prazo de noventa dias, cliente, valor e conta ativa. Fluxos diretos/indiretos separam bloqueio, crédito provisório, transferência, efetivação e avisos; liquidante participa quando há indiretos. Manual de Fluxos 2.1, p. 50Manual de Fluxos 2.1, p. 52Manual de Fluxos 2.1, p. 53Manual de Fluxos 2.1, p. 55Manual de Fluxos 2.1, p. 56
• Na autorização sem QR entre instituições, recebedor envia dados, PSPs armazenam recorrência e trocam PAIN.009/012 para recebimento; pagador é solicitado a autorizar. A confirmação pelo usuário atualiza status, circula PAIN.012 e retorno; recebedor e pagador recebem confirmação final. Quando PSP é o mesmo, armazenamento, status e avisos ficam internos. Manual de Fluxos 2.1, p. 58Manual de Fluxos 2.1, p. 59Manual de Fluxos 2.1, p. 60Manual de Fluxos 2.1, p. 61Manual de Fluxos 2.1, p. 62Manual de Fluxos 2.1, p. 63
• Primeiro pagamento imediato e autorização são confirmados juntos, mas o fluxo de autorização só prossegue após sucesso na liquidação usual do primeiro Pix: entre PSPs diferentes usa canal primário; no mesmo PSP segue liquidação nos seus livros. Fracasso interrompe e avisa que pagamento/autorização não se efetivaram. PSP recebedor também aguarda conclusão antes de atualizar status. Aviso de pagamento pode ser agrupado ao aviso final da autorização. Manual de Fluxos 2.1, p. 70Manual de Fluxos 2.1, p. 71Manual de Fluxos 2.1, p. 72Manual de Fluxos 2.1, p. 73Manual de Fluxos 2.1, p. 74Manual de Fluxos 2.1, p. 75
• Cancelamento da autorização pelo pagador cancela internamente e confirma ao usuário, informa recorrência por PAIN.011 e recebe PAIN.012 entre PSPs; recebedor é avisado. Se há agendas atingidas a cancelar, PSP pagador executa também o fluxo de cancelamento de débito. No mesmo PSP, cancela autorização e atualiza recorrência sem troca interinstitucional. Manual de Fluxos 2.1, p. 84Manual de Fluxos 2.1, p. 85Manual de Fluxos 2.1, p. 86
• Cancelamento da recorrência pelo recebedor registra estado, comunica PAIN.011 e retorno PAIN.012 e avisa partes, cancelando autorização associada. Também serve para cancelar solicitação pendente confirmada por outra jornada. Agendas pendentes atingidas demandam fluxo próprio. No mesmo PSP, recorrência e autorização são canceladas internamente. Manual de Fluxos 2.1, p. 87Manual de Fluxos 2.1, p. 88Manual de Fluxos 2.1, p. 89
• Agenda Automático entre instituições exige validar cobrança contra recorrência no PSP recebedor e contra autorização no pagador; PAIN.013 leva cobrança e PAIN.014 retorna resultado, com armazenamento e aviso ao recebedor. Aviso de agendamento ao pagador pode ser desabilitado, e somente essas etapas são omitidas. Mesmo PSP compara, agenda e comunica internamente. Manual de Fluxos 2.1, p. 90Manual de Fluxos 2.1, p. 91Manual de Fluxos 2.1, p. 92
• Entre PSPs diferentes, com erro no fluxo de liquidação, o PSP do pagador registra o insucesso e cancela a PAIN.013 original por CAMT.055, que o PSP do recebedor confirma com CAMT.029; em seguida, o PSP do recebedor valida novamente a cobrança com a recorrência e deve enviar nova PAIN.013, para que o PSP do pagador gere nova PACS.008 com novo E2EId, a ser liquidada na mesma data. Identificador de ordem não liquidada não é reutilizado; notificações ao pagador do fluxo de cancelamento não se aplicam nessa correção. Retentativa após vencimento tem nova instrução e novo agendamento; não é o mesmo fluxo intradia. No mesmo PSP, registra insucesso, compara cobrança com autorização e agenda nova ordem para o mesmo dia em seus sistemas, sem o roteiro de mensageria entre instituições. Manual de Fluxos 2.1, p. 93Manual de Fluxos 2.1, p. 94Manual de Fluxos 2.1, p. 95
• Cancelar débito específico pelo pagador cancela internamente e avisa; entre PSPs usa CAMT.055 e retorno CAMT.029, com registro e aviso ao recebedor. Cancelamento pelo recebedor antes de enviar dados é interno; após envio comunica pagador, cancela agenda e confirma às partes com CAMT.055/029. Mesmo PSP cancela cobrança/débito e comunica ambos. Manual de Fluxos 2.1, p. 97Manual de Fluxos 2.1, p. 98Manual de Fluxos 2.1, p. 100Manual de Fluxos 2.1, p. 101

O que esta leitura não diz. Não fixa neste contexto todos os prazos de cancelamento ou retentativas do produto, nem garante conclusão de uma ordem.

O que QR, Copia e Cola e aproximação transportam, dados de cobrança e recorrência e condições para comunicar sucesso ou falha.

• Manual 2.10.0 integra o regulamento e detalha iniciação e API Pix; documentação OpenAPI correspondente é a tag do mesmo identificador, evitando misturar versões. BR Code trata QR apresentado pelo recebedor. Histórico e cronograma de junho de 2025 não criam novo prazo de implantação hoje. Manual de Iniciação 2.10.0, p. 1Manual de Iniciação 2.10.0, p. 6Manual de Iniciação 2.10.0, p. 41Manual de Iniciação 2.10.0, p. 118Manual de Iniciação 2.10.0, p. 119Manual de Iniciação 2.10.0, p. 123
• Estático contém chave DICT e opções limitadas; dinâmico usa location para obter cobrança; composto acrescenta location de recorrência e pode conter só recorrência. GUI é br.gov.bcb.pix. Chaves seguem DICT, incluindo CNPJ alfanumérico, celular internacional e aleatória com pontuação. Manual de Iniciação 2.10.0, p. 7Manual de Iniciação 2.10.0, p. 8Manual de Iniciação 2.10.0, p. 9
• Locations não incluem prefixo de protocolo, têm máximo de setenta e sete caracteres e distinguem cob, cobv e rec. Antes de acessar, validar caracteres, estrutura e domínio autorizado; acesso só HTTPS e campos JSON permanecem nulos até acesso e verificações positivas. Duas URLs do composto devem ter mesmo domínio completo e mesmas exigências de segurança. Manual de Iniciação 2.10.0, p. 10Manual de Iniciação 2.10.0, p. 30Manual de Iniciação 2.10.0, p. 37
• No estático, chave, infoAdicional e facilitador disputam espaço de noventa e nove caracteres do template. TxId em efeito é alfanumérico até vinte e cinco caracteres e retransmitido intacto; ausência usa marcador ***. Fss indica Saque; Troco exige dinâmico. Nome de apresentação vem do DICT, não do MerchantName do BR Code. Manual de Iniciação 2.10.0, p. 11Manual de Iniciação 2.10.0, p. 12Manual de Iniciação 2.10.0, p. 13
• Montagem de QR estático não é funcionalidade da API Pix, embora pagamentos com txid possam ser consultados. No dinâmico, valor e txid BR Code são ignorados em favor do payload da URL. QR dinâmico em integração automatizada usa API Pix, ressalvado app mobile próprio; API não retorna arquivo da imagem do QR. Manual de Iniciação 2.10.0, p. 14Manual de Iniciação 2.10.0, p. 15Manual de Iniciação 2.10.0, p. 28
• Cobrança imediata tem revisão iniciada em zero, incrementada só em alterações PUT/PATCH; recomenda-se guardar payload assinado. Timestamps são UTC e expiração ausente assume vinte e quatro horas desde criação. Devedor não é necessariamente pagador; nome é exigido quando CPF/CNPJ preenchido. Manual de Iniciação 2.10.0, p. 16Manual de Iniciação 2.10.0, p. 17Manual de Iniciação 2.10.0, p. 18
• Modalidade de alteração ausente impede editar valor. Compra, Saque e Troco têm campos e regras diferentes: Saque original zero, Troco compra positiva, retirada não se combina entre saque/troco; total não pode ser zero. Valor monetário usa duas casas decimais. Modalidade/ISPB do facilitador e domínio do agente seguem regras próprias. Manual de Iniciação 2.10.0, p. 18Manual de Iniciação 2.10.0, p. 19Manual de Iniciação 2.10.0, p. 20Manual de Iniciação 2.10.0, p. 105
• SolicitacaoPagador pede entrada livre: quem segue para RmtInf é a resposta do usuário, não o enunciado, até cento e quarenta caracteres. Adicionais presentes mostram pares nome/valor; payload JSON é assinado e só se procede ao parsing se assinatura JWS válida. Cobrança concluída/expirada/removida pode retornar HTTP de semântica adequada, a critério do PSP. Manual de Iniciação 2.10.0, p. 21Manual de Iniciação 2.10.0, p. 22Manual de Iniciação 2.10.0, p. 27Manual de Iniciação 2.10.0, p. 28Manual de Iniciação 2.10.0, p. 72
• Cobrança com vencimento consulta DPP e município cadastral IBGE, ressalvada ausência municipal por regulação específica da conta. Sem município, recebedor assume ausência de feriados locais; sem DPP, assume vencimento se não vencida e consulta se vencida. Datas não úteis de vencimento e validade prorrogam ao útil seguinte; devedor é obrigatório nesse tipo. Manual de Iniciação 2.10.0, p. 22Manual de Iniciação 2.10.0, p. 23Manual de Iniciação 2.10.0, p. 24
• PSP recebedor calcula valor final: original menos abatimento e desconto mais juros e multa; o app do PSP pagador apresenta componentes não nulos individualmente. Parametrização distingue valor fixo/percentual, datas e dias úteis/corridos. Abatimento/desconto percentual usam bases distintas, e juros percentuais usam fator truncado em seis casas, resultado truncado em duas; multa calculada também truncada em duas. Antecipação por dias corridos usa vencimento original, mesmo não útil. Manual de Iniciação 2.10.0, p. 25Manual de Iniciação 2.10.0, p. 68Manual de Iniciação 2.10.0, p. 69Manual de Iniciação 2.10.0, p. 70Manual de Iniciação 2.10.0, p. 71Manual de Iniciação 2.10.0, p. 73Manual de Iniciação 2.10.0, p. 74Manual de Iniciação 2.10.0, p. 75Manual de Iniciação 2.10.0, p. 76Manual de Iniciação 2.10.0, p. 77Manual de Iniciação 2.10.0, p. 78Manual de Iniciação 2.10.0, p. 79Manual de Iniciação 2.10.0, p. 80Manual de Iniciação 2.10.0, p. 81
• Composto tem recorrência apenas, estático+recorrência ou dinâmico+recorrência. Dados dos payloads prevalecem sobre EMV; pagamentos compostos não permitem Saque/Troco. Copia e Cola copia integralmente a mesma sequência do QR, valendo também para composto. Manual de Iniciação 2.10.0, p. 29Manual de Iniciação 2.10.0, p. 30Manual de Iniciação 2.10.0, p. 31Manual de Iniciação 2.10.0, p. 38
• NFC exige aparelhos com tecnologia, próximos e conectados; transporta Copia e Cola em URI e mantém confirmação e checagens do QR. Estático não resolve payload JSON. Especificação Android complementar é obrigatória no recorte, sem substituir este manual. Manual de Iniciação 2.10.0, p. 40
• API Pix automatiza recebedor com PSP, cria/consulta/altera/remove cobrança e verifica pagamentos, devoluções e recorrências. Cobrança é entidade diferente de Pix recebido; CONCLUÍDA é estado final da cobrança que não admite novo pagamento, sem afirmar quitação de toda obrigação subjacente. Devolução em processamento difere de devolvida ou não realizada. Manual de Iniciação 2.10.0, p. 41Manual de Iniciação 2.10.0, p. 42Manual de Iniciação 2.10.0, p. 43Manual de Iniciação 2.10.0, p. 44Manual de Iniciação 2.10.0, p. 45Manual de Iniciação 2.10.0, p. 62Manual de Iniciação 2.10.0, p. 63
• Cardinalidades permitem vários pagamentos por cobrança e várias devoluções por Pix; locations têm uma cobrança/recorrência por vez e podem ser reutilizadas. Caso do QR dinâmico impresso confirma liquidação antes de liberar compra e desvincula cobrança para o próximo atendimento. Lote recebido com sucesso ainda está em processamento; consultar resultados individuais. Manual de Iniciação 2.10.0, p. 47Manual de Iniciação 2.10.0, p. 53Manual de Iniciação 2.10.0, p. 54
• Onboarding API ocorre logado, envia credenciais por canal seguro e garante rastreabilidade. API exige alta disponibilidade e confidencialidade/integridade em trânsito e repouso; logs de acesso são guardados pelo menos um ano. Webhooks usam mTLS; reutilizar certificado da API é recomendação, assim como MFA no onboarding, análise de vulnerabilidades e homologação de clientes. Manual de Iniciação 2.10.0, p. 65Manual de Iniciação 2.10.0, p. 66Manual de Iniciação 2.10.0, p. 67
• Automático distingue recorrência, permissão, autorização e cobrança; não gera QR para cada cobrança recorrente. Jornada 3 com erro em qualquer payload interrompe pagamento/autorização; jornada 4 com erro de cobrança interrompe, mas erro só da recorrência permite pagamento normal sem oferta final. Jornada 2 contém só recorrência. Manual de Iniciação 2.10.0, p. 39Manual de Iniciação 2.10.0, p. 40Manual de Iniciação 2.10.0, p. 55Manual de Iniciação 2.10.0, p. 56Manual de Iniciação 2.10.0, p. 57Manual de Iniciação 2.10.0, p. 58Manual de Iniciação 2.10.0, p. 99
• SolicRec é exclusiva da jornada 1, com identificador SC gerado pelo PSP recebedor e dados bancários para endereçar, pois Automático não usa chaves. Guarda payload da recorrência pertinente ao pedido. Confirmação/cancelamento da recorrência cancela pedidos pendentes e comunica pagador para excluí-los; timeout de recebimento de um minuto exige cancelar e enviar pain.011. Manual de Iniciação 2.10.0, p. 46Manual de Iniciação 2.10.0, p. 84Manual de Iniciação 2.10.0, p. 85Manual de Iniciação 2.10.0, p. 89Manual de Iniciação 2.10.0, p. 96
• CobR exige autorização vigente e dados compatíveis. Conta recebedora informada em cada cobrança deve pertencer ao recebedor; PSP impede criação se não pertencer. CobR e tentativa têm status distintos, e código de rejeição pode afetar só tentativa. Histórico guarda política aplicada e tentativas originais, intradia e posteriores. Manual de Iniciação 2.10.0, p. 60Manual de Iniciação 2.10.0, p. 85Manual de Iniciação 2.10.0, p. 86Manual de Iniciação 2.10.0, p. 87Manual de Iniciação 2.10.0, p. 90Manual de Iniciação 2.10.0, p. 91Manual de Iniciação 2.10.0, p. 92Manual de Iniciação 2.10.0, p. 93Manual de Iniciação 2.10.0, p. 94
• AjusteDiaUtil é true por padrão e considera feriados do município pagador; recebedor pode optar false se tiver amparo legal para cobrar no dia não útil. Critério de vencimento em data inexistente deve constar do contrato, enquanto início de ciclo Pix usa data existente imediatamente anterior. Só uma cobrança por ciclo, salvo RIFL e NTAG. Manual de Iniciação 2.10.0, p. 87Manual de Iniciação 2.10.0, p. 97Manual de Iniciação 2.10.0, p. 98
• Após confirmação, recebedor só altera loc e nome do devedor da recorrência; data inicial e txid jornada 3 só antes. Outros parâmetros exigem cancelar e pedir nova autorização. Jornada 3 só confirma recorrência após pagamento imediato confirmado, iniciado como QRDN; pagamento feito com autorização falha exige outra jornada ou nova oferta no período seguinte. Manual de Iniciação 2.10.0, p. 96Manual de Iniciação 2.10.0, p. 97
• Política após vencimento admite até três novas tentativas em dias diferentes por até sete dias corridos desde data prevista original; usuário não recusa só essa condição, mas toda recorrência. PSP rejeita pedido fora da política; pagador recebe instrução até fim da véspera. Retentativa intradia por falta de saldo é controle exclusivo pagador; erro após envio gera RIFL com novo E2E quando recebedor recebe cancelamento por falha. Manual de Iniciação 2.10.0, p. 44Manual de Iniciação 2.10.0, p. 83Manual de Iniciação 2.10.0, p. 96Manual de Iniciação 2.10.0, p. 97Manual de Iniciação 2.10.0, p. 99
• Só alteração permitida de CobR pelo recebedor é cancelamento até véspera da primeira liquidação prevista, respeitando recebimento no PSP pagador até vinte e duas horas. Para corrigir, cancelar e criar nova com novo txid dentro da janela de agendamento. Pagador não cancela individualmente retentativa após vencimento. Cancelar recorrência comunica e cancela autorização vinculada. Manual de Iniciação 2.10.0, p. 61Manual de Iniciação 2.10.0, p. 62Manual de Iniciação 2.10.0, p. 94Manual de Iniciação 2.10.0, p. 95Manual de Iniciação 2.10.0, p. 98
• Cancelamento solicitado pelo recebedor só é confirmado ao seu usuário após camt.029 do pagador. Arquivo padronizado é alternativa API para Automático, baseado em CNAB com setecentas e cinquenta posições fixas por linha; leiautes de remessa/retorno e orientações são documentos complementares. Manual de Iniciação 2.10.0, p. 115Manual de Iniciação 2.10.0, p. 116Manual de Iniciação 2.10.0, p. 117
• Devolução API aponta E2E original e identificador único por E2E, pode ter várias parcelas sem ultrapassar original; no caso de uso ilustrativo, o software do recebedor consulta pela API Pix se a devolução foi liquidada. Remover/alterar cobrança comum concluída é vedado; aceitar requisição ou ter recurso EM_PROCESSAMENTO não equivale a crédito efetivado. Manual de Iniciação 2.10.0, p. 45Manual de Iniciação 2.10.0, p. 62Manual de Iniciação 2.10.0, p. 63

O que esta leitura não diz. Não define aqui todas as telas do manual UX nem permite chamar confirmação de agenda de pagamento liquidado.

Escolhas de QR e integração, geração de cobranças e recorrências, estados, limites de alteração e confirmação de recebimentos.

• Manual 2.10.0 integra o regulamento e detalha iniciação e API Pix; documentação OpenAPI correspondente é a tag do mesmo identificador, evitando misturar versões. BR Code trata QR apresentado pelo recebedor. Histórico e cronograma de junho de 2025 não criam novo prazo de implantação hoje. Manual de Iniciação 2.10.0, p. 1Manual de Iniciação 2.10.0, p. 6Manual de Iniciação 2.10.0, p. 41Manual de Iniciação 2.10.0, p. 118Manual de Iniciação 2.10.0, p. 119Manual de Iniciação 2.10.0, p. 123
• Estático contém chave DICT e opções limitadas; dinâmico usa location para obter cobrança; composto acrescenta location de recorrência e pode conter só recorrência. GUI é br.gov.bcb.pix. Chaves seguem DICT, incluindo CNPJ alfanumérico, celular internacional e aleatória com pontuação. Manual de Iniciação 2.10.0, p. 7Manual de Iniciação 2.10.0, p. 8Manual de Iniciação 2.10.0, p. 9
• No estático, chave, infoAdicional e facilitador disputam espaço de noventa e nove caracteres do template. TxId em efeito é alfanumérico até vinte e cinco caracteres e retransmitido intacto; ausência usa marcador ***. Fss indica Saque; Troco exige dinâmico. Nome de apresentação vem do DICT, não do MerchantName do BR Code. Manual de Iniciação 2.10.0, p. 11Manual de Iniciação 2.10.0, p. 12Manual de Iniciação 2.10.0, p. 13
• Montagem de QR estático não é funcionalidade da API Pix, embora pagamentos com txid possam ser consultados. No dinâmico, valor e txid BR Code são ignorados em favor do payload da URL. QR dinâmico em integração automatizada usa API Pix, ressalvado app mobile próprio; API não retorna arquivo da imagem do QR. Manual de Iniciação 2.10.0, p. 14Manual de Iniciação 2.10.0, p. 15Manual de Iniciação 2.10.0, p. 28
• Cobrança imediata tem revisão iniciada em zero, incrementada só em alterações PUT/PATCH; recomenda-se guardar payload assinado. Timestamps são UTC e expiração ausente assume vinte e quatro horas desde criação. Devedor não é necessariamente pagador; nome é exigido quando CPF/CNPJ preenchido. Manual de Iniciação 2.10.0, p. 16Manual de Iniciação 2.10.0, p. 17Manual de Iniciação 2.10.0, p. 18
• Modalidade de alteração ausente impede editar valor. Compra, Saque e Troco têm campos e regras diferentes: Saque original zero, Troco compra positiva, retirada não se combina entre saque/troco; total não pode ser zero. Valor monetário usa duas casas decimais. Modalidade/ISPB do facilitador e domínio do agente seguem regras próprias. Manual de Iniciação 2.10.0, p. 18Manual de Iniciação 2.10.0, p. 19Manual de Iniciação 2.10.0, p. 20Manual de Iniciação 2.10.0, p. 105
• Txid de cobrança API tem vinte e seis a trinta e cinco caracteres alfanuméricos, único por CPF/CNPJ e PSP inclusive depois de cancelamento/baixa e entre cob/cobv. Recebedor normalmente o gera; delegação ao PSP só para imediata perde garantia de idempotência e exige explicação/análise. Estático tem outro modelo, com consistência de conciliação a cargo do recebedor no contexto da API. Manual de Iniciação 2.10.0, p. 21Manual de Iniciação 2.10.0, p. 43Manual de Iniciação 2.10.0, p. 48Manual de Iniciação 2.10.0, p. 52
• Cobrança com vencimento consulta DPP e município cadastral IBGE, ressalvada ausência municipal por regulação específica da conta. Sem município, recebedor assume ausência de feriados locais; sem DPP, assume vencimento se não vencida e consulta se vencida. Datas não úteis de vencimento e validade prorrogam ao útil seguinte; devedor é obrigatório nesse tipo. Manual de Iniciação 2.10.0, p. 22Manual de Iniciação 2.10.0, p. 23Manual de Iniciação 2.10.0, p. 24
• PSP recebedor calcula valor final: original menos abatimento e desconto mais juros e multa; o app do PSP pagador apresenta componentes não nulos individualmente. Parametrização distingue valor fixo/percentual, datas e dias úteis/corridos. Abatimento/desconto percentual usam bases distintas, e juros percentuais usam fator truncado em seis casas, resultado truncado em duas; multa calculada também truncada em duas. Antecipação por dias corridos usa vencimento original, mesmo não útil. Manual de Iniciação 2.10.0, p. 25Manual de Iniciação 2.10.0, p. 68Manual de Iniciação 2.10.0, p. 69Manual de Iniciação 2.10.0, p. 70Manual de Iniciação 2.10.0, p. 71Manual de Iniciação 2.10.0, p. 73Manual de Iniciação 2.10.0, p. 74Manual de Iniciação 2.10.0, p. 75Manual de Iniciação 2.10.0, p. 76Manual de Iniciação 2.10.0, p. 77Manual de Iniciação 2.10.0, p. 78Manual de Iniciação 2.10.0, p. 79Manual de Iniciação 2.10.0, p. 80Manual de Iniciação 2.10.0, p. 81
• Composto tem recorrência apenas, estático+recorrência ou dinâmico+recorrência. Dados dos payloads prevalecem sobre EMV; pagamentos compostos não permitem Saque/Troco. Copia e Cola copia integralmente a mesma sequência do QR, valendo também para composto. Manual de Iniciação 2.10.0, p. 29Manual de Iniciação 2.10.0, p. 30Manual de Iniciação 2.10.0, p. 31Manual de Iniciação 2.10.0, p. 38
• Serviço de iniciação transmite campos mínimos segundo MANU, DICT, INIC, QRES, QRDN ou AUTO; EndToEndId é gerado pelo iniciador no recorte vigente, Description é enviada se preenchida e cobv considera município informado pelo iniciador. Dados da instrução AUTO vêm da API Open Finance; essa trilha não se confunde com API Pix recebedora. Manual de Iniciação 2.10.0, p. 38Manual de Iniciação 2.10.0, p. 106
• NFC exige aparelhos com tecnologia, próximos e conectados; transporta Copia e Cola em URI e mantém confirmação e checagens do QR. Estático não resolve payload JSON. Especificação Android complementar é obrigatória no recorte, sem substituir este manual. Manual de Iniciação 2.10.0, p. 40
• API Pix automatiza recebedor com PSP, cria/consulta/altera/remove cobrança e verifica pagamentos, devoluções e recorrências. Cobrança é entidade diferente de Pix recebido; CONCLUÍDA é estado final da cobrança que não admite novo pagamento, sem afirmar quitação de toda obrigação subjacente. Devolução em processamento difere de devolvida ou não realizada. Manual de Iniciação 2.10.0, p. 41Manual de Iniciação 2.10.0, p. 42Manual de Iniciação 2.10.0, p. 43Manual de Iniciação 2.10.0, p. 44Manual de Iniciação 2.10.0, p. 45Manual de Iniciação 2.10.0, p. 62Manual de Iniciação 2.10.0, p. 63
• Cardinalidades permitem vários pagamentos por cobrança e várias devoluções por Pix; locations têm uma cobrança/recorrência por vez e podem ser reutilizadas. Caso do QR dinâmico impresso confirma liquidação antes de liberar compra e desvincula cobrança para o próximo atendimento. Lote recebido com sucesso ainda está em processamento; consultar resultados individuais. Manual de Iniciação 2.10.0, p. 47Manual de Iniciação 2.10.0, p. 53Manual de Iniciação 2.10.0, p. 54
• Funcionalidades API são obrigatórias conforme produto/jornada da tabela, não todos os endpoints para todo participante. Webhook de Pix só informa recebimentos associados a txid e chave configurada; Rec e CobR notificam suas atualizações. Tratam integração do PSP com recebedor, sem constituir recurso próprio deste guia. Manual de Iniciação 2.10.0, p. 49Manual de Iniciação 2.10.0, p. 64Manual de Iniciação 2.10.0, p. 100
• Automático distingue recorrência, permissão, autorização e cobrança; não gera QR para cada cobrança recorrente. Jornada 3 com erro em qualquer payload interrompe pagamento/autorização; jornada 4 com erro de cobrança interrompe, mas erro só da recorrência permite pagamento normal sem oferta final. Jornada 2 contém só recorrência. Manual de Iniciação 2.10.0, p. 39Manual de Iniciação 2.10.0, p. 40Manual de Iniciação 2.10.0, p. 55Manual de Iniciação 2.10.0, p. 56Manual de Iniciação 2.10.0, p. 57Manual de Iniciação 2.10.0, p. 58Manual de Iniciação 2.10.0, p. 99
• IdRec tem vinte e nove caracteres e distingue origem Pix/Open Finance e retentativas; API Pix só cria/consulta/gestiona identificadores R, não C. PSP preenche recebedor a partir de cadastro, preserva histórico de status e só usa códigos de encerramento que realmente indiquem rejeição/cancelamento. Ativação aceita jornada informada pelo PSP pagador, sem validar esse campo; inicial AGUARDANDO_DEFINICAO. Manual de Iniciação 2.10.0, p. 82Manual de Iniciação 2.10.0, p. 83Manual de Iniciação 2.10.0, p. 84
• SolicRec é exclusiva da jornada 1, com identificador SC gerado pelo PSP recebedor e dados bancários para endereçar, pois Automático não usa chaves. Guarda payload da recorrência pertinente ao pedido. Confirmação/cancelamento da recorrência cancela pedidos pendentes e comunica pagador para excluí-los; timeout de recebimento de um minuto exige cancelar e enviar pain.011. Manual de Iniciação 2.10.0, p. 46Manual de Iniciação 2.10.0, p. 84Manual de Iniciação 2.10.0, p. 85Manual de Iniciação 2.10.0, p. 89Manual de Iniciação 2.10.0, p. 96
• CobR exige autorização vigente e dados compatíveis. Conta recebedora informada em cada cobrança deve pertencer ao recebedor; PSP impede criação se não pertencer. CobR e tentativa têm status distintos, e código de rejeição pode afetar só tentativa. Histórico guarda política aplicada e tentativas originais, intradia e posteriores. Manual de Iniciação 2.10.0, p. 60Manual de Iniciação 2.10.0, p. 85Manual de Iniciação 2.10.0, p. 86Manual de Iniciação 2.10.0, p. 87Manual de Iniciação 2.10.0, p. 90Manual de Iniciação 2.10.0, p. 91Manual de Iniciação 2.10.0, p. 92Manual de Iniciação 2.10.0, p. 93Manual de Iniciação 2.10.0, p. 94
• AjusteDiaUtil é true por padrão e considera feriados do município pagador; recebedor pode optar false se tiver amparo legal para cobrar no dia não útil. Critério de vencimento em data inexistente deve constar do contrato, enquanto início de ciclo Pix usa data existente imediatamente anterior. Só uma cobrança por ciclo, salvo RIFL e NTAG. Manual de Iniciação 2.10.0, p. 87Manual de Iniciação 2.10.0, p. 97Manual de Iniciação 2.10.0, p. 98
• Após confirmação, recebedor só altera loc e nome do devedor da recorrência; data inicial e txid jornada 3 só antes. Outros parâmetros exigem cancelar e pedir nova autorização. Jornada 3 só confirma recorrência após pagamento imediato confirmado, iniciado como QRDN; pagamento feito com autorização falha exige outra jornada ou nova oferta no período seguinte. Manual de Iniciação 2.10.0, p. 96Manual de Iniciação 2.10.0, p. 97
• Política após vencimento admite até três novas tentativas em dias diferentes por até sete dias corridos desde data prevista original; usuário não recusa só essa condição, mas toda recorrência. PSP rejeita pedido fora da política; pagador recebe instrução até fim da véspera. Retentativa intradia por falta de saldo é controle exclusivo pagador; erro após envio gera RIFL com novo E2E quando recebedor recebe cancelamento por falha. Manual de Iniciação 2.10.0, p. 44Manual de Iniciação 2.10.0, p. 83Manual de Iniciação 2.10.0, p. 96Manual de Iniciação 2.10.0, p. 97Manual de Iniciação 2.10.0, p. 99
• Só alteração permitida de CobR pelo recebedor é cancelamento até véspera da primeira liquidação prevista, respeitando recebimento no PSP pagador até vinte e duas horas. Para corrigir, cancelar e criar nova com novo txid dentro da janela de agendamento. Pagador não cancela individualmente retentativa após vencimento. Cancelar recorrência comunica e cancela autorização vinculada. Manual de Iniciação 2.10.0, p. 61Manual de Iniciação 2.10.0, p. 62Manual de Iniciação 2.10.0, p. 94Manual de Iniciação 2.10.0, p. 95Manual de Iniciação 2.10.0, p. 98
• Cancelamento solicitado pelo recebedor só é confirmado ao seu usuário após camt.029 do pagador. Arquivo padronizado é alternativa API para Automático, baseado em CNAB com setecentas e cinquenta posições fixas por linha; leiautes de remessa/retorno e orientações são documentos complementares. Manual de Iniciação 2.10.0, p. 115Manual de Iniciação 2.10.0, p. 116Manual de Iniciação 2.10.0, p. 117
• Devolução API aponta E2E original e identificador único por E2E, pode ter várias parcelas sem ultrapassar original; no caso de uso ilustrativo, o software do recebedor consulta pela API Pix se a devolução foi liquidada. Remover/alterar cobrança comum concluída é vedado; aceitar requisição ou ter recurso EM_PROCESSAMENTO não equivale a crédito efetivado. Manual de Iniciação 2.10.0, p. 45Manual de Iniciação 2.10.0, p. 62Manual de Iniciação 2.10.0, p. 63

O que esta leitura não diz. Não exige todos os produtos/endpoints para todo PSP; um QR lido ou cobrança agendada não comprova pagamento.

Identificadores, estados e confirmações para investigar cobrança, recorrência, devolução e falhas de processamento.

• Manual 2.10.0 integra o regulamento e detalha iniciação e API Pix; documentação OpenAPI correspondente é a tag do mesmo identificador, evitando misturar versões. BR Code trata QR apresentado pelo recebedor. Histórico e cronograma de junho de 2025 não criam novo prazo de implantação hoje. Manual de Iniciação 2.10.0, p. 1Manual de Iniciação 2.10.0, p. 6Manual de Iniciação 2.10.0, p. 41Manual de Iniciação 2.10.0, p. 118Manual de Iniciação 2.10.0, p. 119Manual de Iniciação 2.10.0, p. 123
• Estático contém chave DICT e opções limitadas; dinâmico usa location para obter cobrança; composto acrescenta location de recorrência e pode conter só recorrência. GUI é br.gov.bcb.pix. Chaves seguem DICT, incluindo CNPJ alfanumérico, celular internacional e aleatória com pontuação. Manual de Iniciação 2.10.0, p. 7Manual de Iniciação 2.10.0, p. 8Manual de Iniciação 2.10.0, p. 9
• Locations não incluem prefixo de protocolo, têm máximo de setenta e sete caracteres e distinguem cob, cobv e rec. Antes de acessar, validar caracteres, estrutura e domínio autorizado; acesso só HTTPS e campos JSON permanecem nulos até acesso e verificações positivas. Duas URLs do composto devem ter mesmo domínio completo e mesmas exigências de segurança. Manual de Iniciação 2.10.0, p. 10Manual de Iniciação 2.10.0, p. 30Manual de Iniciação 2.10.0, p. 37
• No estático, chave, infoAdicional e facilitador disputam espaço de noventa e nove caracteres do template. TxId em efeito é alfanumérico até vinte e cinco caracteres e retransmitido intacto; ausência usa marcador ***. Fss indica Saque; Troco exige dinâmico. Nome de apresentação vem do DICT, não do MerchantName do BR Code. Manual de Iniciação 2.10.0, p. 11Manual de Iniciação 2.10.0, p. 12Manual de Iniciação 2.10.0, p. 13
• Montagem de QR estático não é funcionalidade da API Pix, embora pagamentos com txid possam ser consultados. No dinâmico, valor e txid BR Code são ignorados em favor do payload da URL. QR dinâmico em integração automatizada usa API Pix, ressalvado app mobile próprio; API não retorna arquivo da imagem do QR. Manual de Iniciação 2.10.0, p. 14Manual de Iniciação 2.10.0, p. 15Manual de Iniciação 2.10.0, p. 28
• Txid de cobrança API tem vinte e seis a trinta e cinco caracteres alfanuméricos, único por CPF/CNPJ e PSP inclusive depois de cancelamento/baixa e entre cob/cobv. Recebedor normalmente o gera; delegação ao PSP só para imediata perde garantia de idempotência e exige explicação/análise. Estático tem outro modelo, com consistência de conciliação a cargo do recebedor no contexto da API. Manual de Iniciação 2.10.0, p. 21Manual de Iniciação 2.10.0, p. 43Manual de Iniciação 2.10.0, p. 48Manual de Iniciação 2.10.0, p. 52
• Cobrança com vencimento consulta DPP e município cadastral IBGE, ressalvada ausência municipal por regulação específica da conta. Sem município, recebedor assume ausência de feriados locais; sem DPP, assume vencimento se não vencida e consulta se vencida. Datas não úteis de vencimento e validade prorrogam ao útil seguinte; devedor é obrigatório nesse tipo. Manual de Iniciação 2.10.0, p. 22Manual de Iniciação 2.10.0, p. 23Manual de Iniciação 2.10.0, p. 24
• PSP recebedor calcula valor final: original menos abatimento e desconto mais juros e multa; o app do PSP pagador apresenta componentes não nulos individualmente. Parametrização distingue valor fixo/percentual, datas e dias úteis/corridos. Abatimento/desconto percentual usam bases distintas, e juros percentuais usam fator truncado em seis casas, resultado truncado em duas; multa calculada também truncada em duas. Antecipação por dias corridos usa vencimento original, mesmo não útil. Manual de Iniciação 2.10.0, p. 25Manual de Iniciação 2.10.0, p. 68Manual de Iniciação 2.10.0, p. 69Manual de Iniciação 2.10.0, p. 70Manual de Iniciação 2.10.0, p. 71Manual de Iniciação 2.10.0, p. 73Manual de Iniciação 2.10.0, p. 74Manual de Iniciação 2.10.0, p. 75Manual de Iniciação 2.10.0, p. 76Manual de Iniciação 2.10.0, p. 77Manual de Iniciação 2.10.0, p. 78Manual de Iniciação 2.10.0, p. 79Manual de Iniciação 2.10.0, p. 80Manual de Iniciação 2.10.0, p. 81
• Serviço de iniciação transmite campos mínimos segundo MANU, DICT, INIC, QRES, QRDN ou AUTO; EndToEndId é gerado pelo iniciador no recorte vigente, Description é enviada se preenchida e cobv considera município informado pelo iniciador. Dados da instrução AUTO vêm da API Open Finance; essa trilha não se confunde com API Pix recebedora. Manual de Iniciação 2.10.0, p. 38Manual de Iniciação 2.10.0, p. 106
• API Pix automatiza recebedor com PSP, cria/consulta/altera/remove cobrança e verifica pagamentos, devoluções e recorrências. Cobrança é entidade diferente de Pix recebido; CONCLUÍDA é estado final da cobrança que não admite novo pagamento, sem afirmar quitação de toda obrigação subjacente. Devolução em processamento difere de devolvida ou não realizada. Manual de Iniciação 2.10.0, p. 41Manual de Iniciação 2.10.0, p. 42Manual de Iniciação 2.10.0, p. 43Manual de Iniciação 2.10.0, p. 44Manual de Iniciação 2.10.0, p. 45Manual de Iniciação 2.10.0, p. 62Manual de Iniciação 2.10.0, p. 63
• Cardinalidades permitem vários pagamentos por cobrança e várias devoluções por Pix; locations têm uma cobrança/recorrência por vez e podem ser reutilizadas. Caso do QR dinâmico impresso confirma liquidação antes de liberar compra e desvincula cobrança para o próximo atendimento. Lote recebido com sucesso ainda está em processamento; consultar resultados individuais. Manual de Iniciação 2.10.0, p. 47Manual de Iniciação 2.10.0, p. 53Manual de Iniciação 2.10.0, p. 54
• Funcionalidades API são obrigatórias conforme produto/jornada da tabela, não todos os endpoints para todo participante. Webhook de Pix só informa recebimentos associados a txid e chave configurada; Rec e CobR notificam suas atualizações. Tratam integração do PSP com recebedor, sem constituir recurso próprio deste guia. Manual de Iniciação 2.10.0, p. 49Manual de Iniciação 2.10.0, p. 64Manual de Iniciação 2.10.0, p. 100
• Onboarding API ocorre logado, envia credenciais por canal seguro e garante rastreabilidade. API exige alta disponibilidade e confidencialidade/integridade em trânsito e repouso; logs de acesso são guardados pelo menos um ano. Webhooks usam mTLS; reutilizar certificado da API é recomendação, assim como MFA no onboarding, análise de vulnerabilidades e homologação de clientes. Manual de Iniciação 2.10.0, p. 65Manual de Iniciação 2.10.0, p. 66Manual de Iniciação 2.10.0, p. 67
• Automático distingue recorrência, permissão, autorização e cobrança; não gera QR para cada cobrança recorrente. Jornada 3 com erro em qualquer payload interrompe pagamento/autorização; jornada 4 com erro de cobrança interrompe, mas erro só da recorrência permite pagamento normal sem oferta final. Jornada 2 contém só recorrência. Manual de Iniciação 2.10.0, p. 39Manual de Iniciação 2.10.0, p. 40Manual de Iniciação 2.10.0, p. 55Manual de Iniciação 2.10.0, p. 56Manual de Iniciação 2.10.0, p. 57Manual de Iniciação 2.10.0, p. 58Manual de Iniciação 2.10.0, p. 99
• IdRec tem vinte e nove caracteres e distingue origem Pix/Open Finance e retentativas; API Pix só cria/consulta/gestiona identificadores R, não C. PSP preenche recebedor a partir de cadastro, preserva histórico de status e só usa códigos de encerramento que realmente indiquem rejeição/cancelamento. Ativação aceita jornada informada pelo PSP pagador, sem validar esse campo; inicial AGUARDANDO_DEFINICAO. Manual de Iniciação 2.10.0, p. 82Manual de Iniciação 2.10.0, p. 83Manual de Iniciação 2.10.0, p. 84
• SolicRec é exclusiva da jornada 1, com identificador SC gerado pelo PSP recebedor e dados bancários para endereçar, pois Automático não usa chaves. Guarda payload da recorrência pertinente ao pedido. Confirmação/cancelamento da recorrência cancela pedidos pendentes e comunica pagador para excluí-los; timeout de recebimento de um minuto exige cancelar e enviar pain.011. Manual de Iniciação 2.10.0, p. 46Manual de Iniciação 2.10.0, p. 84Manual de Iniciação 2.10.0, p. 85Manual de Iniciação 2.10.0, p. 89Manual de Iniciação 2.10.0, p. 96
• CobR exige autorização vigente e dados compatíveis. Conta recebedora informada em cada cobrança deve pertencer ao recebedor; PSP impede criação se não pertencer. CobR e tentativa têm status distintos, e código de rejeição pode afetar só tentativa. Histórico guarda política aplicada e tentativas originais, intradia e posteriores. Manual de Iniciação 2.10.0, p. 60Manual de Iniciação 2.10.0, p. 85Manual de Iniciação 2.10.0, p. 86Manual de Iniciação 2.10.0, p. 87Manual de Iniciação 2.10.0, p. 90Manual de Iniciação 2.10.0, p. 91Manual de Iniciação 2.10.0, p. 92Manual de Iniciação 2.10.0, p. 93Manual de Iniciação 2.10.0, p. 94
• AjusteDiaUtil é true por padrão e considera feriados do município pagador; recebedor pode optar false se tiver amparo legal para cobrar no dia não útil. Critério de vencimento em data inexistente deve constar do contrato, enquanto início de ciclo Pix usa data existente imediatamente anterior. Só uma cobrança por ciclo, salvo RIFL e NTAG. Manual de Iniciação 2.10.0, p. 87Manual de Iniciação 2.10.0, p. 97Manual de Iniciação 2.10.0, p. 98
• Após confirmação, recebedor só altera loc e nome do devedor da recorrência; data inicial e txid jornada 3 só antes. Outros parâmetros exigem cancelar e pedir nova autorização. Jornada 3 só confirma recorrência após pagamento imediato confirmado, iniciado como QRDN; pagamento feito com autorização falha exige outra jornada ou nova oferta no período seguinte. Manual de Iniciação 2.10.0, p. 96Manual de Iniciação 2.10.0, p. 97
• Política após vencimento admite até três novas tentativas em dias diferentes por até sete dias corridos desde data prevista original; usuário não recusa só essa condição, mas toda recorrência. PSP rejeita pedido fora da política; pagador recebe instrução até fim da véspera. Retentativa intradia por falta de saldo é controle exclusivo pagador; erro após envio gera RIFL com novo E2E quando recebedor recebe cancelamento por falha. Manual de Iniciação 2.10.0, p. 44Manual de Iniciação 2.10.0, p. 83Manual de Iniciação 2.10.0, p. 96Manual de Iniciação 2.10.0, p. 97Manual de Iniciação 2.10.0, p. 99
• Só alteração permitida de CobR pelo recebedor é cancelamento até véspera da primeira liquidação prevista, respeitando recebimento no PSP pagador até vinte e duas horas. Para corrigir, cancelar e criar nova com novo txid dentro da janela de agendamento. Pagador não cancela individualmente retentativa após vencimento. Cancelar recorrência comunica e cancela autorização vinculada. Manual de Iniciação 2.10.0, p. 61Manual de Iniciação 2.10.0, p. 62Manual de Iniciação 2.10.0, p. 94Manual de Iniciação 2.10.0, p. 95Manual de Iniciação 2.10.0, p. 98
• Mensagens distinguem pain.009 solicitação jornada 1, pain.012 resposta/confirmacão/sincronização, pain.011 cancelamento de recorrência/pedido, pain.013 instrução, pain.014 resultado agendamento e camt.055/029 cancelamento de agenda. Pain.012 não expõe conta/agência pagadora ao recebedor via API/arquivo. Aceitar agendamento não representa liquidação. Manual de Iniciação 2.10.0, p. 101Manual de Iniciação 2.10.0, p. 107Manual de Iniciação 2.10.0, p. 108Manual de Iniciação 2.10.0, p. 109Manual de Iniciação 2.10.0, p. 110Manual de Iniciação 2.10.0, p. 111Manual de Iniciação 2.10.0, p. 112Manual de Iniciação 2.10.0, p. 113Manual de Iniciação 2.10.0, p. 114
• Cancelamento solicitado pelo recebedor só é confirmado ao seu usuário após camt.029 do pagador. Arquivo padronizado é alternativa API para Automático, baseado em CNAB com setecentas e cinquenta posições fixas por linha; leiautes de remessa/retorno e orientações são documentos complementares. Manual de Iniciação 2.10.0, p. 115Manual de Iniciação 2.10.0, p. 116Manual de Iniciação 2.10.0, p. 117
• Devolução API aponta E2E original e identificador único por E2E, pode ter várias parcelas sem ultrapassar original; no caso de uso ilustrativo, o software do recebedor consulta pela API Pix se a devolução foi liquidada. Remover/alterar cobrança comum concluída é vedado; aceitar requisição ou ter recurso EM_PROCESSAMENTO não equivale a crédito efetivado. Manual de Iniciação 2.10.0, p. 45Manual de Iniciação 2.10.0, p. 62Manual de Iniciação 2.10.0, p. 63

O que esta leitura não diz. Não presume quitação comercial pela etiqueta CONCLUÍDA nem garante sucesso por resposta de agendamento.

Locations e JWS, txid/idRec, mapeamentos ISO, requisitos API e separação de cobrança, tentativa, autorização e liquidação.

• Manual 2.10.0 integra o regulamento e detalha iniciação e API Pix; documentação OpenAPI correspondente é a tag do mesmo identificador, evitando misturar versões. BR Code trata QR apresentado pelo recebedor. Histórico e cronograma de junho de 2025 não criam novo prazo de implantação hoje. Manual de Iniciação 2.10.0, p. 1Manual de Iniciação 2.10.0, p. 6Manual de Iniciação 2.10.0, p. 41Manual de Iniciação 2.10.0, p. 118Manual de Iniciação 2.10.0, p. 119Manual de Iniciação 2.10.0, p. 123
• Estático contém chave DICT e opções limitadas; dinâmico usa location para obter cobrança; composto acrescenta location de recorrência e pode conter só recorrência. GUI é br.gov.bcb.pix. Chaves seguem DICT, incluindo CNPJ alfanumérico, celular internacional e aleatória com pontuação. Manual de Iniciação 2.10.0, p. 7Manual de Iniciação 2.10.0, p. 8Manual de Iniciação 2.10.0, p. 9
• Locations não incluem prefixo de protocolo, têm máximo de setenta e sete caracteres e distinguem cob, cobv e rec. Antes de acessar, validar caracteres, estrutura e domínio autorizado; acesso só HTTPS e campos JSON permanecem nulos até acesso e verificações positivas. Duas URLs do composto devem ter mesmo domínio completo e mesmas exigências de segurança. Manual de Iniciação 2.10.0, p. 10Manual de Iniciação 2.10.0, p. 30Manual de Iniciação 2.10.0, p. 37
• No estático, chave, infoAdicional e facilitador disputam espaço de noventa e nove caracteres do template. TxId em efeito é alfanumérico até vinte e cinco caracteres e retransmitido intacto; ausência usa marcador ***. Fss indica Saque; Troco exige dinâmico. Nome de apresentação vem do DICT, não do MerchantName do BR Code. Manual de Iniciação 2.10.0, p. 11Manual de Iniciação 2.10.0, p. 12Manual de Iniciação 2.10.0, p. 13
• Montagem de QR estático não é funcionalidade da API Pix, embora pagamentos com txid possam ser consultados. No dinâmico, valor e txid BR Code são ignorados em favor do payload da URL. QR dinâmico em integração automatizada usa API Pix, ressalvado app mobile próprio; API não retorna arquivo da imagem do QR. Manual de Iniciação 2.10.0, p. 14Manual de Iniciação 2.10.0, p. 15Manual de Iniciação 2.10.0, p. 28
• Cobrança imediata tem revisão iniciada em zero, incrementada só em alterações PUT/PATCH; recomenda-se guardar payload assinado. Timestamps são UTC e expiração ausente assume vinte e quatro horas desde criação. Devedor não é necessariamente pagador; nome é exigido quando CPF/CNPJ preenchido. Manual de Iniciação 2.10.0, p. 16Manual de Iniciação 2.10.0, p. 17Manual de Iniciação 2.10.0, p. 18
• Modalidade de alteração ausente impede editar valor. Compra, Saque e Troco têm campos e regras diferentes: Saque original zero, Troco compra positiva, retirada não se combina entre saque/troco; total não pode ser zero. Valor monetário usa duas casas decimais. Modalidade/ISPB do facilitador e domínio do agente seguem regras próprias. Manual de Iniciação 2.10.0, p. 18Manual de Iniciação 2.10.0, p. 19Manual de Iniciação 2.10.0, p. 20Manual de Iniciação 2.10.0, p. 105
• Txid de cobrança API tem vinte e seis a trinta e cinco caracteres alfanuméricos, único por CPF/CNPJ e PSP inclusive depois de cancelamento/baixa e entre cob/cobv. Recebedor normalmente o gera; delegação ao PSP só para imediata perde garantia de idempotência e exige explicação/análise. Estático tem outro modelo, com consistência de conciliação a cargo do recebedor no contexto da API. Manual de Iniciação 2.10.0, p. 21Manual de Iniciação 2.10.0, p. 43Manual de Iniciação 2.10.0, p. 48Manual de Iniciação 2.10.0, p. 52
• SolicitacaoPagador pede entrada livre: quem segue para RmtInf é a resposta do usuário, não o enunciado, até cento e quarenta caracteres. Adicionais presentes mostram pares nome/valor; payload JSON é assinado e só se procede ao parsing se assinatura JWS válida. Cobrança concluída/expirada/removida pode retornar HTTP de semântica adequada, a critério do PSP. Manual de Iniciação 2.10.0, p. 21Manual de Iniciação 2.10.0, p. 22Manual de Iniciação 2.10.0, p. 27Manual de Iniciação 2.10.0, p. 28Manual de Iniciação 2.10.0, p. 72
• Cobrança com vencimento consulta DPP e município cadastral IBGE, ressalvada ausência municipal por regulação específica da conta. Sem município, recebedor assume ausência de feriados locais; sem DPP, assume vencimento se não vencida e consulta se vencida. Datas não úteis de vencimento e validade prorrogam ao útil seguinte; devedor é obrigatório nesse tipo. Manual de Iniciação 2.10.0, p. 22Manual de Iniciação 2.10.0, p. 23Manual de Iniciação 2.10.0, p. 24
• PSP recebedor calcula valor final: original menos abatimento e desconto mais juros e multa; o app do PSP pagador apresenta componentes não nulos individualmente. Parametrização distingue valor fixo/percentual, datas e dias úteis/corridos. Abatimento/desconto percentual usam bases distintas, e juros percentuais usam fator truncado em seis casas, resultado truncado em duas; multa calculada também truncada em duas. Antecipação por dias corridos usa vencimento original, mesmo não útil. Manual de Iniciação 2.10.0, p. 25Manual de Iniciação 2.10.0, p. 68Manual de Iniciação 2.10.0, p. 69Manual de Iniciação 2.10.0, p. 70Manual de Iniciação 2.10.0, p. 71Manual de Iniciação 2.10.0, p. 73Manual de Iniciação 2.10.0, p. 74Manual de Iniciação 2.10.0, p. 75Manual de Iniciação 2.10.0, p. 76Manual de Iniciação 2.10.0, p. 77Manual de Iniciação 2.10.0, p. 78Manual de Iniciação 2.10.0, p. 79Manual de Iniciação 2.10.0, p. 80Manual de Iniciação 2.10.0, p. 81
• Composto tem recorrência apenas, estático+recorrência ou dinâmico+recorrência. Dados dos payloads prevalecem sobre EMV; pagamentos compostos não permitem Saque/Troco. Copia e Cola copia integralmente a mesma sequência do QR, valendo também para composto. Manual de Iniciação 2.10.0, p. 29Manual de Iniciação 2.10.0, p. 30Manual de Iniciação 2.10.0, p. 31Manual de Iniciação 2.10.0, p. 38
• Serviço de iniciação transmite campos mínimos segundo MANU, DICT, INIC, QRES, QRDN ou AUTO; EndToEndId é gerado pelo iniciador no recorte vigente, Description é enviada se preenchida e cobv considera município informado pelo iniciador. Dados da instrução AUTO vêm da API Open Finance; essa trilha não se confunde com API Pix recebedora. Manual de Iniciação 2.10.0, p. 38Manual de Iniciação 2.10.0, p. 106
• NFC exige aparelhos com tecnologia, próximos e conectados; transporta Copia e Cola em URI e mantém confirmação e checagens do QR. Estático não resolve payload JSON. Especificação Android complementar é obrigatória no recorte, sem substituir este manual. Manual de Iniciação 2.10.0, p. 40
• API Pix automatiza recebedor com PSP, cria/consulta/altera/remove cobrança e verifica pagamentos, devoluções e recorrências. Cobrança é entidade diferente de Pix recebido; CONCLUÍDA é estado final da cobrança que não admite novo pagamento, sem afirmar quitação de toda obrigação subjacente. Devolução em processamento difere de devolvida ou não realizada. Manual de Iniciação 2.10.0, p. 41Manual de Iniciação 2.10.0, p. 42Manual de Iniciação 2.10.0, p. 43Manual de Iniciação 2.10.0, p. 44Manual de Iniciação 2.10.0, p. 45Manual de Iniciação 2.10.0, p. 62Manual de Iniciação 2.10.0, p. 63
• Cardinalidades permitem vários pagamentos por cobrança e várias devoluções por Pix; locations têm uma cobrança/recorrência por vez e podem ser reutilizadas. Caso do QR dinâmico impresso confirma liquidação antes de liberar compra e desvincula cobrança para o próximo atendimento. Lote recebido com sucesso ainda está em processamento; consultar resultados individuais. Manual de Iniciação 2.10.0, p. 47Manual de Iniciação 2.10.0, p. 53Manual de Iniciação 2.10.0, p. 54
• Funcionalidades API são obrigatórias conforme produto/jornada da tabela, não todos os endpoints para todo participante. Webhook de Pix só informa recebimentos associados a txid e chave configurada; Rec e CobR notificam suas atualizações. Tratam integração do PSP com recebedor, sem constituir recurso próprio deste guia. Manual de Iniciação 2.10.0, p. 49Manual de Iniciação 2.10.0, p. 64Manual de Iniciação 2.10.0, p. 100
• Segurança API exige TLS pelo menos 1.2 com forward secrecy, OAuth Client Credentials e mTLS no servidor de autorização e recursos. Certificado autoassinado pelo cliente não é aceito; tokens são vinculados ao certificado e resource server verifica thumbprint. Escopos segregam permissões; client_ID vinculado a CPF/CNPJ só acessa contas daquele titular. Manual de Iniciação 2.10.0, p. 65Manual de Iniciação 2.10.0, p. 66
• Onboarding API ocorre logado, envia credenciais por canal seguro e garante rastreabilidade. API exige alta disponibilidade e confidencialidade/integridade em trânsito e repouso; logs de acesso são guardados pelo menos um ano. Webhooks usam mTLS; reutilizar certificado da API é recomendação, assim como MFA no onboarding, análise de vulnerabilidades e homologação de clientes. Manual de Iniciação 2.10.0, p. 65Manual de Iniciação 2.10.0, p. 66Manual de Iniciação 2.10.0, p. 67
• Automático distingue recorrência, permissão, autorização e cobrança; não gera QR para cada cobrança recorrente. Jornada 3 com erro em qualquer payload interrompe pagamento/autorização; jornada 4 com erro de cobrança interrompe, mas erro só da recorrência permite pagamento normal sem oferta final. Jornada 2 contém só recorrência. Manual de Iniciação 2.10.0, p. 39Manual de Iniciação 2.10.0, p. 40Manual de Iniciação 2.10.0, p. 55Manual de Iniciação 2.10.0, p. 56Manual de Iniciação 2.10.0, p. 57Manual de Iniciação 2.10.0, p. 58Manual de Iniciação 2.10.0, p. 99
• IdRec tem vinte e nove caracteres e distingue origem Pix/Open Finance e retentativas; API Pix só cria/consulta/gestiona identificadores R, não C. PSP preenche recebedor a partir de cadastro, preserva histórico de status e só usa códigos de encerramento que realmente indiquem rejeição/cancelamento. Ativação aceita jornada informada pelo PSP pagador, sem validar esse campo; inicial AGUARDANDO_DEFINICAO. Manual de Iniciação 2.10.0, p. 82Manual de Iniciação 2.10.0, p. 83Manual de Iniciação 2.10.0, p. 84
• SolicRec é exclusiva da jornada 1, com identificador SC gerado pelo PSP recebedor e dados bancários para endereçar, pois Automático não usa chaves. Guarda payload da recorrência pertinente ao pedido. Confirmação/cancelamento da recorrência cancela pedidos pendentes e comunica pagador para excluí-los; timeout de recebimento de um minuto exige cancelar e enviar pain.011. Manual de Iniciação 2.10.0, p. 46Manual de Iniciação 2.10.0, p. 84Manual de Iniciação 2.10.0, p. 85Manual de Iniciação 2.10.0, p. 89Manual de Iniciação 2.10.0, p. 96
• CobR exige autorização vigente e dados compatíveis. Conta recebedora informada em cada cobrança deve pertencer ao recebedor; PSP impede criação se não pertencer. CobR e tentativa têm status distintos, e código de rejeição pode afetar só tentativa. Histórico guarda política aplicada e tentativas originais, intradia e posteriores. Manual de Iniciação 2.10.0, p. 60Manual de Iniciação 2.10.0, p. 85Manual de Iniciação 2.10.0, p. 86Manual de Iniciação 2.10.0, p. 87Manual de Iniciação 2.10.0, p. 90Manual de Iniciação 2.10.0, p. 91Manual de Iniciação 2.10.0, p. 92Manual de Iniciação 2.10.0, p. 93Manual de Iniciação 2.10.0, p. 94
• AjusteDiaUtil é true por padrão e considera feriados do município pagador; recebedor pode optar false se tiver amparo legal para cobrar no dia não útil. Critério de vencimento em data inexistente deve constar do contrato, enquanto início de ciclo Pix usa data existente imediatamente anterior. Só uma cobrança por ciclo, salvo RIFL e NTAG. Manual de Iniciação 2.10.0, p. 87Manual de Iniciação 2.10.0, p. 97Manual de Iniciação 2.10.0, p. 98
• Após confirmação, recebedor só altera loc e nome do devedor da recorrência; data inicial e txid jornada 3 só antes. Outros parâmetros exigem cancelar e pedir nova autorização. Jornada 3 só confirma recorrência após pagamento imediato confirmado, iniciado como QRDN; pagamento feito com autorização falha exige outra jornada ou nova oferta no período seguinte. Manual de Iniciação 2.10.0, p. 96Manual de Iniciação 2.10.0, p. 97
• Política após vencimento admite até três novas tentativas em dias diferentes por até sete dias corridos desde data prevista original; usuário não recusa só essa condição, mas toda recorrência. PSP rejeita pedido fora da política; pagador recebe instrução até fim da véspera. Retentativa intradia por falta de saldo é controle exclusivo pagador; erro após envio gera RIFL com novo E2E quando recebedor recebe cancelamento por falha. Manual de Iniciação 2.10.0, p. 44Manual de Iniciação 2.10.0, p. 83Manual de Iniciação 2.10.0, p. 96Manual de Iniciação 2.10.0, p. 97Manual de Iniciação 2.10.0, p. 99
• Só alteração permitida de CobR pelo recebedor é cancelamento até véspera da primeira liquidação prevista, respeitando recebimento no PSP pagador até vinte e duas horas. Para corrigir, cancelar e criar nova com novo txid dentro da janela de agendamento. Pagador não cancela individualmente retentativa após vencimento. Cancelar recorrência comunica e cancela autorização vinculada. Manual de Iniciação 2.10.0, p. 61Manual de Iniciação 2.10.0, p. 62Manual de Iniciação 2.10.0, p. 94Manual de Iniciação 2.10.0, p. 95Manual de Iniciação 2.10.0, p. 98
• Mensagens distinguem pain.009 solicitação jornada 1, pain.012 resposta/confirmacão/sincronização, pain.011 cancelamento de recorrência/pedido, pain.013 instrução, pain.014 resultado agendamento e camt.055/029 cancelamento de agenda. Pain.012 não expõe conta/agência pagadora ao recebedor via API/arquivo. Aceitar agendamento não representa liquidação. Manual de Iniciação 2.10.0, p. 101Manual de Iniciação 2.10.0, p. 107Manual de Iniciação 2.10.0, p. 108Manual de Iniciação 2.10.0, p. 109Manual de Iniciação 2.10.0, p. 110Manual de Iniciação 2.10.0, p. 111Manual de Iniciação 2.10.0, p. 112Manual de Iniciação 2.10.0, p. 113Manual de Iniciação 2.10.0, p. 114
• Cancelamento solicitado pelo recebedor só é confirmado ao seu usuário após camt.029 do pagador. Arquivo padronizado é alternativa API para Automático, baseado em CNAB com setecentas e cinquenta posições fixas por linha; leiautes de remessa/retorno e orientações são documentos complementares. Manual de Iniciação 2.10.0, p. 115Manual de Iniciação 2.10.0, p. 116Manual de Iniciação 2.10.0, p. 117
• Devolução API aponta E2E original e identificador único por E2E, pode ter várias parcelas sem ultrapassar original; no caso de uso ilustrativo, o software do recebedor consulta pela API Pix se a devolução foi liquidada. Remover/alterar cobrança comum concluída é vedado; aceitar requisição ou ter recurso EM_PROCESSAMENTO não equivale a crédito efetivado. Manual de Iniciação 2.10.0, p. 45Manual de Iniciação 2.10.0, p. 62Manual de Iniciação 2.10.0, p. 63

O que esta leitura não diz. Não substitui OpenAPI e catálogo correspondentes nem detalha leiautes externos que só referencia.

Regras dos mecanismos de iniciação e integração recebedora, com obrigações condicionadas ao produto, titularidade, prazos e uso correto dos estados.

• Manual 2.10.0 integra o regulamento e detalha iniciação e API Pix; documentação OpenAPI correspondente é a tag do mesmo identificador, evitando misturar versões. BR Code trata QR apresentado pelo recebedor. Histórico e cronograma de junho de 2025 não criam novo prazo de implantação hoje. Manual de Iniciação 2.10.0, p. 1Manual de Iniciação 2.10.0, p. 6Manual de Iniciação 2.10.0, p. 41Manual de Iniciação 2.10.0, p. 118Manual de Iniciação 2.10.0, p. 119Manual de Iniciação 2.10.0, p. 123
• Estático contém chave DICT e opções limitadas; dinâmico usa location para obter cobrança; composto acrescenta location de recorrência e pode conter só recorrência. GUI é br.gov.bcb.pix. Chaves seguem DICT, incluindo CNPJ alfanumérico, celular internacional e aleatória com pontuação. Manual de Iniciação 2.10.0, p. 7Manual de Iniciação 2.10.0, p. 8Manual de Iniciação 2.10.0, p. 9
• Locations não incluem prefixo de protocolo, têm máximo de setenta e sete caracteres e distinguem cob, cobv e rec. Antes de acessar, validar caracteres, estrutura e domínio autorizado; acesso só HTTPS e campos JSON permanecem nulos até acesso e verificações positivas. Duas URLs do composto devem ter mesmo domínio completo e mesmas exigências de segurança. Manual de Iniciação 2.10.0, p. 10Manual de Iniciação 2.10.0, p. 30Manual de Iniciação 2.10.0, p. 37
• No estático, chave, infoAdicional e facilitador disputam espaço de noventa e nove caracteres do template. TxId em efeito é alfanumérico até vinte e cinco caracteres e retransmitido intacto; ausência usa marcador ***. Fss indica Saque; Troco exige dinâmico. Nome de apresentação vem do DICT, não do MerchantName do BR Code. Manual de Iniciação 2.10.0, p. 11Manual de Iniciação 2.10.0, p. 12Manual de Iniciação 2.10.0, p. 13
• Montagem de QR estático não é funcionalidade da API Pix, embora pagamentos com txid possam ser consultados. No dinâmico, valor e txid BR Code são ignorados em favor do payload da URL. QR dinâmico em integração automatizada usa API Pix, ressalvado app mobile próprio; API não retorna arquivo da imagem do QR. Manual de Iniciação 2.10.0, p. 14Manual de Iniciação 2.10.0, p. 15Manual de Iniciação 2.10.0, p. 28
• Txid de cobrança API tem vinte e seis a trinta e cinco caracteres alfanuméricos, único por CPF/CNPJ e PSP inclusive depois de cancelamento/baixa e entre cob/cobv. Recebedor normalmente o gera; delegação ao PSP só para imediata perde garantia de idempotência e exige explicação/análise. Estático tem outro modelo, com consistência de conciliação a cargo do recebedor no contexto da API. Manual de Iniciação 2.10.0, p. 21Manual de Iniciação 2.10.0, p. 43Manual de Iniciação 2.10.0, p. 48Manual de Iniciação 2.10.0, p. 52
• Cobrança com vencimento consulta DPP e município cadastral IBGE, ressalvada ausência municipal por regulação específica da conta. Sem município, recebedor assume ausência de feriados locais; sem DPP, assume vencimento se não vencida e consulta se vencida. Datas não úteis de vencimento e validade prorrogam ao útil seguinte; devedor é obrigatório nesse tipo. Manual de Iniciação 2.10.0, p. 22Manual de Iniciação 2.10.0, p. 23Manual de Iniciação 2.10.0, p. 24
• PSP recebedor calcula valor final: original menos abatimento e desconto mais juros e multa; o app do PSP pagador apresenta componentes não nulos individualmente. Parametrização distingue valor fixo/percentual, datas e dias úteis/corridos. Abatimento/desconto percentual usam bases distintas, e juros percentuais usam fator truncado em seis casas, resultado truncado em duas; multa calculada também truncada em duas. Antecipação por dias corridos usa vencimento original, mesmo não útil. Manual de Iniciação 2.10.0, p. 25Manual de Iniciação 2.10.0, p. 68Manual de Iniciação 2.10.0, p. 69Manual de Iniciação 2.10.0, p. 70Manual de Iniciação 2.10.0, p. 71Manual de Iniciação 2.10.0, p. 73Manual de Iniciação 2.10.0, p. 74Manual de Iniciação 2.10.0, p. 75Manual de Iniciação 2.10.0, p. 76Manual de Iniciação 2.10.0, p. 77Manual de Iniciação 2.10.0, p. 78Manual de Iniciação 2.10.0, p. 79Manual de Iniciação 2.10.0, p. 80Manual de Iniciação 2.10.0, p. 81
• Composto tem recorrência apenas, estático+recorrência ou dinâmico+recorrência. Dados dos payloads prevalecem sobre EMV; pagamentos compostos não permitem Saque/Troco. Copia e Cola copia integralmente a mesma sequência do QR, valendo também para composto. Manual de Iniciação 2.10.0, p. 29Manual de Iniciação 2.10.0, p. 30Manual de Iniciação 2.10.0, p. 31Manual de Iniciação 2.10.0, p. 38
• Serviço de iniciação transmite campos mínimos segundo MANU, DICT, INIC, QRES, QRDN ou AUTO; EndToEndId é gerado pelo iniciador no recorte vigente, Description é enviada se preenchida e cobv considera município informado pelo iniciador. Dados da instrução AUTO vêm da API Open Finance; essa trilha não se confunde com API Pix recebedora. Manual de Iniciação 2.10.0, p. 38Manual de Iniciação 2.10.0, p. 106
• API Pix automatiza recebedor com PSP, cria/consulta/altera/remove cobrança e verifica pagamentos, devoluções e recorrências. Cobrança é entidade diferente de Pix recebido; CONCLUÍDA é estado final da cobrança que não admite novo pagamento, sem afirmar quitação de toda obrigação subjacente. Devolução em processamento difere de devolvida ou não realizada. Manual de Iniciação 2.10.0, p. 41Manual de Iniciação 2.10.0, p. 42Manual de Iniciação 2.10.0, p. 43Manual de Iniciação 2.10.0, p. 44Manual de Iniciação 2.10.0, p. 45Manual de Iniciação 2.10.0, p. 62Manual de Iniciação 2.10.0, p. 63
• Funcionalidades API são obrigatórias conforme produto/jornada da tabela, não todos os endpoints para todo participante. Webhook de Pix só informa recebimentos associados a txid e chave configurada; Rec e CobR notificam suas atualizações. Tratam integração do PSP com recebedor, sem constituir recurso próprio deste guia. Manual de Iniciação 2.10.0, p. 49Manual de Iniciação 2.10.0, p. 64Manual de Iniciação 2.10.0, p. 100
• Segurança API exige TLS pelo menos 1.2 com forward secrecy, OAuth Client Credentials e mTLS no servidor de autorização e recursos. Certificado autoassinado pelo cliente não é aceito; tokens são vinculados ao certificado e resource server verifica thumbprint. Escopos segregam permissões; client_ID vinculado a CPF/CNPJ só acessa contas daquele titular. Manual de Iniciação 2.10.0, p. 65Manual de Iniciação 2.10.0, p. 66
• Onboarding API ocorre logado, envia credenciais por canal seguro e garante rastreabilidade. API exige alta disponibilidade e confidencialidade/integridade em trânsito e repouso; logs de acesso são guardados pelo menos um ano. Webhooks usam mTLS; reutilizar certificado da API é recomendação, assim como MFA no onboarding, análise de vulnerabilidades e homologação de clientes. Manual de Iniciação 2.10.0, p. 65Manual de Iniciação 2.10.0, p. 66Manual de Iniciação 2.10.0, p. 67
• Automático distingue recorrência, permissão, autorização e cobrança; não gera QR para cada cobrança recorrente. Jornada 3 com erro em qualquer payload interrompe pagamento/autorização; jornada 4 com erro de cobrança interrompe, mas erro só da recorrência permite pagamento normal sem oferta final. Jornada 2 contém só recorrência. Manual de Iniciação 2.10.0, p. 39Manual de Iniciação 2.10.0, p. 40Manual de Iniciação 2.10.0, p. 55Manual de Iniciação 2.10.0, p. 56Manual de Iniciação 2.10.0, p. 57Manual de Iniciação 2.10.0, p. 58Manual de Iniciação 2.10.0, p. 99
• IdRec tem vinte e nove caracteres e distingue origem Pix/Open Finance e retentativas; API Pix só cria/consulta/gestiona identificadores R, não C. PSP preenche recebedor a partir de cadastro, preserva histórico de status e só usa códigos de encerramento que realmente indiquem rejeição/cancelamento. Ativação aceita jornada informada pelo PSP pagador, sem validar esse campo; inicial AGUARDANDO_DEFINICAO. Manual de Iniciação 2.10.0, p. 82Manual de Iniciação 2.10.0, p. 83Manual de Iniciação 2.10.0, p. 84
• SolicRec é exclusiva da jornada 1, com identificador SC gerado pelo PSP recebedor e dados bancários para endereçar, pois Automático não usa chaves. Guarda payload da recorrência pertinente ao pedido. Confirmação/cancelamento da recorrência cancela pedidos pendentes e comunica pagador para excluí-los; timeout de recebimento de um minuto exige cancelar e enviar pain.011. Manual de Iniciação 2.10.0, p. 46Manual de Iniciação 2.10.0, p. 84Manual de Iniciação 2.10.0, p. 85Manual de Iniciação 2.10.0, p. 89Manual de Iniciação 2.10.0, p. 96
• CobR exige autorização vigente e dados compatíveis. Conta recebedora informada em cada cobrança deve pertencer ao recebedor; PSP impede criação se não pertencer. CobR e tentativa têm status distintos, e código de rejeição pode afetar só tentativa. Histórico guarda política aplicada e tentativas originais, intradia e posteriores. Manual de Iniciação 2.10.0, p. 60Manual de Iniciação 2.10.0, p. 85Manual de Iniciação 2.10.0, p. 86Manual de Iniciação 2.10.0, p. 87Manual de Iniciação 2.10.0, p. 90Manual de Iniciação 2.10.0, p. 91Manual de Iniciação 2.10.0, p. 92Manual de Iniciação 2.10.0, p. 93Manual de Iniciação 2.10.0, p. 94
• AjusteDiaUtil é true por padrão e considera feriados do município pagador; recebedor pode optar false se tiver amparo legal para cobrar no dia não útil. Critério de vencimento em data inexistente deve constar do contrato, enquanto início de ciclo Pix usa data existente imediatamente anterior. Só uma cobrança por ciclo, salvo RIFL e NTAG. Manual de Iniciação 2.10.0, p. 87Manual de Iniciação 2.10.0, p. 97Manual de Iniciação 2.10.0, p. 98
• Após confirmação, recebedor só altera loc e nome do devedor da recorrência; data inicial e txid jornada 3 só antes. Outros parâmetros exigem cancelar e pedir nova autorização. Jornada 3 só confirma recorrência após pagamento imediato confirmado, iniciado como QRDN; pagamento feito com autorização falha exige outra jornada ou nova oferta no período seguinte. Manual de Iniciação 2.10.0, p. 96Manual de Iniciação 2.10.0, p. 97
• Política após vencimento admite até três novas tentativas em dias diferentes por até sete dias corridos desde data prevista original; usuário não recusa só essa condição, mas toda recorrência. PSP rejeita pedido fora da política; pagador recebe instrução até fim da véspera. Retentativa intradia por falta de saldo é controle exclusivo pagador; erro após envio gera RIFL com novo E2E quando recebedor recebe cancelamento por falha. Manual de Iniciação 2.10.0, p. 44Manual de Iniciação 2.10.0, p. 83Manual de Iniciação 2.10.0, p. 96Manual de Iniciação 2.10.0, p. 97Manual de Iniciação 2.10.0, p. 99
• Só alteração permitida de CobR pelo recebedor é cancelamento até véspera da primeira liquidação prevista, respeitando recebimento no PSP pagador até vinte e duas horas. Para corrigir, cancelar e criar nova com novo txid dentro da janela de agendamento. Pagador não cancela individualmente retentativa após vencimento. Cancelar recorrência comunica e cancela autorização vinculada. Manual de Iniciação 2.10.0, p. 61Manual de Iniciação 2.10.0, p. 62Manual de Iniciação 2.10.0, p. 94Manual de Iniciação 2.10.0, p. 95Manual de Iniciação 2.10.0, p. 98
• Mensagens distinguem pain.009 solicitação jornada 1, pain.012 resposta/confirmacão/sincronização, pain.011 cancelamento de recorrência/pedido, pain.013 instrução, pain.014 resultado agendamento e camt.055/029 cancelamento de agenda. Pain.012 não expõe conta/agência pagadora ao recebedor via API/arquivo. Aceitar agendamento não representa liquidação. Manual de Iniciação 2.10.0, p. 101Manual de Iniciação 2.10.0, p. 107Manual de Iniciação 2.10.0, p. 108Manual de Iniciação 2.10.0, p. 109Manual de Iniciação 2.10.0, p. 110Manual de Iniciação 2.10.0, p. 111Manual de Iniciação 2.10.0, p. 112Manual de Iniciação 2.10.0, p. 113Manual de Iniciação 2.10.0, p. 114
• Cancelamento solicitado pelo recebedor só é confirmado ao seu usuário após camt.029 do pagador. Arquivo padronizado é alternativa API para Automático, baseado em CNAB com setecentas e cinquenta posições fixas por linha; leiautes de remessa/retorno e orientações são documentos complementares. Manual de Iniciação 2.10.0, p. 115Manual de Iniciação 2.10.0, p. 116Manual de Iniciação 2.10.0, p. 117
• Devolução API aponta E2E original e identificador único por E2E, pode ter várias parcelas sem ultrapassar original; no caso de uso ilustrativo, o software do recebedor consulta pela API Pix se a devolução foi liquidada. Remover/alterar cobrança comum concluída é vedado; aceitar requisição ou ter recurso EM_PROCESSAMENTO não equivale a crédito efetivado. Manual de Iniciação 2.10.0, p. 45Manual de Iniciação 2.10.0, p. 62Manual de Iniciação 2.10.0, p. 63

O que esta leitura não diz. Não cria API pública do guia nem torna recomendações em obrigações; não assegura liquidação por mera criação da cobrança.

Atendimento separa falta de saldo, limite e erro após envio. Cancelar autorização e cancelar ordem têm recortes temporais próprios; devolução com recursos próprios tem hipótese remetida.

• A IN detalha Automático, Agendado e Cobrança. Recorrência Automático pode ser semanal, mensal, trimestral, semestral ou anual. Solicitação de autorização na jornada indicada fica aberta até resposta, cancelamento pelo PSP recebedor ou trinta dias do envio; recebedor pode encurtar. Excedido prazo/cancelada, PSP pagador exclui solicitação. IN BCB 513/2024, art. 1ºIN BCB 513/2024, art. 2ºIN BCB 513/2024, art. 3º
• Na jornada por QR indicada, PSP pagador oferece proposta Automático inclusive quando cobrança do QR já foi agendada. Isso não transforma automaticamente agendamento em autorização. IN BCB 513/2024, art. 4º
• PSP recebedor provedor envia instrução normalmente entre dois e dez dias corridos antes da liquidação. Exceção de geração mantém antecedência mínima de dois dias entre agendamento/liquidação, dentro do ciclo/recorrência e sem encargos de atraso causado pelo próprio recebedor. Liquidação é vencimento, podendo passar ao útil seguinte por critério do recebedor se não útil. IN BCB 513/2024, art. 5º
• Instrução deve respeitar permissão confirmada e não ser enviada se recebedor estiver na situação remetida do art. 89, § 2º. Identificação usa CNPJ da Receita. Informações da instrução dependem de Catálogo SFN ou arcabouço Open Finance conforme PSP seja provedor ou iniciador. IN BCB 513/2024, art. 5º
• PSP pagador agenda em até duas horas do recebimento. Rejeita valores incompatíveis, data/periodicidade, recebedor, regras de envio, ausência de autorização vigente ou divergência impeditiva. Nova instrução nos casos rejeitados pode ser enviada por comando do recebedor até dois dias antes da liquidação. IN BCB 513/2024, art. 6º
• Automático envia ordem no dia previsto entre zero e oito horas se houver recursos e limite. Ausência de recursos/limite ou falha operacional exige aviso e ao menos nova tentativa entre dezoito e vinte e uma horas. Tentativas adicionais facultativas respeitam mínimas e última até vinte e uma horas; sem liquidação após última, novo aviso. IN BCB 513/2024, art. 7º
• Tentativas Automático em outros dias dependem de critério recebedor e previsão na autorização: até sete dias corridos da data original, no máximo três datas distintas e antes do próximo ciclo/fim da recorrência. Valor fica igual; nova instrução chega até vinte e três horas e cinquenta e nove minutos da véspera. Não é permissão de cobrar indefinidamente. IN BCB 513/2024, art. 7º
• Erro após envio da ordem exige informar PSP recebedor imediatamente; este reenvia instrução para tentativa no mesmo dia, salvo se ele próprio rejeitou a ordem, quando reenvio é facultativo. Pagador aceita só até vinte e uma horas; valor é original e validações do recorte continuam. Reenvio no mesmo dia não é regra geral para toda falta de saldo. IN BCB 513/2024, art. 5ºIN BCB 513/2024, art. 7º
• pacs.008 do Automático tem formaDeIniciacao AUTO inclusive com iniciador. Na consolidação capturada, idConciliacaoRecebedor não é preenchido quando instrução é gerada por iniciador; não se deve resgatar redação histórica com outro conteúdo. IN BCB 513/2024, art. 7º, § 17 em diante
• Cancelamento de ordem Automático deve ocorrer se cliente pede até vinte e três horas e cinquenta e nove minutos da véspera ou PSP recebedor solicita até vinte e duas horas da véspera. Cancelar autorização cancela agendamentos posteriores ao dia do cancelamento/recebimento do aviso; aviso do recebedor entre vinte e duas horas e fim do dia desloca recorte para posteriores ao dia seguinte. IN BCB 513/2024, art. 8ºIN BCB 513/2024, art. 9º
• Pagador tem gestão de autorizações e agendamentos Automático e Agendado; PSP recebedor detentor da conta oferece gestão de permissões e instruções. Detalhes estão nos manuais UX e Padrões, não reproduzidos integralmente nesta IN. IN BCB 513/2024, art. 10IN BCB 513/2024, art. 11
• Agendado e Cobrança com vencimento agendada enviam ordem entre zero e oito horas se saldo/limite. Falta de saldo ou falha exige aviso e nova tentativa entre dezoito e vinte e uma horas, última até vinte e uma horas; falta de limite no horário inicial tem aviso específico. Texto não estende automaticamente a esta hipótese todo regime de retentativas Automático. IN BCB 513/2024, art. 12
• Para Agendado recorrente mensal nos dias vinte e nove, trinta ou trinta e um inexistentes no mês, PSP envia ordem para liquidação no primeiro dia do mês seguinte; antecipação pelo usuário depende de oferta PSP. Cancelamento Agendado/Cobrança agendada aceita pedido até vinte e três horas e cinquenta e nove minutos da véspera. IN BCB 513/2024, art. 13IN BCB 513/2024, art. 14
• No caso remetido ao art. 41-B, inciso III, PSP pagador devolve total com recursos próprios em até vinte e quatro horas após pedido do pagador. A hipótese não é reproduzida aqui, sem universalizar restituição a todo pedido. IN BCB 513/2024, art. 15
• PSP recebedor verifica idoneidade antes de contratar Automático e durante contrato: dados CNPJ/sócios/administração, atividade/capital/faturamento/funcionários, compatibilidade do serviço, habitualidade e informações DICT se tem acesso; relacionamento/uso de cobrança quando provedor. Não é prova automática de idoneidade apenas por CNPJ ativo. IN BCB 513/2024, art. 15-A
• Marcos de implantação de Agendado e Automático são os de 2024/2025 no art. 17; texto consolidado também inclui alterações de junho de 2026. IN 436 foi revogada. Datas históricas não são novos prazos móveis de implantação. IN BCB 513/2024, art. 16IN BCB 513/2024, art. 17IN BCB 513/2024, art. 6ºIN BCB 513/2024, art. 7º, § 17 em diante

O que esta leitura não diz. Não há SLA interno, tentativa indefinida ou regra de devolver com recursos próprios todo Pix contestado.

Cliente gerencia autorizações/agendamentos, com cancelamento e avisos condicionados a eventos. Pedido de autorização em aberto tem expiração; falha após última tentativa exige comunicação.

• A IN detalha Automático, Agendado e Cobrança. Recorrência Automático pode ser semanal, mensal, trimestral, semestral ou anual. Solicitação de autorização na jornada indicada fica aberta até resposta, cancelamento pelo PSP recebedor ou trinta dias do envio; recebedor pode encurtar. Excedido prazo/cancelada, PSP pagador exclui solicitação. IN BCB 513/2024, art. 1ºIN BCB 513/2024, art. 2ºIN BCB 513/2024, art. 3º
• Na jornada por QR indicada, PSP pagador oferece proposta Automático inclusive quando cobrança do QR já foi agendada. Isso não transforma automaticamente agendamento em autorização. IN BCB 513/2024, art. 4º
• PSP pagador agenda em até duas horas do recebimento. Rejeita valores incompatíveis, data/periodicidade, recebedor, regras de envio, ausência de autorização vigente ou divergência impeditiva. Nova instrução nos casos rejeitados pode ser enviada por comando do recebedor até dois dias antes da liquidação. IN BCB 513/2024, art. 6º
• Automático envia ordem no dia previsto entre zero e oito horas se houver recursos e limite. Ausência de recursos/limite ou falha operacional exige aviso e ao menos nova tentativa entre dezoito e vinte e uma horas. Tentativas adicionais facultativas respeitam mínimas e última até vinte e uma horas; sem liquidação após última, novo aviso. IN BCB 513/2024, art. 7º
• Tentativas Automático em outros dias dependem de critério recebedor e previsão na autorização: até sete dias corridos da data original, no máximo três datas distintas e antes do próximo ciclo/fim da recorrência. Valor fica igual; nova instrução chega até vinte e três horas e cinquenta e nove minutos da véspera. Não é permissão de cobrar indefinidamente. IN BCB 513/2024, art. 7º
• Cancelamento de ordem Automático deve ocorrer se cliente pede até vinte e três horas e cinquenta e nove minutos da véspera ou PSP recebedor solicita até vinte e duas horas da véspera. Cancelar autorização cancela agendamentos posteriores ao dia do cancelamento/recebimento do aviso; aviso do recebedor entre vinte e duas horas e fim do dia desloca recorte para posteriores ao dia seguinte. IN BCB 513/2024, art. 8ºIN BCB 513/2024, art. 9º
• Pagador tem gestão de autorizações e agendamentos Automático e Agendado; PSP recebedor detentor da conta oferece gestão de permissões e instruções. Detalhes estão nos manuais UX e Padrões, não reproduzidos integralmente nesta IN. IN BCB 513/2024, art. 10IN BCB 513/2024, art. 11
• Agendado e Cobrança com vencimento agendada enviam ordem entre zero e oito horas se saldo/limite. Falta de saldo ou falha exige aviso e nova tentativa entre dezoito e vinte e uma horas, última até vinte e uma horas; falta de limite no horário inicial tem aviso específico. Texto não estende automaticamente a esta hipótese todo regime de retentativas Automático. IN BCB 513/2024, art. 12
• Para Agendado recorrente mensal nos dias vinte e nove, trinta ou trinta e um inexistentes no mês, PSP envia ordem para liquidação no primeiro dia do mês seguinte; antecipação pelo usuário depende de oferta PSP. Cancelamento Agendado/Cobrança agendada aceita pedido até vinte e três horas e cinquenta e nove minutos da véspera. IN BCB 513/2024, art. 13IN BCB 513/2024, art. 14
• No caso remetido ao art. 41-B, inciso III, PSP pagador devolve total com recursos próprios em até vinte e quatro horas após pedido do pagador. A hipótese não é reproduzida aqui, sem universalizar restituição a todo pedido. IN BCB 513/2024, art. 15

O que esta leitura não diz. Não há layout ou texto literal completo, garantia de restituição ou reembolso de todo desacordo comercial.

Agenda em até duas horas e valida valor, data, recebedor e autorização. Reenvio após erro de liquidação difere de tentativa em outro dia; pacs.008 AUTO e campo não preenchido seguem consolidação.

• A IN detalha Automático, Agendado e Cobrança. Recorrência Automático pode ser semanal, mensal, trimestral, semestral ou anual. Solicitação de autorização na jornada indicada fica aberta até resposta, cancelamento pelo PSP recebedor ou trinta dias do envio; recebedor pode encurtar. Excedido prazo/cancelada, PSP pagador exclui solicitação. IN BCB 513/2024, art. 1ºIN BCB 513/2024, art. 2ºIN BCB 513/2024, art. 3º
• Na jornada por QR indicada, PSP pagador oferece proposta Automático inclusive quando cobrança do QR já foi agendada. Isso não transforma automaticamente agendamento em autorização. IN BCB 513/2024, art. 4º
• PSP recebedor provedor envia instrução normalmente entre dois e dez dias corridos antes da liquidação. Exceção de geração mantém antecedência mínima de dois dias entre agendamento/liquidação, dentro do ciclo/recorrência e sem encargos de atraso causado pelo próprio recebedor. Liquidação é vencimento, podendo passar ao útil seguinte por critério do recebedor se não útil. IN BCB 513/2024, art. 5º
• Instrução deve respeitar permissão confirmada e não ser enviada se recebedor estiver na situação remetida do art. 89, § 2º. Identificação usa CNPJ da Receita. Informações da instrução dependem de Catálogo SFN ou arcabouço Open Finance conforme PSP seja provedor ou iniciador. IN BCB 513/2024, art. 5º
• PSP pagador agenda em até duas horas do recebimento. Rejeita valores incompatíveis, data/periodicidade, recebedor, regras de envio, ausência de autorização vigente ou divergência impeditiva. Nova instrução nos casos rejeitados pode ser enviada por comando do recebedor até dois dias antes da liquidação. IN BCB 513/2024, art. 6º
• Automático envia ordem no dia previsto entre zero e oito horas se houver recursos e limite. Ausência de recursos/limite ou falha operacional exige aviso e ao menos nova tentativa entre dezoito e vinte e uma horas. Tentativas adicionais facultativas respeitam mínimas e última até vinte e uma horas; sem liquidação após última, novo aviso. IN BCB 513/2024, art. 7º
• Tentativas Automático em outros dias dependem de critério recebedor e previsão na autorização: até sete dias corridos da data original, no máximo três datas distintas e antes do próximo ciclo/fim da recorrência. Valor fica igual; nova instrução chega até vinte e três horas e cinquenta e nove minutos da véspera. Não é permissão de cobrar indefinidamente. IN BCB 513/2024, art. 7º
• Erro após envio da ordem exige informar PSP recebedor imediatamente; este reenvia instrução para tentativa no mesmo dia, salvo se ele próprio rejeitou a ordem, quando reenvio é facultativo. Pagador aceita só até vinte e uma horas; valor é original e validações do recorte continuam. Reenvio no mesmo dia não é regra geral para toda falta de saldo. IN BCB 513/2024, art. 5ºIN BCB 513/2024, art. 7º
• pacs.008 do Automático tem formaDeIniciacao AUTO inclusive com iniciador. Na consolidação capturada, idConciliacaoRecebedor não é preenchido quando instrução é gerada por iniciador; não se deve resgatar redação histórica com outro conteúdo. IN BCB 513/2024, art. 7º, § 17 em diante
• Cancelamento de ordem Automático deve ocorrer se cliente pede até vinte e três horas e cinquenta e nove minutos da véspera ou PSP recebedor solicita até vinte e duas horas da véspera. Cancelar autorização cancela agendamentos posteriores ao dia do cancelamento/recebimento do aviso; aviso do recebedor entre vinte e duas horas e fim do dia desloca recorte para posteriores ao dia seguinte. IN BCB 513/2024, art. 8ºIN BCB 513/2024, art. 9º
• Pagador tem gestão de autorizações e agendamentos Automático e Agendado; PSP recebedor detentor da conta oferece gestão de permissões e instruções. Detalhes estão nos manuais UX e Padrões, não reproduzidos integralmente nesta IN. IN BCB 513/2024, art. 10IN BCB 513/2024, art. 11
• Agendado e Cobrança com vencimento agendada enviam ordem entre zero e oito horas se saldo/limite. Falta de saldo ou falha exige aviso e nova tentativa entre dezoito e vinte e uma horas, última até vinte e uma horas; falta de limite no horário inicial tem aviso específico. Texto não estende automaticamente a esta hipótese todo regime de retentativas Automático. IN BCB 513/2024, art. 12
• Para Agendado recorrente mensal nos dias vinte e nove, trinta ou trinta e um inexistentes no mês, PSP envia ordem para liquidação no primeiro dia do mês seguinte; antecipação pelo usuário depende de oferta PSP. Cancelamento Agendado/Cobrança agendada aceita pedido até vinte e três horas e cinquenta e nove minutos da véspera. IN BCB 513/2024, art. 13IN BCB 513/2024, art. 14
• No caso remetido ao art. 41-B, inciso III, PSP pagador devolve total com recursos próprios em até vinte e quatro horas após pedido do pagador. A hipótese não é reproduzida aqui, sem universalizar restituição a todo pedido. IN BCB 513/2024, art. 15
• PSP recebedor verifica idoneidade antes de contratar Automático e durante contrato: dados CNPJ/sócios/administração, atividade/capital/faturamento/funcionários, compatibilidade do serviço, habitualidade e informações DICT se tem acesso; relacionamento/uso de cobrança quando provedor. Não é prova automática de idoneidade apenas por CNPJ ativo. IN BCB 513/2024, art. 15-A
• Marcos de implantação de Agendado e Automático são os de 2024/2025 no art. 17; texto consolidado também inclui alterações de junho de 2026. IN 436 foi revogada. Datas históricas não são novos prazos móveis de implantação. IN BCB 513/2024, art. 16IN BCB 513/2024, art. 17IN BCB 513/2024, art. 6ºIN BCB 513/2024, art. 7º, § 17 em diante

O que esta leitura não diz. Não há payload integral, endpoint, algoritmo de idoneidade ou extensão de toda retentativa a Agendado.

Autorização, instrução, agendamento e liquidação são etapas distintas. Tentativa em outros dias depende da autorização e critérios; cancelar autorização também afeta agendamentos futuros.

• A IN detalha Automático, Agendado e Cobrança. Recorrência Automático pode ser semanal, mensal, trimestral, semestral ou anual. Solicitação de autorização na jornada indicada fica aberta até resposta, cancelamento pelo PSP recebedor ou trinta dias do envio; recebedor pode encurtar. Excedido prazo/cancelada, PSP pagador exclui solicitação. IN BCB 513/2024, art. 1ºIN BCB 513/2024, art. 2ºIN BCB 513/2024, art. 3º
• Na jornada por QR indicada, PSP pagador oferece proposta Automático inclusive quando cobrança do QR já foi agendada. Isso não transforma automaticamente agendamento em autorização. IN BCB 513/2024, art. 4º
• PSP recebedor provedor envia instrução normalmente entre dois e dez dias corridos antes da liquidação. Exceção de geração mantém antecedência mínima de dois dias entre agendamento/liquidação, dentro do ciclo/recorrência e sem encargos de atraso causado pelo próprio recebedor. Liquidação é vencimento, podendo passar ao útil seguinte por critério do recebedor se não útil. IN BCB 513/2024, art. 5º
• Instrução deve respeitar permissão confirmada e não ser enviada se recebedor estiver na situação remetida do art. 89, § 2º. Identificação usa CNPJ da Receita. Informações da instrução dependem de Catálogo SFN ou arcabouço Open Finance conforme PSP seja provedor ou iniciador. IN BCB 513/2024, art. 5º
• PSP pagador agenda em até duas horas do recebimento. Rejeita valores incompatíveis, data/periodicidade, recebedor, regras de envio, ausência de autorização vigente ou divergência impeditiva. Nova instrução nos casos rejeitados pode ser enviada por comando do recebedor até dois dias antes da liquidação. IN BCB 513/2024, art. 6º
• Automático envia ordem no dia previsto entre zero e oito horas se houver recursos e limite. Ausência de recursos/limite ou falha operacional exige aviso e ao menos nova tentativa entre dezoito e vinte e uma horas. Tentativas adicionais facultativas respeitam mínimas e última até vinte e uma horas; sem liquidação após última, novo aviso. IN BCB 513/2024, art. 7º
• Tentativas Automático em outros dias dependem de critério recebedor e previsão na autorização: até sete dias corridos da data original, no máximo três datas distintas e antes do próximo ciclo/fim da recorrência. Valor fica igual; nova instrução chega até vinte e três horas e cinquenta e nove minutos da véspera. Não é permissão de cobrar indefinidamente. IN BCB 513/2024, art. 7º
• Erro após envio da ordem exige informar PSP recebedor imediatamente; este reenvia instrução para tentativa no mesmo dia, salvo se ele próprio rejeitou a ordem, quando reenvio é facultativo. Pagador aceita só até vinte e uma horas; valor é original e validações do recorte continuam. Reenvio no mesmo dia não é regra geral para toda falta de saldo. IN BCB 513/2024, art. 5ºIN BCB 513/2024, art. 7º
• Cancelamento de ordem Automático deve ocorrer se cliente pede até vinte e três horas e cinquenta e nove minutos da véspera ou PSP recebedor solicita até vinte e duas horas da véspera. Cancelar autorização cancela agendamentos posteriores ao dia do cancelamento/recebimento do aviso; aviso do recebedor entre vinte e duas horas e fim do dia desloca recorte para posteriores ao dia seguinte. IN BCB 513/2024, art. 8ºIN BCB 513/2024, art. 9º
• Pagador tem gestão de autorizações e agendamentos Automático e Agendado; PSP recebedor detentor da conta oferece gestão de permissões e instruções. Detalhes estão nos manuais UX e Padrões, não reproduzidos integralmente nesta IN. IN BCB 513/2024, art. 10IN BCB 513/2024, art. 11
• Agendado e Cobrança com vencimento agendada enviam ordem entre zero e oito horas se saldo/limite. Falta de saldo ou falha exige aviso e nova tentativa entre dezoito e vinte e uma horas, última até vinte e uma horas; falta de limite no horário inicial tem aviso específico. Texto não estende automaticamente a esta hipótese todo regime de retentativas Automático. IN BCB 513/2024, art. 12
• Para Agendado recorrente mensal nos dias vinte e nove, trinta ou trinta e um inexistentes no mês, PSP envia ordem para liquidação no primeiro dia do mês seguinte; antecipação pelo usuário depende de oferta PSP. Cancelamento Agendado/Cobrança agendada aceita pedido até vinte e três horas e cinquenta e nove minutos da véspera. IN BCB 513/2024, art. 13IN BCB 513/2024, art. 14
• PSP recebedor verifica idoneidade antes de contratar Automático e durante contrato: dados CNPJ/sócios/administração, atividade/capital/faturamento/funcionários, compatibilidade do serviço, habitualidade e informações DICT se tem acesso; relacionamento/uso de cobrança quando provedor. Não é prova automática de idoneidade apenas por CNPJ ativo. IN BCB 513/2024, art. 15-A
• Marcos de implantação de Agendado e Automático são os de 2024/2025 no art. 17; texto consolidado também inclui alterações de junho de 2026. IN 436 foi revogada. Datas históricas não são novos prazos móveis de implantação. IN BCB 513/2024, art. 16IN BCB 513/2024, art. 17IN BCB 513/2024, art. 6ºIN BCB 513/2024, art. 7º, § 17 em diante

O que esta leitura não diz. Não há garantia de pagamento com saldo/limite insuficiente, recorrência ilimitada ou proposta QR automaticamente aceita.

Prazos de instrução, agendamento, tentativa e cancelamento dependem de papel e produto. Idoneidade e restituição com recursos próprios têm deveres e recortes expressos.

• A IN detalha Automático, Agendado e Cobrança. Recorrência Automático pode ser semanal, mensal, trimestral, semestral ou anual. Solicitação de autorização na jornada indicada fica aberta até resposta, cancelamento pelo PSP recebedor ou trinta dias do envio; recebedor pode encurtar. Excedido prazo/cancelada, PSP pagador exclui solicitação. IN BCB 513/2024, art. 1ºIN BCB 513/2024, art. 2ºIN BCB 513/2024, art. 3º
• Na jornada por QR indicada, PSP pagador oferece proposta Automático inclusive quando cobrança do QR já foi agendada. Isso não transforma automaticamente agendamento em autorização. IN BCB 513/2024, art. 4º
• PSP recebedor provedor envia instrução normalmente entre dois e dez dias corridos antes da liquidação. Exceção de geração mantém antecedência mínima de dois dias entre agendamento/liquidação, dentro do ciclo/recorrência e sem encargos de atraso causado pelo próprio recebedor. Liquidação é vencimento, podendo passar ao útil seguinte por critério do recebedor se não útil. IN BCB 513/2024, art. 5º
• Instrução deve respeitar permissão confirmada e não ser enviada se recebedor estiver na situação remetida do art. 89, § 2º. Identificação usa CNPJ da Receita. Informações da instrução dependem de Catálogo SFN ou arcabouço Open Finance conforme PSP seja provedor ou iniciador. IN BCB 513/2024, art. 5º
• PSP pagador agenda em até duas horas do recebimento. Rejeita valores incompatíveis, data/periodicidade, recebedor, regras de envio, ausência de autorização vigente ou divergência impeditiva. Nova instrução nos casos rejeitados pode ser enviada por comando do recebedor até dois dias antes da liquidação. IN BCB 513/2024, art. 6º
• Automático envia ordem no dia previsto entre zero e oito horas se houver recursos e limite. Ausência de recursos/limite ou falha operacional exige aviso e ao menos nova tentativa entre dezoito e vinte e uma horas. Tentativas adicionais facultativas respeitam mínimas e última até vinte e uma horas; sem liquidação após última, novo aviso. IN BCB 513/2024, art. 7º
• Tentativas Automático em outros dias dependem de critério recebedor e previsão na autorização: até sete dias corridos da data original, no máximo três datas distintas e antes do próximo ciclo/fim da recorrência. Valor fica igual; nova instrução chega até vinte e três horas e cinquenta e nove minutos da véspera. Não é permissão de cobrar indefinidamente. IN BCB 513/2024, art. 7º
• Erro após envio da ordem exige informar PSP recebedor imediatamente; este reenvia instrução para tentativa no mesmo dia, salvo se ele próprio rejeitou a ordem, quando reenvio é facultativo. Pagador aceita só até vinte e uma horas; valor é original e validações do recorte continuam. Reenvio no mesmo dia não é regra geral para toda falta de saldo. IN BCB 513/2024, art. 5ºIN BCB 513/2024, art. 7º
• pacs.008 do Automático tem formaDeIniciacao AUTO inclusive com iniciador. Na consolidação capturada, idConciliacaoRecebedor não é preenchido quando instrução é gerada por iniciador; não se deve resgatar redação histórica com outro conteúdo. IN BCB 513/2024, art. 7º, § 17 em diante
• Cancelamento de ordem Automático deve ocorrer se cliente pede até vinte e três horas e cinquenta e nove minutos da véspera ou PSP recebedor solicita até vinte e duas horas da véspera. Cancelar autorização cancela agendamentos posteriores ao dia do cancelamento/recebimento do aviso; aviso do recebedor entre vinte e duas horas e fim do dia desloca recorte para posteriores ao dia seguinte. IN BCB 513/2024, art. 8ºIN BCB 513/2024, art. 9º
• Pagador tem gestão de autorizações e agendamentos Automático e Agendado; PSP recebedor detentor da conta oferece gestão de permissões e instruções. Detalhes estão nos manuais UX e Padrões, não reproduzidos integralmente nesta IN. IN BCB 513/2024, art. 10IN BCB 513/2024, art. 11
• Agendado e Cobrança com vencimento agendada enviam ordem entre zero e oito horas se saldo/limite. Falta de saldo ou falha exige aviso e nova tentativa entre dezoito e vinte e uma horas, última até vinte e uma horas; falta de limite no horário inicial tem aviso específico. Texto não estende automaticamente a esta hipótese todo regime de retentativas Automático. IN BCB 513/2024, art. 12
• Para Agendado recorrente mensal nos dias vinte e nove, trinta ou trinta e um inexistentes no mês, PSP envia ordem para liquidação no primeiro dia do mês seguinte; antecipação pelo usuário depende de oferta PSP. Cancelamento Agendado/Cobrança agendada aceita pedido até vinte e três horas e cinquenta e nove minutos da véspera. IN BCB 513/2024, art. 13IN BCB 513/2024, art. 14
• No caso remetido ao art. 41-B, inciso III, PSP pagador devolve total com recursos próprios em até vinte e quatro horas após pedido do pagador. A hipótese não é reproduzida aqui, sem universalizar restituição a todo pedido. IN BCB 513/2024, art. 15
• PSP recebedor verifica idoneidade antes de contratar Automático e durante contrato: dados CNPJ/sócios/administração, atividade/capital/faturamento/funcionários, compatibilidade do serviço, habitualidade e informações DICT se tem acesso; relacionamento/uso de cobrança quando provedor. Não é prova automática de idoneidade apenas por CNPJ ativo. IN BCB 513/2024, art. 15-A
• Marcos de implantação de Agendado e Automático são os de 2024/2025 no art. 17; texto consolidado também inclui alterações de junho de 2026. IN 436 foi revogada. Datas históricas não são novos prazos móveis de implantação. IN BCB 513/2024, art. 16IN BCB 513/2024, art. 17IN BCB 513/2024, art. 6ºIN BCB 513/2024, art. 7º, § 17 em diante

O que esta leitura não diz. Não há enquadramento completo do art. 41-B remetido, restituição universal ou aprovação automática do recebedor.

Pedido Decem e contatos cadastrados organizam testes; preparação, janela e novas tentativas têm regras específicas. Documentação QR deve ser preservada e resultados não são presumidos pelo envio.

• A norma trata testes de DICT, QR, iniciação, publicação de saque e Automático conforme modalidade/acesso/serviços. Liquidante especial e provedor direto DICT têm funcionalidades e capacidade; instituição usuária tem funcionalidades, com dispensas específicas. Iniciador direto tem consulta e capacidade em rito próprio. IN BCB 508/2024, art. 1ºIN BCB 508/2024, art. 2ºIN BCB 508/2024, art. 3ºIN BCB 508/2024, art. 3º-AIN BCB 508/2024, art. 27
• Funcionalidades precedem capacidade. Testes usam ISPB próprio; quem presta acesso indireto no recorte também testa com ISPB do indireto cadastrado em homologação, sem ISPB virtual BC. Agendamento funcionalidades usa Protocolo Digital/Decem com ISPB e razão social dos envolvidos. IN BCB 508/2024, art. 4ºIN BCB 508/2024, art. 5ºIN BCB 508/2024, art. 6ºIN BCB 508/2024, art. 7ºIN BCB 508/2024, art. 8ºIN BCB 508/2024, art. 9ºIN BCB 508/2024, art. 10
• Preparação funcionalidades inclui mil chaves de um tipo não aleatório, ao menos cinco transações em homologação com recebedor virtual indicado, orientações Decem e sugestão de dia útil/horário comercial. Tipo, EndToEndId e sugestão vão à caixa indicada; Decem fixa data sem pendências. Instituição usuária dispensa registro das mil chaves e preparação BC de sincronismo. IN BCB 508/2024, art. 11IN BCB 508/2024, art. 12IN BCB 508/2024, art. 13
• Funcionalidades têm janela de uma hora e ausência prévia de pendências de portabilidade, posse ou infração em homologação. Testam registro/consulta por tipo, sincronismo, recebimento de reivindicações em até um minuto, fluxos de reivindicação/infração e devolução por falha e fraude. Usuária dispensa sincronismo, não todos os testes. IN BCB 508/2024, art. 14IN BCB 508/2024, art. 15IN BCB 508/2024, art. 16
• Capacidade do primeiro rito: mil, duas mil ou quatro mil chaves diferentes por sessenta segundos conforme até um milhão, entre um e dez milhões ou mais de dez milhões de contas. Consultas duram dez minutos distribuídos homogeneamente, totais mínimos dez, vinte ou quarenta mil; execução na janela de uma hora agendada. Não são limites permanentes de produção. IN BCB 508/2024, art. 19IN BCB 508/2024, art. 20IN BCB 508/2024, art. 21IN BCB 508/2024, art. 22IN BCB 508/2024, art. 23
• Iniciador obtém chaves de consulta, não fornecidas pelo Decem, e consulta pelo menos uma por tipo em janela de uma hora. Depois de aprovado, capacidade exige mil diferentes por sessenta segundos durante dez minutos, mínimo dez mil homogêneas, em janela de uma hora. IN BCB 508/2024, art. 27IN BCB 508/2024, art. 28IN BCB 508/2024, art. 29IN BCB 508/2024, art. 30IN BCB 508/2024, art. 31IN BCB 508/2024, art. 32IN BCB 508/2024, art. 35IN BCB 508/2024, art. 36IN BCB 508/2024, art. 37IN BCB 508/2024, art. 38IN BCB 508/2024, art. 39
• Decem comunica desempenho/aprovação ou critérios inobservados por e-mail. Cada teste não aprovado admite até duas novas tentativas e novo agendamento; funcionalidades do primeiro rito reiniciam preparação. Terceiro insucesso consecutivo reprova homologação DICT, com exceção expressa de provedor testando ISPB indireto. IN BCB 508/2024, art. 17IN BCB 508/2024, art. 18IN BCB 508/2024, art. 24IN BCB 508/2024, art. 25IN BCB 508/2024, art. 26IN BCB 508/2024, art. 33IN BCB 508/2024, art. 34IN BCB 508/2024, art. 40IN BCB 508/2024, art. 41IN BCB 508/2024, art. 42IN BCB 508/2024, art. 43
• QR distingue leitura pagador e geração recebedor, cobrança imediata/com vencimento, estático/dinâmico, Saque/Troco. Pix Tester valida operações e erros intencionais na leitura. Obrigatoriedade depende de PF/PJ, oferta API/QR e instituição usuária optante; não presume toda geração dinâmica obrigatória a todo participante. IN BCB 508/2024, art. 44IN BCB 508/2024, art. 45IN BCB 508/2024, art. 46
• Documentação da execução de testes QR deve ficar por cinco anos para eventual análise BC. Testes de iniciação distinguem detentor que envia Pix após pedido e iniciador que emite pedido; cobrem chave, dados manuais, informações já detidas e QR. Iniciador precisa colaboração de detentor. IN BCB 508/2024, art. 47IN BCB 508/2024, art. 48IN BCB 508/2024, art. 49IN BCB 508/2024, art. 50
• Facilitador de saque no recorte inclui conjunto de informações no Catálogo de Dados Abertos de homologação e o disponibiliza no local informado. Decem confere inclusão, disponibilidade e especificações da IN 313/documentação técnica. IN BCB 508/2024, art. 51IN BCB 508/2024, art. 52
• Automático testa todos cenários Pix Tester dos serviços ofertados, por ponta. Dispensa PJ de pagamento não dispensa testar rejeição de mensagens indevidas. Obrigatoriedade pagadora/recebedora depende de modalidade, público e opção nos arts. 54 a 56; não é teste único igual para todas instituições. IN BCB 508/2024, art. 53IN BCB 508/2024, art. 54IN BCB 508/2024, art. 55IN BCB 508/2024, art. 56
• Transações liquidadas em sistemas próprios: teste envia TRCK002 e recebe CAMT.025 correspondente com sucesso em homologação. Recuperação testa criação e solicitação de devolução; em adesão ocorre junto a homologação DICT. Sucesso nesse teste não garante reembolso em caso real. IN BCB 508/2024, art. 56-AIN BCB 508/2024, art. 56-B
• Decem pode determinar testes complementares a seu exclusivo critério. IN 290 é revogada e norma vigora da publicação; consolidação incorpora alterações posteriores, incluindo mensageria/recuperação. Conclusão dos testes depende dos resultados, sem prazo de aprovação BC fixado. IN BCB 508/2024, art. 57IN BCB 508/2024, art. 58IN BCB 508/2024, art. 59IN BCB 508/2024, art. 56-AIN BCB 508/2024, art. 56-B

O que esta leitura não diz. Não há SLA interno, agenda automática confirmada ou garantia de aprovação após terceira execução.

Validação de QR abrange leitura, geração e tratamento de inconsistências por jornada. Automático separa pontas e não ofertantes; o texto não descreve todas telas.

• A norma trata testes de DICT, QR, iniciação, publicação de saque e Automático conforme modalidade/acesso/serviços. Liquidante especial e provedor direto DICT têm funcionalidades e capacidade; instituição usuária tem funcionalidades, com dispensas específicas. Iniciador direto tem consulta e capacidade em rito próprio. IN BCB 508/2024, art. 1ºIN BCB 508/2024, art. 2ºIN BCB 508/2024, art. 3ºIN BCB 508/2024, art. 3º-AIN BCB 508/2024, art. 27
• Decem comunica desempenho/aprovação ou critérios inobservados por e-mail. Cada teste não aprovado admite até duas novas tentativas e novo agendamento; funcionalidades do primeiro rito reiniciam preparação. Terceiro insucesso consecutivo reprova homologação DICT, com exceção expressa de provedor testando ISPB indireto. IN BCB 508/2024, art. 17IN BCB 508/2024, art. 18IN BCB 508/2024, art. 24IN BCB 508/2024, art. 25IN BCB 508/2024, art. 26IN BCB 508/2024, art. 33IN BCB 508/2024, art. 34IN BCB 508/2024, art. 40IN BCB 508/2024, art. 41IN BCB 508/2024, art. 42IN BCB 508/2024, art. 43
• QR distingue leitura pagador e geração recebedor, cobrança imediata/com vencimento, estático/dinâmico, Saque/Troco. Pix Tester valida operações e erros intencionais na leitura. Obrigatoriedade depende de PF/PJ, oferta API/QR e instituição usuária optante; não presume toda geração dinâmica obrigatória a todo participante. IN BCB 508/2024, art. 44IN BCB 508/2024, art. 45IN BCB 508/2024, art. 46
• Documentação da execução de testes QR deve ficar por cinco anos para eventual análise BC. Testes de iniciação distinguem detentor que envia Pix após pedido e iniciador que emite pedido; cobrem chave, dados manuais, informações já detidas e QR. Iniciador precisa colaboração de detentor. IN BCB 508/2024, art. 47IN BCB 508/2024, art. 48IN BCB 508/2024, art. 49IN BCB 508/2024, art. 50
• Automático testa todos cenários Pix Tester dos serviços ofertados, por ponta. Dispensa PJ de pagamento não dispensa testar rejeição de mensagens indevidas. Obrigatoriedade pagadora/recebedora depende de modalidade, público e opção nos arts. 54 a 56; não é teste único igual para todas instituições. IN BCB 508/2024, art. 53IN BCB 508/2024, art. 54IN BCB 508/2024, art. 55IN BCB 508/2024, art. 56
• Transações liquidadas em sistemas próprios: teste envia TRCK002 e recebe CAMT.025 correspondente com sucesso em homologação. Recuperação testa criação e solicitação de devolução; em adesão ocorre junto a homologação DICT. Sucesso nesse teste não garante reembolso em caso real. IN BCB 508/2024, art. 56-AIN BCB 508/2024, art. 56-B
• Decem pode determinar testes complementares a seu exclusivo critério. IN 290 é revogada e norma vigora da publicação; consolidação incorpora alterações posteriores, incluindo mensageria/recuperação. Conclusão dos testes depende dos resultados, sem prazo de aprovação BC fixado. IN BCB 508/2024, art. 57IN BCB 508/2024, art. 58IN BCB 508/2024, art. 59IN BCB 508/2024, art. 56-AIN BCB 508/2024, art. 56-B

O que esta leitura não diz. Não há mensagem literal, layout, acessibilidade integral ou equivalência de aprovação técnica a conformidade de toda experiência.

Funcionalidades/consulta antecedem capacidade. Janela do teste, carga por minuto e duração homogênea são medidas diferentes; cenários incluem erros e dependências de outro participante.

• A norma trata testes de DICT, QR, iniciação, publicação de saque e Automático conforme modalidade/acesso/serviços. Liquidante especial e provedor direto DICT têm funcionalidades e capacidade; instituição usuária tem funcionalidades, com dispensas específicas. Iniciador direto tem consulta e capacidade em rito próprio. IN BCB 508/2024, art. 1ºIN BCB 508/2024, art. 2ºIN BCB 508/2024, art. 3ºIN BCB 508/2024, art. 3º-AIN BCB 508/2024, art. 27
• Funcionalidades precedem capacidade. Testes usam ISPB próprio; quem presta acesso indireto no recorte também testa com ISPB do indireto cadastrado em homologação, sem ISPB virtual BC. Agendamento funcionalidades usa Protocolo Digital/Decem com ISPB e razão social dos envolvidos. IN BCB 508/2024, art. 4ºIN BCB 508/2024, art. 5ºIN BCB 508/2024, art. 6ºIN BCB 508/2024, art. 7ºIN BCB 508/2024, art. 8ºIN BCB 508/2024, art. 9ºIN BCB 508/2024, art. 10
• Preparação funcionalidades inclui mil chaves de um tipo não aleatório, ao menos cinco transações em homologação com recebedor virtual indicado, orientações Decem e sugestão de dia útil/horário comercial. Tipo, EndToEndId e sugestão vão à caixa indicada; Decem fixa data sem pendências. Instituição usuária dispensa registro das mil chaves e preparação BC de sincronismo. IN BCB 508/2024, art. 11IN BCB 508/2024, art. 12IN BCB 508/2024, art. 13
• Funcionalidades têm janela de uma hora e ausência prévia de pendências de portabilidade, posse ou infração em homologação. Testam registro/consulta por tipo, sincronismo, recebimento de reivindicações em até um minuto, fluxos de reivindicação/infração e devolução por falha e fraude. Usuária dispensa sincronismo, não todos os testes. IN BCB 508/2024, art. 14IN BCB 508/2024, art. 15IN BCB 508/2024, art. 16
• Capacidade do primeiro rito: mil, duas mil ou quatro mil chaves diferentes por sessenta segundos conforme até um milhão, entre um e dez milhões ou mais de dez milhões de contas. Consultas duram dez minutos distribuídos homogeneamente, totais mínimos dez, vinte ou quarenta mil; execução na janela de uma hora agendada. Não são limites permanentes de produção. IN BCB 508/2024, art. 19IN BCB 508/2024, art. 20IN BCB 508/2024, art. 21IN BCB 508/2024, art. 22IN BCB 508/2024, art. 23
• Iniciador obtém chaves de consulta, não fornecidas pelo Decem, e consulta pelo menos uma por tipo em janela de uma hora. Depois de aprovado, capacidade exige mil diferentes por sessenta segundos durante dez minutos, mínimo dez mil homogêneas, em janela de uma hora. IN BCB 508/2024, art. 27IN BCB 508/2024, art. 28IN BCB 508/2024, art. 29IN BCB 508/2024, art. 30IN BCB 508/2024, art. 31IN BCB 508/2024, art. 32IN BCB 508/2024, art. 35IN BCB 508/2024, art. 36IN BCB 508/2024, art. 37IN BCB 508/2024, art. 38IN BCB 508/2024, art. 39
• Decem comunica desempenho/aprovação ou critérios inobservados por e-mail. Cada teste não aprovado admite até duas novas tentativas e novo agendamento; funcionalidades do primeiro rito reiniciam preparação. Terceiro insucesso consecutivo reprova homologação DICT, com exceção expressa de provedor testando ISPB indireto. IN BCB 508/2024, art. 17IN BCB 508/2024, art. 18IN BCB 508/2024, art. 24IN BCB 508/2024, art. 25IN BCB 508/2024, art. 26IN BCB 508/2024, art. 33IN BCB 508/2024, art. 34IN BCB 508/2024, art. 40IN BCB 508/2024, art. 41IN BCB 508/2024, art. 42IN BCB 508/2024, art. 43
• QR distingue leitura pagador e geração recebedor, cobrança imediata/com vencimento, estático/dinâmico, Saque/Troco. Pix Tester valida operações e erros intencionais na leitura. Obrigatoriedade depende de PF/PJ, oferta API/QR e instituição usuária optante; não presume toda geração dinâmica obrigatória a todo participante. IN BCB 508/2024, art. 44IN BCB 508/2024, art. 45IN BCB 508/2024, art. 46
• Documentação da execução de testes QR deve ficar por cinco anos para eventual análise BC. Testes de iniciação distinguem detentor que envia Pix após pedido e iniciador que emite pedido; cobrem chave, dados manuais, informações já detidas e QR. Iniciador precisa colaboração de detentor. IN BCB 508/2024, art. 47IN BCB 508/2024, art. 48IN BCB 508/2024, art. 49IN BCB 508/2024, art. 50
• Facilitador de saque no recorte inclui conjunto de informações no Catálogo de Dados Abertos de homologação e o disponibiliza no local informado. Decem confere inclusão, disponibilidade e especificações da IN 313/documentação técnica. IN BCB 508/2024, art. 51IN BCB 508/2024, art. 52
• Automático testa todos cenários Pix Tester dos serviços ofertados, por ponta. Dispensa PJ de pagamento não dispensa testar rejeição de mensagens indevidas. Obrigatoriedade pagadora/recebedora depende de modalidade, público e opção nos arts. 54 a 56; não é teste único igual para todas instituições. IN BCB 508/2024, art. 53IN BCB 508/2024, art. 54IN BCB 508/2024, art. 55IN BCB 508/2024, art. 56
• Transações liquidadas em sistemas próprios: teste envia TRCK002 e recebe CAMT.025 correspondente com sucesso em homologação. Recuperação testa criação e solicitação de devolução; em adesão ocorre junto a homologação DICT. Sucesso nesse teste não garante reembolso em caso real. IN BCB 508/2024, art. 56-AIN BCB 508/2024, art. 56-B
• Decem pode determinar testes complementares a seu exclusivo critério. IN 290 é revogada e norma vigora da publicação; consolidação incorpora alterações posteriores, incluindo mensageria/recuperação. Conclusão dos testes depende dos resultados, sem prazo de aprovação BC fixado. IN BCB 508/2024, art. 57IN BCB 508/2024, art. 58IN BCB 508/2024, art. 59IN BCB 508/2024, art. 56-AIN BCB 508/2024, art. 56-B

O que esta leitura não diz. Não há endpoints completos, SLA permanente derivado da carga de teste ou dispensa de homologação por testar localmente.

QR, iniciação, Saque/Troco e Automático têm testes conforme público e serviço. Dispensa de pagamentos Automático a PJ ainda exige cenário de rejeição.

• A norma trata testes de DICT, QR, iniciação, publicação de saque e Automático conforme modalidade/acesso/serviços. Liquidante especial e provedor direto DICT têm funcionalidades e capacidade; instituição usuária tem funcionalidades, com dispensas específicas. Iniciador direto tem consulta e capacidade em rito próprio. IN BCB 508/2024, art. 1ºIN BCB 508/2024, art. 2ºIN BCB 508/2024, art. 3ºIN BCB 508/2024, art. 3º-AIN BCB 508/2024, art. 27
• Decem comunica desempenho/aprovação ou critérios inobservados por e-mail. Cada teste não aprovado admite até duas novas tentativas e novo agendamento; funcionalidades do primeiro rito reiniciam preparação. Terceiro insucesso consecutivo reprova homologação DICT, com exceção expressa de provedor testando ISPB indireto. IN BCB 508/2024, art. 17IN BCB 508/2024, art. 18IN BCB 508/2024, art. 24IN BCB 508/2024, art. 25IN BCB 508/2024, art. 26IN BCB 508/2024, art. 33IN BCB 508/2024, art. 34IN BCB 508/2024, art. 40IN BCB 508/2024, art. 41IN BCB 508/2024, art. 42IN BCB 508/2024, art. 43
• QR distingue leitura pagador e geração recebedor, cobrança imediata/com vencimento, estático/dinâmico, Saque/Troco. Pix Tester valida operações e erros intencionais na leitura. Obrigatoriedade depende de PF/PJ, oferta API/QR e instituição usuária optante; não presume toda geração dinâmica obrigatória a todo participante. IN BCB 508/2024, art. 44IN BCB 508/2024, art. 45IN BCB 508/2024, art. 46
• Documentação da execução de testes QR deve ficar por cinco anos para eventual análise BC. Testes de iniciação distinguem detentor que envia Pix após pedido e iniciador que emite pedido; cobrem chave, dados manuais, informações já detidas e QR. Iniciador precisa colaboração de detentor. IN BCB 508/2024, art. 47IN BCB 508/2024, art. 48IN BCB 508/2024, art. 49IN BCB 508/2024, art. 50
• Facilitador de saque no recorte inclui conjunto de informações no Catálogo de Dados Abertos de homologação e o disponibiliza no local informado. Decem confere inclusão, disponibilidade e especificações da IN 313/documentação técnica. IN BCB 508/2024, art. 51IN BCB 508/2024, art. 52
• Automático testa todos cenários Pix Tester dos serviços ofertados, por ponta. Dispensa PJ de pagamento não dispensa testar rejeição de mensagens indevidas. Obrigatoriedade pagadora/recebedora depende de modalidade, público e opção nos arts. 54 a 56; não é teste único igual para todas instituições. IN BCB 508/2024, art. 53IN BCB 508/2024, art. 54IN BCB 508/2024, art. 55IN BCB 508/2024, art. 56
• Transações liquidadas em sistemas próprios: teste envia TRCK002 e recebe CAMT.025 correspondente com sucesso em homologação. Recuperação testa criação e solicitação de devolução; em adesão ocorre junto a homologação DICT. Sucesso nesse teste não garante reembolso em caso real. IN BCB 508/2024, art. 56-AIN BCB 508/2024, art. 56-B
• Decem pode determinar testes complementares a seu exclusivo critério. IN 290 é revogada e norma vigora da publicação; consolidação incorpora alterações posteriores, incluindo mensageria/recuperação. Conclusão dos testes depende dos resultados, sem prazo de aprovação BC fixado. IN BCB 508/2024, art. 57IN BCB 508/2024, art. 58IN BCB 508/2024, art. 59IN BCB 508/2024, art. 56-AIN BCB 508/2024, art. 56-B

O que esta leitura não diz. Não há obrigação universal de ofertar toda funcionalidade, garantia de lançamento ou sucesso financeiro decorrente de teste.

Homologação depende de modalidade, acesso e serviços. Dispensas de instituição usuária e exceção com ISPB indireto não removem todo dever de teste. Evidência QR tem prazo próprio.

• A norma trata testes de DICT, QR, iniciação, publicação de saque e Automático conforme modalidade/acesso/serviços. Liquidante especial e provedor direto DICT têm funcionalidades e capacidade; instituição usuária tem funcionalidades, com dispensas específicas. Iniciador direto tem consulta e capacidade em rito próprio. IN BCB 508/2024, art. 1ºIN BCB 508/2024, art. 2ºIN BCB 508/2024, art. 3ºIN BCB 508/2024, art. 3º-AIN BCB 508/2024, art. 27
• Funcionalidades precedem capacidade. Testes usam ISPB próprio; quem presta acesso indireto no recorte também testa com ISPB do indireto cadastrado em homologação, sem ISPB virtual BC. Agendamento funcionalidades usa Protocolo Digital/Decem com ISPB e razão social dos envolvidos. IN BCB 508/2024, art. 4ºIN BCB 508/2024, art. 5ºIN BCB 508/2024, art. 6ºIN BCB 508/2024, art. 7ºIN BCB 508/2024, art. 8ºIN BCB 508/2024, art. 9ºIN BCB 508/2024, art. 10
• Preparação funcionalidades inclui mil chaves de um tipo não aleatório, ao menos cinco transações em homologação com recebedor virtual indicado, orientações Decem e sugestão de dia útil/horário comercial. Tipo, EndToEndId e sugestão vão à caixa indicada; Decem fixa data sem pendências. Instituição usuária dispensa registro das mil chaves e preparação BC de sincronismo. IN BCB 508/2024, art. 11IN BCB 508/2024, art. 12IN BCB 508/2024, art. 13
• Funcionalidades têm janela de uma hora e ausência prévia de pendências de portabilidade, posse ou infração em homologação. Testam registro/consulta por tipo, sincronismo, recebimento de reivindicações em até um minuto, fluxos de reivindicação/infração e devolução por falha e fraude. Usuária dispensa sincronismo, não todos os testes. IN BCB 508/2024, art. 14IN BCB 508/2024, art. 15IN BCB 508/2024, art. 16
• Capacidade do primeiro rito: mil, duas mil ou quatro mil chaves diferentes por sessenta segundos conforme até um milhão, entre um e dez milhões ou mais de dez milhões de contas. Consultas duram dez minutos distribuídos homogeneamente, totais mínimos dez, vinte ou quarenta mil; execução na janela de uma hora agendada. Não são limites permanentes de produção. IN BCB 508/2024, art. 19IN BCB 508/2024, art. 20IN BCB 508/2024, art. 21IN BCB 508/2024, art. 22IN BCB 508/2024, art. 23
• Iniciador obtém chaves de consulta, não fornecidas pelo Decem, e consulta pelo menos uma por tipo em janela de uma hora. Depois de aprovado, capacidade exige mil diferentes por sessenta segundos durante dez minutos, mínimo dez mil homogêneas, em janela de uma hora. IN BCB 508/2024, art. 27IN BCB 508/2024, art. 28IN BCB 508/2024, art. 29IN BCB 508/2024, art. 30IN BCB 508/2024, art. 31IN BCB 508/2024, art. 32IN BCB 508/2024, art. 35IN BCB 508/2024, art. 36IN BCB 508/2024, art. 37IN BCB 508/2024, art. 38IN BCB 508/2024, art. 39
• Decem comunica desempenho/aprovação ou critérios inobservados por e-mail. Cada teste não aprovado admite até duas novas tentativas e novo agendamento; funcionalidades do primeiro rito reiniciam preparação. Terceiro insucesso consecutivo reprova homologação DICT, com exceção expressa de provedor testando ISPB indireto. IN BCB 508/2024, art. 17IN BCB 508/2024, art. 18IN BCB 508/2024, art. 24IN BCB 508/2024, art. 25IN BCB 508/2024, art. 26IN BCB 508/2024, art. 33IN BCB 508/2024, art. 34IN BCB 508/2024, art. 40IN BCB 508/2024, art. 41IN BCB 508/2024, art. 42IN BCB 508/2024, art. 43
• QR distingue leitura pagador e geração recebedor, cobrança imediata/com vencimento, estático/dinâmico, Saque/Troco. Pix Tester valida operações e erros intencionais na leitura. Obrigatoriedade depende de PF/PJ, oferta API/QR e instituição usuária optante; não presume toda geração dinâmica obrigatória a todo participante. IN BCB 508/2024, art. 44IN BCB 508/2024, art. 45IN BCB 508/2024, art. 46
• Documentação da execução de testes QR deve ficar por cinco anos para eventual análise BC. Testes de iniciação distinguem detentor que envia Pix após pedido e iniciador que emite pedido; cobrem chave, dados manuais, informações já detidas e QR. Iniciador precisa colaboração de detentor. IN BCB 508/2024, art. 47IN BCB 508/2024, art. 48IN BCB 508/2024, art. 49IN BCB 508/2024, art. 50
• Facilitador de saque no recorte inclui conjunto de informações no Catálogo de Dados Abertos de homologação e o disponibiliza no local informado. Decem confere inclusão, disponibilidade e especificações da IN 313/documentação técnica. IN BCB 508/2024, art. 51IN BCB 508/2024, art. 52
• Automático testa todos cenários Pix Tester dos serviços ofertados, por ponta. Dispensa PJ de pagamento não dispensa testar rejeição de mensagens indevidas. Obrigatoriedade pagadora/recebedora depende de modalidade, público e opção nos arts. 54 a 56; não é teste único igual para todas instituições. IN BCB 508/2024, art. 53IN BCB 508/2024, art. 54IN BCB 508/2024, art. 55IN BCB 508/2024, art. 56
• Transações liquidadas em sistemas próprios: teste envia TRCK002 e recebe CAMT.025 correspondente com sucesso em homologação. Recuperação testa criação e solicitação de devolução; em adesão ocorre junto a homologação DICT. Sucesso nesse teste não garante reembolso em caso real. IN BCB 508/2024, art. 56-AIN BCB 508/2024, art. 56-B
• Decem pode determinar testes complementares a seu exclusivo critério. IN 290 é revogada e norma vigora da publicação; consolidação incorpora alterações posteriores, incluindo mensageria/recuperação. Conclusão dos testes depende dos resultados, sem prazo de aprovação BC fixado. IN BCB 508/2024, art. 57IN BCB 508/2024, art. 58IN BCB 508/2024, art. 59IN BCB 508/2024, art. 56-AIN BCB 508/2024, art. 56-B

O que esta leitura não diz. Não há garantia de aprovação, checklist universal igual para toda instituição ou prazo para Decem concluir análise.

Devolução da cobrança híbrida futura e revisão de marcação têm responsáveis e prazos distintos. Incidentes, divulgação MED e saída de participantes possuem recortes e datas próprios.

• A captura inclui alterações futuras e calendário escalonado: cobrança híbrida, ajustes dos arts. 32/39/40/41-A e comunicação de marcação do art. 78-HB, parágrafo único, em 1º de fevereiro de 2027; conta-salário e art. 11-S em 1º de julho de 2027; demais dispositivos na publicação. Não apresente todas as alterações como vigentes hoje. Res. BCB 587/2026, art. 5º
• Para fevereiro de 2027, cobrança híbrida é facultativa ao PSP recebedor, apenas Cobrança com vencimento e boleto comum ou dinâmico sem vínculo a ativo financeiro registrado/escriturado/depositado nos sistemas indicados. PSP recebedor deve ser a mesma instituição emissora do boleto e assegurar informações consistentes para prevenir pagamento indevido ou duplicado. Res. BCB 587/2026, art. 2ºRes. BCB 587/2026, art. 5º
• Na cobrança híbrida futura, pagamento por boleto ou vinculação do boleto dinâmico a ativo financeiro exige cancelar o Pix Cobrança. Se Pix for pago após vínculo do dinâmico por falha desse cancelamento, PSP recebedor garante totalidade ao beneficiário do boleto com recursos próprios. Pagamento híbrido por Pix remete procedimentos de ambos PSPs aos manuais de Fluxos e UX. Res. BCB 587/2026, art. 2ºRes. BCB 587/2026, art. 5º
• Para fevereiro de 2027, Pix Cobrança híbrido liquidado depois de obrigação já paga por boleto exige PSP recebedor devolver total ao pagador com recursos próprios em até vinte e quatro horas da liquidação. Essa hipótese é diferente de destinar recursos ao beneficiário do boleto dinâmico vinculado. Res. BCB 587/2026, art. 2º, § 3º em dianteRes. BCB 587/2026, art. 2ºRes. BCB 587/2026, art. 5º
• Na perda de participação, o texto altera hipóteses e prazos, incluindo ficar sem liquidante SPI ativo por mais de noventa dias corridos e desligamento imediato nos casos enumerados. Se o responsável perde participação, contratante tem noventa dias do desligamento efetivo para finalizar a troca perante BC. Caputs e hipóteses não transcritos exigem consulta completa; essas alterações ficam no grupo da publicação. Res. BCB 587/2026, art. 2ºRes. BCB 587/2026, art. 2º (continuação)Res. BCB 587/2026, art. 5º
• Liquidação extrajudicial suspende imediatamente; liquidante pode requerer saída ordenada até trinta dias da decretação e, sem pedido tempestivo, há desligamento. Durante saída ordenada, BC pode vedar receber Pix e permitir somente iniciar. Exclusão por decisão definitiva leva a desligamento imediato após comunicação; comprovação das medidas remetidas deve ser apresentada ao BC quando solicitada. O calendário atribui a esses dispositivos vigência na publicação. Res. BCB 587/2026, art. 2º (continuação)Res. BCB 587/2026, art. 3ºRes. BCB 587/2026, art. 5º
• Para fevereiro de 2027, o texto prevê comunicar incidente com dados pessoais em banco de dados relacionado a componente ou infraestrutura do Pix aos titulares PF de contas providas pelo participante, mesmo sem responsabilidade do provedor ou risco/dano relevante, nos termos de documento específico; mecanismos contra instruções indevidas e ofertas excessivas de autorização Automático; e divulgação clara/acessível do MED focada no público vulnerável em publicidade e atendimento. Res. BCB 587/2026, art. 2º (continuação)Res. BCB 587/2026, art. 5º
• O participante pode criar no DICT notificação de fundada suspeita de fraude transacional para CPF/CNPJ de cliente envolvido em Pix específico. Quem aceita notificação ou cria essa marcação é responsável por ela; vínculo à chave depende de informação disponível. No calendário do ato, esses dispositivos e rejeição de registro/portabilidade/reivindicação nos recortes indicados ficam no grupo da publicação. Res. BCB 587/2026, art. 2º, § 3º em dianteRes. BCB 587/2026, art. 5º
• Para fevereiro de 2027, quem criar marcação deve comunicar data, possibilidade de revisão e canal para esclarecimento/pedido. O participante responsável assegura pedido de cancelamento, decide em até sete dias do recebimento, cancela se não subsistir fundamento e guarda razões da decisão; esses últimos dispositivos estão no grupo da publicação. A vinculação prevista dura cinco anos, preservada a hipótese de cancelamento. Res. BCB 587/2026, art. 2º, § 3º em dianteRes. BCB 587/2026, art. 5º
• Nos recortes transcritos, registro de chave é rejeitado para usuário/conta associados a notificação aceita ou marcação criada pelo próprio participante, com motivo comunicado. Portabilidade e reivindicação não são solicitadas quando solicitante está associado a esses recortes. Quem aceita/cria notificação rejeita Pix do usuário pagador/recebedor e conta envolvidos, salvo devoluções. Esses dispositivos estão no grupo da publicação. Res. BCB 587/2026, art. 2º, § 3º em dianteRes. BCB 587/2026, art. 5º
• Instituições podem recorrer de decisões do BC como instituidor em dez dias corridos da comunicação, salvo prazos específicos. Recurso vai à autoridade decisora e, sem reconsideração, à competente em única/última instância; efeito é devolutivo e suspensivo só quando atribuído por justo receio de prejuízo de difícil/incerta reparação. O calendário coloca esses dispositivos na publicação. Res. BCB 587/2026, art. 2º, § 3º em dianteRes. BCB 587/2026, art. 2º, § 3º em diante (2)Res. BCB 587/2026, art. 5º
• O ato revoga os dispositivos listados dos arts. 24/31 do Regulamento e art. 26 do anexo da Resolução 507. Não reproduz seu conteúdo completo; a leitura não infere a dispensa de todo requisito de participação. Res. BCB 587/2026, art. 4ºRes. BCB 587/2026, art. 5º

O que esta leitura não diz. Não há SLA interno ou teor completo de hipóteses omitidas. Não confunda recurso institucional com pedido do usuário; consulte a versão aplicável à data.

O texto prevê comunicação de marcação com data e canal, com vigência futura própria. MED acessível e incidente a titulares PF também são futuros; o ato não reproduz telas dos manuais.

• A captura inclui alterações futuras e calendário escalonado: cobrança híbrida, ajustes dos arts. 32/39/40/41-A e comunicação de marcação do art. 78-HB, parágrafo único, em 1º de fevereiro de 2027; conta-salário e art. 11-S em 1º de julho de 2027; demais dispositivos na publicação. Não apresente todas as alterações como vigentes hoje. Res. BCB 587/2026, art. 5º
• Para julho de 2027, o texto admite iniciação exclusiva de Pix Automático a partir de conta-salário. Recebimentos Pix ficam vedados, exceto STN ou devoluções. As jornadas c/d de autorização remetidas não se aplicam à conta-salário; os fluxos completos dessas jornadas não estão reproduzidos. Res. BCB 587/2026, art. 2ºRes. BCB 587/2026, art. 5º
• Para fevereiro de 2027, cobrança híbrida é facultativa ao PSP recebedor, apenas Cobrança com vencimento e boleto comum ou dinâmico sem vínculo a ativo financeiro registrado/escriturado/depositado nos sistemas indicados. PSP recebedor deve ser a mesma instituição emissora do boleto e assegurar informações consistentes para prevenir pagamento indevido ou duplicado. Res. BCB 587/2026, art. 2ºRes. BCB 587/2026, art. 5º
• Para fevereiro de 2027, Pix Cobrança híbrido liquidado depois de obrigação já paga por boleto exige PSP recebedor devolver total ao pagador com recursos próprios em até vinte e quatro horas da liquidação. Essa hipótese é diferente de destinar recursos ao beneficiário do boleto dinâmico vinculado. Res. BCB 587/2026, art. 2º, § 3º em dianteRes. BCB 587/2026, art. 2ºRes. BCB 587/2026, art. 5º
• Para fevereiro de 2027, o texto prevê comunicar incidente com dados pessoais em banco de dados relacionado a componente ou infraestrutura do Pix aos titulares PF de contas providas pelo participante, mesmo sem responsabilidade do provedor ou risco/dano relevante, nos termos de documento específico; mecanismos contra instruções indevidas e ofertas excessivas de autorização Automático; e divulgação clara/acessível do MED focada no público vulnerável em publicidade e atendimento. Res. BCB 587/2026, art. 2º (continuação)Res. BCB 587/2026, art. 5º
• Nos novos incisos do art. 39, o texto futuro lista agente não habilitado, inconsistência no Automático ressalvada iniciação por serviço, e cobrança híbrida paga por boleto ou boleto dinâmico vinculado. O caput do artigo não está reproduzido nesta alteração; não reconstrua sozinho seu ator ou rito. Res. BCB 587/2026, art. 2º (continuação)Res. BCB 587/2026, art. 5º
• Para fevereiro de 2027, quem criar marcação deve comunicar data, possibilidade de revisão e canal para esclarecimento/pedido. O participante responsável assegura pedido de cancelamento, decide em até sete dias do recebimento, cancela se não subsistir fundamento e guarda razões da decisão; esses últimos dispositivos estão no grupo da publicação. A vinculação prevista dura cinco anos, preservada a hipótese de cancelamento. Res. BCB 587/2026, art. 2º, § 3º em dianteRes. BCB 587/2026, art. 5º
• Nos recortes transcritos, registro de chave é rejeitado para usuário/conta associados a notificação aceita ou marcação criada pelo próprio participante, com motivo comunicado. Portabilidade e reivindicação não são solicitadas quando solicitante está associado a esses recortes. Quem aceita/cria notificação rejeita Pix do usuário pagador/recebedor e conta envolvidos, salvo devoluções. Esses dispositivos estão no grupo da publicação. Res. BCB 587/2026, art. 2º, § 3º em dianteRes. BCB 587/2026, art. 5º
• O ato revoga os dispositivos listados dos arts. 24/31 do Regulamento e art. 26 do anexo da Resolução 507. Não reproduz seu conteúdo completo; a leitura não infere a dispensa de todo requisito de participação. Res. BCB 587/2026, art. 4ºRes. BCB 587/2026, art. 5º

O que esta leitura não diz. Não há mensagem literal ou layout completo. Datas e recortes distintos precisam ser preservados; comunicação futura não se antecipa automaticamente.

As alterações futuras incluem consistência entre Pix e boleto e conta-salário; outras tratam de marcações DICT na publicação. O ato não fornece payloads ou algoritmo completo para implementar as condições.

• A captura inclui alterações futuras e calendário escalonado: cobrança híbrida, ajustes dos arts. 32/39/40/41-A e comunicação de marcação do art. 78-HB, parágrafo único, em 1º de fevereiro de 2027; conta-salário e art. 11-S em 1º de julho de 2027; demais dispositivos na publicação. Não apresente todas as alterações como vigentes hoje. Res. BCB 587/2026, art. 5º
• Para julho de 2027, o texto admite iniciação exclusiva de Pix Automático a partir de conta-salário. Recebimentos Pix ficam vedados, exceto STN ou devoluções. As jornadas c/d de autorização remetidas não se aplicam à conta-salário; os fluxos completos dessas jornadas não estão reproduzidos. Res. BCB 587/2026, art. 2ºRes. BCB 587/2026, art. 5º
• Para fevereiro de 2027, cobrança híbrida é facultativa ao PSP recebedor, apenas Cobrança com vencimento e boleto comum ou dinâmico sem vínculo a ativo financeiro registrado/escriturado/depositado nos sistemas indicados. PSP recebedor deve ser a mesma instituição emissora do boleto e assegurar informações consistentes para prevenir pagamento indevido ou duplicado. Res. BCB 587/2026, art. 2ºRes. BCB 587/2026, art. 5º
• Na cobrança híbrida futura, pagamento por boleto ou vinculação do boleto dinâmico a ativo financeiro exige cancelar o Pix Cobrança. Se Pix for pago após vínculo do dinâmico por falha desse cancelamento, PSP recebedor garante totalidade ao beneficiário do boleto com recursos próprios. Pagamento híbrido por Pix remete procedimentos de ambos PSPs aos manuais de Fluxos e UX. Res. BCB 587/2026, art. 2ºRes. BCB 587/2026, art. 5º
• Para fevereiro de 2027, Pix Cobrança híbrido liquidado depois de obrigação já paga por boleto exige PSP recebedor devolver total ao pagador com recursos próprios em até vinte e quatro horas da liquidação. Essa hipótese é diferente de destinar recursos ao beneficiário do boleto dinâmico vinculado. Res. BCB 587/2026, art. 2º, § 3º em dianteRes. BCB 587/2026, art. 2ºRes. BCB 587/2026, art. 5º
• A alteração de QR estático de Cobrança manda disponibilizar recebimentos imediatos. Ela está no grupo de demais dispositivos com vigência na publicação, segundo o calendário do ato; não significa que cobrança híbrida futura passe a ser produto imediato. Res. BCB 587/2026, art. 2ºRes. BCB 587/2026, art. 5º
• Na perda de participação, o texto altera hipóteses e prazos, incluindo ficar sem liquidante SPI ativo por mais de noventa dias corridos e desligamento imediato nos casos enumerados. Se o responsável perde participação, contratante tem noventa dias do desligamento efetivo para finalizar a troca perante BC. Caputs e hipóteses não transcritos exigem consulta completa; essas alterações ficam no grupo da publicação. Res. BCB 587/2026, art. 2ºRes. BCB 587/2026, art. 2º (continuação)Res. BCB 587/2026, art. 5º
• Liquidação extrajudicial suspende imediatamente; liquidante pode requerer saída ordenada até trinta dias da decretação e, sem pedido tempestivo, há desligamento. Durante saída ordenada, BC pode vedar receber Pix e permitir somente iniciar. Exclusão por decisão definitiva leva a desligamento imediato após comunicação; comprovação das medidas remetidas deve ser apresentada ao BC quando solicitada. O calendário atribui a esses dispositivos vigência na publicação. Res. BCB 587/2026, art. 2º (continuação)Res. BCB 587/2026, art. 3ºRes. BCB 587/2026, art. 5º
• Para fevereiro de 2027, o texto prevê comunicar incidente com dados pessoais em banco de dados relacionado a componente ou infraestrutura do Pix aos titulares PF de contas providas pelo participante, mesmo sem responsabilidade do provedor ou risco/dano relevante, nos termos de documento específico; mecanismos contra instruções indevidas e ofertas excessivas de autorização Automático; e divulgação clara/acessível do MED focada no público vulnerável em publicidade e atendimento. Res. BCB 587/2026, art. 2º (continuação)Res. BCB 587/2026, art. 5º
• Nos novos incisos do art. 39, o texto futuro lista agente não habilitado, inconsistência no Automático ressalvada iniciação por serviço, e cobrança híbrida paga por boleto ou boleto dinâmico vinculado. O caput do artigo não está reproduzido nesta alteração; não reconstrua sozinho seu ator ou rito. Res. BCB 587/2026, art. 2º (continuação)Res. BCB 587/2026, art. 5º
• O participante pode criar no DICT notificação de fundada suspeita de fraude transacional para CPF/CNPJ de cliente envolvido em Pix específico. Quem aceita notificação ou cria essa marcação é responsável por ela; vínculo à chave depende de informação disponível. No calendário do ato, esses dispositivos e rejeição de registro/portabilidade/reivindicação nos recortes indicados ficam no grupo da publicação. Res. BCB 587/2026, art. 2º, § 3º em dianteRes. BCB 587/2026, art. 5º
• Para fevereiro de 2027, quem criar marcação deve comunicar data, possibilidade de revisão e canal para esclarecimento/pedido. O participante responsável assegura pedido de cancelamento, decide em até sete dias do recebimento, cancela se não subsistir fundamento e guarda razões da decisão; esses últimos dispositivos estão no grupo da publicação. A vinculação prevista dura cinco anos, preservada a hipótese de cancelamento. Res. BCB 587/2026, art. 2º, § 3º em dianteRes. BCB 587/2026, art. 5º
• Nos recortes transcritos, registro de chave é rejeitado para usuário/conta associados a notificação aceita ou marcação criada pelo próprio participante, com motivo comunicado. Portabilidade e reivindicação não são solicitadas quando solicitante está associado a esses recortes. Quem aceita/cria notificação rejeita Pix do usuário pagador/recebedor e conta envolvidos, salvo devoluções. Esses dispositivos estão no grupo da publicação. Res. BCB 587/2026, art. 2º, § 3º em dianteRes. BCB 587/2026, art. 5º
• O ato revoga os dispositivos listados dos arts. 24/31 do Regulamento e art. 26 do anexo da Resolução 507. Não reproduz seu conteúdo completo; a leitura não infere a dispensa de todo requisito de participação. Res. BCB 587/2026, art. 4ºRes. BCB 587/2026, art. 5º

O que esta leitura não diz. Não há endpoint, código ou payload completo. Consulte Catálogo e manuais na versão aplicável; caputs omitidos não permitem reconstruir um rito técnico inteiro.

Cobrança híbrida futura é facultativa e restrita a vencimento; conta-salário futura admite somente iniciação de Automático. Consistência, cancelamento e consequências de duplicidade exigem preservar o calendário e o tipo de evento.

• A captura inclui alterações futuras e calendário escalonado: cobrança híbrida, ajustes dos arts. 32/39/40/41-A e comunicação de marcação do art. 78-HB, parágrafo único, em 1º de fevereiro de 2027; conta-salário e art. 11-S em 1º de julho de 2027; demais dispositivos na publicação. Não apresente todas as alterações como vigentes hoje. Res. BCB 587/2026, art. 5º
• Para julho de 2027, o texto admite iniciação exclusiva de Pix Automático a partir de conta-salário. Recebimentos Pix ficam vedados, exceto STN ou devoluções. As jornadas c/d de autorização remetidas não se aplicam à conta-salário; os fluxos completos dessas jornadas não estão reproduzidos. Res. BCB 587/2026, art. 2ºRes. BCB 587/2026, art. 5º
• Para fevereiro de 2027, cobrança híbrida é facultativa ao PSP recebedor, apenas Cobrança com vencimento e boleto comum ou dinâmico sem vínculo a ativo financeiro registrado/escriturado/depositado nos sistemas indicados. PSP recebedor deve ser a mesma instituição emissora do boleto e assegurar informações consistentes para prevenir pagamento indevido ou duplicado. Res. BCB 587/2026, art. 2ºRes. BCB 587/2026, art. 5º
• Na cobrança híbrida futura, pagamento por boleto ou vinculação do boleto dinâmico a ativo financeiro exige cancelar o Pix Cobrança. Se Pix for pago após vínculo do dinâmico por falha desse cancelamento, PSP recebedor garante totalidade ao beneficiário do boleto com recursos próprios. Pagamento híbrido por Pix remete procedimentos de ambos PSPs aos manuais de Fluxos e UX. Res. BCB 587/2026, art. 2ºRes. BCB 587/2026, art. 5º
• Para fevereiro de 2027, Pix Cobrança híbrido liquidado depois de obrigação já paga por boleto exige PSP recebedor devolver total ao pagador com recursos próprios em até vinte e quatro horas da liquidação. Essa hipótese é diferente de destinar recursos ao beneficiário do boleto dinâmico vinculado. Res. BCB 587/2026, art. 2º, § 3º em dianteRes. BCB 587/2026, art. 2ºRes. BCB 587/2026, art. 5º
• A alteração de QR estático de Cobrança manda disponibilizar recebimentos imediatos. Ela está no grupo de demais dispositivos com vigência na publicação, segundo o calendário do ato; não significa que cobrança híbrida futura passe a ser produto imediato. Res. BCB 587/2026, art. 2ºRes. BCB 587/2026, art. 5º
• Para fevereiro de 2027, o texto prevê comunicar incidente com dados pessoais em banco de dados relacionado a componente ou infraestrutura do Pix aos titulares PF de contas providas pelo participante, mesmo sem responsabilidade do provedor ou risco/dano relevante, nos termos de documento específico; mecanismos contra instruções indevidas e ofertas excessivas de autorização Automático; e divulgação clara/acessível do MED focada no público vulnerável em publicidade e atendimento. Res. BCB 587/2026, art. 2º (continuação)Res. BCB 587/2026, art. 5º
• O participante pode criar no DICT notificação de fundada suspeita de fraude transacional para CPF/CNPJ de cliente envolvido em Pix específico. Quem aceita notificação ou cria essa marcação é responsável por ela; vínculo à chave depende de informação disponível. No calendário do ato, esses dispositivos e rejeição de registro/portabilidade/reivindicação nos recortes indicados ficam no grupo da publicação. Res. BCB 587/2026, art. 2º, § 3º em dianteRes. BCB 587/2026, art. 5º
• Para fevereiro de 2027, quem criar marcação deve comunicar data, possibilidade de revisão e canal para esclarecimento/pedido. O participante responsável assegura pedido de cancelamento, decide em até sete dias do recebimento, cancela se não subsistir fundamento e guarda razões da decisão; esses últimos dispositivos estão no grupo da publicação. A vinculação prevista dura cinco anos, preservada a hipótese de cancelamento. Res. BCB 587/2026, art. 2º, § 3º em dianteRes. BCB 587/2026, art. 5º
• Nos recortes transcritos, registro de chave é rejeitado para usuário/conta associados a notificação aceita ou marcação criada pelo próprio participante, com motivo comunicado. Portabilidade e reivindicação não são solicitadas quando solicitante está associado a esses recortes. Quem aceita/cria notificação rejeita Pix do usuário pagador/recebedor e conta envolvidos, salvo devoluções. Esses dispositivos estão no grupo da publicação. Res. BCB 587/2026, art. 2º, § 3º em dianteRes. BCB 587/2026, art. 5º
• O ato revoga os dispositivos listados dos arts. 24/31 do Regulamento e art. 26 do anexo da Resolução 507. Não reproduz seu conteúdo completo; a leitura não infere a dispensa de todo requisito de participação. Res. BCB 587/2026, art. 4ºRes. BCB 587/2026, art. 5º

O que esta leitura não diz. Não há tela completa ou autorização para antecipar oferta. Consulte os manuais futuros e a versão vigente; cobrança híbrida não é todo Pix Cobrança.

A captura inclui alterações futuras e outras com vigência na publicação. Cobrança híbrida, conta-salário, marcações e recursos possuem recortes distintos, que não podem ser antecipados ou generalizados.

• A captura inclui alterações futuras e calendário escalonado: cobrança híbrida, ajustes dos arts. 32/39/40/41-A e comunicação de marcação do art. 78-HB, parágrafo único, em 1º de fevereiro de 2027; conta-salário e art. 11-S em 1º de julho de 2027; demais dispositivos na publicação. Não apresente todas as alterações como vigentes hoje. Res. BCB 587/2026, art. 5º
• Para julho de 2027, o texto admite iniciação exclusiva de Pix Automático a partir de conta-salário. Recebimentos Pix ficam vedados, exceto STN ou devoluções. As jornadas c/d de autorização remetidas não se aplicam à conta-salário; os fluxos completos dessas jornadas não estão reproduzidos. Res. BCB 587/2026, art. 2ºRes. BCB 587/2026, art. 5º
• Para fevereiro de 2027, cobrança híbrida é facultativa ao PSP recebedor, apenas Cobrança com vencimento e boleto comum ou dinâmico sem vínculo a ativo financeiro registrado/escriturado/depositado nos sistemas indicados. PSP recebedor deve ser a mesma instituição emissora do boleto e assegurar informações consistentes para prevenir pagamento indevido ou duplicado. Res. BCB 587/2026, art. 2ºRes. BCB 587/2026, art. 5º
• Na cobrança híbrida futura, pagamento por boleto ou vinculação do boleto dinâmico a ativo financeiro exige cancelar o Pix Cobrança. Se Pix for pago após vínculo do dinâmico por falha desse cancelamento, PSP recebedor garante totalidade ao beneficiário do boleto com recursos próprios. Pagamento híbrido por Pix remete procedimentos de ambos PSPs aos manuais de Fluxos e UX. Res. BCB 587/2026, art. 2ºRes. BCB 587/2026, art. 5º
• Para fevereiro de 2027, Pix Cobrança híbrido liquidado depois de obrigação já paga por boleto exige PSP recebedor devolver total ao pagador com recursos próprios em até vinte e quatro horas da liquidação. Essa hipótese é diferente de destinar recursos ao beneficiário do boleto dinâmico vinculado. Res. BCB 587/2026, art. 2º, § 3º em dianteRes. BCB 587/2026, art. 2ºRes. BCB 587/2026, art. 5º
• A alteração de QR estático de Cobrança manda disponibilizar recebimentos imediatos. Ela está no grupo de demais dispositivos com vigência na publicação, segundo o calendário do ato; não significa que cobrança híbrida futura passe a ser produto imediato. Res. BCB 587/2026, art. 2ºRes. BCB 587/2026, art. 5º
• No calendário de publicação, dispensa de participação obrigatória pode ser concedida pelo BC considerando clientes/modelo de negócio. Documentos da verificação remetida pelo participante responsável ficam à disposição do BC; falsidade, omissão ou discrepância na adesão pode levar à anulação da aprovação, sem automatismo. Res. BCB 587/2026, art. 1ºRes. BCB 587/2026, art. 2ºRes. BCB 587/2026, art. 5º
• Na perda de participação, o texto altera hipóteses e prazos, incluindo ficar sem liquidante SPI ativo por mais de noventa dias corridos e desligamento imediato nos casos enumerados. Se o responsável perde participação, contratante tem noventa dias do desligamento efetivo para finalizar a troca perante BC. Caputs e hipóteses não transcritos exigem consulta completa; essas alterações ficam no grupo da publicação. Res. BCB 587/2026, art. 2ºRes. BCB 587/2026, art. 2º (continuação)Res. BCB 587/2026, art. 5º
• Liquidação extrajudicial suspende imediatamente; liquidante pode requerer saída ordenada até trinta dias da decretação e, sem pedido tempestivo, há desligamento. Durante saída ordenada, BC pode vedar receber Pix e permitir somente iniciar. Exclusão por decisão definitiva leva a desligamento imediato após comunicação; comprovação das medidas remetidas deve ser apresentada ao BC quando solicitada. O calendário atribui a esses dispositivos vigência na publicação. Res. BCB 587/2026, art. 2º (continuação)Res. BCB 587/2026, art. 3ºRes. BCB 587/2026, art. 5º
• Para fevereiro de 2027, o texto prevê comunicar incidente com dados pessoais em banco de dados relacionado a componente ou infraestrutura do Pix aos titulares PF de contas providas pelo participante, mesmo sem responsabilidade do provedor ou risco/dano relevante, nos termos de documento específico; mecanismos contra instruções indevidas e ofertas excessivas de autorização Automático; e divulgação clara/acessível do MED focada no público vulnerável em publicidade e atendimento. Res. BCB 587/2026, art. 2º (continuação)Res. BCB 587/2026, art. 5º
• Nos novos incisos do art. 39, o texto futuro lista agente não habilitado, inconsistência no Automático ressalvada iniciação por serviço, e cobrança híbrida paga por boleto ou boleto dinâmico vinculado. O caput do artigo não está reproduzido nesta alteração; não reconstrua sozinho seu ator ou rito. Res. BCB 587/2026, art. 2º (continuação)Res. BCB 587/2026, art. 5º
• O participante pode criar no DICT notificação de fundada suspeita de fraude transacional para CPF/CNPJ de cliente envolvido em Pix específico. Quem aceita notificação ou cria essa marcação é responsável por ela; vínculo à chave depende de informação disponível. No calendário do ato, esses dispositivos e rejeição de registro/portabilidade/reivindicação nos recortes indicados ficam no grupo da publicação. Res. BCB 587/2026, art. 2º, § 3º em dianteRes. BCB 587/2026, art. 5º
• Para fevereiro de 2027, quem criar marcação deve comunicar data, possibilidade de revisão e canal para esclarecimento/pedido. O participante responsável assegura pedido de cancelamento, decide em até sete dias do recebimento, cancela se não subsistir fundamento e guarda razões da decisão; esses últimos dispositivos estão no grupo da publicação. A vinculação prevista dura cinco anos, preservada a hipótese de cancelamento. Res. BCB 587/2026, art. 2º, § 3º em dianteRes. BCB 587/2026, art. 5º
• Nos recortes transcritos, registro de chave é rejeitado para usuário/conta associados a notificação aceita ou marcação criada pelo próprio participante, com motivo comunicado. Portabilidade e reivindicação não são solicitadas quando solicitante está associado a esses recortes. Quem aceita/cria notificação rejeita Pix do usuário pagador/recebedor e conta envolvidos, salvo devoluções. Esses dispositivos estão no grupo da publicação. Res. BCB 587/2026, art. 2º, § 3º em dianteRes. BCB 587/2026, art. 5º
• Instituições podem recorrer de decisões do BC como instituidor em dez dias corridos da comunicação, salvo prazos específicos. Recurso vai à autoridade decisora e, sem reconsideração, à competente em única/última instância; efeito é devolutivo e suspensivo só quando atribuído por justo receio de prejuízo de difícil/incerta reparação. O calendário coloca esses dispositivos na publicação. Res. BCB 587/2026, art. 2º, § 3º em dianteRes. BCB 587/2026, art. 2º, § 3º em diante (2)Res. BCB 587/2026, art. 5º
• O ato revoga os dispositivos listados dos arts. 24/31 do Regulamento e art. 26 do anexo da Resolução 507. Não reproduz seu conteúdo completo; a leitura não infere a dispensa de todo requisito de participação. Res. BCB 587/2026, art. 4ºRes. BCB 587/2026, art. 5º

O que esta leitura não diz. Não há norma consolidada integral, caputs omitidos ou detalhes dos documentos específicos. Consulte a versão aplicável à data e os manuais; não antecipe vigências futuras.

A alteração distingue a instrução de pagamento gerada por participante iniciador ao tratar o campo idConciliacaoRecebedor da pacs.008. O ato revoga INs enumeradas e começa a vigorar na publicação. Não fixa prazo de atendimento ao cliente.

• Para instrução gerada por participante iniciador, o campo idConciliacaoRecebedor não deve ser preenchido na pacs.008 correspondente. IN BCB 743/2026, art. 1º
• A redação alterada do art. 6º remete aos §§ 1º, 2º, 4º, 5º e 6º do art. 5º da IN 513. IN BCB 743/2026, art. 1º
• São revogadas as INs BCB 43, 58, 71, 87, 372, 373, 422 e 633, enumeradas no art. 2º. IN BCB 743/2026, art. 2º
• A IN entra em vigor na data de sua publicação. IN BCB 743/2026, art. 3º

O que esta leitura não diz. O ato não explica um procedimento de conciliação manual, o tratamento de incidente ou uma comunicação obrigatória ao usuário. Consulte a IN 513 e os documentos técnicos; não crie SLA ou causa de falha com base apenas no campo mencionado.

A IN ajusta uma referência normativa de agendamento e uma condição de preenchimento da mensagem de pagamento. A regra citada para idConciliacaoRecebedor é técnica e não fornece um texto de interface. A entrada em vigor coincide com a publicação.

• A remissão do art. 6º, § 1º, inciso V, passa a listar as regras do art. 5º, §§ 1º, 2º, 4º, 5º e 6º. IN BCB 743/2026, art. 1º
• O campo idConciliacaoRecebedor da pacs.008 não deve ser preenchido quando a instrução tiver sido gerada por participante iniciador. IN BCB 743/2026, art. 1º
• São revogadas as INs BCB 43, 58, 71, 87, 372, 373, 422 e 633, enumeradas no art. 2º. IN BCB 743/2026, art. 2º
• A IN entra em vigor na data de sua publicação. IN BCB 743/2026, art. 3º

O que esta leitura não diz. O ato não determina retirar um dado de uma tela, nem apresenta mensagens obrigatórias, acessibilidade ou sequência visual. A regra de mensagem pacs.008 não autoriza inferir, sozinha, o conteúdo exibido ao pagador ou recebedor.

O ato define uma condição em que idConciliacaoRecebedor não deve ser preenchido na mensagem pacs.008. A condição depende de quem gerou a instrução de pagamento. A alteração também ajusta as remissões normativas do art. 6º da IN 513.

• O campo expressamente nomeado é idConciliacaoRecebedor da mensagem pacs.008 referente à respectiva ordem de pagamento. IN BCB 743/2026, art. 1º
• A vedação de preenchimento aplica-se quando a instrução foi gerada por participante que presta serviço de iniciação de transação de pagamento. IN BCB 743/2026, art. 1º
• O inciso V do art. 6º, § 1º, remete às regras do art. 5º, §§ 1º, 2º, 4º, 5º e 6º, que precisam ser conferidas no texto integral da IN 513. IN BCB 743/2026, art. 1º
• A IN entra em vigor na data de sua publicação. IN BCB 743/2026, art. 3º

O que esta leitura não diz. A IN não especifica valor substituto, preenchimento com string vazia, endpoint ou código de erro. Não trate a ausência de preenchimento como um formato técnico específico sem conferir o catálogo de mensagens.

A alteração ajusta uma remissão da IN 513 e diferencia a ordem de pagamento cuja instrução foi gerada por iniciador. Nessa condição, o campo de conciliação do recebedor da pacs.008 fica sem preenchimento. O ato também revoga INs anteriores enumeradas expressamente.

• O inciso V do art. 6º, § 1º, referencia o respeito às regras do art. 5º, §§ 1º, 2º, 4º, 5º e 6º. IN BCB 743/2026, art. 1º
• Se a instrução vier de participante que presta serviço de iniciação, o idConciliacaoRecebedor não deve ser preenchido na pacs.008 da respectiva ordem. IN BCB 743/2026, art. 1º
• São revogadas as INs BCB 43, 58, 71, 87, 372, 373, 422 e 633, enumeradas no art. 2º. IN BCB 743/2026, art. 2º
• A IN entra em vigor na data de sua publicação. IN BCB 743/2026, art. 3º

O que esta leitura não diz. Não há desenho de jornada nem descrição completa das regras de agendamento ou conciliação. A IN 513 e o catálogo técnico devem ser consultados antes de transformar a alteração em especificação de produto.

A IN altera a referência de regras no art. 6º da IN 513 e define uma condição de não preenchimento de campo da ordem de pagamento. Também revoga os atos enumerados em seu art. 2º. A vigência começa na data de publicação.

• A redação do art. 6º, § 1º, inciso V, passa a referir as regras do art. 5º, §§ 1º, 2º, 4º, 5º e 6º da IN 513. IN BCB 743/2026, art. 1º
• O § 18 do art. 7º determina que o campo idConciliacaoRecebedor da pacs.008 não deve ser preenchido quando a instrução tiver sido gerada por participante que presta serviço de iniciação de transação de pagamento. IN BCB 743/2026, art. 1º
• São revogadas as INs BCB 43, 58, 71, 87, 372, 373, 422 e 633, enumeradas no art. 2º. IN BCB 743/2026, art. 2º
• A IN entra em vigor na data de sua publicação. IN BCB 743/2026, art. 3º

O que esta leitura não diz. O ato não reproduz o caput e os demais incisos do art. 6º nem as regras remetidas do art. 5º. Consulte a IN 513 integral para o enquadramento; não deduza uma regra completa de agendamento apenas deste trecho.

A verificação de idoneidade do recebedor acontece antes da contratação e durante o contrato de Pix Automático. O envio da instrução deve ser impedido nas situações expressas pelo ato. As datas de início da vedação ligada ao Regulamento e das demais alterações são diferentes.

• A verificação do cliente recebedor continua durante a vigência do contrato de prestação do serviço, não se restringindo à contratação. IN BCB 634/2025, art. 1º
• Os critérios mínimos incluem informações cadastrais da empresa, indicadores de atividade e habitualidade transacional com o participante. IN BCB 634/2025, art. 1º
• O histórico de relacionamento, como abertura da conta e uso de outros meios de cobrança, integra a verificação quando o participante atua como provedor de conta transacional. IN BCB 634/2025, art. 1º
• Permissão não confirmada e enquadramento do recebedor no art. 89, § 2º, são as condições indicadas para não enviar a instrução de pagamento. IN BCB 634/2025, art. 1º
• A vedação de envio ligada ao art. 89, § 2º, começa em 16 de julho de 2025; as demais alterações começam em 16 de junho de 2025. IN BCB 634/2025, art. 2º

O que esta leitura não diz. Não são definidos SLA interno, periodicidade exata de revisão cadastral ou texto de atendimento ao recebedor. O ato também não descreve o procedimento para resolver o enquadramento do art. 89, § 2º; consulte o Regulamento.

O ato determina que a identificação do recebedor nos fluxos do Pix Automático use os dados do CNPJ mantido pela Receita Federal. Também estabelece situações em que a instrução de pagamento não deve ser enviada. Esses requisitos de negócio não vêm acompanhados de desenho de tela ou texto de mensagem.

• A regra de identificação alcança todos os fluxos relacionados ao Pix Automático, além das instruções de pagamento, e tem como fonte o CNPJ da Receita Federal. IN BCB 634/2025, art. 1º
• A permissão do pagador ao recebedor precisa estar confirmada para que a instrução possa ser enviada; a falta de confirmação impede o envio. IN BCB 634/2025, art. 1º
• O recebedor enquadrado na situação do art. 89, § 2º, do Regulamento também impede o envio da instrução. IN BCB 634/2025, art. 1º
• A vedação de envio ligada ao art. 89, § 2º, começa em 16 de julho de 2025; as demais alterações começam em 16 de junho de 2025. IN BCB 634/2025, art. 2º

O que esta leitura não diz. A IN não define conteúdo mínimo de telas, mensagem literal de erro ou jornada de confirmação de permissão. Para requisitos de tela, confira o Manual de Experiência do Usuário e a IN 513; soluções de UX não são obrigações deste ato.

O ato traz condições que impedem enviar a instrução de pagamento do Pix Automático e define a origem das informações de identificação do recebedor. A verificação de idoneidade inclui informações de segurança do DICT quando o participante tiver acesso. A IN não especifica endpoints ou um algoritmo de risco.

• A instrução não deve ser enviada quando a permissão do pagador ao recebedor não estiver confirmada. IN BCB 634/2025, art. 1º
• O envio também é vedado para recebedor enquadrado no art. 89, § 2º, do Regulamento; a situação referenciada deve ser conferida nesse dispositivo. IN BCB 634/2025, art. 1º
• Os dados do CNPJ mantido pela Receita Federal devem preencher a identificação do recebedor nas instruções e nos demais fluxos do Pix Automático. IN BCB 634/2025, art. 1º
• As informações de segurança armazenadas no DICT são consideradas na verificação de idoneidade nos casos em que o participante tenha acesso ao diretório. IN BCB 634/2025, art. 1º
• A vedação de envio ligada ao art. 89, § 2º, começa em 16 de julho de 2025; as demais alterações começam em 16 de junho de 2025. IN BCB 634/2025, art. 2º

O que esta leitura não diz. A IN não nomeia endpoints da Receita Federal ou do DICT, campos de mensagem, frequência de consultas ou fórmula de decisão de risco. A referência a essas fontes não autoriza inventar integração técnica.

A contratação do Pix Automático pelo recebedor envolve verificação de idoneidade antes e durante o contrato. A instrução de pagamento não pode ser enviada nas duas condições indicadas pelo ato. A identificação do recebedor nos fluxos usa os dados do CNPJ da Receita Federal.

• A verificação de idoneidade alcança a etapa anterior à contratação e também a vigência do contrato, considerando cadastro, indicadores de atividade e os demais critérios mínimos listados. IN BCB 634/2025, art. 1º
• O envio da instrução de pagamento é vedado se a permissão do pagador não estiver confirmada ou se o recebedor estiver na situação do art. 89, § 2º, do Regulamento. IN BCB 634/2025, art. 1º
• A identificação do recebedor deve usar dados do CNPJ da Receita Federal em todos os fluxos relacionados ao Pix Automático, além das instruções de pagamento. IN BCB 634/2025, art. 1º
• A compatibilidade entre a atividade econômica da empresa e o serviço oferecido para o Pix Automático é um dos indicadores mínimos de idoneidade. IN BCB 634/2025, art. 1º
• A vedação de envio ligada ao art. 89, § 2º, começa em 16 de julho de 2025; as demais alterações começam em 16 de junho de 2025. IN BCB 634/2025, art. 2º

O que esta leitura não diz. O ato não define telas de contratação, critérios de pontuação de risco nem resposta comercial ao recebedor. Essas escolhas não devem ser apresentadas como exigências desta IN.

A IN altera a IN 513 para disciplinar a verificação de idoneidade do recebedor e situações que impedem o envio da instrução de pagamento. A identificação do recebedor deve usar informações do CNPJ mantido pela Receita Federal. Há datas de início distintas para a vedação ligada ao Regulamento e para as demais alterações.

• A idoneidade deve ser verificada antes da contratação e durante a vigência do contrato, considerando no mínimo os critérios enumerados no art. 15-A. IN BCB 634/2025, art. 1º
• As informações de segurança do DICT integram os critérios quando o participante tiver acesso ao diretório; o histórico de relacionamento é considerado quando atuar como provedor de conta transacional. IN BCB 634/2025, art. 1º
• A vedação de envio ligada ao art. 89, § 2º, começa em 16 de julho de 2025; as demais alterações começam em 16 de junho de 2025. IN BCB 634/2025, art. 2º

O que esta leitura não diz. A IN não reproduz a situação prevista no art. 89, § 2º, nem estabelece penalidades específicas. Confira esse dispositivo no Regulamento e o conjunto consolidado da IN 513; não conclua aderência de uma instituição apenas por esta leitura.