A reader sends the same message to support most weeks, in slightly different words. The bank app shows the money gone. The seller says no payment has arrived. Somebody, the reader reasonably concludes, must be lying.
Nobody is. Card payments happen in two stages separated by hours or days, and for the length of that gap the money is in a state most people have never had explained to them: reserved but not transferred, promised but not paid, visible on a statement and absent from every account it might belong to.
Two events wearing one name
We say "the payment went through" as if it were a single act. Technically it is two, and they can be days apart.
Authorisation is a question and an answer. The seller's processor asks your bank whether a specific amount on a specific card is good. Your bank checks the balance or credit line, runs its fraud rules, and replies with an approval code. That code is a promise that the funds exist and have been set aside. It moves no money.
Settlement — often called capture — is the seller telling the network to actually collect. Batches are usually submitted at the end of the trading day, funds move through the network over the following day or two, and the line on your statement changes from pending to posted.
Almost everything confusing about card payments lives in the distance between those two events. Refunds behave differently. Disputes behave differently. Even the text on your statement can change, which is a separate small mystery covered in what the descriptor on your statement is telling you.
Where the money actually is
The honest answer is that during an unsettled authorisation the money is nowhere. It has not moved. Your bank has simply marked part of your balance unavailable.
On a credit card this is easier to see for what it is: your available credit falls by the amount, but no debt has been created and no statement balance has changed. On a debit card the effect looks identical to a payment — the available balance drops — but the mechanics are the same. The funds are still in your account. You just cannot spend them.
Meanwhile the seller holds an approval code. They cannot draw on it at will and they cannot see your balance. What they can do is capture it, once, for up to the approved amount, within a window the network sets.
A hold is not an escrow. Nobody is holding your money on behalf of a deal in progress. Your own bank has drawn a line around part of your own balance, and it will rub the line out again if nothing happens.
This is why "when will the seller release my money" is the wrong question. The seller has none of it. The only thing the seller can release is the reservation, by voiding the authorisation — a message to the network saying the approval will not be used.
Why an authorisation stalls
Approved-then-nothing is not one failure mode. It is at least five, and they have different remedies.
The order never reached the seller. The card was approved and the browser died, the tab was closed, or a redirect back to the shop failed. The processor holds an approved transaction with no order attached to it. Nobody knows anything is wrong until you say so.
The seller captures manually. Plenty of small operations approve at the time of purchase and capture when the order is fulfilled. This is normal and legitimate, and it means a same-day purchase settles the next working day.
A review flagged it. Fraud screening at the processor can hold a transaction after approval, particularly on a first purchase, a cross-border card or a mismatched billing address. The checks doing the flagging are described in the security code, the billing address and the step-up check.
It was a verification charge, not a purchase. Some flows test a card with a tiny amount, or with a zero-value authorisation that still shows as a pending line at some banks. Those are voided immediately and vanish.
The capture failed. Rarer, but it happens: the approval expired before the seller submitted it, or a technical error dropped the batch. The reservation then falls off and the seller has been paid nothing at all — which they may not notice unless the order was never fulfilled.
How long a hold can legitimately last
There is no single number, which is the frustrating part. The window depends on the card network and the merchant category code attached to the seller's account, and neither is something the seller chooses per transaction.
| Situation | Typical window | What ends it |
|---|---|---|
| Ordinary online purchase | Captured within 1–2 days | Seller submits the batch |
| Approved, never captured | Falls away in about 7 days | Authorisation expires |
| Some travel and rental categories | Up to 30 days | Network rule for that category |
| Failed attempt, retried | 1–3 days | Bank drops the orphan reservation |
| Seller voids it | Minutes to 2 days | Void message reaches your bank |
Two practical points come out of that table. First, a void is faster than an expiry, so asking is worth doing. Second, even a void is not instant at your end — the message reaches your bank quickly, but how fast the app updates is your bank's business, and a weekend can add two days to anything.
Why debit cards make it hurt more
The mechanics are identical. The experience is not.
A hold on a credit card consumes headroom you were not using. A hold on a debit card consumes money you might need on Thursday. The same seven-day expiry window that is an abstraction on one card is a genuine problem on the other, especially if a failed attempt was retried and two reservations are sitting there at once.
That difference is one of several reasons a card and a wallet payment are not the same transaction wearing different clothes, a comparison set out in paying by card versus paying by wallet. It is also the practical case for putting an annual purchase on a credit card where you have one: the protections are stronger and a stuck authorisation costs you nothing you were going to spend.
Cryptocurrency has no equivalent state at all, and that cuts both ways. There is no pending limbo because there is no authorisation — but equally there is no reservation to release, no void, and no reversal. Once it confirms it is done, as described in crypto payments: fast, cheap, and completely final.
What to do while it sits there
In order, because the order matters.
Wait one working day. Most of these resolve themselves overnight when the seller's batch runs. Acting on the same evening you paid usually means acting on incomplete information.
Check what your app is actually showing. Pending and posted are displayed very differently by different banks, and some show a pending line in the same list as settled ones with no visual distinction at all. Look for the word, not the position in the list.
Message the seller with the identifying details, not the story. Date, time, exact amount, currency, last four digits, and whether the line reads pending. That set of fields is searchable in a processor log; a description of your afternoon is not. The full list of what makes a support message resolvable in one round is in what to send support so a payment problem is solved in one message.
Ask specifically for a void, not a refund. They are different operations. A refund against an uncaptured authorisation either fails or, worse, creates a second transaction that has to be untangled later. If the seller says they cannot see the payment at all, that is consistent with an order that never arrived, and the hold will expire on its own.
Do not pay again yet. A second attempt while the first is still reserved is how a single purchase becomes two live authorisations and a genuinely confusing statement. If a second payment does end up going through, the cleanup is routine and described in the cost of paying twice: duplicate orders and how they get resolved.
When it never settles at all
Sometimes the right outcome is that nothing happens. The reservation expires, your balance returns, and no money ever moved. If you did not receive the service, that is a clean result and there is nothing to recover — you were never charged.
The awkward case is the opposite: the service was delivered but the capture failed. You have what you paid for and the seller has an expired approval code. A straight operator will come back and ask you to pay again, and they should be able to show you that the first attempt never settled. Your own statement is the evidence for that, which is one more argument for keeping it, along with the rest of the short list in the paperwork worth keeping after you pay for a yearly service.
The case that deserves suspicion is a seller who insists money has been received while your bank shows a pending line, and who then asks for a second payment by a route with no recourse. That is a specific, recognisable pattern rather than a general worry, and it sits alongside the other signals in why a seller who only accepts irreversible payment is telling you something.
How we handle the gap
Our purchase is a single annual payment — $69, $97 or $137 for one, two or three simultaneous screens, with everything listed on the pricing page. One authorisation, one capture, no card retained afterwards, so there is no later reservation appearing against a stored card at a moment you were not expecting it.
Because ordering runs through chat rather than an on-site checkout, we see the order before the payment rather than after it — which is precisely the failure mode that strands most orphan authorisations. If your bank shows a pending line and you are not sure it reached us, message the desk with the date, amount and last four digits. If we have it, we will say so and it will settle. If we do not, we will tell you that too, and the reservation will fall away by itself. Which routes we accept, and how each behaves before it settles, is on the payment methods page.
