Transaction lifecycle - DCS Technical Documentation

📄 Guide

Whether you issue spend cards, withdrawal cards or multi-currency cards, every movement of money on a card follows the same path: authorization (hold) then settlement (the actual debit or refund). Once you understand this path, you can explain any balance change on an account and design your own reconciliation and limit logic around it. As the issuing platform, DCS forwards the decision to the partner during authorization and freezes or releases funds according to the answer; during settlement it records how the money actually moved and generates reconciliation files daily.

Two stages, three entities

Inside DCS, a transaction is expressed by three kinds of records working together. Keep their relationship in mind and every scenario that follows becomes just a different combination of the same model.

Entity	Stage	Role
Authorization	Authorization	The real-time decision recorded when the cardholder pays. An approval holds or releases funds, but never debits anything by itself
Outstanding	Both stages	The bridge between authorization and settlement. Held amounts accumulate on it during authorization and are drawn down during settlement until it reaches zero
Transaction	Settlement	The authoritative record of funds actually debited or credited, and the data behind the daily reconciliation files

Two IDs tie the three together: an authorization and its settlement share the same outsId (Outstanding ID), and a transaction record points back to one or more authorizations through authIds.

Transaction lifecycle: two stages, three entities

Stage 1: authorization (funds are held, never debited)

When a cardholder swipes, dips or taps at a merchant, the merchant estimates an amount and asks the card network for an authorization. No money moves at this point. DCS receives the request from the card network, forwards it to the partner for a real-time decision, and then holds or releases the corresponding amount according to that decision. The key attributes of an authorization record (see the authorization how-to for the full field list):

direction: OUTGOING holds funds (the cardholder pays) / INCOMING releases funds (reversal, refund).
authType: NORMAL ordinary authorization / FORCE_AUTH created by the system to backfill / EXPIRED_RELEASE release on expiry / STATUS_DIFF_RELEASE release on status mismatch.
approveFlag: A approved (funds are held) / D declined (no funds are touched).
outsId: generated with the first authorization. Later increments and reversals belonging to the same purchase reuse that outsId through originalAuthId.

The authorization decision belongs to the partner and draws on the corporate margin it has deposited with DCS. For why the money moves this way, see the funding model.

Stage 2: settlement (funds actually move)

Hours or days later the merchant submits the final amount to the card network and settlement begins. DCS creates a Transaction that records the funds actually debited (OUTGOING) or credited (INCOMING), and draws the Outstanding down accordingly:

The settled amount matches the held amount, so the Outstanding reaches zero and the transaction is closed.
The two differ (more, less, or split into several captures), so the system creates a FORCE_AUTH authorization to absorb the gap. See the scenarios below.

Each transaction record carries a category for business classification (RETAIL ordinary purchase / CASH cash withdrawal / CASH_FEES cash withdrawal fee / PAYMENT return or refund), and multiClearInd to show the progress of multiple captures. This record is the authoritative source for the daily reconciliation files.

One path, many combinations

In the real world an authorization and a settlement do not always match one to one: a merchant may add to the amount, reverse part of it, capture it in several pieces, or settle with no prior authorization at all. All of these are simply different ways of adding to and drawing down the Outstanding along the same authorization-then-settlement path. DCS defines 13 standard scenarios, which fall into the 9 mechanisms below. What distinguishes them is how the Outstanding moves:

Type	Scenario	How the Outstanding moves
Standard	Ordinary authorization then ordinary settlement (amounts match)	One increase, one draw-down, back to zero
Increment	Incremental authorization (a hotel adding charges, for example); several authorizations share one `outsId`	Several authorizations accumulate on the same Outstanding, which is drawn down in one settlement
Reversal	Partial reversal / full reversal	An `INCOMING` authorization releases the held amount (a full reversal produces no settlement entry)
Difference	Over-capture / under-capture	The settled amount differs from the held amount, so the system creates a `FORCE_AUTH` to absorb the difference
Split	Partial capture then final capture	The same Outstanding is drawn down by successive captures and closes when `multiClearInd=F`
No authorization	Forced capture / forced refund (offline transactions)	Settlement arrives first; the Auth and Outstanding are created afterwards
Inquiry / notification	Inquiry authorization, card verification (amount 0 or 1)	No funds are held, so the Outstanding does not change
Release	Release on authorization expiry / release on status mismatch	`EXPIRED_RELEASE` / `STATUS_DIFF_RELEASE` releases a held amount that was never settled
Withdrawal	Ordinary settlement plus a separate withdrawal fee flow	The principal and the fee are drawn down by two separate settlements

The invariant: whichever combination applies, the Outstanding converges to 0 once settlement is complete. That is what makes it usable as your reconciliation check: an outsId that has not returned to zero means the transaction still has an authorization or a settlement outstanding.

For the step-by-step sequence of each combination, including how authId, outsId and amounts change, see authorization and settlement scenarios, the authoritative walkthrough of all 13 cases. For the day-to-day reconciliation of the most common settlement deviations, such as partial, over and multiple captures, see settlement scenarios.

Next steps

To learn why funds are held and how the corporate margin backs them, read the funding model.
To handle a real authorization callback yourself, go to the authorization how-to and webhook events.

​📄 Guide

​Two stages, three entities

​Stage 1: authorization (funds are held, never debited)

​Stage 2: settlement (funds actually move)

​One path, many combinations

​Next steps