On your own shop, a refund is a button in your payment provider. On a Mirakl-powered marketplace (the platform behind Leroy Merlin, Carrefour, MediaMarkt, Worten, Conforama, Decathlon and many more), a refund is a message you send to the marketplace, and the marketplace does the rest: moves the money, tells the customer, and records that you did it.

That difference is the whole subject of this post. Most refund mistakes come from treating the second thing like the first.

A refund is per line, not per order

A Mirakl order is a list of order lines. Each line has its own state (accepted, shipped, received, refused, cancelled…), its own price, and its own history of refunds. When a customer says “refund me,” the first question is which lines, and the second is how much of each.

Two consequences follow. A line can be refunded more than once, in parts, until the total is reached; so “has this been refunded?” is not a yes/no but an amount. And the order can be in a state where some lines are refundable and others are not; a line that was cancelled before shipping is not refunded, it is cancelled, and trying to refund it fails.

Any tool, or person, about to issue a refund therefore has to read the order live, right before acting, and work out per line what is still refundable. Reading it from yesterday’s export is how double refunds happen.

Every refund carries a reason the operator chose

The marketplace operator defines the list of refund reasons a seller may use, and each refund must cite one. The lists differ per marketplace: one has a dozen granular reasons, another five. They are not decoration. Operators use them to spot sellers with too many “item not as described” refunds, and to decide who pays for what, since some reasons put the cost on the seller and some on the marketplace or the carrier.

So the reason has to be picked from that marketplace’s current list, at the moment of refunding, and it has to be the honest one. A tool that hard-codes “customer request” for everything is quietly misreporting you to the operator.

The operator is watching, and the customer hears from them

When the refund goes through, two things happen that you do not control. The operator sees it in their back office, alongside your refund rate. And the customer gets a notification from the marketplace, in their language, with the amount, whether or not you also write to them.

That second point changes what your reply should say. You do not need to explain the mechanics. “The refund of 29,90 € for the returned jacket has been issued to your original payment method; the marketplace will confirm it by email” is complete. Promising a date is a mistake: the timing is the marketplace’s and the bank’s, not yours.

It cannot be undone

There is no “unrefund”. A refund issued for the wrong line, the wrong amount, or the wrong order is a refund, and getting the money back is a conversation with the customer and the operator that you will not enjoy.

This is why the click has to stay with a person, and why that person needs the right information in front of them when they click: the order as it is now, the lines and what is left on each, the amount about to be refunded, and the reason. Not a summary written an hour ago.

What a good refund flow looks like

Here is the sequence we settled on after doing this by hand for long enough:

Recognise the request. The customer asks for their money back, or the situation plainly requires it: a confirmed return, an accepted claim for an item that never arrived, a cancellation of an order that already left. Exchanges, address changes and invoice requests are not refunds and should not be offered one.
Read the order live. From the marketplace, now. Not from a cache.
Work out what is refundable. Per line: state allows it, and the amount already refunded is less than the line total.
Propose, do not act. Show the person the lines, the amounts and the reason picked from the operator’s list, with the evidence (the customer’s own words) that triggered it.
Confirm. A deliberate click, with a warning that this moves money and cannot be undone.
Re-verify, then execute. Between the proposal and the click, the order may have changed (someone in the warehouse refunded it, the customer cancelled). Read it again; if it changed, stop and show the difference rather than proceed.
Log every step. Who clicked, when, which lines, which amounts, which reason, and what the marketplace answered. The log is what you will need when the operator asks.
Reply with the fact. Amount, lines, “issued to your original payment method”. Nothing about timing.

Step 6 is the one everybody skips and the one that prevents the expensive mistakes. Step 7 is the one you are grateful for three months later.

A note on Amazon

None of the above applies to Amazon, where refunds are issued in Seller Central and there is no equivalent seller-side API for buyer-message-driven refunds. Treat Amazon refunds as a separate, manual procedure, and do not let a tool pretend otherwise.

Where Miross stands

Miross issues the refund from the case, per order line and with the operator’s own reason code, and only after a person has read the preview and confirmed it. It re-checks the live state of the order first, refuses to refund twice, and keeps every step in the case’s log. The sequence above is the one it follows.

The short version

A marketplace refund is a per-line action with a reason, seen by the operator, that cannot be reversed. Read the order live, propose, confirm, re-verify, execute, log, and reply with the fact. Keep the click human. That sequence is boring, and boring is the point.