That sequence can look like money moved twice. It may instead be one card payment that passed authorisation but never completed capture. An approved card deposit normally means the issuer allowed the payment to proceed; it does not always mean the funds were captured, settled to the operator or safe from a later dispute.
The useful question is therefore not simply “was it approved?” It is which system approved which step, and whether the operator credited the wallet before the card payment reached its next durable state.
Approved is permission, not final settlement
Card payments move through states rather than one universal “success” moment. Authorisation is the issuer’s approval to reserve funds for a proposed payment. Capture is the merchant-side instruction that moves the authorised amount toward clearing and settlement. A reversal can release an authorisation before capture; after capture, returning money is usually handled as a refund instead.
Adyen’s current payments-lifecycle documentation separates `Authorised`, `Cancelled`, `Expired` and later capture or settlement states. Its capture guide also warns that, in rare cases, a capture can fail after a valid capture request has already been submitted to the card scheme. Those are Adyen implementation labels, not a vocabulary every processor must copy.
The same boundary appears in Stripe’s PaymentIntent documentation: a manual-capture payment places a hold when the customer authorises it, then waits for a separate capture. The visible bank hold is evidence of that reservation. It is not a receipt proving that the operator has settled cash.
| Payment state | What may be visible | What is not yet proved |
|---|---|---|
| Authorised | Bank hold, provider approval, possible wallet credit | Capture or settlement |
| Cancelled or expired | Hold released; provider moves to a final pre-capture state | A refund, because captured funds may never have moved |
| Captured | Provider accepted the capture request | Final bank settlement in every integration |
| Settled | Provider includes the payment in merchant funds | Immunity from a later refund or chargeback |
This is why iGaming payment reconciliation needs separate provider, player-ledger, settlement-batch and bank records. “Success” in one row cannot silently stand in for all four.
A pre-capture reversal is not a refund
When a merchant or payment system cancels an authorised payment before capture, the issuer can release the reserved amount. Adyen calls cancellation an authorisation reversal and says that cancelling an uncaptured payment releases the funds back to the shopper’s bank account in its cancellation guide.
Worldpay’s public Card Payments API likewise exposes authorisation, cancellation, settlement, refund and reversal as different payment actions. The field names and timing vary by integration, but the separation matters: undoing a reservation is not the same accounting event as sending captured money back.
Bank interfaces often compress that distinction. A pending line may vanish rather than reappear as a positive credit. Another issuer may keep the hold visible while the release works through its own systems. The exact release time belongs to the issuer and payment route; an operator should not promise a universal number of hours from a processor example.
The cashier can credit before the rail is finished
A gambling wallet is an internal ledger, not the card network. The operator chooses which provider event is strong enough to create spendable balance and how to handle an event that later changes state.
That creates two valid but different clocks:
the payment processor tracks authorisation, capture, cancellation, settlement and later disputes;
the operator tracks deposit attempts, wallet credits, bets, withdrawals and account controls.
If the cashier credits on an early provider signal, a later cancellation or capture failure needs a compensating wallet entry. Deleting the original credit would hide what the player saw and what happened between the two events. Appending a separate reversal preserves the chronology.
DraftKings’ current US deposit-decline help separates insufficient-funds cases from bank declines and tells readers to review pending charges. That does not establish a reversal rule. It shows the narrower point: a failed operator-side deposit attempt can coexist with a card-side entry that still affects the customer’s available balance.
Our article on why an on-chain payment can still fail at the cashier describes a parallel problem on different rails. A blockchain confirmation and a card authorisation are not equivalent events, but neither one alone proves that the operator’s private wallet ledger has reached its final state.
“Reversed” can describe three different events
Support conversations become confusing when one word covers several payment routes.
| Event | When it starts | What moves | Where to investigate first |
|---|---|---|---|
| Authorisation reversal or cancellation | Before capture | Reserved funds are released | Provider payment timeline and issuer hold |
| Refund | After capture | Merchant sends all or part of the captured amount back | Provider refund record and operator ledger |
| Chargeback | After a cardholder dispute | Issuer and card-network dispute process creates a separate financial case | Dispute file, reason code and evidence deadline |
A chargeback does not rewrite the original approval. It starts a later process. Our guide to gambling chargebacks follows that route through the issuer, network, provider and operator ledger.
The distinction also prevents a misleading promise. A player who sees a vanished hold may not have received a refund; the payment may never have been captured. A player who sees a refund can still have a separate gambling-account question. And a chargeback does not automatically decide whether a bet was correctly accepted or settled.
Gambling controls can stop a technically possible payment
Payment rails are only one part of acceptance. An issuer or provider can decline the card. An operator can also block a deposit because of account restrictions, deposit limits, identity checks, source-of-funds review, safer-gambling controls or a mismatch between the account holder and payment source.
Betfair’s current deposit help separates provider declines from operator-side blocked deposits, including temporary account restrictions. Bet365’s Great Britain terms and conditions say deposits must come from a payment source in the account holder’s name and that withdrawals depend on deposited payments being cleared and not charged back, reversed or cancelled. These are named operator rules, not a universal policy for every market.
Jurisdiction matters too. Great Britain’s licensed operators must not accept credit-card gambling deposits, including specified indirect routes through money-service businesses, under the Gambling Commission’s credit-card payment guidance. A British card example in this article therefore means an eligible debit-card route. Other jurisdictions and operators may allow different card types under their own rules.
None of these controls can be diagnosed from a screenshot alone. A pending bank entry shows only one surface. It does not reveal whether the provider rejected a capture, the operator blocked a wallet credit, the customer hit a limit or a verification review remains open.
One incident needs five linked records
A useful support answer does not guess which party “has the money.” It reconstructs the same attempt across systems. At minimum, the case should connect:
the operator’s deposit-attempt or wallet-transaction ID;
the merchant reference sent to the payment provider;
the provider reference and ordered event history;
amount, currency and timestamps for authorisation, capture, cancellation or refund; and
the issuer’s pending or posted entry, without treating a customer screenshot as the system of record.
The identifiers make it possible to separate a late callback from a failed capture, and a duplicate wallet adjustment from a legitimate second attempt. They also let finance decide whether an unmatched item belongs in today’s exception queue or a later settlement batch.
Payment orchestration can normalise provider callbacks, but it cannot erase the underlying states. Our explainer on payment orchestration in iGaming shows why a common status model still needs the original provider event and reference underneath it.
A reversed deposit does not settle every account question
Once the player has used an early wallet credit, a failed or reversed payment becomes more than a card-status problem. The operator may need to review open bets, completed play, withdrawals and the remaining balance under its terms and the applicable rules.
There is no safe universal formula such as “reverse the deposit, then void every wager.” The payment record proves what happened to the funding attempt. The betting or gaming record proves what the account did after the credit. An operator needs an explicit policy for connecting them without changing history or applying the same correction twice.
For readers, the durable answer is narrower: an approved deposit can be reversed because authorisation is only one stage. The bank hold, processor payment and gambling wallet may briefly agree before capture, settlement or an operator control changes the outcome. The fix is not a stronger “success” label. It is an explainable timeline with one stable reference from card request to wallet entry.
