> ## Documentation Index
> Fetch the complete documentation index at: https://docs.thedecard.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Transaction records
> Where multiClearInd and the related enumerations live.
## Transaction records
Whether you need to reconcile funds line by line, reconstruct the full timeline of one purchase or satisfy a regulator's expectation that every movement of funds is traceable, the transaction record is the single source you need to rely on. As a licensed issuer, DCS persists every settled movement of funds as a tamper-proof record and delivers the complete set to the partner in a daily reconciliation file.
A transaction record captures **only real debits and credits**. It never carries the intermediate states of the authorization stage, such as holds and releases. It is the authoritative record of where the money finally went, and together with the authorization and the Outstanding it forms the complete fund lifecycle.
***
## Where it sits in the fund lifecycle
The authorization decides how much to hold, settlement decides how much is finally taken, and the transaction record is what settlement leaves behind. The three are linked by IDs:
* A transaction record links to its Outstanding through `outsId` and to one or more authorizations through `authIds` (several authorizations are comma-separated, for example `1111,2222`).
* With multiple authorizations, incremental authorizations, partial captures and similar combinations, authorizations and transaction records do not map one to one. All 13 combinations (normal settlement, incremental, reversal, excess and under capture, forced capture, cash withdrawal and the rest) are in [Authorization and settlement: every scenario](./auth-and-settlement).
***
## Transaction direction (direction)
The `direction` field separates two core cases:
| Value | Meaning | Description |
| ---------- | -------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `OUTGOING` | Outgoing | Funds leave the partner's balance account at the enterprise level, matching a cardholder payment; it closes the decision-to-execution loop opened by the hold at the authorization stage |
| `INCOMING` | Incoming | Funds arrive in the partner's balance account, matching a return or refund, which keeps every inflow traceable and reconcilable |
***
## Transaction category (category)
The `category` field classifies each record for business purposes and is the primary dimension the partner uses for analysis and cost accounting.
| Value | Name | Description |
| ------------- | ------------------------ | -------------------------------------------------------------------------------------- |
| `RETAIL` | Ordinary purchase | Standard card purchase transaction |
| `RETAIL_FEES` | Purchase fees | Includes DCC fees, credit adjustments, card annual fees, replacement and re-issue fees |
| `CASH` | Ordinary cash withdrawal | ATM withdrawals and other cash transactions |
| `CASH_FEES` | Cash withdrawal fees | Includes cash withdrawal handling fees |
| `PAYMENT` | Return / refund | Returns, refunds and other incoming transactions |
| `CHARGEBACK` | Chargeback | Chargeback arising from a dispute raised by the cardholder |
> **How do you tell withdrawal principal from fee?** In a cash withdrawal, `category=CASH` is the principal and `category=CASH_FEES` is the fee, and each lands as its own record. The withdrawal fee goes through forced posting on its own; see [Authorization and settlement, scenario 13](./auth-and-settlement).
>
> **On cash withdrawal values**: the daily transaction file always uses the full `category` names (`RETAIL`, `CASH`, `CASH_FEES`, `PAYMENT` and so on). Codes such as `C`, `CF` and `R` are internal enumerations and never appear in the daily transaction file. The `R` / `C` / `Q` / `P` values of `transactionType` on the authorization side are a different dimension again, so do not mix them.
***
## Multiple capture indicator (multiClearInd)
One authorization may be settled several times, for instance when a merchant ships in batches or a hotel bills each line item at check-out. `multiClearInd` tells you where the current record sits in that series:
| Value | Meaning | What the partner should do |
| ----- | --------------------------------------------- | --------------------------------------------------------------------------------------------------- |
| `O` | Ordinary single capture | One authorization, one capture; handle it as usual |
| `P` | Multiple captures, not the last one (Partial) | Draw the Outstanding down only; **do not** treat the authorization as fully settled |
| `F` | Multiple captures completed (Final) | The last one, and the point at which the difference between authorization and settlement is checked |
> With multiple captures, treat the arrival of the `F` record as the signal that the authorization has settled in full. Before `F` arrives, further `P` records may still turn up under the same `authIds`.
***
## How to get transaction records
Under Partner-Managed there is **no real-time endpoint for querying an individual transaction**. Transaction data is delivered through the **daily full reconciliation file**: each day DCS generates a complete file of that day's transaction records for every partner enterprise.
**Endpoint (fetch the download link)**
```
GET /open-api/enterprise/v1/settlement-file-url
```
| Parameter | Type | Required | Description |
| ---------- | ------ | -------- | ---------------------------------------------------------------------------------------------------------- |
| `fileType` | String | Yes | File type; pass `transaction` for transaction records (`authorisation` for the authorization file), max 20 |
| `fileDate` | String | Yes | File date in `yyyyMMdd`, for example `20251106`, max 8 |
**Response**: a string containing the file **download link** (a temporary S3 link with a short lifetime, so download it promptly).
> **Who does what**
>
> * **DCS**: generates the full transaction file every day and issues a temporary download link on request.
> * **Partner**: call this endpoint for the link, download the file, persist it, and check that the balance movements match your own business records.
>
> **About the files and links**: by default the system generates the previous day's authorization and transaction files on T+1, and they can be downloaded once the job status is `DONE`; the exact daily run time is configured on the job platform. A download link is valid for 120 seconds; once it expires, call the endpoint again for a fresh 120-second link. The underlying file is not deleted when a link expires.
For how download links are obtained in general and how the daily reconciliation cycle works, see [Transaction report](../reports/transaction-report).
***
## Fields in the transaction file
One record per line, fields separated by `>`, in this order:
| Field | Description | Notes |
| ---------------------------- | ------------------------------ | ---------------------------------------------------------------------------------------------------------------------- |
| `transactionId` | Unique transaction record ID | The unique number of each movement of funds |
| `direction` | Transaction direction | `OUTGOING` (outgoing) or `INCOMING` (incoming) |
| `outsId` | Bill ID | Links to the matching Outstanding record |
| `authIds` | Related authorization IDs | Several are comma-separated, for example `1111,2222` |
| `enterpriseId` | Enterprise ID | Identifies the partner the movement belongs to |
| `customerId` | User ID | Identifies the cardholder behind the transaction |
| `cardId` | Card ID | The card the transaction happened on |
| `pan` | Card number | Only the first six and last four digits are shown, to keep the data safe |
| `category` | Transaction category | Matches the `category` enumeration above; see [Report field dictionary](../reports/field-dictionary) |
| `currency` | Currency | ISO 3-character currency code |
| `amount` | Amount | The amount involved, in the settlement currency |
| `acquirerCurrency` | Currency requested by the user | May differ from the actual settlement currency |
| `acquirerAmount` | Amount requested by the user | The amount in the requested currency |
| `cardAcceptorIdentification` | Merchant number | Identifies the merchant in the transaction |
| `cardAcceptorNameLocation` | Merchant details | Merchant name and address |
| `multiClearInd` | Capture indicator | `O` single, `P` multiple but not the last, `F` multiple completed |
| `merchantType` | Merchant category | The MCC, 4 digits |
| `createTime` | Creation time | When the record was created, `yyyy-MM-dd'T'HH:mm:ss+08:00` (UTC+8) |
| `modifyTime` | Update time | When the record was last modified, same format |
| `merchantCountryCode` | Merchant country code | 3-digit numeric country code |
| `originalTransactionId` | Original transaction ID | For a refund-type record, the `transactionId` of the original transaction being refunded; empty for non-refund records |
**Sample**
```text theme={null}
174047198631807650000309>OUTGOING>1109862324019138561>1109862318201638913>1095041241881513984>1108391061086846977>1108449591919689729>4382140000003562>CASH>702>1.000000000000000000>>0E-18>001584054110002>>null>5399>2025-03-21T07:20:45+08:00>2025-03-21T07:20:45+08:00>840>
174047198631807650000310>OUTGOING>1109864282771689473>1109864282775883776>1095041241881513984>1108391061086846977>1108449591919689729>4382140000003562>CASH_FEES>702>1.000000000000000000>>0E-18>001584054110002>>null>5399>2025-03-21T07:24:25+08:00>2025-03-21T07:24:25+08:00>840>
```
> The two lines above happen to illustrate a cash withdrawal: the first, `CASH`, is the withdrawal principal and the second, `CASH_FEES`, is the withdrawal fee. Both records share the same card number and the same merchant. Nothing follows the trailing `>` on either line, because non-refund records carry no `originalTransactionId`.
To make mapping into your own database easier, the first `>`-delimited line above is expanded below into an equivalent structured record, with field names matching the table above one for one:
```json theme={null}
{
"transactionId": "174047198631807650000309",
"direction": "OUTGOING",
"outsId": "1109862324019138561",
"authIds": "1109862318201638913",
"enterpriseId": "1095041241881513984",
"customerId": "1108391061086846977",
"cardId": "1108449591919689729",
"pan": "4382140000003562",
"category": "CASH",
"currency": "702",
"amount": "1.000000000000000000",
"acquirerCurrency": "",
"acquirerAmount": "0E-18",
"cardAcceptorIdentification": "001584054110002",
"cardAcceptorNameLocation": "",
"multiClearInd": "null",
"merchantType": "5399",
"createTime": "2025-03-21T07:20:45+08:00",
"modifyTime": "2025-03-21T07:20:45+08:00",
"merchantCountryCode": "840",
"originalTransactionId": ""
}
```
transaction records are **delivered only as the `>`-delimited text file shown above**. This JSON is a field-by-field illustration and does not imply that an endpoint returns JSON. In this sample `multiClearInd` is literally `null`; outside cash withdrawals it carries `O`, `P` or `F`.
***
## Next steps
* To understand every combination from hold to debit: [Authorization and settlement: every scenario](./auth-and-settlement)
* To understand how the daily reconciliation files are generated and downloaded: [Transaction report](../reports/transaction-report)
* For the authoritative definition of the transaction category enumeration: [Report field dictionary](../reports/field-dictionary)