How to Prevent Wrong-Network Crypto Payments: A Merchant Incident Playbook

A transaction can be confirmed on a blockchain and still fail to qualify as the payment your business requested. The customer may have sent the right amount of the right token on the wrong network, a different token to the expected address, too little, or funds to an unrelated address. Your support team needs to separate proof that a transfer occurred from proof that the order was paid correctly.

This is a merchant operations playbook, not a wallet-recovery tutorial. It covers prevention, evidence collection, explorer verification, incident classification, replacement requests, duplicate prevention, and customer communication. The shorter wrong-network payer FAQ remains useful for customers; this guide tells the merchant what to do behind the support reply.

Confirmed transaction does not mean recognized payment

A blockchain confirms a transaction according to that network's rules. Your payment process recognizes a payment only when the observed transfer matches the request and reaches the acceptance state defined by your business.

For a normal payment, verify all of these fields:

Field	What must match
Order or payment reference	The open request for this customer and purchase
Network	The network selected in the live payment flow
Asset	The exact token or native asset requested, including the expected contract or mint where relevant
Destination	The receiving address configured for that payment method
Amount	The amount required by the request and your amount-tolerance policy
Transaction result	Successful on the relevant network, not merely submitted or pending
Confirmation state	The threshold or status your fulfillment policy requires
Uniqueness	The transaction has not already been applied to another order or fulfillment action

Circle's blockchain confirmation reference explains that transactions begin pending, confirmation behavior varies by blockchain, and recent blocks can be affected by reorganizations. A hash, wallet screenshot, or “success” page is therefore evidence to investigate—not, by itself, authorization to fulfill.

Distinguish the main incident types

Customers often describe every mismatch as “wrong network.” Classify the facts before choosing a remedy.

Incident	What happened	Merchant response
Wrong network	The expected asset may have been sent, but on a network other than the one selected for the request	Verify the transaction on the network actually used; check whether the destination is controlled and the asset is usable there; do not promise recovery
Wrong token or currency	The network may be correct, but the transferred asset does not match the request	Verify the token contract or mint and destination; follow the wrong-currency procedure
Wrong address	The transfer went to an address other than the request's destination	Verify both addresses exactly; the merchant cannot reverse a transfer it did not receive
Partial payment	The correct route was used, but the received amount is below the required amount	Pause fulfillment and follow the partial-payment procedure; do not improvise a top-up instruction
Delayed confirmation	The matching transaction is pending or has not reached the merchant's required confirmation state	Keep the case pending, monitor it, and discourage a second payment until the outcome is known
Duplicate payment	The customer sent more than once, or an old and replacement request both succeeded	Fulfill once, preserve every transaction, and send the extra receipt to review

Do not assume a familiar ticker proves the asset is correct. Circle describes USDC as a digital dollar issued on multiple blockchains, while Tether publishes a current list of protocols supporting Tether tokens. Those issuer lists do not define what Yolfi, your wallet, or your business supports. Offer only the exact asset-and-network combinations shown in your live Yolfi setup.

Prevent the incident before the customer signs

The best wrong-network process begins in checkout, not in support.

Treat asset and network as one payment method

Do not label an option only “USDC” or “USDT.” Use a combined label such as “USDC on [the selected network]” everywhere: selection, review screen, QR instructions, wallet handoff, receipt, support records, and reconciliation exports.

The USDC payment guide and USDT payment guide explain why network choice is part of the payment method. Your public instructions should list only combinations that are currently available in the payment flow—not every network on which an issuer happens to make a token available.

Repeat critical details at the decision point

Before the wallet signs, show:

exact asset name and symbol;
exact network name;
exact amount;
destination address, with copy controls;
order or payment reference;
expiration or timing rule, if applicable;
a warning not to choose another network because its address looks similar;
a prompt to return to the payment status page after sending.

Do not tell users that switching networks moves tokens. Changing a wallet's selected network changes what chain the wallet displays and interacts with; it does not transfer an existing balance between chains. A separate bridge or exchange withdrawal would be a different operation, with its own risks and support boundaries.

Reduce avoidable choices

Enable only the options your customers use and your team can support. Every extra combination adds another settlement address, token identifier, explorer, confirmation rule, and exception path. Review available options in your live setup and use the blockchain directory for Yolfi's network-specific pages.

Run a real low-value test for each enabled combination. Confirm the checkout label, destination, wallet prompt, explorer record, status transition, notification or webhook, reconciliation record, and fulfillment behavior.

Build an incident evidence packet

Ask for enough information once. Repeated requests increase delay and encourage the customer to try unapproved fixes.

Required customer evidence

payment-link URL or payment-reference ID;
order, invoice, or account reference;
transaction hash and a block-explorer link, if available;
asset and amount the customer believes they sent;
network they actually selected;
sending wallet address;
approximate time of transfer;

Merchant-side evidence

asset, network, amount, and destination displayed by the original request;
request creation, expiration, detection, and status timestamps;
configured settlement address for the requested combination;
relevant payment notifications, webhook IDs, and processing results;
explorer result from the network used, checked independently;
customer messages and instructions your team issued;
prior and replacement payment references tied to the same order;
fulfillment, credit, refund, or access actions already taken.

A screenshot can be altered, stale, or taken from the wrong network. Use it to locate the transaction, then verify the transaction independently.

Verify the transfer on the correct explorer

Start with the network the customer says they used, but confirm it from the explorer data. MetaMask's wrong-destination guidance also recommends checking transaction status and the block explorer before deciding what happened.

Open a reputable explorer for the network actually used.
Search the full transaction hash. Do not trust a link's visible text; confirm the explorer domain under your internal procedure.
Check whether the transaction is pending, successful, failed, dropped, or replaced.
Confirm the sender and destination addresses character for character.
Confirm the transferred asset. For a token transfer, verify the contract or mint—not only its symbol.
Confirm the raw token amount in the transfer event. Obtain the token precision separately from the canonical contract or mint, or from trusted explorer metadata.
Record the block, timestamp, current confirmations or finality status, and any relevant logs.
Compare every field with the original payment request.
Check your settlement wallet or wallet-monitoring record on that same network.
Search internal records to ensure the hash has not already been recognized or applied elsewhere.

Circle's EVM USDC transfer quickstart illustrates the separate steps of choosing a chain, submitting a transfer, receiving a hash, and checking an explorer. It also notes that the sender needs that network's native token for gas. Treat this as an example of transfer mechanics, not as a list of combinations available in your Yolfi account.

Use a decision tree instead of promising recovery

Follow the branches in order.

1. Is there a valid transaction on the claimed network?

No, or still pending: keep the order unfulfilled. Ask the customer not to send again while you monitor or while their wallet provider handles a pending transaction.
Failed or reverted: no successful payment occurred in that transaction. Confirm the customer's wallet and explorer state before issuing a replacement request.
Successful: continue to field matching.

2. Does it match network, asset, destination, amount, and confirmation policy?

Yes: process it through the normal recognition path and idempotent fulfillment control.
No: place it in exception review. Do not manually mark it paid merely because value moved somewhere.

3. Does the merchant control the destination on the network actually used?

Not established: do not claim the funds were received or recoverable. Escalate to the wallet owner or custodian responsible for that address.
Yes: confirm that the exact asset exists at that address and can be safely managed under your wallet, security, accounting, and compliance procedures. Address control does not automatically make the original order correctly paid.
No: explain that your business cannot move funds from an address it does not control. Ethereum.org's support FAQ notes that Ethereum transactions cannot be reversed by a central operator; if a known service controls the destination, its support team may be the appropriate contact.

4. Is a remediation approved?

Possible outcomes include recognizing the transfer manually, asking for a correct replacement payment, returning accessible funds as a new transaction, applying a documented credit, or declining recovery. The right outcome depends on the network, address control, token, custody arrangement, technical capability, costs, risk checks, and business policy.

Never say funds are “always lost” or “always recoverable.” MetaMask documents one common EVM case where the same wallet address may be accessible on another EVM-compatible network, but it also describes cases with no guaranteed recovery. That guidance does not prove that a merchant, exchange, smart contract, multisignature wallet, or payment system can access or return a specific transfer.

Issue replacement payment links safely

When the original request cannot be recognized and policy permits another attempt, create a fresh Yolfi payment link. Do not edit history or tell the customer simply to “try again.”

The replacement should:

retain the same order or invoice ID;
receive a new unique payment-reference ID;
state the exact asset, network, amount, and destination shown in the live flow;
reference the prior request as superseded or under review;
explain that the original transaction remains a separate incident;
tell the customer not to pay both links;
preserve any expiration rule;
route both requests into duplicate detection before fulfillment.

Do not instruct the customer to send an untracked difference, resend to an address copied from chat, or switch networks after sending as though that relocates the original funds.

Prevent duplicate payment and fulfillment

A delayed transaction can confirm after a replacement is created. A customer may also send twice while waiting for support. Design for both events.

Use one business-level order ID with multiple immutable payment attempts. Enforce these controls:

a transaction hash can be recognized at most once;
one payment attempt cannot fulfill multiple orders;
one order can trigger fulfillment or access only once;
original and replacement requests remain linked;
all open attempts are checked immediately before fulfillment;
late confirmations and excess receipts enter review;
webhook and notification processing is idempotent;
refunds require separate approval, destination verification, and transaction records.

If two transfers succeed, do not delete one, silently apply it to another purchase, or automatically send funds to an address supplied in a new support message. Freeze duplicate fulfillment and follow the documented credit or refund policy.

Set merchant support and security rules

Give frontline support a script and an escalation boundary.

Support may ask for public transaction data, payment references, order details, and screenshots that do not expose secrets. Support must never ask for a seed phrase, recovery phrase, private key, wallet password, one-time code, or remote control of the customer's device. Anyone with a seed phrase or private key may be able to control the wallet.

Use wording such as:

We can see that a transaction was submitted on [network]. We are checking whether its asset, destination, amount, and confirmation state match payment request [reference]. Please do not send another payment until we provide a new approved link or confirm the next step. We will not ask for your seed phrase or private key.

Set deadlines for acknowledgement, evidence review, escalation, approval, and customer updates. Do not promise a recovery date before access and transaction feasibility are established.

Yolfi is a non-custodial service: payments are sent to the merchant's configured wallet rather than held by Yolfi. That makes correct wallet configuration, access ownership, and merchant-side incident policy essential.

Merchant incident checklist

Before accepting payments

Show asset and network together at every step.
Enable only combinations available in the live Yolfi setup.
Verify every settlement address and token identifier.
Test each enabled route end to end.
Define confirmation, mismatch, duplicate, refund, and escalation rules.
Train support never to request wallet secrets.

When an incident arrives

Pause fulfillment and discourage duplicate payment.
Preserve the original request and customer report.
Build the evidence packet.
Verify the transaction on the network actually used.
Compare network, asset, destination, amount, status, and confirmations.
Check address control without assuming recoverability.
Search for prior recognition and linked attempts.
Record an approved decision and customer message.

FAQ

Can a transaction be confirmed but the payment remain unpaid?

Yes. Confirmation proves that a network processed a transaction. A recognized payment must also match the requested network, asset, destination, amount, reference, and merchant confirmation policy.

Does switching the wallet network recover or move the funds?

No. Switching the selected network changes which blockchain the wallet displays and interacts with. It does not move tokens between networks. In some EVM cases, the same address owner may be able to view assets on the network used, but any subsequent transfer or bridging is a separate action and is not guaranteed to be available or appropriate.

Should we ask the customer to pay again immediately?

No. First determine whether the original transaction is pending, failed, successful, or mismatched. If another attempt is approved, issue a new linked payment request and activate duplicate detection for both attempts.

Can Yolfi recover a wrong-network payment?

Do not assume so. In a non-custodial flow, funds go to the configured merchant wallet. The available remedy depends on the actual destination, network, asset, wallet control, technical capability, and merchant policy.

What if the customer sent the right network but wrong token?

Treat it as a wrong-currency incident. Verify the token contract or mint, amount, destination, and wallet receipt, then follow the documented exception process rather than marking the order paid.

What if the transaction is still pending?

Keep the order pending and do not fulfill. Monitor the explorer and payment status under your confirmation policy. Discourage a second transfer until the pending transaction resolves or a controlled replacement is approved.

Is a screenshot enough to approve fulfillment?

No. Use the hash to locate the transaction and independently verify it on the correct explorer. Then match the transaction to the payment request and check that it has not already been used.

Conclusion

Wrong-network prevention requires an unambiguous asset, network, destination, amount, and confirmation state. Incident handling requires verified transaction data, cautious wallet-control checks, no recovery promises, and duplicate prevention.

Start with the combinations shown in your live Yolfi setup, test them, and give support one decision tree. When another attempt is necessary, create a linked replacement request rather than improvising through chat. The goal is to recognize the correct payment, fulfill once, and preserve every exception decision.