Pricing Automation Across Currencies

The cost of goods usually lives somewhere else. In a supplier email, in an accounting system nobody in sales has access to, in a workbook maintained by the one person who knows which tab is current. Once a quarter that person reconstructs the margin, and everyone treats the result as fact because there is no competing version.

Putting the purchase cost next to the price, inside the same admin, changes what the team can answer on the spot. It also removes a dependency on a single colleague that nobody planned and nobody notices until they take a holiday.

The multiplier is where the commercial judgement lives, and there is deliberately no default for it. A run that finds no margin configured is refused in full rather than proceeding on a made-up number. Guessing here would be worse than doing nothing, because a wrong price that looks plausible ships.

You are not obliged to wait for the schedule. A recompute can be triggered from the admin, and each run reports per currency what it actually did, so the first question after a change has an answer in the interface rather than in the logs.

Only the default price is ever read or written. Region overrides, customer group prices, quantity breaks, anything scoped by a rule or living in a price list: all of it is somebody's deliberate exception, and the plugin leaves it alone.

Manual edits are protected by the plugin's own record of the last price it wrote, used as an optimistic concurrency stamp. If the live price no longer matches, a person has been there and the run steps around it.

A currency missing from the store's supported currencies is skipped whole rather than variant by variant. A rate older than the staleness tolerance, five days by default, or one that cannot be fetched at all, skips that currency for the entire run. No stale price gets written because half the data happened to arrive.

And the whole thing seeds to off. Installing it changes nothing until you enable it.

Each record carries more than a number. It carries the currency, the source, meaning whether it was entered by hand, imported from a CSV or written over the API, the Medusa user who changed it, and a note. Six months later the question is rarely what the cost was. It is why it changed, and who agreed to it.

The history table's update, delete, soft delete and restore operations are deliberately overridden to throw. There is no supported path to editing the past, by design. A cost history that can be tidied up is not evidence of anything.

The commission rate defaults to zero, which is honest for a store selling only through its own checkout. VAT has no default at all, and neither does currency: an operation that needs one refuses and names the setting that is missing.

That refusal extends to the outputs. A missing input returns nothing rather than a zero, because a zero margin printed next to a product is a statement, and it would be a false one.

A widget on the product detail page shows the cost, the history and the derived figures for the product in front of you. And a margin column appears in the shared Catalog table, the single extensible product list that our Medusa plugins contribute columns to, rather than each plugin adding a near-identical list of its own.

The practical effect is that margin becomes something you glance at while doing something else, instead of a report somebody has to be asked for. Full documentation for both plugins lives at medusa-fx-pricing and medusa-product-costs, and you can read exactly what they do before commissioning anything.