---
title: "Capture"
url: "https://mahouse.world/glossary/capture"
type: "glossary term"
topic: "Transaction lifecycle"
author: "Ihor Vlasov"
reviewed: "2026-09-20"
published: "2026-08-10"
---

# Capture

Capture is the merchant's confirmation that an authorised payment should be taken — the instruction to the acquirer that turns the issuer's hold into a charge by submitting the transaction for clearing. It may be for the full amount, for less with the balance released, or in several parts as an order ships; it must happen within the authorisation's window, and until it does the merchant has approval but no money.

**Also known as:** Payment capture, Settlement request, Capturing a payment

## Key facts

- **Used at:** every card transaction; immediate capture ("auth and capture" in one) for goods delivered at once, delayed capture for goods shipped later, services rendered later, and amounts finalised later
- **Binding:** the schemes' rules on capture timing (within the authorisation's validity — 7 days for most, longer for some categories), on capture amounts relative to the authorisation (tolerances by category; a capture above the authorised amount may be declined or subject to a new authorisation), and on multiple captures against one authorisation (permitted where the merchant category and scheme allow)
- **Typical timing:** daily batch capture by most merchants (the day's captures submitted at a cut-off), or per-event capture at dispatch; clearing that night, settlement after
- **Typical failures:** capture after the authorisation expired (declined; the merchant must re-authorise and may be declined); capture twice (duplicate charge and a chargeback); capture for the wrong amount; captures never submitted (revenue never collected — found in reconciliation)
- **Parties:** the merchant (which instructs), the PSP or gateway (which submits), the acquirer (which clears), the issuer (which converts the hold to a charge), and the cardholder whose pending becomes posted

## How capture works in practice

A merchant's order system authorises €120 at checkout and stores the authorisation reference. When the warehouse scans the parcel out, the system sends a capture for €120 against that reference; the PSP includes it in the day's clearing submission; the acquirer clears it; the issuer posts €120 to the cardholder's account and releases the hold. If only one of two items shipped, the system captures €70 and, depending on the scheme's rules for the merchant's category, either captures the remaining €50 later against the same authorisation or authorises afresh when the second item ships. If the order is cancelled, nothing is captured and the authorisation is voided.

The discipline is operational. Captures must go out within the window, at the right amount, once. A merchant whose fulfilment lags the window re-authorises and loses the sales that decline the second time; one whose systems capture on both the order event and the shipment event charges twice; one whose capture batch fails silently on a Friday collects nothing for the weekend's orders until reconciliation finds the gap. PSPs offer automatic capture for merchants that do not need the split, and most small merchants use it.

For a finance team, capture is the moment revenue becomes collectable; for payments engineers, it is the second half of the API that the first half's simplicity hides.

## Example

An electronics retailer authorises at order and captures at dispatch. A deploy introduces a bug: the capture call fires on order confirmation and again on dispatch. Over a weekend 3,200 orders are captured twice — €480,000 — before Monday's reconciliation flags 3,200 settled items with no matching order line. The retailer refunds every duplicate by Tuesday (three days of fees and float on €480,000), 140 customers have already raised chargebacks for "duplicate charge", and its acquirer's risk team asks for a written explanation. The rebuild adds an idempotency key per capture, a rule that a capture cannot exceed the outstanding authorised amount, and a daily check that captures equal dispatches. The bug had been in production for fourteen hours.

## Common mistakes

- Capturing after the authorisation window and discovering the re-authorisation declines.
- Duplicate captures from two events in the order flow.
- Partial captures that leave the balance on hold with no reversal.
- Capture batches that fail without an alert.
- Capturing at order for goods that ship in a week, and refunding the cancellations that a void would have handled for free.

## Related terms

- [Authorisation and Capture](https://mahouse.world/glossary/authorisation-and-capture.md)
- [Authorisation Hold](https://mahouse.world/glossary/authorisation-hold.md)
- [Void](https://mahouse.world/glossary/void.md)
- [Clearing](https://mahouse.world/glossary/clearing.md)
- [Refund](https://mahouse.world/glossary/refund.md)
- [Transaction Lifecycle](https://mahouse.world/glossary/transaction-lifecycle.md)

— Ihor Vlasov, M&A FinTech Expert. Last reviewed 2026-09-20. https://mahouse.world/authors/ihor-vlasov