What to Track During a Crypto Sale: The Blind Spots Your Team Inherits

For much of a crypto sale, your team cannot see what is happening.

• Support is left without information in the middle of the sale. Users ask about their money while the sale is still running, and the agent often has nothing on screen to check.
• A failed sale can come back as a second record. A ledger with one line per sale miscounts it, and the error surfaces when finance tries to close the month.
• Missed updates arrive late if the provider retries. Your system has to accept the same update twice and count it once, and someone has to notice when updates stop arriving.
• Each blind spot has an owner in support, finance, or operations, and each can be settled with the provider before the first user sells.

Working with an outside provider creates this kind of blind spot, and outside providers are a common source of incidents.

Of the 3,383 major incidents that EU financial firms reported in 2025, nearly one third originated with a third party, according to the European Supervisory Authorities.

The processing moves to the provider, and the questions from users, finance, and your own team stay with your product. Closing each blind spot before launch costs less than closing it after an incident, when there is also damage to repair.

The first blind spot affects support. A sale takes time, because the provider has to receive the crypto, convert it, and pay out. Users can see the start and the end of that process for themselves, so their questions come in the middle, which is the part your product cannot show.

• Is my money coming? The agent needs to see where the sale stands right now.
• Did it come back? The agent needs to see whether the sale failed and the crypto went back to the user.

If your product records only the start and the end of a sale, the agent can see that the sale began but not where it is now. The answer then depends on someone with access to the provider's side checking on the agent's behalf.

Providers usually offer two ways to follow a sale in progress: a dashboard your team can open and status updates your system can store. Some also answer your users directly.

Mercuryo, for example, offers users round-the-clock chat and email support and gives merchants a dashboard with separate roles, one of them for accounting.

Even with those tools in place, your own agent still has to find the answer somewhere. If the user has already spoken to the provider's support, your agent needs the same information, or the two answers may contradict each other.

Access matters too. If only one person on your team can open the provider's dashboard, every ticket waits for that person.

Before launch, ask your provider what its updates report about a sale in progress, how many people on your side can access its dashboard, and whether it answers your users directly.

With those answers, show the status of each sale in the tool your agents already use, and give dashboard access to more than one person.

The second blind spot affects finance. When a sale cannot be completed, the crypto goes back to the user, and providers record that return in different ways.

Some change the status of the original sale. Others create a separate record for the return, with its own timing. Mercuryo follows the second approach: when a sale fails on Mercuryo's side, a separate transaction sends the crypto back to the user's return address.

If returns arrive as separate records, a ledger that keeps one line per sale has no place for them. One sale produces two records, and the ledger either drops the return or counts it as new activity.

Nothing alerts anyone when this happens, since the system keeps running and the user has the crypto back. The mismatch stays in the numbers until finance tries to close the month and the totals differ from the provider's report.

To avoid that, ask your provider whether a return changes the original sale or creates a new record, and have finance plan the ledger around that answer before the first return.

The third blind spot affects engineering and operations. Many providers send your system an update each time a sale changes, which is simpler to build than checking each sale on a schedule and shows changes sooner.

That setup depends on your system being available when each update arrives. Updates that reach it during an outage, a release, or a slow period can be lost.

• Does the provider try again, and for how long?
• Can the same update reach you more than once?
• If an update is missed for good, can your team still get the current status of a sale?

Retry windows vary between providers, so a reference point helps. Mercuryo resends an update for up to three days, waiting longer between attempts.

Retries change what your engineers need to build. A missed update still reaches your system, only later.

A retry can also arrive after your system has already processed the first copy, so your side has to accept the same update twice and count it once.

Accounts payable teams already have a routine for this. When a supplier gets no reply and sends the same invoice again, the team checks the invoice number before paying, so the second copy is not paid twice.

Your system needs the same check, confirming it has not already processed an update before acting on it. The work is small and belongs in the first estimate, because adding it after duplicates have reached the ledger also means correcting the ledger.

Retries end after a set period, so someone on the operations side needs an alert when updates stop arriving. A retry window only helps if the outage is fixed before it closes.

A postmortem is the report a team writes after something goes wrong, describing what happened, in what order, and why. The one below can be written before launch, because each step comes from the blind spots above. It follows one user and one sale on a day with a routine release.

Each of these steps is common on its own, and in this case they all affect the same sale.

• Tuesday, 09:30. A new release went out, and for twenty minutes the system rejected every update the provider sent.
• 09:40. A user sold crypto from inside the app. The provider could not complete the payout and returned the crypto to the user's wallet as a separate transaction.
• Before noon. The user wrote to support twice. The agent could see that the sale had started and nothing after that, and escalated to the one person with dashboard access, who was out that day.
• That evening. The updates arrived on a retry, and the ledger recorded the return as a new deposit.
• Month end. Finance found totals that did not match the provider's report and spent two days tracing a single sale.

Read in reverse, the incident contains three failures, one for each blind spot. All three happened on your side, and each belonged to a different team, while the provider returned the crypto and kept resending the updates.

The table lists each failure with the team it affected, the decision that would have prevented it, and each of those decisions could have been made before the first user sold.

Providers often describe visibility in general terms. Put these three questions to each provider on your list and compare how specific the answers are.

A general answer: "You'll have full visibility in our dashboard."

A specific answer names which changes send an update to your system and how many people on your side can open the dashboard, with which roles.

For reference. Mercuryo sends an update every time a sale changes, and the dashboard has separate roles, one of them for accounting.

A general answer: "Failed sales are refunded right away."

A specific answer says whether the return changes the original sale or creates a new record, and where it appears in the provider's report.

For reference. When a sale fails on Mercuryo's side, a separate transaction returns the crypto to the user's return address.

A general answer: "You won't miss a notification."

A specific answer covers how long the provider keeps retrying, whether the same update can arrive twice, and how to get a sale's current status after retries stop.

For reference. With Mercuryo, updates are resent for up to three days.

Products that sell crypto through a provider face some version of these blind spots, whichever provider they use, and the point at which they are found decides how much they cost.

Found before launch, each one costs a line in the first estimate and a question for the provider. Found after launch, each one shows up as support tickets, a month that does not reconcile or an outage nobody noticed.

Consider the Friday evening message again. With the blind spots closed, the agent on duty can see where the sale stands and reply without escalating. Finance records the return correctly, and an update missed during a release arrives later and is counted once.

To check these questions against Mercuryo's setup before the estimate is final, talk to our team.

• What should my product keep track of during a crypto sale? The status of the sale at each step, any return linked to it, and whether the provider's updates are still arriving. Recording only the start and the end leaves support without answers and finance without the full record.
• How does my team know where a user's sale is? Either someone checks the provider's dashboard, or your system stores the provider's updates and shows them in your own tools. The first option works at low volume, and the second lets support answer without escalating each question.
• Do I have to check for updates, or do they come to me? Usually the provider sends them to you as the sale changes. What you need to confirm is what happens when your system misses one, and whether you can request a sale's current status when in doubt.
• Why does one sale show up as more than one movement? With some providers, a failed sale sends the crypto back through a separate movement with its own record. If yours works that way, your ledger needs room for that second record, or month-end totals will not match.