When a customer says “I paid, but my order is still unpaid,” start with evidence, not another payment request. Crypto payment support needs enough information to match a transfer to an order, but never a recovery phrase, private key or wallet password.
This guide is for merchants selling digital products, services or memberships. It covers the support intake and escalation process, not a promise to recover funds. It is a recommended merchant workflow; it does not describe an automatic Yolfi support or recovery feature.
Collect the minimum useful payment evidence
Open one private support case and ask for the order reference, intended payment network and transaction hash, if one exists. Use your own stored checkout details as the comparison point rather than asking the customer to reconstruct the entire purchase.
| Evidence | Why it helps | Safe handling |
|---|---|---|
| Order or invoice reference | Locates the intended purchase | Verify against the merchant's order record |
| Selected network and token | Identifies where to inspect the transfer | Record both; a ticker alone is not enough |
| Transaction hash or explorer link | Locates a broadcast transaction | Open a trusted explorer independently |
| Amount sent and approximate time | Helps distinguish several attempts | Keep the asset unit and time zone |
| Sending service, if relevant | Distinguishes a wallet transfer from an exchange withdrawal | Ask for the service name, never its password |
| Redacted error message | Shows where checkout or withdrawal stopped | Remove unrelated balances and personal information |
A transaction hash is not a wallet secret, but connecting it to a name or email can reveal a customer's financial activity. Keep it in the private case rather than a public comment. Do not ask for a full wallet history when one transfer will answer the question.
Never turn troubleshooting into wallet access
State this boundary in the first response: support does not need a recovery phrase, private key, wallet password, one-time login code or remote control of the customer's device. Do not ask the customer to import a wallet into a “repair” website, sign an unexplained message or approve token spending to verify an earlier payment.
MetaMask's official support guidance says its support team will never ask for a Secret Recovery Phrase and warns against unsolicited direct messages. Apply the same no-secrets rule to your own payment intake; do not claim to speak for a wallet provider.
If a customer accidentally submits a secret, restrict access to the case and avoid copying it into logs or internal chat. Tell them to use their wallet provider's official compromised-wallet guidance promptly. Deleting a support message does not make an exposed key safe again.
Separate “not sent” from “sent but unresolved”
Ask whether a transaction hash is available. A checkout page, QR code or wallet confirmation prompt does not prove that a transfer was broadcast. If the wallet action was cancelled or failed before submission, there may be no on-chain payment to investigate.
An exchange withdrawal reference may be an internal service ID, not a blockchain transaction hash. Ask the customer to check that service's withdrawal status through its official application. Do not interpret a queued withdrawal as a confirmed merchant receipt, and do not promise a fixed arrival time.
When a hash is available, verify it on the network selected at checkout. Navigate to a trusted explorer yourself instead of connecting a wallet to a link supplied in a ticket. Reading a public transaction does not require a wallet connection. Check the destination, asset, transfer amount and transaction outcome against the merchant's records. For token transfers, inspect the token transfer details, not only the transaction's native-coin value.
A successful transaction on another network, or a token with a familiar symbol but a different contract, is not automatically a matching payment. Route these exceptions through the wrong-network payment checklist rather than improvising recovery instructions.
Match the payment attempt to the commercial order
Keep the business order, checkout attempt and blockchain transfer separate. A customer may open more than one attempt for the same purchase. A reusable link identifies the product entry point, not necessarily one unique customer's order.
Yolfi's API Checkout documentation distinguishes reusable fixed-price Paylinks from server-created Checkout Sessions for dynamic orders. A standalone session does not require a Paylink. Support should use the references actually stored for that flow, not reject a case because it lacks an object the flow never created.
For fixed products, Yolfi payment links provide the payment entry point. Your support process still needs a way to associate the customer's case with the relevant invoice or order. Avoid posting a complete hosted checkout URL publicly: it can expose order context or allow others to interact with that checkout.
Route the case without asking the customer to pay twice
Use a short decision record: what was expected, what evidence was found, who owns the next action and when the customer will receive an update. A promised update time is not a guarantee of blockchain settlement or fund recovery.
- No broadcast evidence: help identify whether the wallet or sending service actually submitted the transfer before suggesting a new attempt.
- Transfer still pending: check through the sending service or wallet's official guidance; do not request a second payment merely to speed up support.
- Wrong destination, network or asset: preserve the original instructions and transfer evidence, then escalate. Do not promise recovery or ask for wallet secrets.
- Payment recorded, order not delivered: investigate the merchant's order and fulfillment process before asking the buyer to repeat checkout.
- Expired or mismatched attempt: use the specific expired invoice procedure instead of silently treating a new attempt as a replacement for money already sent.
Yolfi's webhook reference identifies payment.confirmed as the primary fulfillment trigger. An invoice.created event is not proof of payment. A customer's screenshot and a browser redirect are useful context, not substitutes for verified server-side payment confirmation.
An explorer can help establish what happened on-chain; it does not by itself show that your application matched the payment or delivered the order. Keep payment investigation and delivery investigation linked, but distinct.
Use a short, safe first-response template
Adapt this message to your own support channel and case number:
Please send your order or invoice reference, the network and token you selected, the amount sent, and the transaction hash if available. If an exchange handled the withdrawal, include its name and the withdrawal status. Redact unrelated balances and personal information. Never send a recovery phrase, private key, wallet password or login code. Please do not repeat the payment while we check the existing attempt. We will update you after reviewing the payment and order records.
Before promising a refund, verify the payer relationship and follow the refund review checklist. A support ticket is not authorization to send funds to any replacement address written in chat.
Frequently asked questions
Can a screenshot prove that the merchant was paid?
Not on its own. It may show an intended transfer, a pending withdrawal or another transaction. Verify the actual transfer and match it to the merchant's payment record before releasing an order.
Is it safe to ask for a transaction hash?
Usually it is appropriate for a private payment investigation. It is public-chain information, not a signing secret, but it can link the customer to visible financial activity. Collect only what is necessary and restrict access.
Should support ask the customer to connect a wallet?
Not to read a public transaction or inspect an existing payment record. If a separate legitimate product action requires a wallet, explain that action clearly through the established checkout flow. Never disguise a signature or spending approval as routine support verification.
Can Yolfi or a wallet provider reverse any mistaken transfer?
Do not assume so. Recovery depends on the destination, network, asset and who controls the receiving funds. No support script should guarantee reversal or recovery from a transaction hash alone.
Conclusion: make support evidence-based
A safe payment support process collects a small set of references, verifies the transfer independently and assigns the next action without exposing wallet credentials. Pair Yolfi payment links with clear customer instructions and a private evidence checklist, so an unresolved order becomes an investigation—not an invitation to share secrets or pay again.
