Markup

Markup is a percentage added on top of the exchange rate, configured per source currency, applied before rounding.

Why you need one

A central-bank reference rate is a benchmark. It is not the rate at which you can actually obtain foreign currency, and it is not the rate at which money reaches your bank account after a card payment. Between the published rate and your settled revenue sit:

• the spread between the reference rate and your bank’s or processor’s rate;
• payment gateway percentage fees and fixed fees;
• cross-border and currency-conversion surcharges;
• movement in the rate between one refresh and the next — the risk window you are actually exposed to.

Setting markup to zero means selling at the benchmark and absorbing every one of those. That is a valid choice; it should be a deliberate one.

Choosing a number

There is no correct value — it is a commercial decision. A defensible way to arrive at one:

1. Take your payment processor’s effective percentage on a typical order.
2. Add the spread between the reference rate and the rate you actually pay for foreign currency.
3. Add a buffer for movement between refreshes. A daily refresh in a volatile currency needs a bigger buffer than an hourly refresh in a stable one.

Then check the result against your competitors’ shelf prices, because a mathematically correct price you cannot sell at is not a correct price.

Markup and refresh interval interact

The more often you refresh, the smaller the window in which the rate can move against you, and the smaller a buffer you need. If you refresh daily in a currency that can move several percent in a day, your markup is carrying that risk. Increasing refresh frequency and reducing markup is often a better trade than the reverse, because it keeps your shelf prices closer to the market.

Where it is applied

Markup is applied after the rate lookup and before rounding. It is exposed to add-ons through a public filter, which is how Pro implements per-product and per-category markup: the same single pipeline still writes the price, so a scoped rule cannot bypass validation, the margin floor or rounding.

Per-user or per-role markup

Not possible, permanently. Price Anchor stores one price per product, written by a background job that runs under cron with no logged-in user — there is no role to branch on at the moment the price is decided. Supporting it would require computing prices at read time, which is precisely the design this plugin rejects and which brings back wrong catalogue sorting, wrong price filters, wrong reports and double conversion. If you need per-customer pricing, you want a role-based pricing plugin; that is a different product.