Ask HN: How do you localize your prices? | Hacker News Reader

Ask HN: How do you localize your prices?

6 pointsjamesfisher12 comments

We recently released an online course. [1] It's $29, but we've had users saying, "I'm in ${country poorer than USA}, and I can't afford the $29. Do you offer regional pricing?"

I would like to support this. The dollar-value to a customer in India is probably lower than in the USA.

Most big platforms (Udemy, App Store, Play Store) seem to solve this with a price tier matrix. They maintain a big table of prices per (tier, currency). The tier comes from the product, and the currency comes from ... the user's IP address? (See example matrix [2])

To build this from scratch, I would have to:

* Define a list of tiers, each with a hard-coded USD price.

* Maintain a list of Purchasing Power Parity multipliers for each currency. For example, regularly scrape OECD data.

* To get a tier's price in currency X, multiply by the current PPP.

* Somehow clamp the prices to "appealing" values, so we get e.g. £25 instead of £24.19.

* Ensure we never make a loss after subtracting Stripe fees!

* Detect a user's location. Presumably using IP. Map location to a country, and country to a currency.

* Probably many more things I haven't thought of.

This feels like a generic problem that I shouldn't be re-solving myself. So, questions:

* What libraries/services can I use instead?

* How do you do implement localized pricing?

* Are there complexities that explain why there's not an out-of-the-box solution?

[1]: https://news.ycombinator.com/item?id=32118530 [2]: https://s3.amazonaws.com/udemy-images/support/Udemy+Price+Tier+Matrix+-+EN+09-17+Matrix.pdf

Hey there! I work on Stripe Checkout and we recently released an update that should make selling globally a lot easier, removing most of the bullet points in your post.

Here are the docs, and please let us know if you try it out and have feedback: https://stripe.com/docs/payments/checkout/present-local-curr...

Thanks!

Ooh, that's nice progress! At TigYog we're actually using Stripe Elements - not Checkout or products - so I think this can't work for us yet. It would be cool if you exposed some of this functionality in Elements. I'm not sure what that would look like though :)

A solution I like is just two tiers. Full price and discounted price. People from certain countries get the discounted price.

Then figure out a line where it's worth discounting. Perhaps 5x lower purchasing power than say, the US. Maybe a third tier if it's 15x difference, though I doubt it's that bad.

After consideration, I think I'll go with this option.

We can actually go even lower effort: add a discount code for this, and just say "get in touch if the US price is unreasonable for your country" or similar.

Thanks for reminding me to KISS :)

As a user I hate it when I get localised prices, especially if the at-the-time exchange rate ends up being more expensive for me. If I see something sold for $9.99 but I get £9.99 I think "why am I paying more for this", simply because the exchange rate is more favourable since I'm in the UK. But when I only see USD prices I'm more likely to buy something as it's not overly complicated.

If you want you could pull real-time exchange rates and have a button that indicates the conversion for someone who wants to see the "most likely" price (depending on when they actually pay for it).

For example if you sell something for $9.99 just leave it as such, and Stripe will make the conversion and you'll always sell at the same price regardless from where someone is coming from.

That's how I feel about it anyway!

It's not just exchange rates.

The problem is that, in some places (like India, for example) $10 might be a lot of money.

One might be able to do a lot more with $10 in India (₹800), than with $10 in USA, due to reasons that are beyond anybody's control.

For instance, I can travel 3000 km by train with $10 equivalent in India if I really wanted to (wouldn't be very comfortable, but it's possible).

The wages in those countries are also proportional of this.

This becomes relevant if you want your product to be not expensive, so that it reaches a wider audience.

For expensive goods the price difference doesn't matter as much. (Though I know people who were bummed that the Ford Mustang 5.0 V8 was twice as expensive in India than USA — but that's a different market).

I totally agree with you, but the common "this is why we can't have nice things" end result of such scenarios is that people will VPN via India in order to buy your product. And then you have to identify VPNs in order to avoid this, etc.

I don't have a solution for this, I just think the effort/reward should be considered.

The solution for this is to match the billing method.

For example, I don't care if they use a VPN - if they want to pay Indian rates, they have to do so from a INR-denominated account with an Indian billing address and have to do so using Razorpay/UPI/Indian Netbanking transfer/AirtelMoney/.... Everyone there has it - not having it is not an excuse, "I want to pay with a US Mastercard" is not an excuse. This solves it for the 99.99%+ use case. The "majority" here is so strong that if someone in India cannot pay with at least one of these payment methods and asks to use a US billing address credit card, it's either stolen or for all practical purposes I would be wondering how they survive day to day or buy groceries (or they are probably not old enough to enter into a contract to purchase or licence content from you). (It's probably stolen)

If you want to pay RUB rates, you have to pay via WMZ or YandexCash, Qiwi, Sberpay, Yoomoney.

THB discount? BigC, Tesco, PromptPay, etc.

BRL? Boleto. Even a 12 year old with no bank account can successfully pay with boleto.

Nearly every single country (I have not found one otherwise yet) that would be lower CoL and require a significant pricing adjustment has multiple unique payment methods that the hypermajority are signed up for (or required to use in the first place so everyone has an account) or is paid physically and accessible by anyone present to pay cash, that is inaccessible from US/EU/AU/etc.

These will even significantly lower your transaction fees due to foreign exchange, and lower your chargeback rates because many are effectively fraudproof due to requiring multiple factor mandatory confirmation, not allowing disputes, or being "pay in cash in person at a physical location within the country".

If you want to pay the standard USD or EUR rates, whatever normal card network is accepted no matter where you are from.

The typical solution is "If you bought this from India, you can only use it in India. Pay full price if you plan to go to Brazil, etc."

Not foolproof, but at least a little inconvenient, especially if you have one of those cheap VPNs that toss you a random IP.

The approach I'm trying is to set a price and then give people an option to raise it or lower it based on what they can or want to pay, maybe along with a message talking about the difficulty in creating prices for people across the world.

Currently, I only have this set to some of the more scalable options (the plan to get access to all the recorded audios and not the plan where I give an hour of 1-on-1 calls per month), yet it may even work for things with more variable costs, if the minimum price is still sufficient.

So that's what I'm gonna try, because as you mention, the other way seems highly complex and also we customers can sometimes feel annoyed by regional pricing, especially for digital goods. But who knows how it'll work.

Don't forget VAT (in EU countries but possibly not only there, GST in Australia).

There is a VAT MOSS (Mini One Stop Shop) requirement for selling courses in EU AFAIK, see (example only, no idea if contents are accurate):

https://botflo.com/eu-vat-moss-tips-for-online-course-creato...

This (of course it is essentially an ad for the company) quickly explains the possible issues:

https://www.youtube.com/watch?v=azeNA13kVpY

I think you are going to tie yourself in knots with this.

Reply on news.ycombinator.com