"The money left, the product never came" is the most common problem with these orders. It is confusing because payment and delivery are separate steps — a successful payment only means the recipient received funds, not that anything has been sent to you.
The key is to locate which layer has stalled before deciding who to contact. Going straight to support without that usually produces rounds of information requests and no progress. Worse is reordering immediately: the duplicate is normally not refundable.
This guide gives the order to work through. Handling times and remedies are set by each provider; their official support channel is the authority on those.
Key points
- Payment succeeding and delivery succeeding are two separate things
- Locate the failing layer first, then choose who to contact
- Never reorder before the first order is resolved
- Capture evidence immediately; reconstructing it later is hard
- Use official support channels only, and distrust anyone who contacts you first
First locate the layer
Work upwards and find the first step that did not hold. That is where the problem is.
| Layer | How to confirm | Who to contact if it failed |
|---|---|---|
| Did the transfer confirm on-chain | Look up the transaction hash on a block explorer | The sending platform or wallet |
| Did the recipient credit it | Check the payment status on the merchant's order page | The merchant or payment service |
| Was the product issued | Check the order's delivery status and your email | The merchant |
| Did the issuer honour it | Check the balance or entitlement with the brand or carrier | The merchant first, the brand if needed |
Layer one: did the transfer itself succeed
Take the transaction hash and look it up on that network's block explorer. Confirm three things: the status is successful, the receiving address exactly matches the one on the order page, and the amount received matches what the order required.
If it never confirmed on-chain, the problem is on the sending side and the funds are usually still under your control — take it to the sending platform. If it confirmed but to the wrong address, you sent to the wrong place or network, which follows a different process.
Layer two: did they credit it
After an on-chain success, the merchant still has to register the payment in its own system. That can stall on insufficient confirmations, an amount that does not match the order (for instance because the fee was deducted from what you sent), or an order that already timed out.
An amount mismatch is the most common cause. When an order requires an exact figure and slightly less arrives, many systems will not match it automatically and it needs manual handling. This is exactly why it is worth checking whether the field you filled in was "what you pay" or "what they receive".
Layer three: was the product issued
Once credited, check the delivery status on the order page. Code-based products are usually sent both on-site and by email — email landing in spam is a very common cause, so check there first.
If the status says delivered but you have nothing, say exactly that when contacting support: "the order shows delivered and I have not received it", with a screenshot of the order page. That routes the case correctly far faster than a general report of non-delivery.
Layer four: did the issuer honour it
Receiving a code is not the same as receiving the entitlement. For top-ups, confirm the balance changed on the carrier's side; for gift cards, it only counts once redemption succeeds with the brand.
When this layer fails, start with the merchant — you have no direct commercial relationship with the brand. The merchant should verify with the issuer or apply its own refund policy.
Evidence to keep
Capture these immediately; they get harder to assemble as time passes, and support will almost certainly ask for them.
- Order number and the time it was placed, including time zone.
- Transaction hash, or the platform's internal transfer reference.
- Payment asset, network name and the full receiving address.
- A screenshot of the order status at the time, showing the timestamp.
- A screenshot of the product page stating its region and delivery terms.
- The complete original record of every support exchange.
What not to do while waiting
These make the situation worse rather than better.
- Do not reorder. Duplicates are usually not refundable and complicate reconciliation.
- Do not keep retrying a code that failed to redeem; it can trigger security limits.
- Do not trust support that contacts you first. Enter only via the official site or app.
- Never give anyone a recovery phrase, private key, password or verification code — genuine support never asks.
- Do not pay a third party claiming they can recover funds. In this scenario those offers are almost always a second fraud.
Frequently asked questions
How long should I wait before contacting support?
Work through the four layers first. If the chain shows success with the correct address and amount, and the order page has not moved past the merchant's own stated handling time, submit it. A single complete report beats repeated chasing.
Can I raise a chargeback through the payment provider?
On-chain transfers are irreversible and have no card-style chargeback mechanism. Internal payments are generally irreversible too. In practice there is one route: a claim through the provider's official support.
Support asked for my private key to verify. Normal?
Never. Anyone asking for a recovery phrase, private key, password or verification code is committing fraud, without exception. Genuine support needs only public information like an order number and transaction hash.
The order timed out but I already paid. What now?
Keep the transaction hash and a screenshot of the order page, and report through the official channel that the order closed after the funds arrived. These cases usually require manual reconciliation and take longer than a normal order.
Sources
Public sources used for this guide. Sources checked on 2026-09-08. We have not tested this with a real purchase.
- Coinsbee: official order help centreReviewed 2026-09-08
- Bitrefill: delivery errors and refundsReviewed 2026-09-08
- Coinsbee: orders in confirming statusReviewed 2026-09-08