The useful question is not “Has the transaction arrived?” It is “Which system now considers which obligation complete?”

The three clocks start at different moments

Suppose a player sends 250 USDC to a deposit address displayed by an operator’s cashier. Three clocks begin to move.

The network clock records broadcast, inclusion and finality. The processor clock applies its supported-asset rules, confirmation threshold and screening. The operator clock decides when to credit the customer ledger and how that liability will be funded.

Circle’s wallet documentation makes the first distinction explicit. A submitted transaction and a finalised transaction are separate events, and Circle recommends asynchronous status notifications rather than treating the initial API response as proof of finality. Circle transaction lifecycle Its confirmation guide says a transaction visible on a block explorer may still be short of the threshold Circle Wallets uses before marking it complete. Circle blockchain confirmations

That is one provider’s state model. Other custodians, chains and processors use different labels and thresholds. The general lesson survives: visibility is not finality, and finality is not an operator credit.

1. The cashier creates a destination

The deposit begins before the wallet sends anything. The cashier must specify the exact asset and network, then provide an address or another supported destination. “USDC” is incomplete if the processor accepts native USDC on one chain but not a bridged representation on another.

The destination also needs an internal reference. Some systems assign a unique address per customer or payment intent; others reuse an address and rely on additional identifiers or ledger mapping. Either design has consequences for privacy, reconciliation and recovery.

Our comparison of USDT and USDC payment routes covers the token-plus-network decision. This article starts after that decision has been made.

2. The wallet broadcasts, but the balance should wait

A transaction hash proves that a network has seen a signed transaction. It does not prove that the transaction will reach the required final state. Fees can be inadequate, a transaction can remain pending and some networks can reorganise recent history.

The receiving system therefore watches the chain or a provider event stream. It validates the destination, token contract, amount and source transaction, then waits according to its policy. Circle’s current Gateway webhook documentation, for example, defines a deposit event only after the on-chain transaction is finalised and processed by Gateway. It also warns that notifications can be retried or arrive out of order, so consumers should deduplicate them. Circle Gateway webhooks

This is where idempotency becomes financial control. If the same finalisation event reaches the cashier twice, it should not create two player credits.

3. A confirmed transfer enters a compliance decision

Blockchains expose transaction history, not a universal legal verdict. A processor or operator may screen addresses and transaction context, compare the payment with the verified customer and place the deposit into review.

The rules depend on jurisdiction and business model. In Great Britain, the Gambling Commission says a licensee introducing cryptoassets or another new customer payment method must review its anti-money-laundering risk assessment. It also expects disclosure of whether cryptoassets are accepted directly or through a third party and how volatility, customer information and source of funds are handled. Gambling Commission cryptoasset guidance

For persons subject to US jurisdiction, OFAC says sanctions obligations apply to virtual-currency transactions as they do to fiat transactions and recommends a risk-based compliance programme suited to the business. OFAC virtual-currency guidance FATF’s standards take another, international layer: regulated virtual-asset service providers are expected to perform customer due diligence, keep records and transmit originator and beneficiary information where the Travel Rule applies. National implementation still determines the actual obligation. FATF virtual-assets overview

None of these sources says that a blockchain analytics score can make the decision alone. The accountable business must define the policy, review ambiguous matches and preserve a defensible record.

4. The operator credits an internal liability

When a cashier credits 250 units to a player balance, it changes the operator’s internal ledger. The player may now be able to wager even though the received asset remains at a processor, in a pooled wallet or awaiting conversion.

That credit needs a durable link to the network transaction and processor record. At minimum, the audit trail should preserve:

  • customer and payment-intent identifier;

  • asset, network and token contract;

  • sending and receiving addresses where legally and operationally appropriate;

  • transaction hash and confirmation state;

  • screening and review outcome;

  • exchange rate if the account is denominated in another currency;

  • credited amount, fees and exact ledger timestamp;

  • any later reversal, refund or manual correction.

This is the boundary between an asset movement and a customer-account event. A transaction can succeed on one side and fail to post on the other because the reference is missing, the webhook is delayed or a rule sends it to review.

5. Treasury decides what “settled” means

After credit, the operator or its payment provider still has an asset. It may keep that asset, sweep it into custody, convert it into another stablecoin, trade it into fiat or use it to fund withdrawals. A processor may periodically remit a net fiat amount to a bank account. Another arrangement may leave the operator with on-chain balances.

There is no universal operator-settlement event. The contract must define it. Is settlement the moment the processor recognises the deposit, the moment the token reaches an operator-controlled wallet, the moment a fiat conversion executes or the moment cash reaches a bank?

Accounting and gaming metrics should not be mixed into this route. A player deposit is generally not gambling revenue at receipt. Our GGR versus NGR explainer separates stakes, winnings, gross gaming revenue and later deductions.

The reconciliation test

At the end of a day, finance should be able to start with either side of the system and reach the other:

  1. Take a player-ledger credit and identify the source transaction, screening decision and treasury destination.

  2. Take an on-chain receipt and identify whether it was credited, held, returned or left unmatched.

  3. Take a processor settlement and explain the gross deposits, conversions, fees, withdrawals and timing differences inside it.

Payment orchestration can unify some routes and states, but it cannot decide the accounting boundary by itself.

The chain supplies a transaction history. The gambling account supplies a liability history. Settlement is the controlled process that makes those histories agree.