Review the submitted proof
Open the order's payment row and compare the selected method, expected network, receiving wallet, asset, amount, transaction ID, and uploaded proof. Use Open explorer when available, or Verify on-chain for a configured automatic check.
Checking is temporary while the request is running. A completed automatic result does not by itself mark the seller's payment row verified or the order paid. Review the evidence, then use the payment actions deliberately.
For a wrong or missing proof, request a corrected proof or replace or clear the saved transaction ID. Do not edit a transaction ID into a different transfer.
Act on a successful or pending result
- Matched means the submitted transaction ID matched the configured network, receiving wallet, asset, and expected amount. Review the explorer record before accepting it.
- Wallet match is a compatibility result for an older no-transaction-ID wallet scan. Open the matched transfer and confirm it is the intended buyer payment.
- Confirming means the transfer was found but does not yet have sufficient finality. Wait and retry; do not treat it as settled yet.
A clean Matched or Wallet match can create accepted payment credit for the order balance. It still does not click Mark verified for the seller or independently move the order to Paid. Rows already classified as refund owed are not accepted as new payment credit.
Fix a transfer that does not match
- Not found: confirm the complete transaction ID and correct network, then wait for explorer indexing and retry.
- Failed transaction: do not accept the transfer; ask the buyer to send a successful payment.
- Wrong network: compare the configured method with the chain the buyer used. Never assume assets can be recovered across networks.
- Wrong wallet: do not accept it unless you independently prove that the receiving wallet belongs to you and the payment is valid for this order.
- Wrong asset: the transfer used another token. Clarify the required token or handle the difference manually.
- Amount short: collect the missing balance or document an intentional adjustment before marking paid.
- Amount over: confirm the transfer belongs to this buyer and decide how to handle the overage; EZFormz does not automatically apply it to another order.
Resolve proof and service errors
- Invalid transaction ID: ask for the chain-native transaction hash, not an exchange order number, screenshot reference, or payment-app receipt number.
- Duplicate transaction: the transfer has already been accepted for another payment claim with the same chain and recipient. One transfer cannot supply payment credit twice. Investigate before changing either order.
- Unsupported network or Unsupported asset: automatic verification cannot validate this combination. Use the correct configured pair or review it manually in a trusted explorer or wallet.
- Provider error: the explorer or verification provider did not return a trustworthy result. Retry later and review the explorer directly; do not treat the error as verified.
- Review required: the scan found ambiguous, old, incomplete, or otherwise non-decisive evidence. Resolve it manually before accepting payment.
If a legacy row displays a general Manual review result, use the same independent wallet and explorer checks. Do not convert an inconclusive result to verified merely because a screenshot looks plausible.
Keep verification safe
Use a public explorer URL or the wallet's normal receive history. Never ask the buyer or seller for a private key, seed phrase, wallet connection, remote-control session, or signed recovery message. Transaction IDs and public wallet addresses are not secrets, but order details and buyer identity remain private and should be shared only where needed.
Automatic checks validate evidence against saved expectations; they do not move funds, reverse a transfer, guarantee ownership of a sending address, or replace seller review. For setup limitations, return to Configure crypto payment methods.