An expired authorisation is not a captured payment
An internal order screen can say “paid” because the first provider step succeeded, even though the business never captured the authorised funds. If the authorisation later expires, that label can lead staff to release an order on evidence that no longer supports the action.
The following fictional investigation concerns an inspected card-payment arrangement with separate authorisation and capture. The merchant's eligibility and supported provider operations are assumed to have been established for the example. It is not a recommendation of a provider for every Lebanese business, a universal capture window or advice about the merchant's accounting treatment.
Identify the order and the provider evidence
Order O-42 is an unfulfilled order for an approved total of USD 240. Its related authorisation A-42 initially succeeded. The integration then set the local payment label to “Paid,” although its selected process required a later capture.
At 12:30 UTC on 3 November 2026, the responsible operator inspects the actual related provider record. Its documented capture deadline was 12:00 UTC that day. The provider now reports the payment as cancelled following expiry, with no captured amount and no amount remaining available for capture.
The investigation retains the original order reference, authorisation reference and events. It does not assume that a similar amount elsewhere belongs to O-42 or that an old authorisation-success message describes the current state.
| Evidence for O-42 at inspection | Recorded value or finding |
|---|---|
| Approved order amount | USD 240 |
| Earlier authorisation | A-42 succeeded under separate-capture flow |
| Provider capture deadline | 3 November 2026, 12:00 UTC |
| Inspection time | 3 November 2026, 12:30 UTC |
| Current provider payment state | Cancelled after uncaptured authorisation expired |
| Captured amount | USD 0 |
| Local application label before correction | Paid |
| Fulfilment | Not dispatched |
The current evidence does not establish a refund. There was no captured amount in this fixture to refund.
Locate the incorrect decision
The local mapping treats successful authorisation as final payment success. It also leaves the label unchanged when the uncaptured authorisation expires. This is a business-state interpretation error, not a currency-format or exchange-rate calculation.
Stripe's separate authorisation and capture documentation provides one concrete provider contract: for relevant card payments it exposes a capture deadline, describes requires_capture after authorisation and explains that an uncaptured expiry releases the hold and changes the payment status to canceled. The exact method and account capabilities must still be inspected. Other payment methods have their own rules.
The example follows that documented distinction without applying a generic number of days to every transaction. The deadline comes from the relevant provider evidence. A local calendar guess or an earlier browser success screen cannot extend it.
Make the order disposition explicit
Maya, the fictional merchant's authorised operations owner, checks that O-42 has not been dispatched. She changes its internal payment condition to “Authorisation expired; no captured payment recorded” and its operational state to “Awaiting agreed payment arrangement.” The dispatch block remains in place.
She also records an action to contact the customer through the merchant's approved process. No replacement payment, capture or refund is initiated by this investigation. The business must agree the appropriate next arrangement and use the provider's supported process if a new payment is required.
The order itself remains identifiable. It is not silently deleted, marked refunded or changed to another customer's payment. The correction removes a false basis for fulfilment while preserving the evidence needed to discuss what happens next.
Check the valid and completed alternatives
A correction that labels every order unpaid would be equally misleading. The test set includes two contrasting provider records inspected at the same time:
| Record | Relevant provider evidence | Correct local interpretation |
|---|---|---|
| O-42 / A-42 | Expired uncaptured authorisation; cancelled; captured USD 0 | No captured payment recorded; named commercial follow-up; dispatch held |
| O-43 / A-43 | Still requires_capture; capture deadline is later; authorised amount remains available |
Authorised and awaiting permitted capture decision, not paid |
| O-44 / A-44 | Supported success evidence confirms USD 240 captured for this order | Captured payment recorded; fulfilment still follows the merchant's separate rules |
The local rule now distinguishes all three. It does not capture O-43 just because its authorisation is still valid. It does not erase O-44's captured evidence or create a refund. Opening the administrative view does not itself initiate any financial operation.
The repeated check of O-42 leaves the same order and the same follow-up action. It does not create a fresh charge each time the provider's expired state is observed.
Give staff and customers the meaning they need
An operator needs the relevant references, current evidence and permitted next action. A customer-facing message should explain the actual unresolved arrangement without promising that money was refunded or that a new payment has been taken. Wording must follow the merchant's approved process and what the provider has established.
The enquiry or checkout should also distinguish a requested currency from an approved payable amount. Clear formatting matters, but it cannot repair a wrong interpretation of the event behind the number.
Before commissioning online ordering, bring the supported provider states, merchant decisions and a controlled expired-authorisation example. Ask the team to show what happens to the existing order, what remains unchanged and who may authorise a new action. That is stronger evidence than a checkout demonstration that ends at the first successful response.