Capture scenarios: partial, excess and multiple

📄 Guide

Once an authorization is approved, the merchant does not necessarily debit the authorized amount in one go. The final settled amount may be smaller than, equal to or larger than the authorized amount, and it may arrive in several instalments. Whichever happens, DCS aligns the money automatically on the same authorization, Outstanding and transaction model, so all you have to follow are the webhooks you receive at each step and the daily reconciliation file. You never have to correct differences yourself. This page focuses on the three settlement deviations that come up most often and cause the most trouble, namely partial capture, excess capture and multiple captures, plus the closely related under capture and refund cases. All 13 combinations of authorization and settlement are in Authorization and settlement: every scenario; field and enumeration definitions are in Authorization and Transaction records.

Start with the three objects

Fund reconciliation at DCS rests on three objects. Once they are clear, every scenario below reads at a glance:

Object	Purpose	Key fields
Authorization	The limit decision taken before the transaction happens, placing or releasing a hold	`authId`, `authType`, `direction`
Outstanding	The unsettled balance, tracking held minus debited	`outsId`, `amount`
Transaction	The record the merchant’s actual settlement produces, a debit or a refund	`transactionId`, `authIds`, `outsId`, `multiClearInd`

One authorization, or several sharing the same record, creates or adds to an Outstanding.
Every settlement received draws the Outstanding amount down accordingly; reaching zero means the authorization is fully settled.
Whenever the settled amount differs from the amount held, DCS automatically back-fills a FORCE_AUTH authorization to top up or release the difference, so the Outstanding can always reach zero. This step is transparent to the partner.

Who does what: approve or decline at the authorization stage is the partner’s real-time decision (see Authorization); aligning funds at the settlement stage, back-filling differences and maintaining the Outstanding are all done automatically by DCS, and the results reach you in the daily transaction reconciliation file.

Scenario 1: partial capture

What it means: the merchant ends up debiting only part of the authorized amount, as when a petrol station pre-authorizes 100 and the actual fill comes to 80. This is the most common deviation and is entirely normal from the partner’s point of view. Action sequence (authorized 100, actually settled 80):

Step	direction	Amount	authType / identifier	Outstanding
1. Authorization approved	OUTGOING	100	`authId1` (NORMAL)	`outsId1` = 100
2. Under-capture back-fill	INCOMING	20	`authId2` (FORCE_AUTH)	100 → 80
3. Settlement debit	OUTGOING	80	`transactionId1`	80 → 0

What the partner does: once you read the settlement in the daily transaction reconciliation file, post the actual debited amount against its transactionId and release the surplus hold back to the cardholder. DCS releases the difference automatically through FORCE_AUTH, so you simply mirror what the reconciliation file tells you.

Scenario 2: excess capture

What it means: the final settled amount is larger than the authorized amount, for example a restaurant authorizing 100 and settling 110 after a gratuity, or a cross-currency exchange-rate move. Card network rules let merchants settle above the authorized amount within defined tolerances. Action sequence (authorized 100, settled 150):

Step	direction	Amount	authType / identifier	Outstanding
1. Authorization approved	OUTGOING	100	`authId1` (NORMAL)	`outsId1` = 100
2. Excess top-up hold	OUTGOING	50	`authId2` (FORCE_AUTH)	100 → 150
3. Settlement debit	OUTGOING	150	`transactionId1`	150 → 0

Steps 2 and 3 complete inside the same database transaction: DCS sees that the settled amount (150) exceeds the Outstanding (100), back-fills an OUTGOING FORCE_AUTH for the difference of 50, and then settles the whole amount.

Limit note: the excess consumes additional enterprise security deposit that the partner holds at DCS. A FORCE_AUTH true-up does not go through the authorization forwarding decision: it is driven by settlement and auto-approved, so the partner cannot decline at that step. To control excess exposure, keep a buffer in the limits you apply at the authorization decision stage.

Scenario 3: multiple captures

What it means: one authorization is matched by several settlements from the merchant, as when an order ships in batches and each batch is settled separately. All the captures share one Outstanding, and the multiClearInd field tells you how far along the series you are. Action sequence (authorized 100, settled as 60 plus 40):

Step	direction	Amount	Identifier	`multiClearInd`	Outstanding
1. Authorization approved	OUTGOING	100	`authId1` (NORMAL)	—	`outsId1` = 100
2. First capture	OUTGOING	60	`transactionId1`	`P`	100 → 40
3. Final capture	OUTGOING	40	`transactionId2`	`F`	40 → 0

The multiClearInd enumeration (see Transaction records):

Value	Meaning
`O`	Ordinary single capture, no series
`P`	Not the last capture of a series: draws the Outstanding down without checking the difference
`F`	The series is complete: the last capture, and the point at which the difference is checked and trued up

Illustration: how two captures look in the daily transaction reconciliation file (fields taken from the transaction records file schema; captures in one series share the same authIds and outsId, and multiClearInd distinguishes P from F):

[
  {
    "transactionId": "1109900000000000001",
    "direction": "OUTGOING",
    "outsId": "1109800000000000001",
    "authIds": "1109700000000000001",
    "amount": "60.000000000000000000",
    "currency": "840",
    "category": "RETAIL",
    "multiClearInd": "P"
  },
  {
    "transactionId": "1109900000000000002",
    "direction": "OUTGOING",
    "outsId": "1109800000000000001",
    "authIds": "1109700000000000001",
    "amount": "40.000000000000000000",
    "currency": "840",
    "category": "RETAIL",
    "multiClearInd": "F"
  }
]

This is an illustrative record built from the fields of the transaction file (settlement has no request or response endpoint of its own and is delivered through the daily reconciliation file, see Transaction records: how to get them). It shows only the key fields of the P record (not the last) and the F record (the last) under one authorization, and omits merchant, timestamps and the remaining fields.

What the partner does: seeing multiClearInd = P, do not rush to treat the Outstanding as settled; only F means the authorization has settled in full. If a difference remains after F, DCS back-fills a FORCE_AUTH following the logic of scenarios 1 and 2.

What it means: the cardholder returns goods and the money comes back from the merchant to the card. A refund is an incoming transaction in the INCOMING direction.

With an original authorization: DCS finds the original authId and outsId and creates an INCOMING refund transaction against the same Outstanding.
Without an original authorization (forced or offline refund): DCS creates a new Outstanding (amount = 0) purely for linkage, creates the refund transaction and does not back-fill an authorization.

Refunds appear in the daily transaction reconciliation file as direction = INCOMING with category = PAYMENT (return or refund).

Reconciliation at a glance

Put the three scenarios side by side and the pattern is obvious: the Outstanding always converges to 0.

Scenario	Authorized	Settled	Difference handling
Partial / under capture	100	80	INCOMING `FORCE_AUTH` releases 20
Excess capture	100	150	OUTGOING `FORCE_AUTH` holds a further 50
Multiple captures	100	60 + 40	`P` accumulates, `F` closes
Refund	—	INCOMING credit	New Outstanding created for linkage

The standard approach when the partner reconciles: use outsId to link authorization to settlement and authIds to link a transaction back to its authorizations (with several authorizations, authIds is comma-separated, for example 1111,2222), post the actual funds against transactionId, and finish by confirming the Outstanding has reached zero.

Additional notes

The daily transaction file uses full names for category (RETAIL, CASH, CASH_FEES, PAYMENT and so on); see Report field dictionary for the complete enumeration. The transactionType=R/C/Q/P values on the authorization side belong to a different field, so do not mix them up.
Excess capture differences are aligned automatically by DCS through FORCE_AUTH; to control excess exposure, keep a buffer at the authorization decision stage (see the limit note in scenario 2).
The OUTGOING + FORCE_AUTH raised for a difference does travel over the authorization notification channel, but it is a notification plus a forced posting, not a fresh request for consent. Declining it does not cancel the posting.

Next steps

To see all 13 combinations of authorization and settlement (including incremental authorizations, reversals, expiry releases, status mismatch releases and withdrawal fees): Authorization and settlement: every scenario
To check fields and enumerations: Authorization and Transaction records
To reproduce these captures in the sandbox: Simulating transactions

​📄 Guide

​Start with the three objects

​Scenario 1: partial capture

​Scenario 2: excess capture

​Scenario 3: multiple captures

​Related scenario: refund

​Reconciliation at a glance

​Additional notes

​Next steps