When a Crypto Sale Fails: Where the Money Goes and Who Handles It

The cost of a failed sale is settled before you integrate:

• The crypto comes back. If it returns on its own, there is nothing for your team to do; if the user has to claim it, you owe them a recovery flow.
• It comes back as crypto. Money refunds are the exception, and each provider draws that line somewhere else.
• Someone answers the user. Either the provider answers them during stated hours, or you hire for it.
• A refused card is the bank's decision. Your controls are the message on the screen and whether retry exists.

Every off-ramp documents a return path for a failed sale. Which one applies depends on the point at which the sale broke, and there are three of those.

Providers hold a sale open for a fixed window and close it when nothing lands. Crypto that arrives after that is handled as an exception rather than as a sale.

Mercuryo, for instance, gives the user six hours. Crypto that lands after that is credited to the user's Mercuryo Wallet as a regular deposit instead of being converted.

Users reach this one by walking away mid-flow. Nothing is lost, and nothing is finished either, because the user now holds crypto in an account they may not have known they had.

Between the quote and the deposit, the market moves. The provider either absorbs the difference or stops the sale, and the threshold where it stops is a number worth asking for.

A tight threshold returns more deposits and spares you arguments about the amount. A loose one pays out more often and produces those arguments instead.

Here the provider faces the same choice a retailer faces when a purchase comes undone.

A retailer sends money back to the card, hands you a credit you have to claim, or leaves a balance that only exists inside their app, and off-ramps take the same three routes:

• Automatic return to the address the user gave before sending anything.
• A claim step, where the funds sit until the user comes back and asks for them.
• An internal balance, credited inside the provider's own interface and nowhere else.

Mercuryo uses the first route when the error is on its side: the crypto goes back to the return address the user gave before sending.

An automatic return needs no work on your side. A claim flow means new screens, a notification, and a support path left out of the estimate, so pin down which one you are buying before engineering assumes the automatic one.

A return sends crypto to an address; a refund pays money to a card or an account. Documentation usually describes the return in detail and the money refund in a sentence, or not at all.

The confusion between the two ends up in your support scripts. Ask where that boundary sits, and what the user has to provide for a refund to apply.

A provider that cannot put it in a sentence has not written it down, so each case gets decided after the fact.

With Mercuryo, those returns go to the return address as crypto, and the payout card isn't involved.

Write that into your macros now. A team that tells users "we will refund you" when the provider returns crypto to an address has promised something the provider never offered, and those tickets escalate.

There are two models, and the choice is a hiring decision more than an integration one:

• The provider answers directly. Its support team talks to your end users on its own channels and hours.
• You answer first. Your team is the first line, and the provider talks only to you, usually through an account manager.

Failed payouts produce questions that belong to payments support rather than product support, like card declines, bank policy, verification holds, or a deposit visible on-chain but not yet credited. Ask for hours and channels in writing. "We handle support" means nothing without a schedule attached.

End users are Mercuryo's to answer. They reach the team around the clock through live chat and email, and the partner keeps a separate channel agreed case by case, whether that is Slack, Telegram, a ticket portal, or email.

When the provider owns that conversation, your job is to make the route to it visible at the moment the sale fails. If the user cannot find it immediately, they write to you instead, and the coverage you paid for makes no difference.

When a payout to a card is refused, the decision belongs to the bank that issued it. No off-ramp can reverse it, and a provider that suggests otherwise is claiming something it does not control. A provider can pass on the decline reason in words the user can act on, and that is the extent of it.

Some of those refusals hit users who did nothing wrong, and the only thing to offer them is another card.

Mercuryo lists four, and all four sit with the bank:

• the bank does not support crypto-related transactions;
• its security team flagged the payment;
• a regulatory restriction applies;
• the card details or billing address do not match.

The next steps it gives the user are another card or a call to their bank.

Everything you can do here happens on one screen, in the wording and the step it offers next. Escalation paths are wasted effort, because there is nothing upstream to escalate to.

Buying is cheap to retry. No money has moved yet, so the user enters another card and continues. Selling costs more, because the crypto has already left the wallet and has to return before anything can be attempted again.

Ask about selling specifically, and do not let a demo of the buying flow answer for it. A sale fails after the deposit arrives; what does the user see, and what can they press?

Without retry, a user who fails once starts the whole sale again, including the deposit and any verification step they already passed. Every step they repeat is another chance to abandon the sale.

Put that loss in the launch plan rather than waiting for it to arrive as a bug report. The wait on a sale that does work is its own subject, covered in how long it takes users to get their money after selling crypto.

Send these five before you commit to a provider, then check whether the answer gives you something to act on.

When a sale fails after the deposit arrives, how does the crypto get back to the user?

• Do not settle for "We take care of failed transactions."
• A usable answer names: the route back · how long it takes · whether the user has to ask for it

When do you pay money back instead of returning crypto?

• Do not settle for "It depends on the case."
• A usable answer names: whose fault gets money back · who decides that · what the user has to send you

Who talks to our end users when a sale fails?

• Do not settle for: "we handle support."
• A usable answer names: which channels · which hours · where our team goes instead

When a card payout is refused, what do you pass to us?

• Do not settle for "The bank declined it."
• A usable answer names: the decline reason in plain words · the next step we can put on screen

Can a user retry a failed sale inside the flow?

• Do not settle for "Users can always try again."
• A usable answer names: whether retry exists for a sale · what the user has to redo · whether verification repeats

Ask for the five answers in an email, then read the replies next to the provider's own documentation. Read them together, because the documentation is the part a provider has to stand behind.

Sometimes the return turns out to need the user to trigger it, or the refund turns out to be crypto landing at an address. In other cases, the support hours do not cover your users' time zones, the decline reason reaches you as a code, and nothing else, or the sale begins again from the deposit.

Little of this appears in a demo, because a demo only runs the case where everything works. It appears after launch, in the hours between the crypto leaving and the money arriving, and by then your only job is staffing the failure path you were handed.

If Mercuryo is one of the providers on your list, send the five questions over.

• If a sale fails, does the user lose their crypto? In almost every case, no. The crypto returns, either automatically to an address the user provided or through a claim step. With Mercuryo, crypto goes back to the return address when the error is on Mercuryo's side, and crypto that arrives after the six-hour window lands in the user's Mercuryo Wallet.
• What is a return address, and why does the user enter one up front? It is the wallet address the provider uses to send crypto back if the sale is not complete. It is collected before the deposit, because the provider needs it before the user leaves the flow.
• Is a failed sale refunded in money? Usually not. The standard outcome is crypto returned to an address. Money refunds are the exception, and each provider sets its own rules for when they apply, so get the answer in writing.
• Who answers the user, us, or the provider? It depends on the support model. Mercuryo covers end users directly, 24/7, through chat and email. Partners get a separate channel, agreed upon one by one rather than fixed.