API endpoint to get geo-resolved currency/price for a product

[eelior]

First off, the multi-currency support with custom per-currency pricing is fantastic. Being able to set specific prices for each currency rather than relying on auto-conversion gives us real control over regional pricing strategy. It's one of the features that made us go all-in on Polar as our payment provider.

We're building a checkout flow where Polar is our single source of truth for pricing. We display product prices on our marketing pages and app before the user reaches the Polar checkout.

The problem

Polar automatically serves localized prices based on the user's detected location at checkout time. However, we have no way to know which currency/price Polar will show a given user before creating a checkout session.

Currently, we fetch product prices via products.get() which returns all configured currency prices, and then we do our own geo-IP → currency mapping to pick which price to display. This means we're maintaining a separate country-to-currency mapping that may not match Polar's internal geo-detection logic, leading to potential price discrepancies between what we show on our site and what the user sees at checkout.

What we'd like

An API endpoint (or a parameter on the existing products endpoint) that returns the geo-resolved price for a given user, similar to what the checkout page would show. Something like:

GET /v1/products/{id}/price?country=DE
// or
GET /v1/products/{id}/price  (with IP-based auto-detection)

Response:

{
  "price_amount": 5400,
  "price_currency": "eur",
  "original_price_amount": 9000
}

This way we can display the exact same price on our marketing pages that the user will see at checkout, with Polar being the single source of truth for both the price amounts and the geo → currency resolution.

Workaround we're considering

Creating a lightweight/disposable checkout session per request just to read back which currency and amount Polar resolved for that user. This might work, but feels too much like a workaround.

[HuzinaPatrik]

I opened a similar issue like this 3 weeks ago but no response yet: #10083