Reporting Field Descriptions

The richest source of fields is the statement detail endpoint GET /card/v2/statements/detail, so it forms the main table here, supplemented by the fields of fiat transaction records GET /card/v1/fiat/transactions. How to query each endpoint, its prerequisites and its pagination rules are covered in Managing Transactions · Overview and are not repeated here; this page is about fields only.

Why this is not a CSV column dictionary: in the DeCard-Managed model, data comes back as JSON from real-time query APIs, and there is no offline artefact such as a daily full reconciliation file. This page therefore documents API response fields, not file columns. Whether daily reconciliation files are offered to partners is a product decision, so raise it with the DCS team if you need one.

Prerequisites

Your Enterprise account is live and you hold an ApiKey and SecretKey; see First Steps and the Authentication Guide.
The end user holds an externalUserId (see Signing Up a Customer) and a card (a cardId, see Issuing Cards).
The externalUserId, cardId, card numbers, merchant names and postedTransactionId values in every example on this page are placeholders or redacted. Never put real end-user PII in a request or a log.

Field conventions (site-wide)

Before you store anything, note the following conventions of the DeCard-Managed model:

Dimension	DCS convention
Amount unit	High-precision decimals with a currency (such as `transactionAmount: 12.34` or `postingAmountInUsd: 12.34`), not minor-unit integers, and with no `×10^6` scaling
Debit or credit direction	`debitCreditIndcator`: `C` = credit (money in) / `D` = debit (money out)
Posting state	`postIndicator`: `1` = posted / `0` = not yet posted (see “Posted versus outstanding” below for the semantics)
Card number	The field name is `cardNumber` (a masked card number); the statement list uses `cardNumberLast4` (the last 4 digits)
MCC	The field name is `mcc`, the Merchant Category Code
Country code	`merchantCountryCode`, the merchant country code
Response envelope	Site-wide `{code, message, messageDetail, data}`, with no `success` boolean; the success code is `code = SYS_SUCCESS`. `messageDetail` is a structured object `{message, title, type, icon, action, linkTitle, linkUrl}` (it carries front-end prompts, action buttons and links; on a successful request every sub-field is an empty string `""`, not `null` and not omitted, while on a business exception or when user action is needed the system fills in the relevant fields), so it is not always `null`

The field set of the DeCard-Managed model is exactly what the tables on this page describe. Columns such as authorizationAmount, settlementAmount, interchangeAmount(×10^6), cardLast4, isThreeDSecureTransaction, walletName and foreignExchangeFees do not exist in this model, so do not build your schema around them.

1. Statement detail field dictionary (main table)

A redacted sample response, where data is an array of the line items in the statement:

{
  "code": "SYS_SUCCESS",
  "message": "",
  "messageDetail": {
    "message": "",
    "title": "",
    "type": "",
    "icon": "",
    "action": "",
    "linkTitle": "",
    "linkUrl": ""
  },
  "data": [
    {
      "merchantName": "EXAMPLE MERCHANT",
      "mcc": "5411",
      "merchantCountryCode": "702",
      "transactionType": "R",
      "cardOrganizationLogo": "https://example.com/logo.png",
      "postIndicator": 1,
      "transactionDateTime": "2026-06-15 10:00:00",
      "postingAmountInSgd": 0.00,
      "postingAmountInUsd": 12.34,
      "debitCreditIndcator": "D",
      "transactionDescription": "POS PURCHASE",
      "cardNumber": "************0000",
      "postingDate": "2026-06-16",
      "transactionAmount": 12.34,
      "transactionCurrency": "USD",
      "externalTranId": 0,
      "cardOrganization": "VISA",
      "postedTransactionId": "posted_xxxxxxxx",
      "cardScheme": "Visa Platinum",
      "systemTraceAuditNumber": "000000",
      "transactionDateTimeStr": "2026-06-15 10:00:00",
      "assetMovements": [
        {
          "id": "00_xxxxxxxx",
          "asset": "USDC",
          "amount": -12.34,
          "movementTime": "2026-06-15 10:00:01",
          "movementType": "DEBIT"
        }
      ],
      "assetMovementStatus": 1
    }
  ]
}

At runtime the success code literal is SYS_SUCCESS (identical in both integration models). Judge success and failure against the runtime values shown in the examples on this page.

Field	Type	Meaning and values
`merchantName`	string	Merchant name
`mcc`	string	Merchant Category Code (MCC)
`merchantCountryCode`	string	Merchant country code
`transactionType`	string	Card transaction type; for the values, see “Transaction type” below
`cardOrganizationLogo`	string	Card network logo image URL
`postIndicator`	integer	Posting state: `1` = posted / `0` = not yet posted
`transactionDateTime`	string	Transaction time
`postingAmountInSgd`	number	Posted amount in SGD (high-precision decimal)
`postingAmountInUsd`	number	Posted amount in USD (high-precision decimal)
`debitCreditIndcator`	string	Debit or credit direction: `C` = credit (money in) / `D` = debit (money out)
`transactionDescription`	string	Transaction description
`cardNumber`	string	Card number (masked)
`postingDate`	string	Posting date
`transactionAmount`	number	Transaction amount (high-precision decimal, paired with `transactionCurrency`)
`transactionCurrency`	string	Transaction currency
`externalTranId`	integer	External transaction ID
`cardOrganization`	string	Card network name (such as `VISA`)
`postedTransactionId`	string	Posted transaction ID (present once the transaction has posted)
`cardScheme`	string	Card scheme type (such as `Visa Platinum`)
`systemTraceAuditNumber`	string	System trace audit number (STAN)
`transactionDateTimeStr`	string	Raw transaction time string, formatted `yyyy-MM-dd HH:mm:ss`
`assetMovements`	array	The user’s asset movements, see “Asset movements” below
`assetMovementStatus`	integer	Asset processing state: `1` = funds processed / `0` = funds not yet processed

Transaction type (`transactionType`)

transactionType groups the posting type into the following four categories, using the same single-letter encoding as the same-named field in the CARD_TRANSACTION / CARD_TRANSACTION_SETTLEMENT webhooks:

Enum value	Meaning
`R`	Purchases: ordinary purchases, plus purchase-related fees, annual fees, physical card fees, card replacement fees and purchase interest
`C`	Cash withdrawals: ordinary withdrawals, plus cash fees and cash advance interest
`P`	Repayments, plus dispute registration and dispute release
`Q`	Memo transactions that do not affect the cardholder’s balance

Read the debit/credit direction from debitCreditIndcator, not from transactionType.

Asset movements (`assetMovements[]`)

Specific to the DeCard-Managed model: every card transaction carries the movements of the underlying user assets (stablecoins) behind it, which is part of end-to-end visibility across the “crypto → fiat → card spending” chain.

Field	Type	Meaning
`id`	string	Unique identifier of the asset movement (the last two digits of `userId` plus an auto-increment ID within the shard)
`asset`	string	Asset type (such as `USDT` or `USDC`)
`amount`	number	Amount moved: negative = a deduction, positive = a refund
`movementTime`	string	Time of the movement
`movementType`	string	Movement type (such as `DEBIT` or `CREDIT`)

2. Fiat transaction record fields (supporting)

The key fields follow the same conventions as the rest of this page: debitCreditIndcator (C/D), transactionAmount (a high-precision decimal paired with transactionCurrency), postedTransactionId and merchantName. Its transaction type field is postingTransType (for example CTU01 for a stablecoin top-up), whose enumeration is in Overview (section 2).

The same field name has different types across endpoints: transactionAmount on this endpoint, GET /card/v1/fiat/transactions, is a string amount, whereas transactionAmount in statement detail (GET /card/v2/statements/detail) is a number. When storing fiat transaction records, parse transactionAmount as a string first and then convert it to a high-precision decimal; do not assume it is numeric.

Posted versus outstanding

The DeCard-Managed model has no daily report file, so “has this transaction finally settled” is expressed through the posting state fields:

Dimension	Field and values	Meaning
Line item posting state	`postIndicator = 1` / `0`	`1` = posted (settlement complete, the amount is final) / `0` = not yet posted (still an authorization hold, the amount may change)
Statement type	`type = POSTED` / `NOT_POSTED`	The statement list (`/card/v2/statements`) groups and totals by posted and not yet posted, see Overview · Querying statements
Linking the two	`postedTransactionId`	The posted transaction ID of a posted record; `POST /card/v1/transaction/id/resolve` ties the outstanding and posted ends of the same purchase together

Reconciliation rule: treat posted records (postIndicator = 1 / POSTED) as the authoritative basis for final settlement of funds. Outstanding records are authorization holds whose amounts may still change at settlement, so they cannot be treated as deductions. For the concepts behind authorization and posting, see Transaction Lifecycle · Overview.

Notes on the reported data

Delivery: JSON returned by real-time query APIs; no daily report files or reconciliation CSV downloads are offered.
Amount unit: high-precision decimals with a currency, unscaled.
Posting: expressed through postIndicator and POSTED.
Distinctive fields: assetMovements (movements of the underlying stablecoin assets), postingAmountInSgd and postingAmountInUsd (dual-currency posted amounts), and the on-chain deposit forensic fields in the fiat transaction records.

Next steps

For which endpoints return these fields and how to query and paginate them, see Managing Transactions · Overview.
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.

Getting Started

Basic Concepts

How to Use

Integration Resources

Customer Success

Prerequisites

Field conventions (site-wide)

1. Statement detail field dictionary (main table)

Transaction type (`transactionType`)

Asset movements (`assetMovements[]`)

2. Fiat transaction record fields (supporting)

Posted versus outstanding

Notes on the reported data

Next steps

​Prerequisites

​Field conventions (site-wide)

​1. Statement detail field dictionary (main table)

​Transaction type (transactionType)

​Asset movements (assetMovements[])

​2. Fiat transaction record fields (supporting)

​Posted versus outstanding

​Notes on the reported data

​Next steps

Prerequisites

Field conventions (site-wide)

1. Statement detail field dictionary (main table)

Transaction type (`transactionType`)

Asset movements (`assetMovements[]`)

2. Fiat transaction record fields (supporting)

Posted versus outstanding

Notes on the reported data

Next steps