How to Check a Crypto Payment: TXID, Network, Amount, Status, and Customer Replies

How do you check a crypto payment when a customer says, “I paid, but my order was not credited”?

For the customer, the situation looks simple: funds left their wallet or exchange, so the product, subscription, deposit, credits, or account balance should appear immediately. For the business, it is not one check. It is a chain of questions: which network was used, whether the amount matches, whether the TXID exists, how many confirmations the transaction has, whether the invoice expired, and whether the payment can be matched to the right order.

Without a clear process, every payment issue turns into manual chaos. Support asks for screenshots. Finance looks for wallet inflows. Developers check webhooks. The customer gets frustrated. The order stays pending.

This guide gives support, finance, operations, and product teams a practical workflow for checking crypto payments and responding to customers clearly.

First, separate “the customer sent funds” from “the order is paid”

Crypto payments need more precise statuses than card payments.

A customer may have opened an invoice but not sent a transaction. They may have sent a transaction that has not yet been confirmed. They may have sent the right asset on the wrong network. They may have sent less than the invoice requires. Or the funds may have arrived on-chain but failed to match the order because the invoice expired, the address was reused, a memo/tag was missing, or a webhook failed.

To the customer, all of this may sound like the same thing: “I paid.”

To the business, these are different cases with different actions.

A basic crypto payment workflow should distinguish:

• invoice created;
• waiting for transaction;
• transaction detected;
• waiting for network confirmations;
• payment completed;
• underpayment received;
• overpayment received;
• payment received after invoice expiry;
• wrong network used;
• transaction sent to manual review;
• refund or manual credit issued.

If these statuses are not separated, support cannot explain what is happening. If payment exceptions happen often, start by reviewing the broader causes of failed crypto payments: wrong network, gas fees, amount errors, expired invoices, and weak checkout instructions.

What support should ask the customer for

The first rule: do not rely only on a screenshot.

A screenshot can help, but it is not the source of truth. It may show an internal exchange withdrawal ID instead of a blockchain transaction hash. It may hide the network, cut off the address, show the wrong fee logic, or display a withdrawal that has not yet been broadcast on-chain.

Support needs data that can be checked both in the payment system and on the blockchain:

• order ID, invoice ID, deposit ID, or top-up ID;
• email, user ID, or customer account ID;
• asset, such as USDT, BTC, ETH, TRX, BNB, SOL;
• network, such as TRON, Ethereum, BSC, Polygon, Solana;
• amount the customer was expected to send;
• amount the customer actually sent;
• TXID, transaction hash, or transaction ID;
• time of payment;
• recipient address;
• screenshot of the transaction details as extra context.

The TXID is the key identifier. In wallets and exchanges, it may be called TXID, Hash, Transaction Hash, Transaction ID, TxHash, or Details.

A useful support reply is:

“Please open the transaction history in your wallet or exchange, select the relevant withdrawal, and send us the TXID / transaction hash. We need the blockchain transaction hash, not the internal exchange withdrawal ID.”

Step 1. Check the TXID on the correct network

A TXID must be checked in the explorer for the network the customer actually used.

This matters most for USDT and other tokens that exist across multiple networks. USDT on TRON, Ethereum, BSC, Polygon, and Solana is not one universal payment route. To the customer, it may all look like “USDT.” To the business, these are different networks, different fees, different addresses, and different crediting rules.

When checking a TXID, verify:

• whether the hash is found in the explorer;
• which network processed the transaction;
• which asset was sent;
• sender address;
• recipient address;
• amount sent;
• network fee;
• transaction status;
• number of confirmations;
• whether the transaction failed, reverted, or was cancelled.

If the TXID is not found, do not immediately say “there is no payment.” Several things may have happened. The customer may have copied an internal exchange ID. The exchange may not have broadcast the withdrawal yet. The customer may have used a different network. The hash may be incomplete. Or the support agent may be checking the wrong explorer.

A better customer reply is:

“We cannot see this transaction hash in the network yet. Please check that you sent the blockchain TXID / Hash, not the internal withdrawal number from the exchange. If the withdrawal is still being processed by the exchange, please wait until the blockchain hash appears and send it again.”

Step 2. Compare the payment network with the invoice network

Wrong-network payments are one of the most common crypto support issues.

For example, the invoice asks for USDT TRC-20, but the customer sends USDT BEP-20. From the customer’s perspective, they paid USDT. From the merchant’s perspective, the payment arrived through a different route than the invoice expected.

The support check should answer four questions:

• which network was shown on the invoice;
• which network the customer actually used;
• whether the recipient address is controlled by the merchant or payment provider on that network;
• whether the transfer can be recovered, credited, refunded, or must be rejected.

Do not promise recovery immediately. Some wrong-network transfers can be investigated and processed manually. Others cannot be recovered, especially if the asset or network is unsupported, the address is not controlled on that network, or the route is incompatible.

To prevent these cases, the network should be shown as part of the payment instruction. Do not show only “USDT.” Show “USDT TRC-20,” “USDT ERC-20,” or another exact format.

If your business supports USDT across several networks, define which networks are best for your audience, support team, and cost model. The guide on choosing the right USDT network covers this in more detail.

Step 3. Compare expected, sent, and received amount

Even if the network is correct, the payment may not close the order.

Example: the invoice requires 100 USDT, but the business receives 99.50 USDT. This can happen when the customer changes the amount manually, pays from an exchange that deducts a fee, misunderstands the network fee, copies the wrong number, or tries to “subtract the fee” from the invoice amount.

Support should avoid saying only “the payment failed.” Instead, show the exact difference:

• expected: 100 USDT;
• received: 99.50 USDT;
• difference: 0.50 USDT;
• status: underpaid;
• next step: pay the remaining amount, receive a refund, get the received amount credited to balance, or wait for manual review.

An underpayment in an online store is not the same as an underpayment in an account-balance product. If the customer is buying a fixed-price subscription, course, license, or physical product, the order usually should not be completed until the full amount arrives. If the customer is topping up a hosting, iGaming, API, ad network, VPN, or SaaS balance, the business may credit the amount actually received if its rules allow it.

Overpayments also need a process. If the customer sends more than required, the order can usually be completed, but the excess must be handled. It may be refunded, credited to balance, or reviewed manually.

These rules should be connected to your crypto payment refunds policy before support starts improvising.

Step 4. Check status and confirmations

A “sent” status in the customer’s wallet does not always mean the order should be credited.

The transaction must be broadcast, included in the network, confirmed, detected by the payment system, and matched to the invoice. Depending on the asset, network, amount, risk level, and provider policy, the required number of confirmations may vary.

Support should distinguish:

• transaction not found;
• transaction found but not confirmed;
• transaction confirming;
• transaction confirmed;
• transaction failed;
• transaction confirmed but underpaid;
• transaction confirmed but sent on the wrong network;
• transaction confirmed after invoice expiry;
• transaction confirmed but sent to manual or AML review.

Customer communication should be simple:

“Your payment was found in the network. We are waiting for the required confirmations. Once the transaction is confirmed, the order status will update. Please do not send another payment while this transaction is still processing.”

This is much clearer than saying “pending” without context.

Step 5. Check gas and network fee issues

A customer may hold USDT but not have TRX, ETH, BNB, SOL, or another native token needed to pay the network fee. To the customer, this is confusing: “I have USDT, so why can’t I pay?” To the business, it becomes an abandoned checkout, an underpayment, or a support ticket.

The problem is especially visible in manual payment flows. The customer chooses the network, copies the address, enters the amount, and confirms the transaction. If they do not understand gas or withdrawal fees, they may send the wrong amount or fail to send anything at all.

The payment page should explain:

• which network is selected;
• which exact amount must arrive;
• who pays the network fee;
• whether the customer needs a native token for gas;
• what happens if the customer sends less;
• what to do if the wallet cannot confirm the transaction.

This is why gasless USDT payments are relevant to support operations, not only checkout UX. Reducing gas friction can reduce payment errors before they become tickets.

Step 6. Check whether the transaction matched the order

Sometimes the transaction exists, the network is correct, the amount is correct, and confirmations are complete — but the order is still not credited.

This means the issue may be in matching, not in the blockchain transaction itself.

Common causes include:

• the customer sent funds to an old address;
• the invoice expired before the payment arrived;
• the customer paid twice;
• the system expected a memo, tag, or another identifier;
• the webhook did not reach the merchant backend;
• the order was cancelled before confirmation;
• funds arrived at a shared address without a usable invoice ID;
• the merchant system failed to update the internal order status.

In these cases, support needs more than a TXID. The team needs invoice status inside the payment system: created, waiting, detected, confirming, completed, expired, underpaid, overpaid, manual review, or refunded.

If support cannot see those statuses, every unclear payment will be escalated to developers.

For higher-volume products, this should be checked before launch. The crypto payment API should support invoice IDs, transaction hashes, clear statuses, webhooks, metadata, test cases, and safe order-crediting logic.

Step 7. Decide whether AML review is needed

Not every crypto payment needs manual AML review. But every business needs a process for transactions with elevated risk.

This is especially important for large payments, unusual customer behavior, marketplaces, iGaming, fintech, VPN, international digital services, and refund cases where the customer asks to receive funds at a new address.

AML or risk review may apply when:

• incoming funds have a high risk score;
• the transaction is linked to suspicious addresses;
• the amount is unusually large for the customer;
• the payment pattern does not match normal behavior;
• the refund address differs from the original sender address;
• a wrong-network or manually recovered payment needs extra checks.

Support should not decide these cases alone. The payment system or internal dashboard should have clear statuses: under review, additional information required, credited, refund blocked, sent to finance, or sent to compliance.

AML, KYC, data retention, and refund requirements depend on the jurisdiction, business model, and provider policy. They should be reviewed with legal and compliance specialists where relevant.

The broader risk-control framework is covered in the guide to AML and crypto payment security.

What to tell customers in common cases

TXID is not found

“We cannot find this transaction hash in the blockchain network yet. Please check that you sent the TXID / transaction hash, not the internal withdrawal number from your exchange. If the withdrawal is still being processed by the exchange, wait until the blockchain hash appears and send it again.”

Transaction is found but not confirmed

“We found your payment in the network, but it has not received the required confirmations yet. Once it is confirmed, the order status will update. Please do not send another payment while this transaction is still processing.”

Amount is lower than expected

“We received your payment, but the amount is lower than the invoice amount. Expected: X. Received: Y. To complete the order, please pay the remaining amount in the same network, or choose another available resolution option if supported by the service.”

Amount is higher than expected

“The order is paid, but the received amount is higher than the invoice amount. The excess may be refunded or credited to your account balance, depending on the service rules. A network fee may apply to an on-chain refund.”

Payment arrived after invoice expiry

“We can see the payment, but it arrived after the invoice expired. We have sent it for review. The team will confirm whether it can be credited, recalculated, refunded, or added to your account balance.”

Customer used the wrong network

“The payment was sent on a different network from the one shown on the invoice. We will check whether this transfer can be technically detected and processed. Recovery depends on the asset, network, address, and provider rules, so we cannot confirm crediting until the review is complete.”

Payment is under AML review

“The payment was found, but it has been sent for additional security review. This does not mean it is rejected. We need to complete the internal check before updating the payment status.”

What support should see in the dashboard

If support needs a developer every time a customer asks about a payment, the process will not scale.

A merchant dashboard or admin panel should show:

• order ID or invoice ID;
• invoice status;
• expected amount;
• received amount;
• asset and network;
• destination address;
• TXID;
• number of confirmations;
• invoice creation time;
• invoice expiry time;
• exception reason;
• AML or risk status, if applicable;
• available action: wait, credit, refund, request top-up, or send to manual review.

Finance needs additional fields: amount after fees, exchange rate used for the invoice, settlement amount, balance impact, withdrawal status, and refund history.

This connects directly to stablecoin payment operations for CFOs. A crypto payment is not only “money arrived.” It must be tied to the right order, reconciled, reported, and prepared for settlement or withdrawal.

Metrics to track after launch

Payment checks should not live only inside support tickets. If the same issues repeat, they should become product and operations metrics.

Track:

• share of payments automatically matched to orders;
• share of payments requiring manual review;
• underpayment rate;
• overpayment rate;
• wrong-network payment rate;
• late payment rate;
• average time to credit;
• support tickets per 1,000 crypto payments;
• share of payments sent to AML review;
• refunds caused by payment errors.

These metrics show where the payment flow breaks: network selection, amount entry, gas, invoice expiry, confirmations, webhook delivery, or support communication.

The broader framework is covered in crypto payment metrics.

How to reduce crypto payment disputes before they happen

Checking payments is necessary. Reducing avoidable payment issues is better.

A stronger crypto checkout should:

• show asset and network together, such as USDT TRC-20, not only USDT;
• use a QR code or app-based flow to reduce manual address and amount entry;
• show the invoice timer near the payment details;
• explain whether network fees are included or paid separately;
• warn customers about gas or native-token requirements;
• separate “transaction detected” from “payment credited”;
• avoid using one generic “pending” status for every case;
• define rules for underpayments, overpayments, late payments, and wrong-network transfers;
• test exception scenarios before launch;
• give support access to transaction history and statuses.

Do not evaluate payment cost only by provider commission. Manual support, unresolved balances, refunds, and failed orders also cost money. This is why crypto payment fees should be analyzed together with checkout UX and support load.

How a payment system helps

A business does not need to build the whole process from scratch.

A good crypto payment system should do more than show a wallet address. It should help the merchant:

• create an invoice for a specific order;
• show asset, network, amount, and expiry time;
• reduce manual entry through QR or app-based payment;
• track TXID and confirmations;
• match the transaction to the order;
• show payment status in the dashboard;
• handle underpayments, overpayments, and late payments;
• send statuses through API or webhooks;
• support AML checks;
• help with reconciliation and withdrawals.

CryptumPay can fit this kind of workflow for businesses accepting cryptocurrency on a website, in an app, in a Telegram bot, or on another digital platform. The key principle is the same for any provider: the customer should understand what is happening with the payment, and the business should have enough data to avoid manual guesswork.

FAQ

How do I check a crypto payment by TXID?

Copy the TXID or transaction hash from the customer’s wallet or exchange, open the correct blockchain explorer for the network used, and check the transaction status, recipient address, amount, fee, and confirmations.

Why did the customer send USDT but the order was not credited?

Common reasons include the wrong network, underpayment, missing confirmations, an expired invoice, webhook failure, an old address, missing memo/tag, or AML review. Start by checking TXID, network, amount, and invoice status.

What should support do if the customer used the wrong network?

Check whether the payment provider supports that network and whether the recipient address can be controlled or recovered on that network. Do not promise recovery before review.

Can a business accept an underpaid crypto payment?

It depends on the business model. A fixed-price order usually requires the remaining amount or a refund. A balance-based product may credit the amount actually received if the rules allow it.

When is AML review needed for a crypto payment?

AML review may be needed for large, unusual, high-risk, or suspicious transactions, and for some refund or manual recovery cases. Requirements depend on jurisdiction, business model, and provider policy.