INTRODUÇÃO

Conheça a API Pix

A API Pix foi desenvolvida pela Cielo como prestadora de serviços de pagamento, provedora de conta transacional e participante direto do Pix. Esta API segue os padrões definidos pelo Banco Central do Brasil no Regulamento do Pix e demais documentos relacionados.

Essa interface padronizada permite que aplicações automatizem a interação com os participantes do Pix, possibilitando uma experiência integrada e segura para o usuário final. As APIs de recebimento via Pix permitem ao cliente recebedor gerenciar integralmente seus pagamentos, desde a geração de QR Codes até a conciliação dos valores recebidos, abrangendo tanto transações por QR Code quanto transferências Pix.

Confira abaixo alguns dos maiores benefícios oferecidos por esta solução:

beneficios da API Pix

Modelos de negócio

A API Pix é destinada a clientes que utilizam soluções de captura como, por exemplo, TEF, Cielo Smart e E-commerce, e desejam realizar transações Pix por meio dessas plataformas.

Primeiros passos

Está iniciando agora a sua jornada de integração e não sabe por onde começar? Aqui, você encontra uma visão simplificada dos principais passos para integrar com a API Pix.

jornada de integracao do pix

1. Acesso à documentação: Consulte a documentação técnica da API Pix e explore o  Swagger, onde estão disponíveis os endpoints, métodos, parâmetros e exemplos de requisições e respostas.

2. Solicitação de credenciais Sandbox: A solicitação deve ser realizada por e-mail. Você vai precisar de Client ID e Client Secret (credenciais de autenticação OAuth2) e de uma Chave Pix transacional (tipo aleatória).

3. Homologação: Suporte na execução de testes e validações juntamente com apontamento de correções e melhorias.

4. Geração de certificado mTLS: Em produção, é obrigatório o uso de mTLS para: geração de cobranças, devoluções, consultas. No ambiente Sandbox, o mTLS não é exigido.

5. Recebimento de notificações: Esta etapa é opcional, porém altamente recomendada. Enquanto o polling realiza consultas periódicas para verificar atualizações de status, o webhook envia notificações automaticamente sempre que uma alteração ocorre. Você pode optar por utilizar apenas um dos métodos, mas a abordagem mais robusta e eficiente é combinar ambos

6. Habilitação do Pix: Habilite a funcionalidade Pix no Portal Cielo.

7. Credenciais e chaves de produção: Gere suas credenciais e chaves de produção.

8. Rollout: Com a integração concluída, é possível gerar e pagar QR Codes, realizar devoluções, fazer transações de Pix automático e testar notificações.

Ao longo desta documentação, todas estas etapas são descritas detalhadamente.

Glossário

Este glossário reúne os principais termos utilizados no ecossistema da API Pix. Ele foi criado para facilitar a compreensão de conceitos técnicos e operacionais, promovendo uma integração mais eficiente com nossas soluções. Consulte-o sempre que tiver dúvidas sobre siglas, nomenclaturas ou funcionalidades.

Termo Descrição
Chave Campo obrigatório que determina a chave Pix registrada junto ao Banco Central. Essa chave identifica o usuário recebedor e os dados da conta transacional à qual a cobrança está vinculada.
Client_ID Componente de acesso à API Pix que identifica um elemento de software cliente do usuário. Para acessar a API, é necessário utilizar o Client_ID e um segredo, ambos fornecidos pelo PSP do usuário durante o cadastramento. Um mesmo usuário pode ter mais de um Client_ID, caso possua múltiplos elementos de software cliente.
Escopos Definem as autorizações associadas a cada serviço da API. Cada Client_ID possui acesso a um ou mais escopos, determinando quais serviços podem ser acessados.
Facilitador de Serviço de Saque (FSS) Participante do Pix que atua como provedor de conta transacional e é autorizado pelo Banco Central do Brasil a oferecer o serviço de saque, diretamente ou por meio de agente de saque, mediante contrato específico.
Payload JSON Conteúdo retornado a partir da chamada à URL, obtido por meio da leitura do QR Code dinâmico, que representa uma cobrança.
PSP Pagador Instituição do Pix na qual o usuário pagador mantém sua conta transacional. Atua como ponte técnica e regulatória entre o usuário pagador e o sistema de pagamentos.
PSP Recebedor Instituição do Pix na qual o usuário recebedor mantém sua conta transacional. Para oferecer integração automatizada com o arranjo Pix, deve seguir as especificações da API Pix definidas pelo Banco Central.
TransactionId (txid) Identificador único da transação, gerado pelo usuário recebedor e enviado ao PSP recebedor na criação da cobrança. Utilizado para conciliação de pagamentos e deve ser único por usuário recebedor (CPF/CNPJ).
Usuário pagador Pessoa que efetua o pagamento de uma cobrança via Pix, tendo sua conta transacional debitada.
Usuário recebedor Pessoa que recebe cobranças via Pix e pode utilizar a API Pix para automatizar a geração de cobranças e a conciliação de pagamentos.

Suporte técnico

Nosso objetivo é apoiar você em cada etapa. Caso tenha dúvidas, envie um e-mail para apipix.suporte@cielo.com.br.

Seja um parceiro

A Aliança Cielo objetiva construir parcerias estratégicas com empresas de tecnologia, ampliando nossa atuação no mercado com soluções integradas e completas. A proposta é democratizar o acesso à inovação, conectando nossos serviços às soluções dos parceiros. A maioria das parcerias é formada por meio da integração entre os produtos da Cielo e as soluções dos parceiros. Também há troca de leads qualificados, criando oportunidades comerciais para ambos os lados.

Quem pode ser parceiro?

O programa é destinado a empresas de tecnologia de todos os portes que atuam nos segmentos do varejo físico e do e-commerce. Isso inclui Software Houses, TEF Houses, desenvolvedores de soluções integradas com maquininhas e aplicativos para Cielo Smart, além de plataformas de e-commerce, orquestradores de pagamento, agências implementadoras e criadores de marketplaces.

etapas para se tornar parceiro

Ficou com dúvidas? Envie um e-mail para parcerias@cielo.com.br ou acesse o site com mais informações sobre o programa de parcerias e seus benefícios.

VISÃO GERAL TÉCNICA

Funcionalidades

A API Pix disponibiliza um conjunto de recursos projetados para otimizar a jornada de pagamento, ampliar a automação operacional e proporcionar maior controle sobre as transações financeiras. Entre os principais destaques estão:

Cobrança

Conciliação

Devolução

Pix automático

Arquitetura

Na implementação da API, a Cielo é responsável por gerar o QR Code para pagamentos via Pix, garantindo conformidade com os requisitos de segurança do Banco Central. Durante a transação, são identificadas informações importantes, como:

Fluxo da API Pix

A API Pix é o elemento do arranjo responsável por viabilizar que usuários pagadores ou recebedores automatizem a comunicação com seus respectivos Prestadores de Serviços de Pagamento (PSPs). Por meio dessa interface, é possível realizar ou receber transações Pix de maneira integrada, segura e sem necessidade de interações manuais.

O foco da API está na automação do fluxo do usuário recebedor, permitindo que ele:

fluxo da API Pix

Primeira etapa: Cobrança com geração do QR Code

  1. Uma venda é iniciada no ponto de venda (PDV);
  2. O software de automação comercial recebe essa informação e envia os dados para ERP, Sefaz (quando houver nota fiscal) e para a impressora fiscal quando necessário;
  3. Em seguida, o software de automação solicita ao módulo TEF/Gateway que gere uma cobrança Pix;
  4. O TEF ou Gateway se conecta à API Pix do PSP recebedor;
  5. A API Pix gera um QR Code dinâmico contendo as informações necessárias;
  6. O QR Code gerado é exibido no PDV para o cliente.

Segunda etapa: Pagamento pelo usuário pagador

  1. O pagador lê o QR Code com o app do banco ou carteira digital;
  2. O app envia a ordem de pagamento ao PSP pagador (banco do cliente);
  3. O PSP pagador envia o pagamento ao PSP recebedor, usando a infraestrutura do Banco Central.

Terceira etapa: Confirmação do pagamento e retorno ao comércio

  1. O PSP recebedor recebe o pagamento e atualiza o status da cobrança.
  2. A API Pix comunica ao Gateway/TEF que a cobrança foi liquidada. Isso ocorre por consulta ativa ou por notificação (webhook), dependendo da integração.
  3. O TEF/Gateway informa o SW de automação comercial que o pagamento foi confirmado.
  4. O PDV então libera a venda, finaliza o pedido, registra no ERP, emite nota fiscal pela Sefaz e/ou dispara outros processos automáticos internos.

Requisitos de segurança

Para garantir a conformidade e a proteção das informações, devem ser adotadas as seguintes medidas:

Comunicação e autenticação

A Cielo utiliza seu próprio Resource Server, que implementa o OAuth 2.0 (RFC 6749) com TLS mútuo (mTLS – RFC 8705), conforme regulamentações do Banco Central. Assim, o processo de comunicação e autenticação deve seguir os seguintes critérios:

Confidencialidade e integridade

Habilitando o Pix

Para que seja possível efetivar transações Pix, é necessário habilitar este tipo de pagamento. Para realizar essa ação, siga as instruções abaixo.

1. Entre no site Cielo com seu login e senha.

2. Clique em Meu cadastro.

Meu cadastro

3. Clique em Autorizações e selecione a opção Pix.

Autorizações Pix

4. Clique em Iniciar habilitação.

Iniciar habilitação

5. Na opção Habilitação simplificada, clique em Selecionar.

Iniciar habilitação

6. Marque a caixa de aceite , e clique em Enviar solicitação.

Iniciar habilitação

Após essa habilitação via site Cielo, o estabelecimento estará apto a trabalhar com a modalidade Pix!

RECEBIMENTOS PIX

Com o Pix na Cielo, todo cliente tem uma conta de pagamento gratuita e pode optar como deseja receber as suas vendas: pela Transferência automática ou pela Conta Cielo.

Modalidades de recebimento

Caso escolha transferência automática, há duas opções:

Ao optar pela Conta Cielo, suas vendas são direcionadas para essa conta, permitindo que você utilize todas as funcionalidades do Pix diretamente pelo App Cielo Gestão. O saldo das vendas realizadas via Pix pode ser usado para fazer transferências e pagamentos por Pix. Nessa modalidade, o valor das vendas não é transferido automaticamente para um domicílio bancário escolhido pelo cliente.

Como alterar a modalidade de recebimento Pix?

A modalidade de recebimento Pix pode ser alterada via site Cielo ou via app Cielo Gestão.

Antes de aprender como alterar a modalidade de recebimento, confira as regras para alteração:

regras pra alterar modalidade de recebimento

Aderindo a transferência programada

Via app Cielo Gestão

Siga o passo-a-passo abaixo para alterar a modalidade de recebimento para transferência programada via app Cielo Gestão:

1. Na área logada do Pix no app Cielo Gestão, selecione a opção Recebimentos Pix.

2. Clique em Transferência programada.

4. Clique em Configurar.

5. Selecione o horário da transferência.

6. Marque o opt-in e clique em Ativar modalidade.

7. Seu token de segurança será validado.

Pronto! Seu modelo de recebimento foi alterado.

fluxo de transferência programada no app

Via site Cielo

Siga o passo-a-passo abaixo para alterar a modalidade de recebimento para transferência programada via site Cielo:

1. Na área logada do site Cielo, no menu superior clique em Pix > Configurações.

2. Clique em Recebimentos.

3. Selecione a opção Transferência programada.

fluxo de transferência programada no site

4. Selecione o horário da transferência.

5. Marque o opt-in e clique em Ativar.

6. Para prosseguir, insira o token de segurança Cielo Gestão e clique em Verificar.

ativando transferência programada no site

Pronto. Seu modelo de recebimento foi alterado!

sucesso na alteração da transferência programada

Aderindo a transferência por venda

Via app Cielo Gestão

Siga o passo-a-passo abaixo para alterar a modalidade de recebimento para transferência por venda via app Cielo Gestão:

1. Na área logada do Pix no app Cielo Gestão, selecione a opção Recebimentos Pix.

2. Clique em Transferência por venda.

3. Marque o opt-in e clique em Ativar modalidade.

4. Seu token de segurança será validado.

Pronto! Seu modelo de recebimento foi alterado.

fluxo de transferência por venda no app

Via site Cielo

Siga o passo-a-passo abaixo para alterar a modalidade de recebimento para transferência por venda via site Cielo:

1. Na área logada do site Cielo, no menu superior clique em Pix > Configurações.

2. Clique em Recebimentos.

3. Selecione a opção Transferência por venda.

fluxo de transferência por venda no site

4. Marque o opt-in e clique em Ativar.

5. Para prosseguir, insira o token de segurança Cielo Gestão e clique em Verificar.

ativando transferência por venda no site

Pronto. Seu modelo de recebimento foi alterado!

sucesso transferência por venda no site

Aderindo a Conta Cielo

A adesão a Conta Cielo pode acontecer somente via app.

Siga o passo-a-passo abaixo para alterar a modalidade de recebimento para transferência por venda:

1. Na área logada do Pix no app Cielo Gestão, selecione a opção Recebimentos Pix.

2. Clique em Conta Cielo.

3. Marque o opt-in e clique em Ativar modalidade.

4. Seu token de segurança será validado.

Pronto! Seu modelo de recebimento foi alterado.

fluxo Conta Cielo app

INTEGRAÇÃO COM A API

Aqui, você encontra todas as informações necessárias sobre endpoints e recursos disponíveis na API Pix.

Para utilizar a API PIX, as requisições devem ser executadas utilizando as respectivas credenciais dos ambientes de Homologação e Produção.

Ambientes


Ambiente Base da URL
Sandbox https://api2.cielo.com.br/sandbox/cielo-pix/v1
Produção https://api-mtls.cielo.com.br/cielo-pix/v1

Todas as chamadas devem ser executadas utilizando as respectivas credenciais dos ambientes de Sandbox e Produção.

Arquitetura da API

A API Pix está detalhada no formato OpenAPI 3.077 e o formato de dados utilizados é o JSON.

A automação do usuário recebedor interage com a API utilizando web services baseados em REST sobre HTTPS.

O modelo empregado na integração das APIs é simples. Para executar uma operação:

1. Combine a base da URL do ambiente com o endpoint da operação desejada. Ex.: https://api-mtls.cielo.com.br/cielo-pix/v1/

2. Envie a requisição para a URL utilizando o método HTTP adequado à operação.

Método HTTP Descrição
GET Retorna recursos já existentes, ex.: consulta de cobrança.
POST Cria um novo recurso, ex.: criação de cobrança.
PUT Atualiza um recurso existente, ex.: realizar devolução.
DELETE Exclui um recurso, ex.: exclui um webhook.
PATCH Revisa um recurso, ex.: revisa uma cobrança.

Cada envio de requisição irá retornar um código de Status HTTP, indicando se ela foi realizada com sucesso ou não.

Código de status HTTP

Os códigos do padrão HTTP, retornados como resposta à requisição feita para a API, informam se as informações enviadas à API estão obtendo sucesso ao atingir nossos endpoints.

Código Status Descrição Exemplo de situações em que pode ocorrer
200 OK Operação realizada com sucesso Cobrança recorrente revisada
Dados da cobrança recorrente
Lista de cobranças recorrentes
Lista de cobranças imediatas
Lista dos Pix recebidos de acordo com o critério de busca
Lista dos locations cadastrados de acordo com o critério de busca
Dados da location do Payload
Entidade representada pelo recurso informado desvinculada com sucesso
Dados da recorrência
Recorrência revisada
Dados da solicitação da recorrência
Cobrança imediata revisada. A revisão deve ser incrementada em 1.
Dados da cobrança imediata.
Dados da devolução
Webhook para notificações acerca de Pix recebidos associados a um txid.
Dados do webhook.
Webhook para notificações.
201 Created A solicitação foi realizada, resultando na criação de um novo recurso Access Token Criado
Cobrança imediata recorrente
Cobrança recorrente criada
Cobrança recorrente
Dados da location do Payload
Recorrência criada
Dados da solicitação da recorrência
Solicitação de recorrência atualizada
Cobrança imediata criada
Dados da devolução
204 Empty Operação realizada com sucesso, mas nenhuma resposta foi retornada Webhook para notificações foi cancelado.
400 Bad Request A requisição possui parâmetro(s) inválido(s) Requisição com formato inválido
401 Unauthorized O token de acesso não foi informado ou não possui acesso às APIs Erro credencial inválida
403 Forbidden O acesso ao rescurso foi negado Requisição de participante autenticado que viola alguma regra de autorização
404 Not Found O recurso informado no request não foi encontrado Recurso solicitado não foi encontrado
503 Service unavailable Serviço não está disponível no momento. Serviço solicitado pode estar em manutenção ou fora da janela de funcionamento Serviço não está disponível no momento. Serviço solicitado pode estar em manutenção ou fora da janela de funcionamento.

Credenciais e autenticação

Abaixo, você aprende como solicitar credenciais Sandbox e, em seguida, credenciais Produção.

Solicitação de credenciais Sandbox

Para obter acesso ao ambiente Sandbox, solicite à Cielo, por meio do e‑mail apipix.suporte@cielo.com.br, as seguintes credenciais:

No ambiente Sandbox, após gerar o QR Code, envie-o por e-mail apipix.suporte@cielo.com.br para que a Cielo efetue o pagamento. Configure um tempo de expiração maior para o QR Code.

Solicitação de credenciais Produção

Para transacionar em nome dos clientes da Cielo, os parceiros devem ter as seguintes chaves do cliente:

Siga o passo-a-passo abaixo para gerar credenciais de Produção:

1. No site da Cielo, acesse o portal Minha Conta e clique em Meu Cadastro.

2. Na aba Autorizações, clique em Pix.

3. Selecione a opção Novo acesso.

IMG_PIX_02

4. Clique em Criar credencial.

IMG_PIX_03

5. Selecione o parceiro.

IMG_PIX_04

6. Clique em Criar.

IMG_PIX_05

7. Aceite os termos de uso e marque a caixa.

IMG_PIX_06

8. Clique no botão Autenticar e continuar.

IMG_PIX_07

9 Insira o token de segurança.

A ativação do token deve ser realizada através do Cielo Gestão.

IMG_PIX_08

Pronto! Credencial criada com sucesso.

IMG_PIX_09

Após essa etapa, o cliente poderá copiar o Cliente ID, Client Secret e Chave Transacional para realizar onboarding no portal parceiro.

IMG_PIX_10

Geração de certificado mTLS

Com mTLS, seu sistema precisa provar sua identidade usando um certificado cliente. Sem esse certificado, a API Pix não permite conexões. O mTLS adiciona uma camada extra de criptografia e validação. Isso evita interceptação de dados e acesso indevido à API.

Nesse contexto, o arquivo .csr (Certificate Signing Request) é o pedido de certificado contendo sua chave pública e os dados da sua empresa. Você gera o .csr localmente, envia para a Cielo e nós devolvemos um certificado assinado que sua aplicação deve usar.

Para obter o certificado assinado pela Cielo, gere um arquivo .csr com o seguinte comando no terminal (CMD):

openssl req -new -newkey rsa:2048 -nodes -keyout chave_privada.key -out certificado.csr

Você deve passar as seguintes informações:

Certificado do tipo MTLS
E-mail: sustentacaopix@cielo.com.br
Common Name (CN) = api-insiraaquionomedoparceiro-mtls
Organizational Unit (OU) = PIX
Organization (O) = CIELO S.A.
Locality (L) = Barueri
State (ST) = SP
Country (C)C= BR

Envie o .csr para: apipix.suporte@cielo.com.br.

Ao preencher os campos obrigatórios listados acima, lembre-se:

Entidades

As entidades representam os principais objetos de dados utilizados na comunicação com a API Pix. Elas definem a estrutura das informações que são enviadas e recebidas durante as operações de pedidos e pagamentos.

Cobrança (/cob)

Representa cada uma das cobranças geradas por meio da API Pix, a fim de permitir que o usuário pagador efetue um pagamento identificado para o usuário recebedor. A cobrança é caracterizada por um conjunto de informações que são utilizadas para que o usuário pagador execute um pagamento por meio do Pix, geralmente, em função de acordo comercial entre o usuário pagador e o usuário recebedor, sem se confundir com o pagamento Pix em si. O modelo de cobrança utilizado é para pagamento imediato.

Estados da cobrança:

Pix (/pix) Representa um pagamento recebido por meio do arranjo de pagamentos Pix.

Devolução (devolução)

Representa uma solicitação de devolução de um Pix realizado, cujos fundos já se encontrem disponíveis na conta transacional do usuário recebedor.

Estados da devolução:

Cardinalidade entre as entidades

Ciclo de vida do TransactionID (txid)

Há duas situações de uso para o campo TransactionId (txid), que envolvem regras distintas para seu preenchimento.

As cobranças para pagamentos imediatos ou com vencimento criadas por meio da API Pix são identificadas unicamente por meio de um txid. O txid pode ser enviado pelo usuário recebedor quando da geração da cobrança, e não poderá se repetir entre cobranças distintas, a fim de garantir a correta conciliação dos pagamentos. Alternativamente, no caso de cobranças para pagamento imediato, é possível que o usuário recebedor delegue a geração do txid para o seu PSP.

Uma vez que seja solicitada a criação de uma cobrança por meio da API Pix, o PSP Recebedor deve assegurar que não exista repetição do txid para o mesmo usuário recebedor, seja ele enviado pelo usuário ou gerado pelo próprio PSP. Assim, o conjunto CNPJ ou CPF e txid deve ser único para um dado PSP.

O txid deve ter, no mínimo, 26 caracteres e, no máximo, 35 caracteres de tamanho. Os caracteres aceitos neste contexto são: A-Z, a-z, 0-9.

Funcionalidades e endpoints

As funcionalidades da API Pix, na versão atual, estão definidas em grupos:

I – Gerenciamento de Cobranças com pagamento imediato (Cob), que trata do ciclo de vida da entidade Cobrança:

Criação e atualização de cobrança PUT/cob/{txid}
Criação de uma cobrança sem passar txid POST/cob
Consulta de uma cobrança GET/cob/{txid}
Consulta de lista de cobranças GET/cob
Alteração de uma cobrança PATCH/cob/{txid}

II – Gerenciamento de Pix Recebidos (Pix), que trata do ciclo de vida das entidades Pix e Devolução:

Solicitação de devolução PUT/pix/{e2eid}/devolucao/{id}
Consulta de devolução GET/pix/{e2eid}/devolucao/{id}

CASOS DE USO

O objetivo dessa seção é trazer exemplos de como a API Pix pode ser utilizada na automação das interações entre usuários recebedores e seus respectivos PSPs em transações associadas ao Pix. Esses casos de uso NÃO pretendem esgotar as formas de utilização ou as funções disponibilizadas pela API Pix.

Pagamento imediato (no ato da compra) com QR Code Dinâmico

Aplicação: Comerciantes com volumes de vendas médios ou altos. Comércios online.

1. O usuário pagador, ao realizar a compra, informa que deseja pagar com Pix;

2. O software de automação utilizado pelo usuário recebedor acessa a API Pix para criação de uma cobrança e, com os dados recebidos como resposta, gera um QR Code Dinâmico, que é apresentado em um dispositivo de exibição qualquer:

Serviço invocado: PUT /cob/{txid}  Devem ser informados todos os dados necessários para criação do payload da cobrança, conforme especificação detalhada. Alternativamente, se o usuário recebedor não quiser identificar a cobrança imediata com seu próprio número {txid}, pode-se optar por utilizar o método POST /cob.

3. O usuário pagador lê, a seguir, o QR Code com o App do seu PSP e efetua o pagamento;

4. O usuário recebedor, de forma automatizada, por meio de nova consulta à API Pix, verifica se o pagamento foi realizado: Serviço invocado: GET /cob/{txid};

5. O usuário recebedor libera os produtos para o usuário pagador ou, no caso das compras online, confirma o recebimento do pagamento. Alternativamente, o passo 4 pode ser realizado com o uso de webhooks configurados no serviço correspondente. Nesse caso, o usuário recebedor seria informado pelo PSP Recebedor do crédito de um Pix associado a um txid na sua conta transacional.

Efetuar uma devolução

Aplicação: várias (devolução de produto, erro na cobrança, indisponibilidade do produto em estoque etc.) Premissa: Quando comprador e vendedor estiverem de acordo, será possível realizar o processo de devolução de uma transação Pix. Esse processo deverá ser iniciado pelo vendedor, ou seja, por quem recebeu a transação Pix. É importante se atentar aos prazos (de acordo com regulamento do Banco Central).

Importante: a devolução está disponível exclusivamente para clientes que possuem livre movimentação da conta e deverá ser realizada por meio do App Cielo Gestão ou, caso o cliente possua, pelos meios de captura via API Pix Banco Central (TEF, LIO Integrada ou E-commerce) ou ainda pela API 3.0 (E-commerce). Os clientes que optarem pela transferência automática não conseguirão efetivar a operação de devolução, devido falta de saldo em conta. Para ter acesso a efetivação, devem alterar o seu perfil para Livre Movimentação.

O usuário pagador solicita ao usuário recebedor, via algum meio de comunicação adequado, a devolução total ou parcial de um pagamento realizado;

O usuário recebedor concorda e identifica o pagamento original realizado pelo Pix. Há duas situações possíveis:

a. Quando o Pix está associado a uma Cobrança:

b. Quando o Pix não está associado a uma Cobrança. Nesse caso, é necessário saber, por outros meios, o EndToEndId do Pix original. Alternativamente, pode ser uma consulta ampla, trazendo a relação dos Pix recebidos.

O software de automação do usuário recebedor aciona a API Pix para realizar a devolução.

Jornada de adesão

Por jornada de adesão, entende-se o processo por meio do qual um usuário recebedor passa a utilizar os serviços de um PSP específico. Do ponto de vista da API Pix, tal processo deve incluir o fornecimento de credenciais de acesso (Client_IDs e senhas) e de certificados ao usuário recebedor.

No processo de adesão, o Client_ID disponibilizado pelo PSP deve possuir um conjunto de escopos que determinarão as funcionalidades às quais o Usuário Recebedor terá acesso. Os critérios de autorização nos escopos são de responsabilidade do PSP, que pode criar critérios diferenciados em função das características do Usuário Recebedor.

Dessa forma, é possível, por exemplo, que determinadas funcionalidades estejam acessíveis apenas por usuários que cumpram requisitos adicionais de segurança estipulados por cada PSP.

PIX AUTOMÁTICO

O Pix Automático é uma funcionalidade do Pix criada para facilitar pagamentos recorrentes, permitindo que o usuário pagador autorize previamente uma cobrança periódica feita por um estabelecimento. Após o consentimento, os débitos são realizados de forma automática na conta do pagador, sem necessidade de ações manuais a cada ciclo. Esse modelo torna o processo mais simples, rápido e seguro para ambos os lados, substituindo mecanismos tradicionais como débito automático, boletos ou renovações manuais de assinatura.

Benefícios

O Pix Automático permite criar contratos de cobrança que podem ser por tempo indeterminado ou com um período definido, informando data de início e de término. Também é necessário indicar a periodicidade combinada entre pagador e recebedor, que pode ser: semanal, quinzenal, mensal, trimestral ou anual.

Esta solução preenche lacunas atualmente existentes no mercado de meios de pagamento, ao oferecer maior simplicidade para a empresa recebedora. Com ela, o recebedor pode operar utilizando apenas um único provedor de Pix Automático, o que aumenta a eficiência, reduz a carga operacional e acelera processos. Além disso, aproveita a agilidade do Pix, que possui liquidação instantânea, garantindo a identificação e baixa do pagamento de forma imediata.

Casos de uso

O Pix Automático pode ser aplicado em diversos tipos de pagamentos recorrentes, especialmente aqueles que exigem praticidade e regularidade. Entre os principais casos, destacam‑se:

Fluxo de integração

Para utilização do Pix Automático na visão de usuário recebedor, por meio da API Pix, é necessário seguir os seguintes passos:

1. Criação da recorrência: É o ponto de partida para habilitar o recebimento de pagamentos pelo produto. Nessa etapa, é criado um contrato de recorrência que reúne as informações do recebedor, a descrição do débito recorrente, a periodicidade e a data de início das cobranças. Após a criação, é gerado um identificador para essa recorrência (idRec).

2. Autorização do pagador: Após a criação da recorrência, é necessário que o pagador realize o consentimento para autorizar pagamentos vinculados ao contrato estabelecido. e pagamento da recorrência criada.

3. Cobranças recorrentes: Com o aceite da solicitação de recorrência, o usuário recebedor pode enviar as cobranças correspondentes ao período vigente para agendamento e liquidação. Para isso, cada cobrança deve obedecer as condições definidas no contrato de recorrência, como valor, periodicidade e data de vencimento, além de ter um Txid único por transação.

4. Cancelamento: Pode acontecer a qualquer momento do ciclo de vida do produto e pode partir tanto do usuário recebedor como do pagador.

Endpoints da API Pix

Abaixo estão listados os principais endpoints da API Pix, com foco nas funcionalidades relacionadas ao Pix Automático. A tabela a seguir resume os métodos disponíveis, sua presença na documentação da Cielo e no Swagger do Bacen.

Endpoint Método Descrição
/rec (POST) POST Criação de recorrência
/rec/{recUrlAccessToken} GET Recupera payload da recorrência (JWS)
/cobr (POST) POST Criação de cobrança vinculada à recorrência
/cobr/{txid} GET Recupera payload da cobrança (JWS)
/pix/{e2eid}/devolucao/{id} GET Consulta devolução de Pix
/pix/{e2eid}/devolucao/{id} PUT Efetua devolução de Pix
/webhook POST Notificação de eventos via webhook
/rec (GET) GET Consulta lista de recorrências
/rec/{idRec} GET Consulta recorrência específica
/rec/{idRec} DELETE Cancelamento de recorrência

Jornadas

As jornadas do Pix são caminhos padronizados definidos pelo Banco Central que determinam como o usuário pagador concede autorização para pagamentos recorrentes no Pix Automático.

No Pix Automático na Cielo, estão previstas algumas jornadas:

Jornadas de adesão

Para realizar a adesão ao Pix Automático, o usuário recebedor deve primeiro criar a recorrência. Em seguida, ele solicita o aceite do usuário pagador, concluindo assim o processo de adesão ao meio de pagamento.

Jornada 1: Por meio de notificação

1.O usuário pagador seleciona o Pix Automático como forma de pagamento no ambiente da empresa recebedora e informa os dados de agência e conta.

2. Com essas informações, o recebedor solicita ao seu PSP a criação da recorrência e o envio da solicitação correspondente.

3. Quando o usuário recebedor cria a recorrência, a Cielo retorna um ID de recorrência (IdRec), que poderá ser utilizado pela empresa recebedora para consultar aquele contrato a qualquer momento.

4. É gerada uma solicitação de recorrência vinculada ao IdRec, que também possui um identificador único (IdSolicRec) para consulta. Essa solicitação permanece válida até a data de vencimento definida pelo recebedor.

Jornada 1

Jornada 2: Leitura de QRCode

1. O usuário pagador seleciona o Pix Automático como forma de pagamento, e a empresa recebedora exibe um QR Code contendo todas as informações da recorrência.

2. Ao ler esse QR Code no aplicativo do banco onde possui conta, o pagador é direcionado diretamente para a jornada de autorização dentro do próprio aplicativo bancário.

A solicitação de uma recorrência via QR Code é realizada por meio da rota de location da recorrência, utilizando um identificador específico destinado a esse fluxo de leitura por QR Code.

O processo de criação da recorrência permanece igual ao descrito na Jornada 1, adotando o mesmo padrão de identificadores, conforme demonstrado no fluxograma a seguir:

Jornada 2

Jornada 3: Pagamento imediato de Pix + autorização da recorrência

1. A empresa recebedora disponibiliza ao cliente um QR Code (ou código copia e cola) que reúne as informações necessárias para a autorização da recorrência e para o pagamento imediato da primeira cobrança.

2. O cliente concede a autorização ao mesmo tempo em que realiza o pagamento inicial via Pix.

3. Após o pagamento dessa primeira cobrança, a solicitação do Pix Automático é automaticamente aceita, e as próximas cobranças passam a ocorrer conforme os parâmetros definidos na recorrência.

Jornada 3

Jornada de cobrança: Agendamento

Para agendar uma cobrança no Pix Automático, a empresa recebedora deve enviar a solicitação de acordo com a periodicidade definida no contrato de recorrência. A solicitação de agendamento deve ser enviada entre 10 e 2 dias antes da data de vencimento, conforme regra estabelecida pelo Banco Central.

O cancelamento do agendamento pode ser realizado tanto pelo pagador quanto pelo recebedor, seguindo prazos específicos para cada parte:

A consulta de agendamentos e o cancelamento devem ser realizados por meio dos endpoints específicos desse serviço, permitindo que a empresa recebedora acesse o status dos agendamentos, seja de forma individual ou em lista.

Abaixo, apresentamos um exemplo com os campos obrigatórios para criação de cobrança recorrente.

Método Ambiente Endpoint
PUT Sandbox https://api2.cielo.com.br/sandbox/cielo-pix/v1/cobr/{txid}
PUT Produção https://api2.cielo.com.br/sandbox/cielo-pix/v1/cobr/{txid}

Requisição:

{ 
  "idRec": "RR1234567820240115abcdefghijk", 
  "infoAdicional": "Serviços de Streaming de Música e Filmes.", 
  "calendario": { 
    "dataDeVencimento": "2024-04-15" 
  }, 
  "valor": { 
    "original": "106.07" 
  }, 
  "ajusteDiaUtil": true, 
  "devedor": { 
    "cep": "89256-140", 
    "cidade": "Uberlândia", 
    "email": "sebastiao.tav@mail.com", 
    "logradouro": "Alameda Franco 1056", 
    "uf": "MG" 
  }, 
  "recebedor": { 
    "agencia": "9708", 
    "conta": "012682", 
    "tipoConta": "CORRENTE" 
  } 
} 

Como o cliente acessa os dados da sua conta?

Na chamada do endpoint CobR, o usuário recebedor deve informar agência e conta de pagamento da Cielo. Para encontrar essses dados, no Site Cielo, em ambiente logado, acesse a aba Pix e serão apresentados os dados da Conta de pagamento, conforme abaixo:

cliente acessando dados

Fluxos de webhook

A aplicação atua como um monitor ativo de todos os eventos relacionados ao Pix Automático, independentemente de terem sido iniciados pelo pagador ou pelo recebedor. Seu objetivo é notificar o usuário recebedor sobre cada etapa do fluxo do Pix Automático, garantindo visibilidade completa do processo.

A Cielo disponibiliza esse serviço tanto para as etapas da recorrência — incluindo todos os passos que compõem esse ciclo — quanto para a jornada de agendamento, cobrindo desde a criação do agendamento até a etapa de liquidação.

fluxowebhook

QR Code composto

Nas jornadas que utilizam QR Code, existem casos em que é empregado o QR Code composto, que oferece um conjunto mais amplo de funcionalidades em comparação ao QR Code estático e ao QR Code dinâmico. A principal diferença desse tipo de QR Code é a presença de uma URL adicional, inserida em um campo específico do payload. Essa URL contém as informações associadas às configurações de recorrência de pagamentos que o usuário recebedor disponibiliza ao usuário pagador.

Jornada Descrição
Jornada 2 QR Code apenas com location da recorrência
Jornada 3 QR Code de uma Cob + location da recorrência

AS periodicidades possíveis são:

Política de retentativa

Política Definição Endpoint
NÃO_PERMITE Não serão autorizadas retentativas após o vencimento • /rec (POST)
PERMITE_3R_7D Serão permitidas até 3 tentativas após o vencimento dentro de 7 dias corridos • /rec (POST)

Status de recorrência

Status Definição Endpoint
CRIADA Recorrência criada pelo usuário recebedor • /cobr (GET)
ENVIADA Recorrência enviada ao PSP do pagador • /cobr (GET)
RECEBIDA Recorrência recebida pelo PSP do pagador • /cobr (GET)
REJEITADA Recorrência rejeitada pelo usuário pagador, apenas para a jornada 1, via notificação • /cobr (GET)
ACEITA Recorrência aceita pelo usuário pagador • /cobr (GET)
EXPIRADA Data da vigência da recorrência já expirada • /cobr (GET)
CANCELADA Recorrência cancelada pelo usuário pagador ou recebedor • /cobr (GET)

Tipo de jornada

tipoJornada Definição Endpoint
JORNADA_1 Usuário pagador aceitou a recorrência através de notificação externa ao ecossistema • /rec (POST)
JORNADA_2 Usuário pagador aceitou a recorrência através de leitura de QR Code de recorrência • /rec (POST)
JORNADA_3 Usuário pagador iniciou a recorrência através de leitura de QR Code composto e pagamento de cobrança imediata. O uso desta jornada torna obrigatório o preenchimento de dadosJornada.txid • /rec (POST)
AGUARDANDO_DEFINICAO Valor inicial posterior à criação e anterior à ativação da recorrência • /rec (POST)

Dados de entrada

Campo Definição Obrigatório Tamanho Tipo Exemplo
vinculo Informações sobre o objeto da recorrência. Sim Objeto
objeto (vínculo) Identificador do objeto de vínculo. Não 35 String “Conta de água Av. Brasil, 2804”
contrato (vínculo) Número, identificador ou código que representa o objeto da autorização (contrato, pedido etc.). Sim 35 String ContratoXYZ
devedor (vínculo) O objeto devedor organiza as informações sobre o devedor da recorrência. Sim Objeto
cpf (devedor) CPF do usuário. Não pode ser utilizado ao mesmo tempo que o CNPJ. Sim 11 String 09591481080 — Pattern: /^\d{11}$/
cnpj (devedor) CNPJ do usuário. Não pode ser utilizado ao mesmo tempo que o CPF. Sim 14 String 3202386000185 — Pattern: /^\d{14}$/
nome (devedor) Nome do usuário. Sim 140 String Ciclano de Tal
calendario Informações sobre o calendário de recorrência. Sim Objeto
datainicial (calendário) Data no formato YYYY-MM-DD, segundo ISO 8601. Representa a estimativa do primeiro pagamento. Sim String 2025-03-01
dataFinal (calendário) Campo opcional para autorizações com vigência pré-definida. Compatível com tipoFrequencia e datainicialRecorrencia. Não deve ser preenchido para autorizações de tempo indeterminado. Data ISO 8601 no formato YYYY-MM-DD. Não String 2025-03-01
periodicidade Periodicidade das cobranças recorrentes. Sim String ENUM MENSAL
valor Objeto que agrupa informações de valor. Não Objeto
valorRec (valor) Campo opcional. Preenchido apenas quando o valor dos pagamentos é fixo ou não está sujeito a alteração durante a vigência da autorização. Não String 100.00 — Pattern: \d{1,10}\.\d{2}
valorMinimoRecebedor (valor) Campo opcional. Valor definido pelo usuário recebedor. Se o usuário pagador atribuir um valor máximo para os pagamentos daquela autorização, ele não poderá ser inferior ao piso definido pelo usuário recebedor. Não pode ser preenchido nas autorizações de valor fixo, ou seja, com campo valor preenchido. Não String 100.00 — Pattern: \d{1,10}\.\d{2}
politicaRetentativa Política de retentativas pós-vencimento de recorrência. Determinará se após a data de liquidação determinada na cobrança recorrente será autorizada o reagendamento com data superior a data do vencimento. NAO_PERMITE: Não será autorizado retentativas após o vencimento PERMITE_3R_7D: Será permitida até 3 tentativas após o vencimento dentro do período de 7 dias corridos. Sim String ENUM NAO_PERMITE
loc Identificador da location a ser informada na criação da recorrência.    
recebedor O objeto recebedor organiza as informações sobre o usuário recebedor da recorrência. Sim Object
cnpj (recebedor) CNPJ do usuário recebedor. Não pode ser utilizado ao mesmo tempo que o CPF. Sim 14 String 32023886000185 — Pattern: /^\d{14}$/
nome (recebedor) Nome do usuário recebedor. Sim 140 String Empresa de Serviços S.A.
ativacao Dados relacionados à confirmação da ativação da recorrência. Não Object
dadosJornada (ativacao) Dado de preenchimento obrigatório quando utilizada a Jornada 3. Este campo deve ser removido pelo PSP Recebedor quando a ativação for realizada pelas jornadas 1, 2 ou 4. Não Object JORNADA_3
txid (dadosJornada) Identificador da transação. O campo txid determina o identificador da transação. O objetivo desse campo é ser um elemento que possibilite ao PSP do recebedor apresentar ao usuário recebedor a funcionalidade de conciliação de pagamentos. Na pacs.008, é referenciado como TransactionIdentification ou idConciliacaoRecebedor. Não String 33beb661bed4a4892feff47dbeb2cd5 — Pattern: [a-zA-Z0-9]{26,35}

Exemplo de entrada

{
  "vinculo": {
    "contrato": "63100862",
    "devedor": {
      "cpf": "45164632481",
      "nome": "Fulano de Tal"
    },
    "objeto": "Serviço de Streamming de Música."
  },
  "calendario": {
    "dataFinal": "2025-04-01",
    "dataInicial": "2024-04-01",
    "periodicidade": "MENSAL"
  },
  "valor": {
    "valorRec": "35.00"
  },
  "politicaRetentativa": "NAO_PERMITE",
  "loc": 108,
  "ativacao": {
    "dadosJornada": {
      "txid": "33beb661beda44a8928fef47dbeb2dc5"
    }
  }
}

Dados de saída

Campo Definição Obrigatório Tamanho Tipo Exemplo
dataFinal (calendario) Campo opcional que deve ser preenchido para autorizações com vigência pré-definida, devendo ser compatível com os valores informados em tipoFrequencia e a dataInicialRecorrencia. Não deve ser preenchido para autorizações por tempo indeterminado. Trata-se de uma data, no formato YYYY-MM-DD, seguindo ISO 8601. Não   String 2025-03-01
periodicidade Periodicidade das cobranças recorrentes. Sim   String (ENUM) MENSAL
valor Campo opcional, deve ser preenchido apenas quando o valor dos pagamentos for fixo ou não for sujeito à alteração durante a vigência da autorização. Não   Object  
valorRec (valor)   Não   String 100.00
Pattern: \d{1,10}.\d{2}
valorMinimoRecbedor (valor) Campo opcional. Valor definido pelo usuário recebedor. Se o usuário pagador atribuir um valor máximo para os pagamentos daquela autorização, ele não poderá ser inferior ao piso definido pelo usuário recebedor. Não pode ser preenchido nas autorizações de valor fixo, ou seja, com campo valor preenchido. Não   String 100.00
Pattern: \d{1,10}.\d{2}
politicaRetentativa Política de retentativa após vencimento da recorrência. Determinará se após a data de liquidação determinada na cobrança recorrente será autorizado o reagendamento com data superior à data do vencimento. NÃO_PERMITE: Não será autorizado retentativas após o vencimento PERMITE_3R_7D: Será permitida até 3 tentativas após o vencimento dentro do período de 7 dias corridos. Sim   String (ENUM) NAO_PERMITE
loc Location do payload completa Não   Object  
criacao (loc) Data e hora em que o location foi criada. Respeita RFC 3339 Não   String 2023-12-10T07:10:05.115Z
id (loc) Identificador da location a ser informada na criação de uma recorrência Não   Int64 108
location (loc) Localização do payload a ser informada na criação da recorrência Não 77 String pix.example.com/q/v2/rec/2353c790eefb11eaadc10242ac120002
idRec (loc) Identificador da recorrência Não 29 String RR1234567820240115abcdefghijk
Pattern: [a-zA-Z0-9]{29}
atualizacao Histórico das mudanças de status da recorrência Sim   Object  
status Status da recorrência Sim   String (ENUM) CRIADA
data Data e hora do registro do status atualizado. Respeita RFC 3339 Sim   String 2023-12-19T12:28:05.230Z
recebedor O objeto devedor organiza as informações sobre o devedor da recorrência. CNPJ do usuário. Não pode ser utilizado ao mesmo tempo que o CPF. Sim   Object  
cnpj (recebedor)   Sim 14 String 8202386000185
Pattern: ^\d{14}$
nome (recebedor) Nome do usuário recebedor Sim 140 String Empresa de Serviços S.A
ativacao Dados relacionados à confirmação da ativação da recorrência Não   Object  
dadosJornada (ativacao) Dado de preenchimento obrigatório quando utilizada a Jornada 3. Este campo deve ser removido pelo PSP Recebedor quando a ativação for realizada pelas jornadas 1, 2 ou 4. Não   Object  
tipoJornada Dado relacionado ao caminho percorrido pelo processo de adesão à recorrência pelo usuário pagador, os valores possíveis são Sim   String (ENUM) JORNADA_3
txid (dadosJornada) Identificador da transação. O campo txid determina o identificador da transação. O objetivo desse campo é ser um elemento que possibilite ao PSP do recebedor apresentar ao usuário recebedor a funcionalidade de conciliação de pagamentos. Na pacs.008, é referenciado como TransactionIdentification ou idConciliacaoRecebedor. Não   String 33beb661beda44a8928fef47dbeb2dc5
Pattern: [a-zA-Z0-9]{26,35}

Exemplos de saída

{
  "idRec": "RN1234567820240115abcdefghijk",
  "vinculo": {
    "contrato": "63100862",
    "devedor": {
      "cpf": "45164632481",
      "nome": "Fulano de Tal"
    },
    "objeto": "Serviço de Streamming de Música."
  },
  "calendario": {
    "dataFinal": "2025-04-01",
    "dataInicial": "2024-04-01",
    "periodicidade": "MENSAL"
  },
  "politicaRetentativa": "NAO_PERMITE",
  "recebedor": {
    "cnpj": "01602606113708",
    "nome": "Empresa de Serviços SA"
  },
  "valor": {
    "valorRec": "35.00"
  },
  "status": "CRIADA",
  "loc": {
    "criacao": "2023-12-10T07:10:05.115Z",
    "id": 108,
    "location": "pix.example.com/qr/v2/rec/2353c790eefb11eaadc10242ac120002",
    "idRec": "RN1234567820240115abcdefghijk"
  },
  "ativacao": {
    "dadosJornada": {
      "tipoJornada": "JORNADA_3",
      "txid": "33beb661beda44a8928fef47dbeb2dc5"
    }
  },
  "atualizacao": [
    {
      "data": "2023-12-19T12:28:05.230Z",
      "nome": "CRIADA"
    }
  ]
}

Códigos de retorno

Código HTTP Descrição Técnica Quando ocorre
200 Sucesso Requisição processada corretamente.
201 Criado Recurso criado com sucesso (ex: recorrência ou cobrança).
400 Requisição inválida Campos obrigatórios ausentes, formato inválido, valores fora do padrão.
401 Não autorizado Token de acesso ausente, inválido ou expirado.
403 Proibido O client_id não tem permissão para acessar o recurso.
404 Não encontrado ID de recorrência, cobrança ou devolução não existe.
409 Conflito Tentativa de criar uma recorrência ou cobrança com txid já existente.
422 Entidade não processável Dados válidos em estrutura, mas com regras de negócio violadas.
500 Erro interno do servidor Falha inesperada no processamento da requisição.
503 Serviço indisponível API fora do ar, manutenção ou instabilidade temporária.

Recursos

Consultar listas de recorrência

Retorna todos os contratos de recorrência de forma paginada a partir das informações do pagador.

Ambiente Método Endpoint
Sandbox GET https://api2.cielo.com.br/sandbox/cielo-pix/v1/rec
Produção GET https://api-mtls.cielo.com.br/cielo-pix/v1/rec

AS periodicidades possíveis são:

Política de retentativa

Política Definição
NÃO_PERMITE Não será autorizado retentativas após o vencimento
PERMITE_3R_7D Será permitida até 3 tentativas após o vencimento dentro de 7 dias corridos

Status de recorrência

Status Definição
CRIADA Recorrência criada pelo usuário recebedor
ENVIADA Recorrência enviada ao PSP do pagador
RECEBIDA Recorrência recebida pelo PSP do pagador
REJEITADA Recorrência rejeitada pelo usuário pagador, apenas para a jornada 1, via notificação
ACEITA Recorrência aceita pelo usuário pagador
EXPIRADA Data da vigência da recorrência já expirada
CANCELADA Recorrência cancelada pelo usuário pagador ou recebedor

Tipo de jornada

tipoJornada Definição
JORNADA_1 Usuário pagador aceitou a recorrência através de notificação externa ao ecossistema
JORNADA_2 Usuário pagador aceitou a recorrência através de leitura de QR Code de recorrência
JORNADA_3 Usuário pagador iniciou a recorrência através de leitura de QR Code composto e pagamento de cobrança imediata. O uso desta jornada torna obrigatório o preenchimento de dadosJornada.txid
AGUARDANDO_DEFINICAO Valor inicial posterior à criação e anterior à ativação da recorrência

Os possíveis solicitantes de cancelamento da cobrança recorrente são:

Códigos de cancelamento

Código Descrição
ACCL Fechamento de conta. Utilizado para transações relacionadas ao encerramento de uma conta bancária.
CPCL Encerramento da empresa.
DCSD Cancelamento por motivo de falecimento
FRUD Utilizado para transações que foram identificadas como fraudulentas
SLCR Solicitado pelo usuário pagador
SLDB Solicitado pelo usuário recebedor

SWAGGER: API PIX

Acesse nosso Portal de Desenvolvedores para visualizar a especificação técnica da API no formato Swagger.