Managing Transactions · Overview - DCS Technical Documentation

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

Three transaction and statement query entry points

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 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 and the Authentication Guide.
The end user is registered (you hold an externalUserId, see Signing Up a Customer) and holds a card (you hold a cardId, see 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:

{
  "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):

{
  "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):

{
  "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

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

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.
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.
To understand how a transaction travels from authorization to posting, see Transaction Lifecycle · Overview.
Authorization decisions are made inside DCS and are never forwarded to you (forwarding belongs to the Partner-Managed model); see Authorizing Transactions.

​One place to query, three views

​Prerequisites

​1. Querying statements

​1.1 Statement list

​1.2 Statement detail

​2. Querying fiat transaction records (DeCard-Managed only)

​3. Resolving transaction IDs

​Pagination, sorting and error handling

​Capability notes

​Next steps