> ## 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.
# Capture scenarios: partial, excess and multiple
> Mapped to multi / partial / over-capture.
## 📄 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](./auth-and-settlement); field and enumeration definitions are in [Authorization](./authorization) and [Transaction records](./transaction).
***
## 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](./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](../../basic-concepts/fund-model) 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](./transaction)):
| 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](./transaction) file schema; captures in one series share the same `authIds` and `outsId`, and `multiClearInd` distinguishes `P` from `F`):
```json theme={null}
[
{
"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](./transaction)). 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.
***
## Related scenario: refund
**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 | Outstanding, final |
| ----------------------- | ---------: | --------------: | ---------------------------------------- | -----------------: |
| Partial / under capture | 100 | 80 | INCOMING `FORCE_AUTH` releases 20 | 0 |
| Excess capture | 100 | 150 | OUTGOING `FORCE_AUTH` holds a further 50 | 0 |
| Multiple captures | 100 | 60 + 40 | `P` accumulates, `F` closes | 0 |
| Refund | — | INCOMING credit | New Outstanding created for linkage | 0 |
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](../reports/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](./auth-and-settlement)
* To check **fields and enumerations**: [Authorization](./authorization) and [Transaction records](./transaction)
* To **reproduce these captures** in the sandbox: [Simulating transactions](../sandbox/simulating-transactions)