Name the amount a buyer is agreeing to
A price is incomplete when it is only a number and a dollar sign. For a Hong Kong shop, the same symbol can be read as Hong Kong, US, Singapore or another dollar. Begin with one explicit currency code for every price that can lead to a purchase. The decisive amount is the currency and total that the payment provider will ask the customer to authorize. The shop's settlement currency is a separate accounting matter. Stripe distinguishes the payment method currency, the charge or presentment currency, and the settlement currency; those can differ. A shopper needs the charge currency before committing, even if the merchant later receives a different settlement currency.
Write the shop's policy as a simple sentence before changing the interface: for example, all orders are charged in HKD, while another currency may appear only as an estimate; or buyers may choose from specific supported charge currencies. Do not let a locale switch silently change that policy. English versus Chinese copy is a language choice, not evidence that the shopper wants USD or HKD. Likewise, a card issued abroad does not prove that the issuer will bill in the displayed currency. The provider's documentation warns that a card issuer may apply foreign exchange fees when payment method and charge currencies differ, and may sometimes do so because of cross-border conditions. Avoid promising the final card statement amount.
Trace one price through the buying path
Audit a real product from search result to product page, variant choice, basket, delivery selection, order review, provider handoff and confirmation. At every step record the displayed number, currency code and what the number includes. A currency badge in the page header is too far from a mobile buy button or an emailed basket link to carry the whole meaning. Put the code beside key line items and especially the final total. If a delivery charge or discount changes the amount, update the total in the same currency and name it again before the payment action. A useful review sheet has columns for screen, amount source, charge currency and observed customer text.
Suppose a product is offered for HKD 480, delivery is HKD 30, and the shop has approved a HKD 20 discount. The example total is HKD 490; it is an arithmetic illustration, not a measured customer price or a rate quotation. The catalogue, basket and provider request must agree that the order is HKD 490. If the payment screen instead says USD 490, formatting cannot repair the discrepancy: the request or its mapping is wrong. If the shop displays an approximate USD equivalent, label it as an estimate and keep it separate from the HKD amount that will be charged. Explain where the estimate comes from and when it was calculated if it is shown at all.
Make a currency switch deliberate
A selector is only useful if it changes the actual charge currency under a defined rule. If it changes display alone, label the result as an approximate reference and leave the final charge currency visible. If it changes the charge, first confirm that the chosen payment method and merchant account support that currency. Stripe's currency guidance says available presentment currencies vary by method and that some local methods support only one currency. A disabled or unavailable option should be explained before the customer reaches an unusable payment screen. Do not invite a buyer to choose an unsupported currency and then switch it without a fresh review of the payable total.
Treat a currency change as a price decision, not merely a visual preference. Recalculate eligible prices, shipping, discounts and minimums using the shop's published conversion or price-book rule; then show a fresh review total. Some shops maintain separate fixed price lists instead of converting a base price on every visit. That is a valid design choice if customers can see which list applies and the selected list remains stable through payment. Do not describe separate price lists as live exchange conversion. If a basket contains a saved price from a previous visit, resolve it under the current documented policy before asking for authorization, and tell the shopper if the payable amount changed.
Format for language without changing value
Use a stored amount and currency code as the source of truth, then format them for the selected interface language. MDN documents Intl.NumberFormat with an explicit currency option and currency display controls. This can place separators and symbols appropriately, but it cannot decide the business currency or convert one amount into another. Prefer the three-letter code when a symbol could be ambiguous. In a bilingual Hong Kong interface, check both English and Traditional Chinese outputs on product tiles, totals, narrow mobile layouts and screen-reader output. A formatter might change punctuation and placement; the underlying charge amount and code must remain exactly the same unless the buyer deliberately changes currency.
Keep arithmetic in the payment system's expected units and format only after calculating the final amount. Stripe notes that most currencies use two decimal places but some have different minor-unit rules. A developer should read the current rules for each actual currency and payment method before mapping an internal amount into the provider request. A display such as '490.00' must not be assumed to mean the same API integer in every currency. Test rounding at boundaries and reconcile the displayed total against the provider's returned amount and currency. A screenshot that looks correct is insufficient if the charge request carries a different unit or code.
Keep the order record explainable
At order creation, save the charge currency, the authorized amount, the item and delivery components, and the price rule or price-list version that produced them. The customer confirmation should state what was submitted for payment and distinguish authorization, capture and refund states if the shop exposes them. A later settlement amount is useful for finance, but it must not rewrite the historical customer-facing charge currency. Support staff need to answer a buyer who asks why the card statement differs from the order total. They can explain the shop's charge currency and point to the issuer for any card conversion, without pretending to know an individual issuer's rate or fee.
Refund communication needs the same discipline. State the refund currency and amount the shop initiated, and separate that from the amount that a cardholder may see after issuer conversion. If a partial refund follows a multi-item order, identify which line items or charges it covers so support can reconcile it. Test an order made in every supported charge currency, including a cancelled payment, a delayed confirmation and a partial refund. The objective is a consistent trail, not a promise that exchange movements or bank fees will reverse exactly. Revisit the text whenever the payment provider or the shop's currency policy changes.
Test the amount the customer will see
Run a small acceptance matrix across language, device, supported currency and payment method. Start with a clean basket, then repeat with an old basket, a shipping change and a discount. For each path compare the product page, review screen, provider-hosted screen, callback or API response, stored order and customer message. Record both the numeric amount and the currency code; comparing numbers alone misses the most damaging error. Include a deliberately unsupported currency and verify that the interface stops with an explanation before authorization. Repeat with a screen reader so the code and total are spoken together rather than disconnected from the payment action.
The release decision is straightforward: if the customer-facing total and provider charge disagree, pause that currency path until the mapping is corrected. If an approximate converted figure causes confusion, remove the estimate while keeping the verified charge price available. Ask one colleague who did not configure the pricing to explain, from the screen alone, what currency the customer pays and which amount the bank may convert. Their answer is a practical clarity check, not a performance metric. Document the tested paths and the shop's approved currency wording so a future promotion or payment-method change does not silently undo the decision.
Before you proceed
- Does every decisive total carry the actual charge currency code?
- Do provider requests and stored orders match the reviewed amount and currency?
- Are reference conversions clearly separated from the payable amount?
