Authorization report

Whether you want to review every authorization decision, check which transactions were approved or declined, or satisfy a regulatory requirement for end-to-end traceability of the authorization path, the daily authorization report gives you a complete, loadable snapshot of that day’s authorization decisions. As a licensed card issuer, DCS records every authorization decision, approvals and declines alike, as standardized fields and delivers them to you in a full daily settlement file. What the authorization report captures is the decision and the hold placed during the authorization stage, that is, whether the transaction was let through and how much was frozen, not where the money finally landed. It is delivered alongside the transaction report: the authorization report answers “was it approved”, the transaction report answers “how much was actually charged”.

Where it sits in the funds lifecycle

Under the Partner-Managed model, the authorization decision belongs to you and is made by you. DCS forwards the channel’s authorization request to you for an approve-or-decline verdict and records the outcome of each decision as an authorization record. Authorization, outstanding and transaction are chained together by IDs:

Where the authorization report sits in the funds lifecycle

Every record in the authorization report is uniquely identified by authId and links to its outstanding record through outsId.
originalAuthId is used wherever a record must be traced back to an original authorization, such as multiple refunds or incremental authorizations.
For the full set of authorization and clearing combinations (plain clearing, incremental, reversal, over- and under-clearing, forced clearing, cash withdrawal and so on), see Authorization and clearing scenarios.

Authorization type (authType)

authType tells you how an authorization record came into being, so you can separate real-time authorizations from records the system created or released on its own.

Value	Name	Description
`NORMAL`	Normal authorization	The real-time authorization record produced by an authorization callback from the channel; covers purchases, incremental authorizations, reversals, refunds, cash withdrawals and balance inquiries
`FORCE_AUTH`	Forced authorization	An authorization record the system creates by itself, seen when clearing arrives with no matching authorization (an offline transaction, for example) or when the cleared amount differs from the held amount and the difference must be booked
`EXPIRED_RELEASE`	Expiry release	The authorization was never settled in time, and the channel uses the settlement file to instruct the release of the funds still on hold
`STATUS_DIFF_RELEASE`	Status mismatch release	The channel declined the authorization on timeout while the DCS side had approved it; the mismatch triggers a reconciliation correction

The authoritative definitions also appear in Authorization and clearing scenarios.

Transaction type (transactionType)

transactionType tells you what kind of transaction the cardholder initiated when the authorization was requested, so you can recognize the scenario at a glance during reconciliation.

Value	Name	Description
`R`	Card purchase	All card purchase transactions
`C`	ATM withdrawal	ATM withdrawals and other cash advance transactions
`Q`	Inquiry	Inquiry transactions, with no movement of funds
`P`	Return or refund	All transfers or refunds credited back to the card

Authorization outcome and decline reason (approveFlag / rejectReason)

Field	Value	Description
`approveFlag`	`A`	Approved; the authorization was let through
`approveFlag`	`D`	Declined; the authorization was not let through
`rejectReason`	Present only when `D`	The specific reason for the decline, given as a `DAPI_*` error code; common values are listed below

Common rejectReason values:

Value	When it occurs
`DAPI_AUTH_ENTERPRISE_REJECT`	You explicitly declined in the authorization callback
`DAPI_AUTH_ENTERPRISE_TIMEOUT_REJECT`	You did not answer within the response window, so DCS declined as a fallback
`DAPI_AUTH_INTERNAL_REJECT`	Declined inside DCS (signature verification failure, forwarding failure, a response value outside the protocol, and similar)
`DAPI_AUTH_INSUFFICIENT_FUNDS_REJECT`	Insufficient funds; the hold or release check did not pass
`DAPI_CARD_STATUS_NOT_ACTIVATED`	The card is not activated
`DAPI_CARD_CONSUME_FROZEN`	A KYC factor has expired and the enterprise has spending restrictions enabled
`DAPI_CARD_VELOCITY_LIMIT_CHECK_REJECT`	The card velocity limit check declined the transaction
`DAPI_SYSTEM_ERROR`	Fallback for an unexpected system error

Because the authorization decision sits on your side, a rejectReason may come from your own business logic or from a DCS or channel-side check or reconciliation correction, a timeout being the obvious example. For how each code is classified and handled, see Authorization declines and error codes.

How to retrieve the authorization report

Under the Partner-Managed model there is no real-time endpoint for querying an individual authorization; authorization records are delivered exclusively through the full daily settlement file. Each day DCS generates one file per partner (Enterprise) containing all of that day’s authorizations. Endpoint (to obtain the download link)

GET /open-api/enterprise/v1/settlement-file-url

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

Note that the fileType value uses the British spelling authorisation, not authorization. Pass it exactly as shown.

Response: inside the standard response envelope { code, message, messageDetail, data }, data is the file’s download link as a string (a temporary AWS S3 link with a short validity, so download it promptly).

{
  "code": "...",
  "message": "...",
  "messageDetail": { },
  "data": "https://....s3.amazonaws.com/....authorisation.....?X-Amz-..."
}

About the response envelope: judge success or failure from code. message is a short prompt, and messageDetail is a structured message object meant for end-user display (carrying title, type, action, linkUrl and so on). For the envelope and the rules for interpreting it, see API Reference overview. For error codes, see Authorization declines and error codes.

Who does what

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

Partner: calls this endpoint for a link, downloads the file while the link is valid, then loads it and checks the authorization decisions against your own records.

by default the previous day’s file is generated on T+1 and can be downloaded once the job finishes. The temporary download link is valid for a fixed 120 seconds; once it expires, call the endpoint again for a new one.

For the shared retrieval mechanism behind download links and the daily reconciliation cycle, see Reconciliation overview.

Fields in the authorization report file

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

Field	Description	Notes
`authId`	Unique authorization ID	Used to link to transaction flow, outstanding records and other downstream records
`direction`	Transaction direction	`OUTGOING` (funds out) / `INCOMING` (funds in)
`authType`	Authorization type	Matches the `authType` enumeration above; see Authorization and clearing scenarios
`outsId`	Outstanding ID	Links to the corresponding outstanding record
`originalAuthId`	Original related authorization ID	Used to trace back in linked scenarios such as multiple refunds and incremental authorizations
`enterpriseId`	Enterprise ID	Identifies the partner that initiated the authorization
`customerId`	User ID	Identifies the cardholder the authorization 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
`approveFlag`	Authorization outcome	`A` approved / `D` declined
`rejectReason`	Decline reason	Present only when `approveFlag` is `D`
`approveDate`	Processing time	Format `yyyy-MM-dd'T'HH:mm:ss+08:00` (UTC+8)
`currency`	Currency	ISO 3-digit currency code (settlement currency)
`amount`	Amount	The amount the authorization 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
`transactionType`	Transaction type	Matches the `transactionType` enumeration above; see Authorization and clearing scenarios
`merchantType`	Merchant type	The MCC, four digits
`createTime`	Creation time	When the authorization record was created; same format as `approveDate`
`modifyTime`	Update time	When the authorization record was last modified; same format as above
`merchantCountryCode`	Merchant country code	Three-digit numeric country code

Sample line

1109086179954790401>OUTGOING>NORMAL>>>1095041241881513984>1108391061086846977>1108449591919689729>4382140000003562>D>DAPI_AUTH_ENTERPRISE_TIMEOUT_REJECT>2025-03-19T11:52:33+08:00>702>0.100000000000000000>>0E-18>>>R>5399>2025-03-19T03:52:31+08:00>2025-03-19T03:52:31+08:00>840

The sample above shows a declined authorization: approveFlag=D with rejectReason=DAPI_AUTH_ENTERPRISE_TIMEOUT_REJECT (the partner did not answer in time, so the authorization was declined), transaction type R (card purchase), settlement currency 702 (SGD), merchant country 840 (United States).

Notes

Field extensions

New fields may be appended to the authorization 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

Check what was finally charged: Transaction report
Understand the full path from hold to clearing: Authorization and clearing scenarios
Look up the authoritative definitions of the authorization enumerations: Authorization and clearing scenarios
Understand the shared retrieval mechanism for daily settlement files: Reconciliation overview