Wrong network or wrong token: where did the customer's money go?

In Paymos, when a customer sent crypto on the wrong network or paid with the wrong token, the payment is not destroyed. It ends one of three ways. The same token from another network the invoice accepts pays the invoice one for one, on its own. A different token that Paymos accepts on that network lands on your balance by itself, at the ordinary processing fee, with no support ticket and no recovery fee, while the invoice runs out its window and expires. Only a transfer in a token or on a network the invoice does not accept, or below the network's minimum, does not arrive on its own.

Which of the three you are looking at decides what you tell the customer and what your order system does next. The overpayment guide covers what Paymos does when the amount is off. This post covers money that reaches the invoice address without paying the invoice: what Paymos does with it, how Paymos tells you, and what your server receives.

What does Paymos do when a customer pays from a different network?

It counts the payment toward the invoice one for one, on nearly every network where Paymos accepts that token.

The address is why this happens at all. An address that starts with 0x is the same string on every network running the Ethereum Virtual Machine; MetaMask's help centre says it directly — a recovery phrase "generates the same address across all EVM-compatible networks". So when the checkout shows an address on Polygon and the customer picks BNB Smart Chain in an exchange's withdrawal form, the transfer reaches the same address on another chain.

Paymos takes that transfer against the invoice as if the right network had been chosen. The invoice closes, your endpoint receives the same events it would have, and the order goes out as it always does; neither you nor the customer has anything to do. How the networks differ from one another is a separate comparison.

Where Paymos accepts the token on that network and the payment still does not count toward the invoice, the money is credited to your balance outside it, provided it clears the network minimum, and the invoice expires when its window ends. If that transfer, alone or with what the customer paid before, covers the invoice amount, your endpoint then receives invoice.paid_late. The invoice keeps its status, paid_late_at records when the total reached the amount, and whether the order ships is your decision.

Tron, TON, and Solana each use an address format of their own, which a wallet on another network rejects as a destination, so the wrong-network mistakes that reach an invoice happen between EVM chains.

Customer paid with the wrong token — what does Paymos do with the money?

It credits the money to your balance if Paymos accepts that token on the network it came on. No support ticket is needed and there is no recovery fee: the only deduction is the ordinary processing fee, the same one any settled payment carries, at the rate on the pricing page.

USDC sent against an invoice priced in USDT lands as USDC: the amount that was sent, less that fee. Nothing is converted, and no rate is applied to dress it up as the invoice amount. The invoice is not paid by it, and a different token never counts toward the invoice amount later either, so no invoice.paid_late follows. The credit is marked as a wrong-token payment, and the order behind it waits on your decision.

What counts is the pair: this token, on this network. Each network's copy of a token is its own contract, and each issuer keeps its own list of networks — Circle for USDC, Tether for USDT. The pairs Paymos accepts are on /tokens/usdt and /tokens/usdc, and why a business might prefer one dollar token to another is a comparison of its own.

Why was the order cancelled if the money is on your balance?

Because the invoice expired, and your server acted on the expiry. It is the one place your integration needs a change.

A credit outside an invoice has no webhook of its own: none of the nine invoice events in the event catalog describes a credit. The invoice the money missed still runs out its window, though, and Paymos sends invoice.expired for it — documented as "the invoice expired without a qualifying payment". That is true. It says nothing about the money already on your balance.

So the handler to read today is the expiry handler. Restocking the item, releasing a seat, cancelling the order, emailing the customer that their payment never came: each of those now runs against an order somebody paid for.

// invoice.expired means the invoice was not paid.
// It does not mean nobody sent money to its address.
if (eventType is "invoice.expired")
    await HoldForReviewAsync(invoiceId); // not Cancel, not Restock

Holding an expired order until a person has looked is the safer default for ordinary expiries too — the idempotency argument arriving from another side.

A held order can get a second signal. If money in the invoice's own token, late or from another network, covers the amount after all, invoice.paid_late arrives for the same invoice. The status stays expired, so the event changes nothing by itself: it is a note for the held order and the cue for whoever reviews it to look again. A different token never sends it.

How does Paymos tell you about the credit?

The notice goes out with the credit: by email, on the dashboard bell, and on Telegram when that contact is linked — through the same inbox a withdrawal notice uses. It carries the net amount that reached your balance, the fee on its own line, the token, the network, the reason, and a link into the dashboard.

On the Balance page these credits sit on the Activity tab, in one table with your payouts; the type filter separates the two. Each row says whether the money came in on an invoice or without one, and what kind of arrival it was: a wrong token, a wrong network, a payment after the deadline, an invoice that was already closed, or an address with no invoice behind it. Its amount, marked +, is what reached your balance. Click the row and it unfolds into Gross, Fee, Net, the Invoice the address belonged to or No invoice, Sender, Transaction, and a short explanation. When the transfer behind the credit was never observed, the row reads Sender unknown and Transaction unknown, and details found later are attached to the same row.

The credits themselves have no webhook and no API call: an integration learns about them from the dashboard and the mail. The only event this money can cause is the invoice.paid_late described above.

What do you do with the order and the money?

That decision is yours, and Paymos has already put in front of you what it takes to make it. The invoice stays expired whatever you choose, even after an invoice.paid_late; what you are choosing is the order's fate.

Fulfilling means closing the order in your own system by hand. The proof of payment is the credit row, not the invoice status, so copy the row's details onto the order where your team will look during the next reconciliation.

Refunding is a transfer from your balance, in the amount, token, and network you choose. Nothing goes back on its own, and the product promises the payer no refund. The row gives you the material: the amount that landed, the fee that came off, and the sender's address and the transaction hash when they are known.

Settle two details before you promise the customer anything. The balance holds what arrived minus the fee, so returning the full amount they sent costs you the difference. And where the sender is unknown, there is no address to send anything to.

When does the money not arrive on its own?

In three cases, and none of them is credited automatically.

A token Paymos does not accept on that network — USDC on Tron or TON, USDT on Base. A transfer like that is not credited. The accepted pairs are on /tokens/usdt, /tokens/usdc, and /chains.

A network the invoice does not accept. For an address starting with 0x, this is where the realistic mistake lives: the same address exists on every EVM chain, and ERC-7828, a proposed standard in Ethereum's own process, describes an ecosystem of "hundreds, and eventually thousands, of L2s that share the same address format as Ethereum mainnet". That is far more networks than Paymos accepts. A payment sent on one of them stays at that address, on that chain.

An amount below the network's minimum. The Paymos checkout already refuses a token and network whose minimum sits above the invoice amount, so paying the full amount on the network the page showed does not run into it. A small partial transfer can, and so can a detour to a network with a higher minimum. An amount under the minimum is not credited, and support takes it from there.

What should a customer who already sent it do?

Write to the seller with four things: the order number, the token, the network, and the transaction hash. Nothing on the customer's side undoes a confirmed transfer — a blockchain payment has no reversal to ask for, and the wallet that sent it cannot pull it back.

The seller is the right door because every outcome ends with the seller. If the payment closed the invoice, the order ships as it would have anyway. If it was credited outside the invoice, the money is on the seller's balance and the decision is theirs. If it did not arrive on its own, the hash is the first thing support will ask for. The customer can also reach Paymos support from the payment page, and operators there can bring the seller in; the four details are the same.

Of the four, the hash matters most: with it, the payment is found in one step instead of by matching amounts and times.

How is this different from an overpayment or an underpayment?

By whether an invoice is involved at all.

Paymos treats an overpayment and an underpayment as states of an invoice. Each has a status your integration reads and an event it subscribes to — invoice.paid_over, invoice.underpaid, invoice.underpaid_waiting — and each belongs to an order that exists and is waiting on something. The amount guide covers both, and the invoicing guide covers how an invoice is issued in the first place.

A credit outside an invoice is money with no invoice behind it: no status, no event of its own, and an order that may have expired, may have closed weeks earlier, or may never have existed.

Confusing the two produces one mistake, always the same shape. An operator sees the credit, reads it as a part payment toward the invoice, and ships against the invoice. The invoice never completes, and the next reconciliation holds a credit and an order that nobody tied together. One question keeps them apart: which invoice is waiting for this money? An underpayment has an answer. A credit outside an invoice does not.