- Keep one reference price and record every exchange rate used to derive other prices.
- Apply rounding and commercial adjustments as explicit business rules.
- Never let a temporary rate failure silently replace valid catalogue prices.
- Separate automated currency updates from merchant-authored price changes.
- Give finance and operations a way to explain any displayed price.
Medusa stored the prices; it did not define the client’s FX policy
Medusa already supplied regional price lists and product pricing primitives. The client’s unresolved problem was how one EUR reference price should become USD and GBP selling prices: which external rate to accept, which commercial buffer to apply, when to refresh and how finance could reconstruct the decision later.
We built a daily workflow that requires the configured quote rates, records raw rate, buffer and applied rate separately, appends audit records and applies derived values product by product. We also exposed those facts in Medusa Admin, giving finance and e-commerce teams a visible history of each pricing run.
The formula is easy; the operating system is not
If a product costs €100 and one euro buys 0.86 pounds, the raw conversion is £86. That calculation takes one line of code. A production pricing system must answer harder questions. Where did the rate come from? When was it retrieved? What happens when the provider is unavailable? Should £86 become £85.99, £89 or remain £86? When does the catalogue update, and can finance explain the price shown to a customer last Tuesday?
In this project, one source price had to feed several Medusa market prices. The client needed conversion to behave as a controlled pipeline rather than a live calculator on every page view. A pipeline means a sequence the business can observe: obtain rates, validate them, store the accepted values, calculate candidate prices, apply commercial rules, update the catalogue and record what changed.
Why finance and merchandising should care
Uncontrolled conversion can quietly destroy margin. A stale or inverted rate may underprice an entire market. Excessive precision can produce unattractive prices. Frequent tiny changes can trigger unnecessary catalogue updates, cache invalidations and downstream synchronisation. If nobody can reconstruct which rate produced a price, support and finance are left comparing screenshots with today’s exchange rate.
The company therefore needs more than ‘automatic FX’. It needs a policy. Which currency is the reference? Which markets are converted? How often do rates change? Is there a safety margin? What rounding style fits the brand? How old may a rate become before publishing stops? Who can override a derived price, and will the next automatic run overwrite that decision? Those are commercial choices expressed through software.
The pipeline we designed
The process begins by requesting rates from an external source. Before accepting them, it checks that every required currency exists, values are positive and movements are within a sensible range. The accepted rate is stored with its source and time. Price calculation then uses the accepted input, not a fresh network call on every product, so one catalogue update works from one consistent set of facts.
The project used workflow steps so retrieval, storage and application were visible parts of one operation. Finance can distinguish the market rate received, the commercial buffer chosen and the selling price applied instead of trying to reconstruct the decision from a final number.
Conversion and selling price are not the same thing
A mathematically converted price is only a candidate. The business may add a buffer for currency movement or market costs, then round according to a chosen style. £86.13 might become £86, £85.99 or £89. Each rule changes margin and customer perception. It must be documented, deterministic and tested at boundaries.
Order matters. Applying a percentage buffer before rounding can produce a different result from rounding first. Currencies also have different minor units, so assuming that every price uses two decimal places is unsafe. We store calculations in the smallest supported currency unit, avoid floating-point arithmetic for money and show the components in an audit view: reference amount, rate, adjustment, rounding rule and final price.
When exchange-rate data fails, do less
A missing or suspicious rate should not turn products into zero-priced items and should not erase the last valid market price. The safe response is to keep the last accepted values, mark the run as failed and alert the team. A maximum age policy decides when old rates become too risky to continue using. That threshold depends on the business and currency volatility.
Updates are handled as a controlled product-by-product boundary. If one currency is invalid, the operating policy decides whether to reject the run or continue only with independent markets. The run history makes partial progress visible so the team knows exactly what needs attention.
Do not mistake an automatic recalculation for a merchant edit
Changing derived prices can emit normal product-update events. If an ERP, search index or other integration treats each event as a human catalogue change, one FX run can create a storm of unnecessary work.
Labelling the origin of the change lets downstream systems decide whether an FX-only update matters to them. A search index may need the new price; a product-content synchronisation may not. Origin metadata is safer than ignoring every update that happens shortly after the currency job, because a real merchant edit can occur during the same period.
The questions we ask before automating currencies
Name the reference currency, rate source, update frequency, accepted rate age, movement limits, market adjustments and rounding rules. Decide how manual overrides behave. Record every accepted rate and every resulting price change. Keep the last valid prices when a run fails, and alert on stale rates or unusually large catalogue changes.
Then test a rate provider outage, a missing currency, an inverted rate, a large movement, zero-decimal currencies, repeated runs with unchanged values and a partial product-update failure. Automation is valuable when it removes repetitive work without hiding commercial decisions. The test of maturity is simple: months later, can finance explain exactly why a customer saw a particular market price?
Common questions
Stored derived prices are faster, more stable and easier to audit. Every visitor sees a price produced from an accepted rate and commercial policy rather than whatever the provider returns at that instant.
Keep the last valid prices, fail the update visibly and alert when the accepted rates become older than the company’s policy allows.
Usually yes, according to an explicit market and brand rule. Record the raw conversion, adjustment and rounding so the final selling price remains explainable.