DEV Community: Ademiju Adelakin

Why Supporting Two Currencies Is More Complicated Than Adding a Currency Symbol

Ademiju Adelakin — Fri, 28 Aug 2026 12:06:59 +0000

Why Supporting Two Currencies Is More Complicated Than Adding a Currency Symbol

«"We'll support dollars later. For now, let's just add naira."»

It sounds like a small feature.

Add a currency selector.

Show "$" for one customer and "₦" for another.

Maybe convert the price using today's exchange rate.

Ship it.

The problem is that supporting another currency usually isn't a frontend change.

It's a pricing decision.

And those are two very different things.

The day one price becomes two

Imagine your SaaS launches with one plan:

«Pro — $20/month»

A few months later, Nigerian customers start signing up. They ask if they can pay in naira.

So you do the obvious thing.

Convert $20 into naira.

Except your business doesn't actually want to charge the converted amount.

Maybe the exchange rate says it's ₦34,800.

But you've decided the local price should be ₦30,000 instead.

Now your product has something it didn't have before.

Not another currency.

Another price.

The Pro plan now exists in two versions:

Currency| Monthly Price
USD| $20
NGN| ₦30,000

That's not currency conversion.

That's multi-currency pricing.

And your billing system needs to understand the difference.

The complexity sneaks in from there

Once each currency has its own pricing, the questions start multiplying.

Do annual plans have separate prices too?

What about seat-based pricing?

If your USD plan charges $8 per additional seat, is the naira version a direct conversion, or its own business price?

What happens when someone paying in NGN upgrades their plan?

Or switches to a USD-priced subscription later?

None of these questions are about displaying a different currency symbol.

They're about how your business wants pricing to work.

Then your payment processors enter the picture

A lot of SaaS businesses don't use the same payment processor for every currency.

Maybe Stripe handles your dollar payments.

Paystack handles your naira payments.

That's completely reasonable.

The mistake is letting those processors become the place where your pricing lives.

Suddenly your application starts thinking like this:

USD plan → Stripe
NGN plan → Paystack

Instead of thinking:

Pro plan → USD price
Pro plan → NGN price

That difference seems small.

But it's the difference between pricing rules and payment infrastructure.

One is a business decision.

The other is simply how money gets collected.

Your pricing needs one source of truth

Your application shouldn't have to recreate the same pricing logic every time another currency or payment processor is introduced.

It should be able to understand something as simple as:

«Pro plan

USD → $20/month

NGN → ₦30,000/month»

Everything else should build on top of that.

Your pricing.

Your billing rules.

Your seat-based pricing.

Your recurring subscriptions.

The payment processor should only come into the picture when it's time to collect the payment.

That's the problem AoraHQ is built around

AoraHQ gives your pricing its own layer.

You connect the payment processors you already use—whether that's Stripe and Paystack, or PayPal and Flutterwave.

Then you configure your pricing from one dashboard.

Currency-specific prices.

Recurring plans.

Seat-based pricing.

Everything lives in one place instead of being recreated for every payment processor.

Once it's configured, you copy your AoraHQ secret credentials into your application and use the AoraHQ pricing UI.

Your application keeps focusing on your product.

Your payment processors keep processing payments.

AoraHQ handles the pricing and billing logic in between.

Because supporting another currency shouldn't mean rebuilding your pricing system.

Sometimes the hardest part of multi-currency billing isn't accepting another currency.

It's deciding what that currency should actually mean for your business.

I'm curious—how does your SaaS handle pricing in multiple currencies?

Do you use live exchange rates, configure separate prices, or something in between?

The Problem With Building Billing "Just for Now"

Ademiju Adelakin — Mon, 24 Aug 2026 09:46:09 +0000

"Let's just hard-code it for now."

It's an MVP.

You have one pricing plan, a handful of customers, and one payment processor.

You don't need a billing architecture that can support every possible pricing model your SaaS might have three years from now.

You just need people to pay.

So you create the plan, connect checkout, write the necessary logic, and move on to building the product.

And that's a perfectly reasonable decision.

The problem starts when your business grows, but your "temporary" billing setup becomes permanent infrastructure.

Your MVP didn't break. Your business outgrew it.

Imagine you launch with one plan:

$20/month.

Simple.

Then customers ask for annual billing.

You add it.

A larger customer wants to pay for 15 employees, so you introduce seat-based pricing.

You add that too.

Then you start accepting customers in Nigeria, so you need naira pricing alongside your dollar pricing.

Then you add Paystack alongside Stripe.

None of these decisions are unreasonable.

They're signs that the business is growing.

But now look at what happened to that original $20/month plan.

What started as one pricing rule is now connected to plans, currencies, seats, billing periods, and payment processors.

The business changed.

But the billing logic is still living in the architecture you built when the business had one plan.

This is where technical debt starts hiding

Technical debt doesn't always look like broken code.

Sometimes everything works.

Customers can subscribe.

Payments go through.

Invoices look right.

Nobody is complaining.

Until someone says:

«"We want to change our pricing."»

Now changing a business decision means changing the code that was written to support the old decision.

And the problem isn't necessarily that the original code was bad.

It solved the problem you had at the time.

The problem is that the solution was never given somewhere to evolve.

The code starts carrying your pricing history

At first, your application might only need to understand:

«Customer is on Plan A → charge $20.»

Then it becomes:

«Customer is on Plan A → charge $20 monthly, or $200 annually.»

Then:

«If they're on the team plan, charge based on seats.»

Then:

«If they're paying in naira, use the naira price.»

Then:

«If they're paying through Paystack, use this implementation.»

And suddenly, your application isn't just running your product.

It's carrying every pricing decision the business has made.

The problem isn't that there are more rules.

It's that those rules can end up scattered across your application, database, pricing UI, and payment-provider integrations.

So the next pricing change isn't just a business decision.

Someone has to find where that decision lives in the codebase.

That's the separation that's easy to miss

Your application has a job.

It needs to know what a customer can do.

Your billing layer has a different job.

It needs to know what that customer should pay.

And your payment processor has another job.

It needs to process the transaction.

When those responsibilities are tightly coupled, a change in one area starts creating work in the others.

Add a new plan, and you touch the application.

Add another currency, and you touch the payment integration.

Add another processor, and you implement the pricing logic again.

That's how "just for now" turns into infrastructure you don't want to touch.

What if pricing had somewhere else to live?

Your business should be able to define its pricing without having to care which processor ultimately collects the money.

You should be able to configure:

Your plans
Recurring prices
Currencies
Seat-based pricing
The payment processors you support

in one place.

Then your application can focus on the business logic that actually makes your SaaS unique.

That's the problem AoraHQ is built around.

You connect the payment processors you already use by adding their credentials to the AoraHQ dashboard.

Then you configure your pricing there.

Whether you're using Stripe and Paystack for dollar and naira payments, or PayPal and Flutterwave, you don't have to manually recreate the same pricing logic for each processor.

Once your pricing is configured, you copy your AoraHQ secret credentials into your application and use the AoraHQ pricing UI.

Your payment processors still process the payments.

Your application still handles your actual product and business logic.

AoraHQ handles the pricing and billing layer in between.

Because hard-coding your first pricing plan isn't bad engineering.

Forgetting that your pricing will eventually change is.

Your MVP can be temporary.

Your pricing shouldn't have to be trapped inside it.

How did your first billing implementation hold up as your SaaS grew?

Did you eventually have to rewrite it, or did you manage to evolve it without touching everything else?