That combination looks like a contradiction only if “paid” is treated as one event. It is not. A crypto cashier joins a public network, a payment processor and an operator ledger. Each system has its own test for completion, and none is obliged to use the block explorer’s language.
This is why support teams should resist the tempting diagnosis: “the blockchain worked, so the operator failed.” Sometimes the gap is an operational defect. Sometimes it is an expected wait. Sometimes the asset arrived in a place that the receiving system cannot automatically recognise. The transaction hash alone does not tell those stories apart.
Arrival is not yet acceptance
The first split happens inside the word “confirmed.” A transfer can be included in a block before a receiving provider has reached its own finality threshold.
Circle’s current confirmation documentation illustrates the distinction. It exposes an incoming transfer after block inclusion but keeps the transfer in a `running` state until Circle’s required number of confirmations has been reached. Only then does it become `completed` and credit the associated wallet balance. The threshold varies by chain because block design and reorganisation risk vary too.
That is Circle’s implementation, not an industry-wide clock. The broader point is that “I can see it” and “the payment provider will act on it” are different claims.
Our deposit-to-settlement map follows the full route. Here, the useful task is narrower: locate the hand-off where a visible receipt stopped becoming an automatic cashier credit.
The address has a job description
A blockchain address is not merely a mailbox. In a payment integration it can be bound to a particular account, network and expected asset.
Coinbase’s developer documentation describes deposit destinations created for a specific account and network. A destination may credit the received asset or act as a liquidation address that converts into another asset before credit. Coinbase also warns that unsupported assets or networks may lead to permanent loss.
That creates several ordinary ways for a transfer to be real on-chain and unusable to the cashier:
the token arrived on a network the integration does not support;
the token contract is not the supported representation of the named asset;
the destination belongs to the provider but lacks the customer or payment-intent mapping the operator expected;
the amount arrived after an invoice or quote expired;
a conversion step has not completed, so the player account’s fiat amount is not ready to post.
None of those states, by itself, proves fraud or a compliance concern. They are routing and matching facts. A support investigation should establish them before attaching a motive.
The cashier may be waiting for another company
The branded deposit screen is often the front of a multi-party service. The operator may not custody the token or perform the conversion.
Paysafe’s April 2026 announcement offers a concrete US example. Its MoonPay-powered product lets an eligible customer choose crypto in an operator cashier; after verification, the service converts the deposit into US dollars to fund the player account. The operator can then choose settlement in stablecoins or fiat. Paysafe’s release describes those hand-offs, although its speed and demand statements remain vendor claims rather than independent benchmarks.
In a route like that, one customer action produces several records: wallet transfer, processor transfer, verification outcome, conversion, operator payment event and player-ledger credit. A delay between any two can leave the blockchain receipt ahead of the cashier.
This is also why payment orchestration can improve visibility without making every route simple. An orchestration layer can normalise statuses and retries; it cannot turn every underlying provider state into the same legal or financial event.
Review is a state, not an accusation
Regulated operators and payment providers may place a payment into review before account credit. The important editorial boundary is not to reverse-engineer why a particular transaction was reviewed.
In Great Britain, the Gambling Commission tells licensees that introducing cryptoassets or another new customer payment method should trigger a review of money-laundering and terrorist-financing risk. Its guidance asks operators to explain whether they accept crypto directly or through a third party and how they manage issues including customer information, source of funds and volatility. The Commission’s cryptoasset guidance applies to its licensees, not universally.
Scott Burrows, then Head of Technical Compliance at SuperBet, made a similar operational point in a 2025 interview with Payment Expert: any future crypto integration at the operator would need a risk assessment, trusted partners and monitoring embedded from the start. He also said SuperBet was not then considering crypto integration as a business. The published Q&A is useful precisely because it does not pretend that fast rails remove the operator’s control obligations.
We did not interview Burrows for this article, and his comments do not diagnose any individual payment. They show why a cashier may have an internal state between receipt and credit.
The quiet failure: the ledger event never lands
The least dramatic explanation is often the hardest to spot. The provider has completed the payment, but the operator did not consume the completion event correctly.
A webhook may be delayed, delivered twice or processed out of order. A reference can fail validation. A retry may be blocked because the receiving system believes it has already seen the event. A manual credit may be created without closing the original exception, leaving finance with two records that appear unresolved.
Good reconciliation gives every payment a trace across systems:
the exact network, asset, contract, destination and transaction hash;
the provider’s own transfer identifier and current status;
the customer and payment-intent reference;
any review or conversion state, without unsupported assumptions about its cause;
the operator-ledger entry, including timestamp, amount, currency and correction history.
If support can see only the transaction hash, the system is asking a public ledger to explain a private workflow. It cannot.
What the customer should be told
“Pending” is a poor answer when it has no owner, state or next check. A useful status message should say what has been verified and what remains open: received on the expected network, waiting for provider confirmations; received but asset mapping under review; provider completed, cashier credit being reconciled.
It should not expose sensitive controls or promise recovery before the responsible party has confirmed it. It should also distinguish a deposit issue from a withdrawal or game settlement issue.
The most revealing question is not whether the chain succeeded. It is whether the business can name the next accountable system. Until it can, “pending” is not a payment state. It is an information gap.
