The Price You See Is a Conversion
Subscription prices are held in shillings, shown in dollars, and charged in shillings. Every part of that is deliberate, and the part worth understanding is which figure the server trusts when the two disagree.
The dollar figure on the pricing page is not a price. It is a conversion of one, and it changes without anybody repricing anything.
Our take
A single displayed currency and a single charged currency, with a conversion between them, is a much cleaner arrangement than maintaining two price lists — and the price of it is that the displayed figure moves with the exchange rate. That is an honest trade and it is only safe because of one rule: the browser never decides what is charged. The page shows a converted figure, the confirmation submits that figure, and the server throws it away and recomputes the charge from the authoritative price list, keeping the submitted number only as a note in a log. Everything else here follows from taking that rule seriously.
Where a price actually lives
Plan prices are held by the payment provider, in shillings, and read from there. They are not maintained in the application, which means there is no possibility of the application and the provider disagreeing about what a plan costs — a disagreement that would surface as a charge nobody expected.
The prices are cached briefly and mirrored into a local table as a last-known-good copy. If the provider cannot be reached, the last successfully stored prices keep being served rather than the pricing page failing or falling back to a hard-coded number that has drifted.
The annual price is a price, not a multiplication
The annual amount already includes whatever discount the annual plan carries, so multiplying a monthly figure by twelve — or by any adjusted factor — produces a number that is wrong in a way nobody catches, because it looks like arithmetic. The annual price is fetched as its own value for exactly this reason, and the instruction beside it is blunt: never multiply it.
The rate, and what happens when it cannot be fetched
The displayed dollar figure is the shilling price divided by an exchange rate. That rate is refreshed on a daily schedule, cached for a day and stored.
What it does not have is a fallback value in configuration. That is deliberate and it is the more interesting half of the design.
-
A configured fallback would go stale invisibly
A rate written into configuration is correct on the day it is written and drifts from then on. When the live source fails, the system would quietly switch to a number from months ago and every displayed price would move without explanation.
-
The last stored rate is at worst a day old
Serving the most recent successfully fetched rate means a failure produces a slightly stale figure rather than a very stale one, and the staleness is bounded by how long the outage lasts rather than by when somebody last edited a file.
-
So the configured value is a seed, not a fallback
It exists to populate the store the first time and is never read again. That distinction is worth keeping clear, because a value that looks like a fallback invites somebody to "fix" the displayed price by editing it.
A stale rate you can date is safer than a fixed one nobody remembers setting.
The browser submits a figure and the server ignores it
This is the rule that makes the whole arrangement safe. The confirmation form carries the dollar total the customer was shown. The server does not charge that. It recomputes the shilling amount from the authoritative price list and charges that, converting the submitted dollar figure only to write a comparison into a log.
The reason is general and worth taking away from this article even if you never see a pricing page. A figure that came from the server, went to the browser and came back is not a figure from the server — it is a figure from the browser that happens to have originated with you. Any decision that depends on it has to be made again on the server side, from the source, every time.
The log comparison is the thoughtful part. It does not gate anything, and it means a systematic divergence between what customers are being shown and what they are being charged is visible as a pattern rather than discovered through a complaint.
What is charged, and what is recorded
| Currency | Where it comes from | |
|---|---|---|
| The price list | Shillings | The payment provider, read live and mirrored locally. |
| The pricing page | Dollars | The shilling price divided by the current stored rate. |
| The checkout page | Shillings | The provider's own page, which shows what will actually be charged. |
| The charge | Shillings | Recomputed on the server from the price list, never from the form. |
| The stored transaction | Shillings | The real amount charged, with the currency recorded as such. |
The one place shillings appear to a customer before the charge is the provider's own checkout page, which is both unavoidable and correct — the page that takes the money should say what it is taking.
None of this touches your own money
Worth stating explicitly because the two are easy to conflate. Everything above concerns what a workspace pays for its subscription. What a workspace does with its own customers — invoices, till sales, supplier payments — runs in that workspace's own base currency, which is locked at registration and never converted for a document.
Two currency systems in one product, deliberately separate, with opposite postures: one converts for display because it is selling to a global audience from a single price list, and the other refuses to convert on any document because it is recording your money.
Around a converted price
The mechanism is settled and the safety rule is right. What would improve it is transparency about the conversion at the moment somebody is deciding.
The rate stated beside the price
The conversion rate and its date shown where the figure is, so a price that moved between two visits is explicable.
More displayed currencies
The same single price list converted for other markets, on the same rule and with the same server-side recomputation.
A divergence report
The comparison already written to the log surfaced as a trend, so a systematic difference between shown and charged is visible without reading logs.
We publish scope, not dates.
Scope subscription billingFive questions to ask about a converted price
Which currency am I actually charged in?
A good answer sounds like
A single, named one.
What ours actually is
Shillings. The displayed dollar figure is a conversion, and the provider's checkout page states the charge.
Where does the price come from?
A good answer sounds like
One source of truth.
What ours actually is
The payment provider, read live, cached briefly and mirrored locally as a last-known-good copy.
What happens if the rate cannot be fetched?
A good answer sounds like
A bounded staleness.
What ours actually is
The last successfully stored rate keeps being served. There is deliberately no configured fallback, because a configured rate goes stale invisibly.
Is the amount from the form what gets charged?
A good answer sounds like
No.
What ours actually is
No. The server recomputes from the price list and keeps the submitted figure only for a comparison in a log.
Is my own invoicing converted the same way?
A good answer sounds like
No — separate system.
What ours actually is
No. Your workspace's own money runs in your own locked base currency and is never converted on a document.
What AWRA OpsHub does today
- Plan prices held by the payment provider in shillings and read from there, so the application and the provider cannot disagree about what a plan costs.
- A short-lived cache in front of a locally mirrored copy, so an unreachable provider produces the last known prices rather than a failure or a hard-coded figure.
- Annual prices fetched as their own values rather than derived from a monthly figure, because the annual price already carries its discount.
- A displayed dollar figure computed as the shilling price divided by a rate refreshed daily, cached for a day and stored.
- No configured fallback rate, so a failure to fetch produces a bounded staleness rather than a value from whenever somebody last edited a file.
- The charge recomputed on the server from the authoritative price list, never taken from the submitted form.
- The submitted figure converted and written to a log as a comparison, so a systematic divergence is discoverable.
- Transactions recorded in shillings with the currency stated, matching what was actually charged.
- Add-on pricing held in shillings on the same basis as plan pricing.
- A complete separation from a workspace's own money, which runs in its own locked base currency and is never converted on a document.
More we can add to your workspace
- The conversion rate and its date shown beside the displayed price, so a figure that moved between two visits explains itself.
- Additional displayed currencies from the same single price list, on the same rule.
- A divergence report surfacing the shown-against-charged comparison already written to the log.
- A price held for the duration of a checkout, so a rate refresh between the pricing page and the confirmation cannot move the displayed figure mid-decision.
- A history of what a plan cost on a given date, for answering a question about a past invoice.
- A notification when a plan price changes at the provider, rather than the change arriving through the daily refresh unannounced.
Where we point you to a specialist
- We will not charge a figure the browser submitted. A number that originated on the server, travelled to a browser and came back is a number from the browser, and any decision that depends on it has to be made again from the source.
- We will not carry a fallback exchange rate in configuration. A fixed rate is correct on the day it is written and wrong from then on, and it fails in the worst way — silently, at exactly the moment the live source is unavailable and nobody is watching.
- The exchange rate is a market fact from a public source rather than a figure we set. We publish which rate is being used and when it was fetched; we will not quote a rate as though it were ours to offer.
Showing the rate and its date beside the price is the smallest piece here and answers the only question the arrangement reliably provokes, which is why a figure differs from the one somebody remembers.
Read the checkout page, not the pricing page
The provider's own checkout states the amount that will actually leave your account, in the currency it will leave in. That is the figure worth checking against your expectation.
Talk through billingFrequently asked questions
Why is the price shown in dollars and charged in shillings?
Because the price list is maintained in one currency at the payment provider, and the audience reads in another. Converting for display keeps a single authoritative price list — which is what stops the application and the provider disagreeing about what a plan costs — while presenting a figure most readers can evaluate. The provider's checkout page states the charge in the currency it will be taken in.
The dollar price changed and I was not told. Why?
Almost certainly the exchange rate rather than a repricing. The displayed figure is the shilling price divided by a rate that refreshes daily, so it moves with the market while the actual price is unchanged. Showing the rate and its date beside the figure is the first item on the list of what would make this clearer.
Could I be charged a different amount than I was shown?
The shilling amount is exactly what the price list says, because the server recomputes it rather than accepting the figure from the form. The dollar figure you saw is a conversion at the rate current when the page was drawn, so if the rate has moved the two will not correspond precisely. The provider's checkout page always states the amount that will be charged.
Why is there no fallback exchange rate in configuration?
Because a configured rate is correct on the day it is written and drifts thereafter, and it would be used at exactly the moment the live source is unavailable and nobody is watching. Serving the last successfully fetched rate instead means a failure produces a figure that is at worst a few days old, and the staleness is bounded by the outage rather than by when a file was last edited.
Is the annual price twelve times the monthly one?
No, and it is important not to calculate it that way. The annual price already includes whatever discount the annual plan carries, so it is fetched as its own value. Multiplying a monthly figure produces a number that looks like arithmetic and is wrong, which is the hardest kind of wrong to notice.
Does this affect how we invoice our own customers?
Not at all. Everything described here is about what your workspace pays for its subscription. Your own money — invoices, till sales, supplier payments — runs in your workspace's own base currency, which is locked at registration and never converted on any document you issue.
