Why an order stays unpaid after cryptocurrency has been sent

If a customer has sent cryptocurrency but the order remains unpaid, identify the point of failure: sending, network confirmation, matching the payment to an invoice, or order processing on your website. Do not ask them to pay again until you establish what happened to the first transfer.

This guide is for merchants accepting payments through Cryptanio invoices. You need access to the project and the order details. Handler setup is covered in the guide to confirming orders through a webhook.

Gather the details of one payment

Record the order and invoice numbers, transaction ID, network, asset, amount sent, recipient, and time. If the customer changed payment methods, save the details of the attempt they used. A screenshot without a transaction ID is insufficient for reconciliation.

Do not match receipts to orders by amount alone: the price and customer may be the same, and an invoice can have several payment attempts.

Step 1. Check whether the transfer took place

Look up the transaction by its ID in the selected network's explorer. Check the execution result and recipient. A withdrawal request on an exchange does not yet mean that a transfer has been completed.

A transaction waiting for inclusion or ending in an error does not confirm payment. For a transaction you have found, check its confirmations: the time required depends on the network and its condition. See What transaction confirmations mean for details.

Step 2. Check the network, token, and all payment details

Check the network, asset, address, and additional payment details for the specific attempt. The name USDT appearing in two applications does not prove that the network or token is the same. A counterfeit or similarly named token does not pay an invoice in the expected asset.

If a destination tag, memo, or comment was required, check those too. For Solana Pay, reference is a separate part of the payment request, rather than arbitrary memo text. An address match alone may be insufficient to attribute the receipt.

Read How networks and tokens differ if these values are unclear. Changing a dashboard filter does not change a transfer already completed on another network.

Step 3. Find the correct payment attempt

In Payments, open the relevant project and invoice. Expand “Payment attempts,” then “Transfers” for the corresponding attempt. If the history spans multiple pages, review them: the first screen does not necessarily show all entries.

Changing the asset or requesting payment details again may create a new attempt within the same invoice. Match the transfer to the attempt used: the current address may differ from the previously issued one. Similar payment details do not justify moving a receipt to another order.

If the transfer exists on the network but is missing from “Events,” check the selected project, network, asset, and event mode. A live payment cannot be confirmed using a test entry or a simulation.

Step 4. Read the invoice status

Look at the status of the whole invoice, rather than just one transaction:

• pending and seen — payment is not yet complete for order fulfillment;
• partial — only part of the amount is confirmed; further payment is expected;
• underpaid — the amount received is below the allowed threshold and requires a decision;
• overpaid — the overpayment has been referred for review under the project's rules;
• expired, late, and canceled — the deadline has passed, the payment requires review, or the invoice has been canceled;
• paid — the invoice is recorded as paid; next, check order fulfillment.

An overpayment may result in paid if the project's policy permits it. An amount above the price does not determine the status by itself. See What an invoice is for details.

Step 5. Review the amount and timing

Compare the amount actually received with the exact amount for the attempt. The sender's fee may have reduced the receipt. A rounded price in a conversation does not replace the value on the payment page.

For partial payments, the project may wait for the remainder or require a manual decision. Check the applicable rule before advising the customer to pay the difference. A late transfer also cannot automatically count as payment for any new order. Check the attempt's history, its deadline, and the recorded receipt time.

If manual acceptance or rejection of a disputed payment is available, agree on the decision with the customer first. Changing the invoice status does not send funds back from your wallet.

Step 6. If the invoice is already paid, check your website

Refresh the order status in your application. Check its invoice relationship and webhook delivery log: a delivery error, incorrect association, or handler failure can prevent the order from being confirmed.

Repeated processing must check the current status and must not deliver the product twice. If the transaction was rolled back after confirmation, check the latest events and reassess whether the order can be fulfilled.

When to contact support

If you cannot identify the cause, send support the invoice number, transaction ID, network, asset, amount, time, status, and checks already performed. Passwords, API keys, seed phrases, and the webhook signing secret are not needed.