Exchange Rates for Pricing: Spot, Mid-market and the Spread You Actually Pay

The mid-market rate is the midpoint between buy and sell prices in the interbank market. It is useful for dashboards and rough comparisons. Card networks, banks and payment processors apply a spread around it, sometimes plus a fixed fee. If you quote a customer the mid-market rate and settle at the processor rate, the gap becomes your loss or an awkward conversation.

The bid is what a dealer will pay for a currency; the ask is what they will sell it for. Retail customers usually buy at the ask and sell at the bid, so they always sit on the worse side of the spread. Tools that show a single rate without labelling which side it is are fine for education and dangerous for contracts.

Rates move. An invoice that says converted at the rate on the day without naming the source and time is ambiguous when the day spans a volatile session. Record the source, the exact rate, and the UTC timestamp in the invoice metadata. That record is what settles disputes, not a recollection of what a website showed that morning.

If a customer paid in one currency and is refunded days later, the rate may have moved. Decide in advance whether refunds use the original rate, the current rate, or the processor default, and put that in the terms. Silent choices here create support load and, in some jurisdictions, compliance questions.

Not every currency has two decimal places. Some have zero, some have three. Rounding half-units away from zero versus bankers rounding changes totals on large batches. Pick a rule, apply it consistently, and keep unrounded values in the ledger when possible so you can re-open the arithmetic.

Converting A to B via USD as an intermediate can differ from a direct A to B quote, especially for less liquid pairs. If your provider only offers certain pairs, document the path. Unexpected triangular conversion is a common source of one-cent discrepancies that multiply across thousands of orders.

Choose one primary rate source for display and one settlement source for money movement. Show the customer which was used. Refresh displayed rates on a known schedule. Store historical rates with invoices. Never recompute an old invoice with todays rate unless the contract says you will.

Finance and support will ask months later why an invoice used 7.12 instead of 7.09. If the answer is not in the invoice record, someone will re-query a live API and get a different number. Store the numeric rate, the ISO currency pair, the source name, and the timestamp with every conversion that affects money. That habit is dull and it prevents almost every FX dispute that is not a true processor error.

When a store lists prices in several currencies, decide whether each price is a hard local price or a live conversion from a base currency. Hard local prices need manual review when FX moves a lot. Live conversions need a freeze at checkout so the amount authorised matches the amount captured. Mixing the two without a written policy produces carts that change while the user is paying.

A user may browse in EUR while the merchant settles in USD. Show the display conversion as an estimate and the settlement amount as the charge. State which amount is final at payment time. Hidden dual-currency logic is a frequent source of chargebacks that look like fraud but are actually expectation mismatches.