Loading
Related Articles
Related Articles
TrustFinance Research Team
Oct 12, 2026
6 min read
7
Authorized usually means that an eligible payment flow has approved and reserved an amount on the customer's payment method. Captured means collection has moved beyond that authorization-only stage. Neither label alone proves that your merchant bank has received a payout.
Read your provider's definitions before acting. A capture request, an accepted request and its final processing result can be different events. Labels used below describe stages; providers do not all use identical status names.
A card statement may display a temporary hold much like a completed charge. The customer's screenshot is useful context, but match it to the provider's payment history rather than marking an order paid from appearance alone.
Keep the order identifier, authorization reference and capture reference connected. Then reconcile separate settlement and payout records. One sales-dashboard total cannot answer whether every transaction has reached your bank.
| Stage | What to verify | What it does not prove |
|---|---|---|
| Authorized | Eligible reservation and actual expiry | Merchant bank receipt |
| Capture requested | Request reference and processing result | Successful completion from acknowledgment alone |
| Captured | Provider-confirmed capture status and later history | Settlement, payout or freedom from disputes |
| Settlement | Provider's balance or settlement record | Funds already credited to your bank |
| Payout | Payout reference matched to bank receipt | Receipt merely because a payout was sent |
First check that the payment method, merchant account and transaction support separate capture. Some methods collect automatically or do not offer manual capture. A card capability must not be assumed for bank debits or every wallet.
Confirm the actual capture setting for this transaction. Automatic, delayed automatic and manual capture create different responsibilities. An account default can differ from a permitted transaction-level setting; an order confirmation is not a substitute.
Find the transaction's actual expiry timestamp and its time zone. Card network, transaction type, geography and provider rules can affect validity. Do not apply a universal seven-day or 28-day deadline to every payment.
Extended authorizations and repeated partial captures are conditional features. Check current eligibility and enabled settings before relying on them. A long delivery schedule does not itself extend an existing hold.
Verify the currency, authorized amount, current capturable amount and matching reference before capture. A canceled or expired authorization, an unsupported amount or a mismatched currency can prevent the operation.
An asynchronous acknowledgment is not completion. Adyen, for example, distinguishes a received capture request from its webhook result, and documents possible later CAPTURE_FAILED events. Check the actual result and subsequent history.
Imagine an eligible card order for 1,200 currency units. Authorization occurs on Day 1 at 10:00 UTC; a capture example follows on Day 2 at 10:00 UTC. Assume expiry is Day 3 at 18:00 UTC. All amounts and times are invented.
At the first stage, record 1,200 authorized and zero captured. This is a customer-side reservation, not 1,200 of merchant cash or a merchant processing reserve. Fees and tax are excluded from the model, not assumed free in reality.
In the partial-capture branch, assume the provider confirms capture processing for 900 and this fictional flow permits only one partial capture. The unused 300 is canceled or released under that assumption: 1,200 minus 900 equals 300.
In an alternative branch, the merchant cancels the full authorization before any capture. The 1,200 hold follows the supported cancellation/release process. There is no captured payment to refund in this branch; visible bank release timing is unspecified.
In another alternative, no capture occurs before the fictional deadline. The authorization expires, so that hold cannot simply be captured afterward. A new authorization, where permitted, needs the proper provider process and customer permissions.
The branches are alternatives, not amounts to add together. The unused 300 in our partial-capture model is not a refund from the captured 900. Capture confirmation still needs separate settlement and bank-payout checks.
| Alternative branch | Captured amount | Unused authorization | Separate check |
|---|---|---|---|
| Partial capture on Day 2 | 900 | 300 canceled/released under the assumed single-capture rule | Capture result, settlement and bank receipt |
| Cancel before any capture | 0 | 1,200 follows cancellation/release | Provider and customer bank release state |
| No capture before Day 3 18:00 UTC | 0 | 1,200 expires under the fictional deadline | Any new payment needs a valid process |
Set a documented fulfillment policy for your business and payment method. Some supported flows capture around shipment; others differ. Do not promise delivery or financial protection merely because the provider approved an authorization.
If capture fails or the result is uncertain, inspect the original payment history before retrying or creating another charge. Match references and amounts so customer support does not accidentally initiate duplicate collection.
Once a payment has been captured, use the provider's supported refund or reversal process when appropriate. Canceling an order in your shop system does not, by itself, cancel an authorization or return a collected payment.
If the customer still sees a hold after cancellation, provide the permitted transaction reference, amount and timestamps for provider or bank follow-up. Do not promise instant release or ask for full card credentials.
Not necessarily. Issuer displays can blur the difference between a reservation and a posted charge. Compare the exact payment, capture and cancellation states; explain the current evidence without promising a bank's processing time.
Only if the actual flow supports further captures and the authorization remains usable. Our example explicitly allows one partial capture and releases the remainder. Do not treat those 300 units as automatically available for another capture.
After identifying the capture state, read Settlement, refunds and chargebacks for settlement and bank cash, and Payment gateway total costs for fees and restricted merchant funds. Find further neutral guides in TrustFinance Blog.
Official pages below illustrate provider-specific mechanisms checked on 12 October 2026. They do not establish universal deadlines, local consumer rights or guaranteed receipt. Confirm current terms for your own contracting entity, account and payment method.
TrustFinance Research Team
Official TrustFinance research and editorial team, sharing insights, analysis, and best practices to help financial companies and traders build transparency, credibility, and growth.
