> ## 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.
# Authorization report
> Covers the daily authorization report file itself: where it sits in the funds lifecycle, the authType / transactionType / approveFlag enumerations, how to download it, the >-delimited field layout, and how to read a sample line. For the shared mechanism used to retrieve any report, see Reconciliation overview; for a single reference covering the fields of both files, see Report field dictionary.
## 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:
* 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](../transactions/auth-and-settlement).
***
## 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](../transactions/auth-and-settlement).
***
## 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](../transactions/decline-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).
```json theme={null}
{
"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](../../api-reference/index). For error codes, see [Authorization declines and error codes](../transactions/decline-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](./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](../transactions/auth-and-settlement) |
| `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](../transactions/auth-and-settlement) |
| `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**
```text theme={null}
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:
1. **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;
2. **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;
3. **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](./transaction-report)
* Understand the full path from hold to clearing: [Authorization and clearing scenarios](../transactions/auth-and-settlement)
* Look up the authoritative definitions of the authorization enumerations: [Authorization and clearing scenarios](../transactions/auth-and-settlement)
* Understand the shared retrieval mechanism for daily settlement files: [Reconciliation overview](./overview)