

This gap explains many apparently missing crypto payments. Automated reconciliation lacks one of the details required to credit the transfer.
| Blockchain evidence | Merchant still needs to establish |
|---|---|
| Transaction hash | Which order generated the payment |
| Receiving address | Whether the address belongs to an active invoice |
| Token amount | Whether fees caused an underpayment |
| Network name | Whether that chain is supported |
| Block confirmations | Whether the merchant considers the payment settled |
| Memo or destination tag | Which customer owns a pooled-account deposit |
Success Has More Than One Meaning
A wallet signs and broadcasts a transaction. Validators or miners include it in a block. A payment processor then waits for its required confirmation count.
BTCPay Server illustrates the distinction. A transaction can appear as “processing” in the mempool, while the invoice becomes “settled” after reaching the merchant’s confirmation threshold. Its default invoice timer is 15 minutes and protects the quoted exchange rate.
A transfer broadcast before expiry can confirm later. The processor then has to decide whether the rate, amount, and order are still acceptable. A merchant that ships goods after seeing only a transaction hash takes a different risk than one waiting for settlement.
One Token Name Can Hide Several Networks
USDC and USDT use familiar dollar values, yet both circulate across multiple blockchains. Ethereum and BNB Smart Chain addresses can share the same hexadecimal format, making a network mistake hard to notice.
The token contract matters as much as the ticker. Native USDC issued for a supported chain is not automatically interchangeable with every bridged token carrying “USDC” in its name. A processor monitors specific networks and contract addresses. Funds sent through another route may reach an address controlled by the merchant without triggering the expected event listener.
Recovery depends on wallet architecture. A merchant controlling the private key may retrieve the asset manually. A custodial gateway may decline recovery or charge a fee.
Matching Requires More Than a Transaction Hash
Online stores cannot complete an order until the blockchain transfer is matched with the relevant invoice. An incorrect network, receiving address or payment reference can leave the product unshipped even when a block explorer marks the transaction as successful.
The same technical requirement applies when cryptocurrency is used at Royal Reels: a deposit must reach the assigned address through a supported network before the casino balance can be updated. The transaction hash proves that the wallet sent the funds, but a missing reference or mismatched network can prevent automatic crediting.

Shared Addresses Need an Extra Identifier
Some custodial services do not create a separate on-chain address for every customer. They receive many payments into a pooled account and use a memo or destination tag as the internal identifier.
Stellar documentation describes memos as transaction identifiers. An exchange can use a shared G account plus a memo containing the customer’s unique ID. Omitting it can leave the received XLM without the clue needed for allocation.
The official Circle documentation gives an equally direct warning for stablecoins: Circle Mint accepts USDC and EURC only on its listed blockchains and advises against sending unsupported tokens or bridged USDC to a Mint address.
Merchants should place the memo, network, and token contract beside the QR code. A confirmation screen can repeat all three before the wallet opens.
Exact Amounts Can Miss by a Few Cents
An invoice requesting 0.002 BTC can receive 0.00198 BTC when an exchange deducts its withdrawal fee from the amount entered by the customer. The transaction is valid, but the invoice is underpaid.
Processors handle this in different ways. BTCPay Server can mark an invoice as partially paid and allows a merchant-defined tolerance for small shortages. An automatic tolerance reduces support work, although an overly generous setting creates a predictable discount on every order.
A Transaction Hash Starts the Investigation
Support staff can resolve most crediting failures through a fixed process:
Copy the transaction hash into the correct block explorer.
Confirm the chain, token contract, and final status.
Compare the receiving address with the invoice address.
Check the amount after exchange and network fees.
Verify the memo, tag, or payment reference.
Compare the broadcast time with the invoice expiry.
Record any manual credit or refund against the order.
Screenshots often omit the network. The hash supplies a public record, while the invoice ID connects it with the merchant’s accounting system.
Checkout Design Prevents Expensive Recoveries
The strongest protection appears before the send button. A merchant can generate a fresh address for each invoice, restrict the currency selector to supported network-token pairs, and encode the amount in a standards-based payment URI.
The payment page should also keep its status visible after broadcast. “Detected,” “confirming,” “settled,” “underpaid,” and “expired” describe distinct conditions more accurately than a single pending label.
Manual recovery should remain an exception with documented approval, wallet access controls, and an audit trail. Blockchain settlement may be irreversible, but merchant accounting is still software. A successful transfer becomes a completed purchase only after those two records agree.