Purchasing power parity: A simple low-code proof of concept

I was reading about pricing and how it's unfair that a person with less economic resources should pay the same amount of money to obtain the same item, or level of service, as someone that has more economic resources at their disposal.

Using McDonald's Big Mac infographic as a simple reminder, it is obvious that you're going pay more or less for the same thing.

😉 The problem!

As an example, if you're a developer in a Venezuela or Italy, is it fair that you should pay $19.99 to access a SaaS product offered by someone in a country with high purchase power?

Living in Venezuela, the cost of living and, more importantly, your income and purchase power are extremely different from folks living in North America or Switzerland.

Disclaimer: I was able to sneak into the Stripe Beta for Pricing Tables, not sure if they're going to accept more applicants, it's not under my control! Please go ahead and try to apply, or at least read the docs.

🤔 Solving the problem

I wanted to allow people to pay the "right" price based on their geopolitical zone.

• If you're in France - you should pay with Euros
• If you're in India - you should pay in Rupees
• If you're in the US - you should pay in Dollars

...but most importantly the price should be adjusted to your "buying power".

I figured the best way would be to parse the IP address of the person browsing my website and return which country they're visiting from [1].

Using an API I found on RapidAPI's hub, I could quickly develop a solution that allows me to provide the most FAIR price.

🤯 Implementing a solution

To solve the above problem, I have done a couple of things:
1) I created some products tiers for a (fake) service I want to sell. You can create them without having to write a single line of code
2) I created alternative prices in different currencies for each product tier created above (this is a Stripe feature, you can add these additional prices from the dashboard or API)
3) I created a Pricing Table for dollars, euros, etc - using once again the Stripe dashboard. I made a video on how to achieve this
4) I wrote some code (with in-line comments) that show how you can parse the location of the visitor and dynamically load the "right" pricing table.

This uses GEO API a simple to use yet super effective way to retrieve geo location data based on a given IP.

This includes city, continent, currency, timezone, latitude, longitude and some security data.

I am using the currency data returned by this API, to apply logic in JavaScript that returns the "right" pricing table, through a lookup table.

What happens in the background is that Stripe pricing tables load asynchronously through a JavaScript snippet.

This code takes as a data argument a pricing table ID, called data-id.

By providing a different pricing table ID I can show a different pricing table.

Therefore by invoking the GEO API and figuring out the location of the visitor I extract the ID from a lookup table.

This lookup table has multiple pricing table IDs that I created manually.

Finally, I load the right one based on this data to show the user.

💪 I also added a fall-back in case there isn't a pricing table for a specific country (there are a lot of countries out there - that means a lot of custom pricing tables!)

Take a look at the code

👉 If you're in the US: try inverting the names of the keys on lines 12 and 13 in the code and you will see the pricing table load the European (French localized) pricing table instead of the North American (US localized) one.

There is perhaps another way to localize pricing using the user's location instead of having to rely on an API or custom code.

This is an exploration for another time, though!

Conclusion

Purchasing power parity might seem like adding a lot of headache for little to nothing.

However you could compare this to other features like providing invoices, SSO and many other features.

Sometimes these features are the difference between acquiring a new customer and not acquiring it.

Please consider purchasing power parity next time you think of pricing, and I hope this taught you something new!

---

Will you think about purchasing power going forward? How will you implement it? Do you use another solution?

Let me know in the comments!

[1] As long as they're not behind a VPN this works flawlessly, and yes I know this can be used to game the system.