Criar Consentimento Recorrente

Visão Geral

O consentimento recorrente é o objeto central do Pix Automático. Ele define as regras de toda a série de pagamentos futuros: quem é o recebedor, a periodicidade, os limites de valor e a vigência. Após criado, retorna uma authorizationUrl para que o usuário autorize a cobrança recorrente na sua instituição detentora.

Cada consentimento corresponde a uma série de pagamentos recorrentes (e não a um único pagamento como no Pix Instantâneo).

Criar Consentimento

POST /baas/v1/open/itp/automatic-payments/payment-initiation

Autenticação: Bearer Token (application_token)

Request

POST {{base_url}}/baas/v1/open/itp/automatic-payments/payment-initiation
Authorization: Bearer {{application_token}}
Content-Type: application/json

{
  "brandId": "66f4d9e296f18bc4606e1618",
  "redirectUrl": "http://localhost:8080/callback",
  "data": {
    "startDateTime": "2026-05-22T00:00:00Z",
    "creditors": [
      {
        "name": "João Silva",
        "cpfCnpj": "11111111000111",
        "personType": "PESSOA_JURIDICA"
      }
    ],
    "loggedUser": {
      "document": {
        "identification": "12345678909",
        "rel": "CPF"
      }
    },
    "recurringConfiguration": {
      "automatic": {
        "contractId": "XE00038166201907261559y6j6",
        "interval": "SEMANAL",
        "contractDebtor": {
          "name": "Policarpo Quaresma",
          "document": {
            "identification": "11111111111111",
            "rel": "CNPJ"
          }
        },
        "isRetryAccepted": false,
        "referenceStartDate": "2026-05-22",
        "maximumVariableAmount": "500.00",
        "minimumVariableAmount": "0.11"
      }
    }
  }
}

Campos do Request

Nível raiz

data

data.creditors[]

data.loggedUser.document

data.recurringConfiguration.automatic

data.recurringConfiguration.automatic.contractDebtor (opcional)

Informa o devedor do contrato quando este tem titularidade diferente do usuário pagador (ex: empresa pagando por um colaborador).

Intervalos de Pagamento (interval)

Valor: Fixo vs. Variável

Os campos de variável e fixedAmount são mutuamente exclusivos. Enviar ambos causa 422.

Response — HTTP 200

{
  "id": "6a3d1e159c0f8d0011779569",
  "authorizationUrl": "https://api-openfinance.opb.bricks.demo.fsapps.io/orgs/bricks/auth?client_id=CSYrcp9dzeRdUWbuXLFiF&request_uri=urn%3Aietf%3Aparams%3Aoauth%3Arequest_uri%3A82A3zcrbiqhoh15jCL78A",
  "paymentInitiationApi": "AUTOMATIC_PAYMENTS_V2",
  "ofConsent": {
    "consentId": "urn:bricks-demo:f4b0c161-f5f6-4adb-ae63-21a2160238d0",
    "status": "AWAITING_AUTHORISATION",
    "recurringConsentId": "urn:bricks-demo:f4b0c161-f5f6-4adb-ae63-21a2160238d0"
  },
  "createdAt": "2026-06-25T12:24:53.798Z"
}

Códigos de Retorno

Pontos de Atenção

⚠️

startDateTime e referenceStartDate — regra D+2: Ambas as datas devem ser pelo menos 2 dias úteis após a criação do consentimento. Datas no mesmo dia ou D+1 são rejeitadas com 422. Gere sempre essas datas dinamicamente.

⚠️

fixedAmount vs. variável: São mutuamente exclusivos. Nunca envie fixedAmount junto com minimumVariableAmount ou maximumVariableAmount no mesmo request.

⚠️

isRetryAccepted: false: Desabilita completamente as retentativas automáticas. Se o pagamento falhar, nenhuma nova tentativa será realizada pela detentora. Use true para habilitar o fluxo de tentativas intradia e extradia.

⚠️

contractId: É o identificador do contrato do ponto de vista do recebedor. Deve ser único por relação recebedor-pagador. Contratos duplicados para o mesmo par podem causar conflito no consentimento.

⚠️

contractDebtor ≠ loggedUser: O devedor do contrato pode ser uma empresa diferente do usuário pagador autenticado. Esse cenário é comum em cobranças B2B onde a empresa paga por um serviço, mas quem autoriza na detentora é um funcionário com acesso.

⚠️

Guarde o id retornado: O id da payment initiation é necessário para executar pagamentos (/payments), consultar e cancelar o consentimento.