Transaction report - DCS Technical Documentation

Daily transaction report

Whether you reconcile balance movements day by day, need to reconstruct the full detail of every settled amount, or must satisfy a regulatory requirement that the flow of funds be traceable and auditable, the daily transaction report is the authoritative reconciliation record you can rely on directly. As a licensed card issuer, DCS records all of the day’s settled fund movements in a standardized file, stores it in AWS S3, and delivers it to you through a single endpoint. The transaction report captures the actual debits and credits, meaning the outcome of clearing. It does not include the intermediate states of the authorization stage such as holds and releases. If what you need is the authorization decision itself, use the authorization report instead; put the two files together and you can reconstruct the complete path from hold to charge.

How the file is generated

Each day DCS generates one full transaction file per partner (Enterprise).

Item	Description
Scope	One full file per day, per Enterprise
Storage	AWS S3; a temporary download link is issued through the endpoint DCS provides
Format	Plain text, one record per line, fields delimited by `>` (see “File fields” below)
Timing	By default the previous day’s file is generated on T+1; the exact run time is set on the scheduling platform, and the file can be downloaded once the status is `DONE`

Who does what

DCS: generates the full transaction file each day and stores it in S3, then issues a temporary download link on request.

Partner: calls the endpoint below for a link, downloads the file, then loads it and checks that balance movements match your own business records.

How to retrieve the file

Under the Partner-Managed model, transaction records have no real-time endpoint for querying an individual record; they are delivered exclusively through the full daily file. Use the shared settlement file endpoint to obtain the link: GET /open-api/enterprise/v1/settlement-file-url

Parameter	In	Type	Required	Description
`fileType`	query	String	Yes	File type; pass `transaction` for the transaction file (`authorisation` for the authorization file), max 20
`fileDate`	query	String	Yes	File date, format `yyyyMMdd`, for example `20251106`, max 8

Response: the standard response envelope { code, message, messageDetail, data }, where data is the file’s download link as a string (a temporary S3 link). The link is valid for a fixed 120 seconds and can be requested again once it expires. Judge success or failure from code; messageDetail exists only for front-end display and must not be used to decide the outcome. For the endpoint definition and response fields, see the Enterprise Account & Reconciliation group in the API Reference. Request example

GET /open-api/enterprise/v1/settlement-file-url?fileType=transaction&fileDate=20251106

Response example

{
  "code": "SYS_SUCCESS",
  "message": "success",
  "messageDetail": null,
  "data": "https://<bucket>.s3.<region>.amazonaws.com/...&X-Amz-Expires=120&..."
}

the temporary download link is valid for a fixed 120 seconds. Once it expires, call this endpoint again with the same fileType + fileDate to obtain a new link.

File fields

One transaction record per line, fields delimited by >, in the following order:

Field	Description	Notes
`transactionId`	Unique transaction ID	The unique number identifying each movement of funds
`direction`	Transaction direction	`OUTGOING` (funds out) / `INCOMING` (funds in)
`outsId`	Outstanding ID	Links to the corresponding outstanding record
`authIds`	Related authorization IDs	Multiple authorizations are separated by commas, for example `1111,2222`; use these to link back to `authId` in the authorization report
`enterpriseId`	Enterprise ID	Identifies the partner the fund movement belongs to
`customerId`	User ID	Identifies the cardholder the transaction belongs to
`cardId`	Card ID	The card the transaction took place on
`pan`	Card number	Only the first six and last four digits are shown, to keep the number safe
`category`	Transaction category	The transaction category `code`, for example `RETAIL` for an ordinary purchase; see Transaction flow
`currency`	Currency	ISO 3-digit currency code
`amount`	Amount	The amount the transaction covers, in the settlement currency
`acquirerCurrency`	Requested currency	May differ from the actual settlement currency
`acquirerAmount`	Requested amount	The amount in the requested currency
`cardAcceptorIdentification`	Merchant ID	The merchant identifier for the transaction
`cardAcceptorNameLocation`	Merchant details	Merchant name and address
`multiClearInd`	Clearing indicator	`O` ordinary single clearing / `P` multi-part clearing, not the final part / `F` multi-part clearing complete. To decide whether an authorization has finished clearing, wait until you have received `F`; see Transaction flow, multi-part clearing indicator
`merchantType`	Merchant type	The MCC, four digits
`createTime`	Creation time	When the transaction record was created, format `yyyy-MM-dd'T'HH:mm:ss+08:00` (UTC+8)
`modifyTime`	Update time	When the transaction record was last modified; same format as above
`merchantCountryCode`	Merchant country code	Three-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

Time zone warning: time fields inside the report are UTC+8 (+08:00), consistent with the business time fields across the partner-facing APIs (the velocity-limit query endpoint, whose dates are UTC, is the one exception).

Sample lines

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>
174047198631807650000311>INCOMING>1109865120004237313>1109865120008431616>1095041241881513984>1108391061086846977>1108449591919689729>4382140000003562>PAYMENT>702>1.000000000000000000>>0E-18>001584054110002>>null>5399>2025-03-22T09:12:07+08:00>2025-03-22T09:12:07+08:00>840>174047198631807650000301

The first two lines show a cash withdrawal: the first, category=CASH, is the withdrawal principal, and the second, category=CASH_FEES, is the withdrawal fee. Both records share the same card number and the same merchant. The third line shows a refund: an incoming record with category=PAYMENT whose trailing originalTransactionId points to the transactionId of the original purchase being refunded; that column is empty for non-refund records, which is why the first two lines end in >. An empty field (consecutive >>) means that column has no value.

in the settlement file, category is written in full as CASH / CASH_FEES (withdrawal principal / withdrawal fee). Treat those spellings as authoritative.

Notes

Field extensions

New fields may be appended to the transaction file in the future. Field extensions follow these compatibility commitments:

Existing column indexes stay stable: the columns already defined in this document never change their index or meaning; no column is removed and no new column is inserted in the middle;
New fields are appended at the end of the line only: every addition is announced in advance through a change notice. Partners can read the new indexes as needed; until then, simply ignore the extra trailing columns — existing parsing is unaffected;
Every column keeps its placeholder: every column (including empty ones) keeps its placeholder, so the number of separators per line always matches the column count.

We recommend parsing fields by column index and tolerating unknown trailing columns.

Next steps

Understand the concept of transaction flow and where it sits in the funds lifecycle: Transaction flow
Reconcile the daily file on the authorization side: Authorization report
Look up the authoritative definitions of the transaction category (category) enumeration: Transaction flow
See the full definition of the download link endpoint and its response envelope in the Enterprise Account & Reconciliation group of the API Reference

​Daily transaction report

​How the file is generated

​How to retrieve the file

​File fields

​Sample lines

​Notes

​Field extensions

​Next steps

Daily transaction report

How the file is generated

How to retrieve the file

File fields

Sample lines

Notes

Field extensions

Next steps