Guide
A payment that has not arrived is nearly always doing one of four things: waiting for a block, sitting on the wrong network, falling a few cents short, or already delivered to an inbox you have not checked. Here is how to tell which, in about two minutes.
Nothing is lost. A transfer that has left your wallet is written on a public ledger, and a payment page still showing "waiting" is reporting a situation, not a fault. Either the network has not confirmed yet — normal, and anything from seconds on TRON or Solana to half an hour on Bitcoin — or the amount that landed is short of the invoice, or the transfer went out on a different network than the one the invoice named, or the codes are already sitting in a spam folder. Check them in that order. Three of the four you can settle yourself; the fourth needs your order ID and a transaction hash, and nothing else.
Confirmation was never instant on every chain. A TRON or Solana transfer settles in seconds, Litecoin in a couple of minutes, Ethereum and ERC-20 stablecoins according to the gas you paid, and Bitcoin waits for a block — ten minutes on average, longer when the mempool is busy. Withdrawing straight from an exchange adds that exchange's own processing queue on top, and that queue is frequently the largest part of the wait. Leave the order page open; it updates itself. Start investigating only once you are past those windows.
Before anything else, confirm the money actually left. Open the wallet or exchange you paid from and read the transaction: it shows a status, a destination address and a transaction ID — a hash, a long string of letters and numbers. If your wallet still says pending or queued, the delay is on your side and there is nothing for us to receive yet. If it says sent, copy the hash. That single string answers every remaining question on this page.
Paste the hash into a block explorer for that chain and check three things. The destination must match the invoice address character for character — compare the first four and the last four. The amount that arrived must be at least what the invoice asked for, after any fee your wallet deducted. And the chain must be the one the invoice named: USDT on ERC-20 and USDT on TRC-20 are separate rails carrying the same ticker, and that is where most misrouted payments happen.
A payment that arrives under the total is not rejected. The order page switches to a partial-payment panel showing what arrived, what is still required and the total. Send the difference to the same address on the same network before the invoice expires and the order completes on its own. This is by far the most common cause that is not a network delay, and the usual reason is a wallet that subtracts its withdrawal fee from the amount you typed instead of adding it on top.
If the explorer shows the payment confirmed and complete, the codes have almost certainly been issued already. Search your mail for the order ID rather than scrolling — delivery mail lands in spam more often than anyone expects, and a mistyped address at checkout is the other half of these cases. The order page itself also carries the codes, and it works without an account, which is exactly why it is worth bookmarking the moment the invoice appears.
If the transfer is confirmed, on the right chain, for the full amount, to the right address, and still no codes have appeared, stop retrying and raise a ticket. Bring the order ID and the transaction hash. With those two the payment can be matched on-chain and settled by hand; without them there is nothing to verify and the ticket simply waits. Whatever you do, do not send a second payment to fix the first.
Nothing has reached the address yet. If your wallet says the transfer is sent, it is still propagating across the network or still queued at the exchange you withdrew from. This is the default state and not an error — it means the ledger has not yet shown anything to match against your invoice.
Funds landed, but under the invoice total. The panel shows what arrived, what is left and the address to send it to. Complete it on the same invoice and the same network. Do not start a fresh order to make up the difference: a new invoice generates a new address, and the payment ends up split across two orders that each look incomplete.
That countdown is the rate lock, not a deadline on your money. The crypto amount is held against the live price for about thirty minutes so a market move mid-payment is not your problem. Funds arriving after it runs out are not swallowed — they are on the ledger like any other transfer, they simply no longer match an active quote, and settling that takes a ticket.
Some chains route to a shared address and separate deposits by memo or destination tag. When the invoice shows one, it is not decorative: a transfer sent without it arrives with nothing to attribute it to. If you have already sent without the memo, do not resend — the transaction hash is what lets it be traced and credited.
Confirmed and matched. Codes are generated and emailed within about a minute. If that minute has clearly passed, what you have is a delivery problem rather than a payment problem: check spam, check the address you typed at checkout, and open the order page, which holds the codes regardless of what your mail server did with them.
Every other item on this page is a waiting problem. This one is not. A token sent on a chain the invoice did not name has not gone missing — it is sitting at a same-looking address on an entirely different ledger, where nothing is watching for it. USDT is the usual culprit, because one ticker rides both Ethereum and TRON, but the trap exists anywhere your wallet offers a network dropdown. Two habits remove the risk completely: read the network badge on the invoice before you copy the address, and set the network in your sending wallet before you paste, not after. If it has already happened, do not send a replacement to the same address hoping to overwrite it. Open a ticket with the order ID and the hash — recovery depends on the chain and on the receiving side, and those are questions a support agent can look into and a second transfer cannot.
Copy the amount from the invoice instead of typing an approximation. Amounts are quoted to the coin's full precision for a reason: rounding down by a fraction is enough to land in the partial-payment state, and the fraction you saved is worth far less than the time it costs you.
Most wallets deduct the network fee from the figure you enter; a few add it on top. Find out which yours does before you send, and if it deducts, raise the amount so the invoice total is what actually arrives. This one check prevents the most common underpayment there is.
The coin changes the fee, never the price of the card. A stablecoin on TRON costs cents and confirms in seconds; the same value on Ethereum at a busy hour can cost more than the order is worth arguing about. On a small purchase, choose the rail rather than the brand.
Splitting a payment across two transfers is the slow path even when the total is right, because each arrival is matched on its own and the first one reads as a shortfall. Send once, for the full amount, from a wallet holding enough to cover the network fee as well as the invoice.
It is the one link that survives everything: live payment state, the partial-payment panel if there is one, and eventually the codes themselves — with no account and no login. Save it when the invoice appears rather than hunting for it later in your history.
Seconds on TRON and Solana, a couple of minutes on Litecoin, minutes on Ethereum depending on gas, and roughly ten to thirty minutes on Bitcoin. Add the withdrawal queue of whatever exchange you sent from, which is often longer than the chain itself. Codes are emailed within about a minute of the confirmation landing.
Check the transaction on a block explorer first. If it is confirmed for the full amount, to the invoice address, on the network the invoice named, then the codes were issued: search your inbox and your spam folder for the order ID, and open the order page, which holds them too. If the explorer shows something else — short, still pending, or on another chain — that is your answer instead.
The order moves to a partial-payment state rather than failing. The page shows what arrived, what is still needed and the address to send it to; transfer the difference on the same invoice and the same network and it completes automatically. The usual cause is a wallet that took its own fee out of the amount you typed.
The invoice is satisfied and your codes are issued as normal. An overpayment is not carried over to a future order automatically, so if the excess is worth recovering, open a ticket with the order ID and the transaction hash rather than leaving it sitting there.
Possibly, but not by you and not by resending. ERC-20 and TRC-20 are separate ledgers, and funds sent on the one the invoice did not name are invisible to the payment that was created for you. Open a ticket with the order ID and the transaction hash — what is recoverable depends on the chain and the receiving wallet, and the hash is what makes it checkable at all.
No. The countdown is the rate lock: it fixes the crypto amount against the price for about thirty minutes so a market swing mid-payment is not your problem. A transfer landing after it runs out is on the ledger like any other — it just no longer matches an active quote, so it needs a ticket with the hash to be settled manually.
No — resending is the one action that reliably makes things worse, because a second transfer creates a second payment that then has to be matched and unwound separately. Let the first one confirm. If your wallet supports fee bumping, that is the correct way to hurry a stuck transaction: RBF on Bitcoin, speed-up on Ethereum.
Crypto payments have no chargebacks, which is precisely why order problems are settled by fixing the order rather than reversing the payment — codes issued, codes replaced, or the balance applied. A ticket carrying the order ID and the transaction hash is what starts that, and it is normally the fastest route by a wide margin.
No. The order page works from its link alone, and order tracking asks only for the order ID and the email address you checked out with. Tickets are raised against a verified order rather than an account, so paying as a guest puts you at no disadvantage when something needs looking at.
Eight coins, a rate locked while you pay, and a code in your inbox about a minute after the network confirms — pick a fast rail for a small amount and it is done before you have closed the tab.
A real person reads every ticket and replies to the email on your order.
