> ## 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.
# Managing Transactions · Overview
> The starting point for retrieving end-user transaction data in the DeCard-Managed model: which endpoint serves each of the four views (card spending, statements, fiat transaction records, transaction ID resolution), and how to query and paginate them.
## One place to query, three views
Every card purchase, every statement and every fiat movement belonging to an end user can be retrieved from DCS in one place and shown to the user as it is. As a licensed issuer running its own BINs, DCS keeps the whole "crypto → fiat → card spending" chain inside its own systems in the managed model, so you consume the three views below instead of stitching raw card network and ledger records together yourself.
The DeCard-Managed model organizes this data into three views — statement summaries, fiat transaction records and transaction-ID resolution — each served by its own endpoint. Start with the overview:
| View | Question it answers | Endpoint | Lookup key |
| ----------------------------- | --------------------------------------------------------------------------------------------------------- | -------------------------------------- | ---------------- |
| **Statement** | How much was spent and repaid in a given billing period? | `GET /card/v2/statements` | `cardId` |
| **Statement detail** | Which line items make up this statement? | `GET /card/v2/statements/detail` | `cardId` |
| **Fiat transaction records** | What are all of this user's credits, debits, repayments and top-ups, including the on-chain deposit hash? | `GET /card/v1/fiat/transactions` | `externalUserId` |
| **Transaction ID resolution** | Is this ID outstanding or posted, and which record does it link to? | `POST /card/v1/transaction/id/resolve` | `ids[]` |
> **Scope**: this page covers only the three views of **statements, fiat records and transaction-ID resolution**. An end user's **crypto funding history** (`user-asset/v1/transactions`, `transaction-detail`) belongs to the User Balance page and is not repeated here; see [User Balance](./user-balance) when you need it.
## Prerequisites
* Your Enterprise account is live and you hold an `ApiKey` and `SecretKey`. If you do not have them yet, see [First Steps](../../getting-started/first-steps) and the [Authentication Guide](../../integration-resources/overview).
* The end user is registered (you hold an `externalUserId`, see [Signing Up a Customer](../signing-up-a-customer/overview)) and holds a card (you hold a `cardId`, see [Issuing Cards](../managing-cards/issuing-cards)).
* Every request must carry the signature headers described in the Authentication Guide. The examples below omit those headers and show only the business fields.
* **The `externalUserId`, `cardId`, last 4 digits, merchant names, addresses and `txHash` values in all examples are placeholders or redacted. Never put real end-user PII in requests or logs.**
## 1. Querying statements
A statement rolls up the spending, repayments and not-yet-posted amounts of one billing period into a single record. The statement endpoints identify the card precisely with `cardId`, and the response carries both the SGD and USD amount fields.
### 1.1 Statement list
```
GET /card/v2/statements?externalUserId=usr_xxxxxxxx&cardId=card_xxxxxxxx&page=1&rows=20
```
| Parameter | Type | Required | Description |
| ----------------------- | ------ | -------- | --------------------------------------- |
| `externalUserId` | string | Yes | User ID |
| `cardId` | string | Yes | Card ID |
| `page` / `rows` | string | No | Pagination: page number / rows per page |
| `startTime` / `endTime` | string | No | Time range |
A successful response returns an array of statements in `data`:
```json theme={null}
{
"code": "SYS_SUCCESS",
"message": null,
"messageDetail": null,
"data": [
{
"type": "POSTED",
"statementId": "stmt_xxxxxxxx",
"statementDateStart": "2026-06-01",
"statementDateEnd": "2026-06-30",
"cardNumberLast4": "0000",
"cardOrganization": "VISA",
"cardScheme": "Visa Platinum",
"cardOrganizationLogo": "https://example.com/logo.png",
"debitAmountExcludePayment": 100.00,
"paymentAmountInSgd": 0.00,
"paymentAmountInUsd": 100.00,
"nonPostedAmountInSgd": 0.00,
"nonPostedAmountInUsd": 0.00
}
]
}
```
| Field | Description |
| ---------------------------------------------------------- | --------------------------------------------------------------------------- |
| `type` | Statement type: `POSTED` (posted) / `NOT_POSTED` (not yet posted) |
| `statementId` | Statement ID, used to drill down into the detail |
| `statementDateStart` / `statementDateEnd` | Start and end date of the billing period |
| `cardNumberLast4` | Last 4 digits of the card number |
| `cardOrganization` / `cardScheme` / `cardOrganizationLogo` | Card network / card scheme / card network logo |
| `debitAmountExcludePayment` | Actual spending on the statement, with repayments and fees already deducted |
| `paymentAmountInSgd` / `paymentAmountInUsd` | Repayment amount in SGD / USD |
| `nonPostedAmountInSgd` / `nonPostedAmountInUsd` | Not-yet-posted amount in SGD / USD |
### 1.2 Statement detail
Once you have a `statementId`, drill down into the individual line items of that statement.
```
GET /card/v2/statements/detail?externalUserId=usr_xxxxxxxx&cardId=card_xxxxxxxx&statementId=stmt_xxxxxxxx&page=1&rows=20
```
| Parameter | Type | Required | Description |
| ---------------------------------- | ------ | -------- | ---------------------- |
| `externalUserId` | string | Yes | User ID |
| `cardId` | string | Yes | Card ID |
| `statementId` | string | Yes | Statement ID |
| `page` / `rows` / `order` / `sort` | string | No | Pagination and sorting |
**Statement detail response** (redacted excerpt):
```json theme={null}
{
"code": "SYS_SUCCESS",
"message": null,
"messageDetail": null,
"data": [
{
"merchantName": "EXAMPLE COFFEE",
"postIndicator": 1,
"transactionDateTime": "2026-06-15 10:00:00",
"transactionAmount": 5.50,
"transactionCurrency": "SGD",
"postingAmountInSgd": 5.50,
"postingAmountInUsd": 4.05,
"debitCreditIndcator": "D",
"transactionType": "SPEND",
"mcc": "5814",
"merchantCountryCode": "702",
"transactionDescription": "EXAMPLE COFFEE SG",
"postedTransactionId": "posted_xxxxxxxx",
"assetMovements": [
{
"id": "asset_mvmnt_xxxxxxxx",
"asset": "USDC",
"amount": -4.05,
"movementTime": "2026-06-15 10:00:00",
"movementType": "DEBIT"
}
],
"assetMovementStatus": 1
}
]
}
```
**Key fields** (the API Reference remains authoritative for the complete field set):
| Field | Type | Description |
| ------------------------------------------------ | --------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `merchantName` | string | Merchant name |
| `postIndicator` | integer | Posting state: `1` = posted, `0` = not yet posted |
| `transactionDateTime` / `transactionDateTimeStr` | string | Transaction time / raw string (`yyyy-MM-dd HH:mm:ss`) |
| `transactionAmount` / `transactionCurrency` | number / string | Transaction amount / transaction currency |
| `postingAmountInSgd` / `postingAmountInUsd` | number | Posted amount in SGD / USD (dual currency) |
| `debitCreditIndcator` | string | Debit or credit direction (the field name keeps a historical typo; the intended name is debitCreditIndicator): `C` = credit (money in), `D` = debit (money out) |
| `transactionType` | string | `SPEND` (purchase) / `REFUND` / `PARTIAL_REFUND`. Note: the same-named webhook field uses a separate single-letter coding (R/C/Q/P) — do not mix the two |
| `mcc` | string | Merchant Category Code |
| `merchantCountryCode` | string | Merchant country code (3 digits, for example `702` for Singapore) |
| `postedTransactionId` | string | Posted transaction ID, usable for cross-checking with `transaction/id/resolve` |
| `assetMovements[]` | array | **DeCard-Managed only**: the user's asset movements. Each entry carries `id` (unique identifier), `asset` (asset type, such as USDC), `amount` (negative for a debit, positive for a refund), `movementTime` (time of the movement) and `movementType` (such as DEBIT or CREDIT) |
| `assetMovementStatus` | integer | Fund processing state: `1` = processing complete, `0` = incomplete |
> **`assetMovements` (DeCard-Managed only)**: in the DeCard-Managed model, every card purchase draws down the user's own wallet balance. `assetMovements` records **which asset funded it, how much was deducted and when**, which is a capability specific to the DeCard-Managed model.
## 2. Querying fiat transaction records (DeCard-Managed only)
Fiat transaction records are a view specific to the DeCard-Managed model: they aggregate every transaction, **credits, debits, repayments, disputes and stablecoin top-ups**, into one list retrieved by user, and they expose forensic fields for **on-chain deposits** (hash, network, asset, sending and receiving addresses). This is what end-to-end visibility of the "crypto → fiat → card spending" chain looks like in the DeCard-Managed model.
```
GET /card/v1/fiat/transactions?externalUserId=usr_xxxxxxxx&page=1&rows=20&order=time&sort=desc
```
| Parameter | Type | Required | Description |
| ---------------- | ------ | -------- | ------------------------------ |
| `externalUserId` | string | Yes | User ID |
| `page` / `rows` | string | No | Pagination |
| `order` | string | No | Sort field |
| `sort` | string | No | Sort direction: `asc` / `desc` |
A successful response (redacted excerpt):
```json theme={null}
{
"code": "SYS_SUCCESS",
"message": null,
"messageDetail": null,
"data": [
{
"debitCreditIndcator": "C",
"postingTransType": "CTU01",
"transactionAmount": "100.00",
"transactionCurrency": "USD",
"merchantName": "",
"transactionDateTime": "2026-06-15 10:00:00",
"postedTransactionId": "posted_xxxxxxxx",
"transferDetails": {
"channelCode": "fomo",
"txnAmt": 100.00,
"txnCcy": "USDC",
"sender": "0xSENDER_ADDRESS_REDACTED",
"receiving": "0xRECEIVING_ADDRESS_REDACTED",
"timeStamp": "1718438400",
"txHash": "0xTXHASH_REDACTED",
"network": "Polygon",
"asset": "USDC"
}
}
]
}
```
**Debit or credit direction, `debitCreditIndcator`** (the field name keeps a historical typo; the intended name is `debitCreditIndicator`): `C` = credit (money in) / `D` = debit (money out).
**Transaction type, `postingTransType`** (complete enumeration):
| Value | Meaning | Value | Meaning |
| ----- | -------------------- | ------- | ----------------- |
| `1` | Purchase | `9` | Dispute release |
| `2` | Cash | `M` | Memo transaction |
| `5` | Purchase fee | `A` | Purchase interest |
| `6` | Cash fee | `B` | Cash interest |
| `7` | Repayment | `N` | Annual fee |
| `8` | Dispute registration | `P` | Physical card fee |
| `R` | Card replacement fee | `CTU01` | Stablecoin top-up |
**Top-up information, `transferDetails`** (returned only for top-up transactions):
| Field | Description |
| ---------------------- | ----------------------------------------------------------------------------- |
| `channelCode` | Top-up channel: `fomo` (FOMO channel) / `icn` (ICN channel) |
| `txnAmt` / `txnCcy` | Top-up amount / top-up currency |
| `sender` / `receiving` | Sender / recipient (an on-chain address for `fomo`, a name for `icn`) |
| `timeStamp` | Transaction timestamp |
| `txHash` | Blockchain transaction hash (**`fomo` channel only**) |
| `network` | Blockchain network (**`fomo` channel only**, such as Polygon, Base or Solana) |
| `asset` | Asset currency (**`fomo` channel only**) |
> Deposit addresses and the currency and network configuration behind on-chain top-ups belong to the crypto deposit and withdrawal group and are not covered here. `txHash` lets you confirm receipt on a block explorer, which makes it an important anchor for reconciliation in the DeCard-Managed model.
## 3. Resolving transaction IDs
When you hold a transaction ID but are unsure whether it is **outstanding** or **posted**, resolve its posting state and linked IDs in bulk.
```
POST /card/v1/transaction/id/resolve
```
```json theme={null}
{
"ids": ["txn_xxxxxxxx", "txn_yyyyyyyy"]
}
```
| Field | Type | Required | Description |
| ----- | --------- | -------- | ---------------------------------------------------------------------------------------------- |
| `ids` | string\[] | Yes | List of transaction IDs (each may be an `outstandingTransactionId` or a `postedTransactionId`) |
The key fields of a successful response, where `data` is the list of resolution results:
| Field | Description |
| -------------------------- | ------------------------------------------------------------------------------------------------------------------------- |
| `id` | The original ID you passed in |
| `outstandingTransactionId` | Outstanding transaction ID; `null` when the transaction posted directly with dual messaging and has no outstanding record |
| `postedTransactionId` | Posted transaction ID; `null` while the transaction is still outstanding |
| `posted` | Boolean, whether the transaction has been posted |
> Why you need this: the same purchase can carry different IDs at the hold stage (outstanding) and at the posting stage (posted), and this endpoint ties the two ends together. For the concepts behind authorization and posting, see [Transaction Lifecycle · Overview](../../basic-concepts/transaction-lifecycle).
## Pagination, sorting and error handling
* **Pagination**: list endpoints all take `page` (page number) plus `rows` (items per page) in the query string, both as strings. Follow the field table of each endpoint on this page.
* **Sorting**: the endpoints that support `order` (sort field) plus `sort` (`asc` or `desc`) are statements, statements/detail and fiat/transactions.
* **Success check**: treat `code == SYS_SUCCESS` in the response envelope as the request being accepted; for any other value, read `message` and `messageDetail` for the reason. The envelope is documented in full in the [Authentication Guide](../../integration-resources/overview).
* **Time range**: when `startTime` and `endTime` are omitted, each endpoint applies its own default range. Pass them explicitly to keep response sizes under control.
## Capability notes
The DeCard-Managed model does not currently offer transaction memos or receipts. If you need to show memos or receipts in your own interface, store them on your side; adding the capability on the DCS side is a product decision, so raise it with the DCS team if you need it.
DCS does provide two views, **statement summaries** and **fiat transaction records including on-chain deposit forensics**, both covered in sections 1 and 2 above.
## Next steps
* To read a user's asset balances and crypto funding history, see [User Balance](./user-balance).
* To understand how a transaction travels from authorization to posting, see [Transaction Lifecycle · Overview](../../basic-concepts/transaction-lifecycle).
* Authorization decisions are made inside DCS and are never forwarded to you (forwarding belongs to the Partner-Managed model); see [Authorizing Transactions](./authorizing-transactions).