Why We Charge You in Your Local Currency

The thing that's broken

Open the pricing page of any global SaaS company aimed at African businesses. The number you see is in US dollars. "Growth plan — $39/month."

Then you become a customer. Your card statement arrives. The actual charge is ₵485, not ₵474 — because the issuer applied an FX markup you didn't agree to. And because the SaaS bill posts on the 1st of the month and the exchange rate moves overnight, the GHS amount is slightly different every month. Reconciling that against your books is annoying. Forecasting cash flow is annoying. Knowing what you're actually paying is annoying.

It's a small papercut. But you don't get to ignore small papercuts when you're selling SaaS to small businesses in markets where every shilling matters.

The choice we made

A merchant in Ghana sees this:

A merchant in Canada sees this:

A merchant in the US sees the USD version. Same plan, three different sticker prices, each one matching the currency the merchant actually runs their business in. No FX surprise on the statement, no forecasting noise, no mental conversion math.

Why this is harder than it looks

Stripe Subscription mode infers the billing currency from the Price object, not from a runtime parameter. Which means a multi-currency SaaS isn't one plan in three currencies — it's nine Price objects in the Stripe Dashboard plus a merchant attribute that picks the right one.

That's the engineering shape. The data model has to:

1. Carry a billing_currency on every merchant, resolved at registration from country (GH → GHS, US → USD, CA → CAD; everything else → CAD by default).
2. Carry a (name, currency) pair on every pricing plan row — so the FREE tier has three rows in the database, not one.
3. Pick the matching row at every read site: the dashboard plan list, the subscription-creation flow, the upgrade endpoint, the Stripe checkout.
4. Use the merchant's currency, not USD, in every formatter on the billing UI.

We shipped that this month. Migration V137 introduced the column with a country-based backfill; the pricing service got currency-aware finders; the merchant and developer-portal billing pages now resolve currency from the authenticated merchant and render the matching Price object. None of this is visible to the merchant. That's the point.

Why "just pay in USD" isn't an answer

Three reasons.

It builds the wrong habits in the customer. SaaS pricing teaches users what to expect. If your "starter" tier is $39 USD, the merchant remembers that number. When you eventually localize, they feel like the GHS price went up even when it didn't.

It hides the cost. Every FX markup is a fee. Adding an opaque 2-3% to every month's bill is the same playbook used by remittance providers we criticized last month — and the same trust breakdown follows.

It tells the merchant who you built for. If your pricing page says USD only, you've decided the West is the primary audience and Africa is a long-tail market. We built Danipa for the African business first; the pricing page should say so.

What we won't claim

We're not solving FX for the merchant's customers. If a Ghanaian merchant takes a payment from a Canadian customer, the customer is paying in CAD and the merchant's wallet credits in GHS at the live mid-market rate (no markup) — but there's still an exchange happening. The rate is transparent; the timing is real-time; the wallet history shows both currencies. That's as honest as multi-currency commerce gets.

And we don't claim every currency in the world. Today we support CAD, USD, and GHS as billing currencies. GBP, EUR, NGN, KES are not wired. When the underlying corridors land, those will land too — and the merchants in those countries will see their own currency on their bill, the same way Ghanaian merchants see theirs today.

The hidden lesson

This change is small in the diff and small in the marketing copy. But it took a multi-week engineering pass to get the data model and the cache and the UI all to converge on a single source of truth. That's roughly the shape of every worthwhile fintech feature: a tiny experience change resting on a big chunk of careful infrastructure work.

The shortcut would have been: ship USD-only, claim "localization coming Q3," move on. We didn't take it because the entire thesis of Danipa is that we don't take that shortcut. The diaspora built this — and the merchants who use it are worth the engineering pass.

You can see the result on the merchant sandbox billing page. Or read the multi-currency engineering write-up for the line-by-line on what shipped.