ELECTRONIC STATEMENT v15

Updates v15.15 – Deployment date: May 19, 2026

​ • Display of judicial block/unblock/settlement events in Pix transactions.
​ • Inclusion of offset entries related to Voucher (PAT) negotiations.
​ ​

Updates v15.14.1 – Deployment date: January 13, 2026​

• Identification of registration hierarchy.
​ • Identification of transactions with the TC product (“Vendeu, Tá na Conta”) in record type “E”.

Attachments

UPDATED LAYOUTS:

• Technical Specification Manual - English
• Manual de Especificação Técnica - Português
  

Statement delivery flow

• Single customer portal: File queries and downloads are available in the logged-in area of ​​the Cielo website www.cielo.com.br - Services tab > access Electronic Statement.
• Customer service channel: edi@cielo.com.br or (11) 4002-5270

Description

The Electronic Statement is a solution developed by Cielo for clients who require automation in their financial reconciliation processes. This product provides standardized data—without manual intervention—related to sales, payments, negotiations, and outstanding balances processed by Cielo. The information is generated in a structured format and made available for direct download from the Cielo portal, ensuring speed, security, and data integrity during transmission. This approach enables client systems to integrate the data efficiently, reducing operational errors and increasing the productivity of back-office processes

Benefits

• Enables automated accounting and financial reconciliation
• Increased agility and operational efficiency
• Integration with the sales automation
• Security in receiving information
• Specialized support

Consent Flow

Introduction to the API (exclusive for Reconciliation Companies)​

This API (exclusive for Reconciliation Companies) enables the registration of groups and maintains their records to receive EDI (Electronic Data Interchange) files.

Step 1 - Login

1 - The partner redirects the client to {cielo-login-url}.
2 - The customer enters with their credentials and clicks on ‘Login’.
3 - Cielo shows the authorization terms and the customer approves this access by clicking on ‘Allow Access. 4 - Cielo redirects the customer to the partner again at {partner-call-back-url}`.

What is cielo-login-url?

https://{base-login-url}?response_type=code&client_id={client_id}&redirect_uri={redirect_uri}&scope={scope}&state={state}`

• base-login-url: Base URL that changes by the environment, will be sent at design time
• response_type: The value must be fixed “code”
• client_id: Customer identifier, will be sent by Cielo at project time
• redirect_uri: Partner URL for Cielo to redirect the user when the login process ends, or if there is an error in the process
• scope: A comma-separated list of the APIs that the partner wants to access, the possible scopes will be sent by API.
• state: A value that the customer wants to receive in return to maintain the state between the request and the return

What is partner-callback-url?

https://{partner-callback-url}?code={code}&state={state}

• partner-callback-url: The partner URL will be redirected when the login process ends.
• code: The authorization code generated by Cielo. With this code the partner will be able to exchange for an access_token to make calls on behalf of the customer.
• state: The same amount that the partner sent in the requisition.

Step 2 - Requesting an Access Token

• The partner service requests an access_token.
• Cielo returns an acess_token, a refresh_token and an expiration_time.

Request

POST {cielo-api-base-url}/consent/v1/oauth/access-token

Key	Value
Authorization	Basic Base64(client_id do parceiro concatenado com “:” e o client_secret codificado em base64)

curl --location --request POST 'https://{cielo-api-base-url}/consent/v1/oauth/access-token' \
--header 'Basic Base64'
--header 'Content-Type: application/json' \
--data-raw '{
    "grant_type": "authorization_code",
    "code": "{}"
}'

Response

{
"access_token": "{access_token}",
"refresh_token": "{refresh_token}",
"token_type": "access_token",
"expires_in": {expiration_time}
}

Observações

• The authorization_code needs to be replaced with an access_token in less than 10 minutes.
• This type of access_token is mandatory to call APIs that return sensitive customer data.
• The partner needs to store access_token and refresh_token in a safe place.
• When the access_token expires, the partner will no longer be able to call the APIs until they request a new acess_token using the refresh_token flow.
• The acess_token generated in this flow will be unique per Cielo customer, as it must be approved by the customer.
• The partner is NOT able to generate an access_token without the customer’s consent.
• The partner is NOT able to use the authorization code, received in the first step, more than once.

Step 3 - Requesting the APIs

At this point, the partner will be able to call Cielo’s APIs without the need for customer approval, as this has already been granted.

The only requirement to call Cielo’s APIs is to send the following HTTP header: ** Authorization: Bearer {access_token} ** In all calls to the APIs.

• The access_token was obtained in the second step

Step 3.1 - Updating an Access Token

1. The partner calls the service refresh_token.
2. Cielo returns a new access_token, a new refresh_token and a new expiration_time.

The response data will be the same as in step 2 when the partner requests an acess_token, however all data returned is new and needs to be stored in place of the old ones.

Request

curl --location --request POST 'https://{cielo-api-base-url}/consent/v1/oauth/access-token' \
--header 'Basic Base64'
--header 'Content-Type: application/json' \
--data-raw '{
    "grant_type": "refresh_token",
    "refresh_token": "{}"
}'

A point of attention in the request because now the partner needs to send grant_type as refresh_token and in the refresh_token field a valid refresh_token should be sent (and no longer an access_token).

Response

{
"access_token": "{access_token}",
"refresh_token": "{refresh_token}",
"token_type": "access_token",
"expires_in": {expiration_time}
}

Errors

If an error occurs on the Cielo side, the customer will be redirected to the partner’s call-back URL with the error parameter in the URL, for example https: // {partner-callback-url}? Error = {error}.

Possible values for {error}:

• lid_request: The request is missing some mandatory parameter, or it has an invalid parameter, or any other possibility that makes the URL incorrect.
• unauthorized_client: The partner is not authorized to make a request using this method.
• access_denied: The resource owner or authorization server denied the request.
• unsupported_response_type: The authorization server does not support obtaining an authorization code using this method.
• invalid_scope: The scope is invalid, unknown or malformed.
• server_error: The authorization server encountered an unexpected condition and is unable to complete this request. (This error is necessary because it is not possible to return an HTTP status code 500 Internal Server Error via HTTP redirect)
• temporarily_unavailable: The authorization server is unable to handle the request due to temporary overhead or is undergoing maintenance. (This error is necessary as it is not possible to return an HTTP Status 503 Service Unavailable to the partner via HTTP redirect)

Optionally, another parameter error_description can be returned with a detail of the error, just plain text.

Note

• All tokens (access_token and refresh_token) must be stored in a safe place.
• The partner needs to start a new concession flow if they lose the tokens or both expire (The refresh_token expires 90 days from generation).
• If you generate a new refresh_token it has another 90 days from the generation to expire.
• The partner needs to start a new concession flow for each Cielo client that the partner wants to consult the data.

Environment

Collection

We make the Collections used to perform all API operations available. You only need to configure the URL and credentials.

Collections Download

Operations

POST Register Merchant ID

Register Merchant ID (just one, a list or all), based on a Entity Number.

Request

POST /edi/registers

Headers

Key	Value
Authorization	Bearer + access_token

{
  "mainMerchantId": "9999111222",
  "merchants": [
    "9999111111",
    "9999111333"
  ],
  "merchantEMail": "customer@customer.com",
  "type": [
    "SELL"
  ]
}

Response

{
  "legalEntityNumber": 1234567890,
  "mainMerchantId": 2008983,
  "registerID": 12345,
  "merchants": [
    823958412384701,
    679809436576210
  ],
  "type": [
    "SELL"
  ],
  "status": "PROCESSING"
}

GET Retrieve status

Retrieve the EDI registration status.

Response

GET /edi/registers/{registerID}

Headers

Key	Value
Authorization	Bearer + access_token

{
  "legalEntityNumber": "01234567890",
  "registerID": 12345,
  "merchants": [
    9999222111,
    9999222222
  ],
  "status": "PROCESSING"
}

GET Consult Register Merchant ID

Consult Merchant ID based on a Register ID or a Main Merchant ID.

Response

GET /edi

Headers

Key	Value
Authorization	Bearer + access_token
registerID	Registration ID provided by /edi/registers when registering. Can be used in place of mainMerchantID if preferred (only one needs to be informed).
mainMerchantID	Main Customer ID. The most usual way to retrieve an EDI register in the company. Can be used instead of registerID mainly in cases of registration not performed by /edi/registers.

{
  "legalEntityNumer": "12314314",
  "mainMerchantId": 9999111222,
  "registerID": 12345,
  "merchants": [
    9999111111,
    9999111333
  ],
  "type": [
    "SELL"
  ],
  "acknowledge": "COMPLETED"
}

PUT Update Register Merchant ID

Update Merchant ID based on a Register ID or a Main Merchant ID.

Request

PUT /edi

Headers

Key	Value
Authorization	Bearer + access_token

{
  "registerID": "string",
  "mainMerchantId": "9999222333",
  "merchants": [
    "9999222111",
    "9999222222"
  ],
  "type": [
    "SELL"
  ]
}

Response

{
  "legalEntityNumber": "01234567890",
  "mainMerchantId": 9999111222,
  "registerID": 12345,
  "merchants": [
    9999222333,
    9999111222
  ],
  "type": [
    "SELL"
  ]
}

DELETE Delete Register Merchant ID

Delete MerchantID based on a Register ID or a Main Merchant ID.

Response

DELETE /edi

Headers

Key	Value
Authorization	Bearer + access_token
registerID	Registration ID provided by /edi/registers when registering. Can be used in place of mainMerchantID if preferred (only one needs to be informed).
mainMerchantID	Main Customer ID. The most usual way to retrieve an EDI register in the company. Can be used instead of registerID mainly in cases of registration not performed by /edi/registers.

{
  "legalEntityNumer": "12314314",
  "mainMerchantId": 9999111222,
  "registerID": 12345,
  "acknowledge": "COMPLETED"
}

GET List of branches

Performs the list of customers below the informed access_token. The filter can be used to list only those available or unavailable. Unavailable means that the branch already participates in another register. In the register and editing services, there is validation to allow only those available to be informed.

Response

GET /edi/merchantgroup

Headers

Key	Value
Authorization	Bearer + access_token

{
  "legalEntityNumber": "string",
  "branches": [
    {
      "merchantID": "9999111222",
      "legalEntityNumber": "01234567890",
      "businessName": "V",
      "status": "UNAVAILABLE"
    }
  ]
}

File transmission and resending

For customers who do not use a third-party reconciliation service, files can be received as follows: download from the Cielo website www.cielo.com.br. After logging in to the website, the files are available under Services > Access Electronic Statement. ​ For customers who use a market reconciliation provider, the entire process of requesting and sending statements is carried out directly by the reconciler.

File resending

For customers, simply locate the file and download it from the Cielo website. For reconciliation companies, if file resending is required, they must contact EDI Support (edi@cielo.com.br), indicating the statement parent companies, file dates, and file type.

File recovery

Allows for the recovery of a previous transaction, updating the status of the entries. The files are made available separately from the daily file and are identified with the sequential number “9999999” in the header. Recovery is not available for the Remaining Balance file (09). The request can be made to EDI Service (edi@cielo.com.br).