Adding Crypto Cash-Out to Your Product: Four Decisions Before You Build

Four things make selling its own feature:

• Fewer of your users can use it. Payouts usually reach fewer currencies and countries than purchases do.
• Verification moves to the exit. Users who bought on a light check meet a full one when they try to sell.
• The crypto goes first. A stalled sale leaves your user waiting with nothing in hand.
• Small sales come out expensive, because a flat minimum fee sets their price.

Whichever provider you use, expect sell coverage to be narrower than buy coverage.

Charging a card and paying money out to one run on different rails, and payouts reach fewer currencies and countries. So check two things separately: which currencies users can get paid in, and which countries the payout works in.

With Mercuryo, users get paid in EUR or USD, while buying takes more than 60 currencies. Someone in Brazil who paid in reais gets euros or dollars back.

Country coverage works by exception. Any country not on Mercuryo's published list is supported for both Visa and Mastercard. The list is long, though, and includes large markets you'd probably assume were covered. The same list flags countries where payouts work with Visa but not Mastercard.

Then do the arithmetic. Run where your users live and which cards they carry against your provider's lists, and you get a percentage: the share of your base that can actually use the feature.

Nobody should estimate a sprint without that number - if it comes back low, sequencing cash-out behind a market expansion may beat shipping it for a minority of your base.

Buying can often go through on a light identity check. Paying money out works differently. The provider is sending money to a named card, and it has to know whose card that is. What the industry calls KYC, proving who you are with documents, moves to the exit.

So some of your users, people who bought months ago and think of themselves as onboarded, will meet a document upload for the first time at the moment they're trying to get money out. They want their money right then, and that's when patience runs out.

Before you design around this, ask your provider whether every sale needs a full check and whether expired documents block a sale. Also ask whether it can accept verification you've already done.

Each is a product decision, and each has a price you pick up front:

1. Verify earlier. Move the check into onboarding or into a prompt after the first purchase, so users reach the sell screen already verified. You pay for it in people who drop out before they ever buy.
2. Verify at the point of sale. Keep onboarding light and let users meet the check on the way out, inside the provider's flow. The drop-offs land at the exit instead, along with tickets from people who wanted their money today.

Anyone who has sold something on a marketplace knows the feeling. You post the parcel, the tracking says delivered, and the money still isn't there. Nothing has gone wrong, and you check your phone every ten minutes anyway.

That's your user after they hit sell, except what they handed over is their money.

A purchase gone wrong ends better than that. A card gets declined, or a payment goes through and the order never completes. Either way, the charge comes back. They try again, annoyed, but still holding their money.

Selling runs the other way around. The user sends crypto first and gets paid after, so anything that goes wrong happens after they've already handed something over.

Every provider has to answer the same questions: how long the user has to send, what happens to crypto that arrives late, and when it gets returned. Get those answers before you design the flow, because they decide what your status screens need to say.

With Mercuryo, the user has six hours to send. Crypto that arrives later lands in their Mercuryo Wallet and stays there as crypto instead of turning into cash. The return address they enter up front is only used if the error is on Mercuryo's side.

Your users will ask you first, because it's your product they're looking at. I sent it, and I don't see the money.

Ask your provider what the flow reports about a sale in progress and who answers users when one stalls. That decides where the question lands: a status screen in your product, a route to the provider's support, or your own team checking each one.

With Mercuryo, the flow reports where each sale stands, and users get 24/7 chat support for transaction issues.

If a fee has a flat minimum, small sales pay the most for it. People tend to try small cash-outs first, so a new user can meet your worst price on their first sale. Caps matter too, since a provider's sell limits don't have to match its buy limits.

Ask for the minimum fee on a sale, any extra charge by payout currency, and the sell caps next to the buy ones.

With Mercuryo, selling costs up to 3.95% with a €3 minimum. On a €40 cash-out, the minimum alone works out to 7.5%. The final quote is shown before the user confirms.

Sell caps are €10,000 per transaction, €30,000 a day and €50,000 a month. The daily and monthly caps match buying, but buying allows €15,000 per transaction, so someone who moves large amounts in hits a lower ceiling going out.

Here's what to ask before you sign with a provider. For reference, the second column shows how Mercuryo answers each one.

The integration is the smaller half of this project. Leaving any of these open is how a shipped cash-out feature ends up with low usage and a busy support queue.

1. Coverage. Run your user base against your provider's currency and country lists first. If the covered share comes back small, the release is premature.
2. Verification. Does the check move into onboarding, happen on the way out, or reuse one you already run? Pick on purpose and measure what it costs you.
3. Failure routing. When a sale stalls, does the user see the status in your product, get sent to the provider's support, or reach your team? Decide before launch, not after the first ticket.
4. Disclosure. Users should see the caps and the minimum fee by the time they reach confirmation, especially on small amounts, where the minimum sets the price.

Mercuryo's off-ramp handles verification and pays out to the user's card inside the same widget that runs buying. Walk through the sell flow screen by screen and check it against the decisions above before you scope the work.

• Is crypto cash-out just the buy flow reversed? No. Payouts usually reach fewer currencies and countries, verification applies at the exit, and failures happen after the user has already sent their crypto. The specifics depend on the provider.
• Which currencies can users receive when they sell? It depends on the provider, but payouts usually cover fewer currencies than purchases. With Mercuryo, users get EUR or USD paid to a Visa or Mastercard, subject to country availability, while buying accepts more than 60 currencies.
• Do users need to complete KYC to sell crypto? Expect verification before any payout, since the money goes to a named card. With Mercuryo, every sale needs a verified user with current documents. Users who bought on a light check verify inside the sell flow, and partners who verify through Sumsub can share an approved result.
• What does selling cost the user? Usually a percentage plus a flat minimum, and on small amounts the minimum can account for a larger share of the transaction. With Mercuryo, selling costs up to 3.95%, with a €3 minimum. On a €40 cash-out, the €3 minimum alone equals 7.5%.