Guides How to turn Stripe FX fees into extra profits for your SaaS

For most SaaS, the default pricing is 3 plans in USD and a yearly discount.

And that's fine in beginning, but as you grow, that simplistic price stays mostly untouched and becomes an invisible brake to growth.

Here are 3 scenarios to help you reveal and fix that invisible growth brake:

1. USD-only pricing
2. Multi-currency pricing / USD bank account
3. Multi-currency pricing / Muti-currency bank account

Scenario 1: Offer one currency and leave it to customers to pay FX fees

This is still, in 2023, the default way to price digital products. Paddle offers payments in 30+ currencies, and Stripe supports 150+ of them, but most SaaS just don’t want to think about it. Let’s see why this is losing you both money with an example: Say that I have a US SaaS company with a $19 USD price.

1. A customer from France visits my site. French people use Euros. At the time of writing this article, $1 USD ≈ €0.979 EUR. At this rate, our $19 plan should cost €18.60 EUR to European customers.
2. But we don’t handle FX (conversion) fees! This means we leave it to customers to pay for the conversion fees, or rather leave it to their bank. At the #1 French bank, conversion fees on payments of that range are €0.90 + 2%. In other words, our customer will pay €19,52 EUR. The equivalent of $19.94 USD, a price 4.94% higher than our original price!

If that doesn’t seem like much to you, picture it like this: 4.94% of your week is the equivalent of from Monday 0.01 am to 8.17 am. Your SaaS company just worked 1/3 of a day for a French bank. Oui Monsieur!

Scenario 2: Charge local currencies and leave FX fees to your Payment System Provider (PSP)

PSP are companies like Stripe, Paddle, Braintree, etc. that make it easy to get paid online.

Let’s keep that same example, only this time, we offer our plan in Euros. We could go for the exact converted price of the day, €18.60 EUR. But we’ll rather use the magic price and offer it at €19 EUR. This has 3 advantages:

1. It’s prettier. Commas and cents have their purpose in pricing, but we can probably agree a rounded number is prettier.
2. It’s reassuring. Local currencies make prospects feel like the company is established in their country. Also, they won’t worry about FX fees. This is reassuring and removes friction to payment.
3. It’s more money! Magic price is an opportunity to round prices up and cover FX fees. You could even have gone for 19.90€ and increased your price even more.

Great! We relieved customers of the burden of conversion, but now it’s on us. Stripe offers to make that change for a 1% conversion fee.

At that same rate, €19 EUR becomes $19.40 USD of which we need to take out the FX fees: You make $19.40-1% = $19.21 USD.

Not only did we save customers 4,94% in fees and removed friction to payment: But we also increased our average revenue per account (ARPA) by 1.21% on EU customers. VCs will be happy.

Scenario 3: Charge local currencies and optimize FX fees with a multicurrency bank account

A few months ago I was talking with Lemlist’s founder, Guillaume Moubêche, a 150MM French SaaS company with a huge share of customers outside the EU. They just had hired their part-time CFO, and the first thing he did was manage currencies.

Instead of leaving it to Stripe to convert automatically USDs to EURs, he opened a bank account in USD, stocked USD, and converted them to EUR manually. By doing so, he managed to get a discount on FX fees and do the conversion for a 0.1% fee instead of 1%.

That single update saved 10 of 1.000s of dollars in conversion fees every single month.

If you don’t have a CFO, you can still make major improvements on your FX fees par yourself. One way of doing that is to use a multicurrency bank account like Wise:

1. Stock foreign currencies on your Stripe account
2. Transfer them out to your Wise account
3. Convert them there to $USD for 0.50% and send them back to your company account.

If we replay scenario 2 with that new figure, you’d increase your ARPA by 1.63%.

FAQ

What happens if I sell high price items? The higher your price, the less fixed fees have an impact. But the same logic applies. Try it for yourself with this public spreadsheet.

You didn’t talk about Stripe 2,9% fees. These are charged on any successful charge and unrelated to currencies. I ignored them for simplicity.

What about Stripe’s 1% international card fees? These are related to the credit card customers use. They do not impact the logic described here.

When should you localize your prices?

Early stage. When you’re getting started, the first goal is to make a sale. Talk to your users, have a feel for what they want, and how much they’re willing to pay. At this point, price localization doesn’t matter.

Start-up. As soon as you’ve reached your first 1.000s in MRR, you should be thinking hard about your pricing. Everything done right at this stage will translate 10x into the future. Price localization at this stage allows for 2 things:

• Remove friction and increase revenue, nothing new here.
• To have the ability to test things with your pricing. Trying new prices is hard and scary when you address your whole audience. But localize it to a few countries, A/B test, and deploy only positive features to your audience. That’s what Tinder did with Australia.

Scale-up. Unless you have good reasons (the market is limited to one country, legal reasons,…), you should have localized your product’s prices by now. Failing to do so not only loses you market shares but also increases the chances for copycats to get started and compete with you soon.

With tools like Stripe, Pricery, Wise, and many others, charging in local currencies should be the norm. But laziness, fear, and habit make it one of the most underestimated growth levers in a SaaS marketer’s toolbox. Show your foreign customers you care about them and start offering multicurrency today. If you have any questions related to this topic, I’d love to chat. You can reach out to me at jules@pricery.io.

Thanks to Vlad Falin ex-banker turn content marketer for sharing his Stripe expertise. Also, thanks to Guillaume Moubêche and Mathieu Melo for allowing me to share Lemlist use case.