lighthouse.dock.tech

Dock Lighthouse

Welcome to Dock Lighthouse! You'll find comprehensive guides and documentation to help you start working with our products as quickly as possible, as well as support if you get stuck. Let's jump right in!

Get Started

Reconciliation Process and Base II File

The reconciliation process is responsible for confirming the online authorized transactions and realizing adjustments, such as credit vouchers and revert transactions, for example. The reconciliation process must be done based on a reconciliation file named "Base II", which is provided by DOCK via Secure Shell File Transfer Protocol (SFTP) protocol to our partners.

What is the Base II File?


The "Base II" file is a positional file used in the reconciliation process done by our partner. This file is sent daily by DOCK and can contain the transaction types described in the following table:

Transaction Type

Identification

Purchase

TC05

Credit Voucher

TC06

Withdrawal

TC07

Purchase Cancellation

TC25

Credit Voucher Cancellation

TC26

Withdrawal Cancellation

TC27

File Composition


The base II file is composed by three types of records (rows):

  • Header: Contains general information about the file;
  • Information: Contains transactions information;
  • Trailer: Contains summarized information about the transactions in the file.

Header Record Description

Information

Description

Format

Size

Domain

Required

Register Type

Code for identification of the register Type (row).

AN

2

Fixed "H1" for this type of record (row).

Yes

File version

File generation reference version.

N

4

Filled with leading zeros. Ex: "0001".

Yes

Original Bank

Conductor Id.

N

3

Filled with leading zeros. Ex: "008".

Yes

Destination Bank

Issuer Id.

N

3

Filled with leading zeros. Ex: "005".

Yes

Movement date

Date of generation of the original file sent by the card scheme.

N

8

Date format "yyyyMMdd".

Yes

File Sequence

File number.

N

6

Filled with leading zeros. Ex: "000001".

Yes

Generation Date

File creation date.

N

8

Date format "yyyyMMdd".

Yes

Generation Time

File creation time.

N

6

Time format "HHmmss".

Yes

Identification

File id.

AN

1

Fixed "A".

Yes

Future Use

Placeholder for future use.

AN

143

Filled with blank positions.

Yes

Layout type

Identification of the "information line" layout.

N

3

If it presents the value "001" it means that it has a "transactionUUID" field in the information lines. (started with "AA").

Yes

Line counter

File line indication

N

12

Filled with leading zeros. Ex: "000000000001".

Yes


Information Record Description

Information

Description

Format

Size

Domain

Required

Register Type

Code for identification of the register Type (row).

AN

2

Fixed "AA" for detail rows.

Yes

Transaction Date and Time

Date and of the transaction.

AN

17

Date and time format "yyyyMMdd HHmmss".

Yes

NSU

Source transaction identifier (unique by merchant).

N

12

Filled with leading zeros.

Yes

Process Code

Transaction processing code.

N

6

Filled with leading zeros.

Yes

Entry Mode Code

Terminal transaction entry Mode Code.

N

4

Filled with leading zeros.

Yes

Transaction Amount

Transaction amount.

N

18

Filled with leading zeros.

Yes

Return Code

Authorizer return code.

N

2

Filled with leading zeros.

Yes

Transaction type

Informs the transaction Type.

AN

4

Check the transaction types' table at the "What is the Base II File?" section.

Yes

Branch

Holder branch at issuer structure. This field is defined in the onboarding process.

N

10

Filled with leading zeros.

Yes

Account number

Holder account at issuer structure. This field is defined in the onboarding process.

N

9

Filled with leading zeros.

Yes

Merchant name

Name of the establishment in which the transaction happened.

AN

45

Right alignment with blanks to the left.

Yes

Currency Code

Currency code of the transaction.

N

3

Filled with leading zeros. May present the value "986" for domestic transaction (Brazil), and "840" for international ones.

Yes

Acquirer Reference Number

Transaction Identifier

N

23

Filled with leading zeros.

Yes

Transaction Information

Reserved for additional info

AN

44

Filled with leading zeros.

Yes

TransactionUUID

Transaction's UUID (V4), used to identify and conciliate with online authorized transactions.

AN

36

Ex value: "oc455l2c0-d10a-027d-8984-ce3f797933e7".

Yes

Line counter

File line indication

N

12

Filled with leading zero. Ex: "000000000001".

Yes


Trailer Record Description

Information

Description

Format

Size

Domain

Required

Register Type

Code for identification of the register Type (row).

AN

2

Fixed "T9".

Yes

Movement date

Date referring to the Transaction day.

N

8

Date format "yyyyMMdd".

Yes

TC05 (PURCHASE) total number of records

Total number of purchases.

N

12

Filled with leading zeros

Yes

TC05 (PURCHASE) total amount

Total amount in Real (or BRL according to ISO 4217) of purchases.

N

18

Filled with leading zeros

Yes

TC06 (CREDIT VOUCHER) total number of records

Total number of credit vouchers.

N

12

Filled with leading zeros

Yes

TC06 (CREDIT VOUCHER) total amount

Total amount in Real (or BRL according to ISO 4217) of credit vouchers.

N

18

Filled with leading zeros

Yes

TC07 (WITHDRAWAL) total records

Total number of withdrawals.

N

12

Filled with leading zeros

Yes

TC07 (WITHDRAWAL) total Amount Records

Total amount in Real (or BRL according to ISO 4217) of withdrawals.

N

18

Table 1

Yes

TC25 (PURCHASE REVERSAL) total Records

Total number of purchase reversals.

N

12

Filled with leading zeros

Yes

TC25 (PURCHASE REVERSAL) total Amount Records

Total amount in Real (or BRL according to ISO 4217) of purchase reversal.

N

18

Filled with leading zeros

Yes

TC26 (CREDIT VOUCHER REVERSAL) total Records

Total amount of credit voucher reversa.

N

12

Right alignment with blanks.

Yes

TC26 (CREDIT VOUCHER REVERSAL) total Amount Records

Total number in Real (or BRL according to ISO 4217) of credit voucher reversals.

N

18

Filled with leading zeros

Yes

TC27 (WITHDRAWAL REVERSAL) total Records

Total number of withdrawals.

N

12

Filled with leading zeros

Yes

TC27 (WITHDRAWAL REVERSAL) total Amount Records

Total amount in Real (or BRL according to ISO 4217) of withdrawals.

N

18

Filled with leading zeros

Yes

Future Use

Placeholder for future use.

AN

24

Filled with blank positions.

Yes

Line counter

File line indication

N

12

Filled with leading zeros. Ex: "000000000001".

Yes


Issuer Reonciliation Process


The reconciliation file has the absolute truth about the transactions that happened. That being said, the issuer must:

  • Process the file;
  • Confirm, cancel or execute the transactions (making balance adjustments if necessary);
  • Conciliate the transactions with the online authorizations that happened previously (by matching key data).

While processing the file, purchase and withdrawal operations (online authorized previously) are liable to be canceled (refunding a holder) upon receiving a "Purchase Reversal" or "Withdrawal Reversal" operation in the file.

❗️

Unconfirmed transactions!

All unconfirmed transactions will be canceled after 30 days of the online authorization.

The "Credit Voucher" operation is only sent in the reconciliation file (never online) and must be executed whenever it is present in a file by giving credit to a specific holder. This type of operation is used for making adjustments on the holder balance, such as a variation of the amount of a transaction, for example.

The following flowchart presents the reconciliation process that should be implemented by the partner and the actions involved in it when processing a file:

Reconciliation flow chart.

📘

Search in the Authorized Transactions Database

It is necessary to use specific key data to match the transactions from the file with online authorized ones when searching in the authorized transactions database. For such, it is needed to use the transactionUUID, which is present in the reconciliation file and the API request (endpoint POST /transaction).

Updated 14 days ago


Reconciliation Process and Base II File


Suggested Edits are limited on API Reference Pages

You can only suggest edits to Markdown body content, but not to the API spec.