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:

Where transactions sit in the fund lifecycle

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.

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. 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.

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
`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

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:

{
  "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
To understand how the daily reconciliation files are generated and downloaded: Transaction report
For the authoritative definition of the transaction category enumeration: Report field dictionary