Gumroad PPP Pricing: How the Native Toggle Works vs Region Codes

Updated 2026-07-27 · GumKit guides

You priced your course at $49. A developer in San Francisco taps "buy" without thinking twice. A developer in Manila does the math, realizes $49 is a meaningful chunk of a week's pay, and closes the tab. Same product, same value to them — but one global price quietly filters out everyone who doesn't earn in dollars.

That gap is what Gumroad PPP pricing (purchasing-power-parity pricing) is meant to close. The idea is simple: charge buyers in lower-income countries less, so the relative cost of your product is closer to even everywhere. The execution is where sellers get stuck, because Gumroad's built-in feature is far more opinionated than the one-line description suggests — and most guides never say what it's actually doing under the hood.

This is the long version. Where the toggle lives and what every control does, how Gumroad computes the discount (and why some countries never get one), the four behaviors that surprise sellers at checkout, and when you should skip the toggle entirely and build explicit per-region offer codes instead.

What PPP pricing means on Gumroad

Purchasing power parity is an economics idea: a dollar buys very different amounts of "stuff" in different countries. A $49 price that reads as reasonable in the US reads as a luxury in India, Brazil, Indonesia, the Philippines, Nigeria, or Mexico. PPP pricing applies a discount in those regions so the perceived cost lands closer to even.

Gumroad's own description of the feature is that it "lets Gumroad creators set up dynamic discounts based on where the customer lives, ensuring that the price is proportional to their local currency and cost of living."

There are two ways to deliver that on Gumroad, and they are genuinely different products, not two settings for the same thing:

• The native PPP toggle — an account-level switch. Gumroad detects the buyer's country from their IP and applies its own discount automatically. No codes, nothing to share, nothing to maintain.
• Explicit per-region offer codes — you create real discount codes (INDIA60, BRAZIL45) and hand them out. You pick the regions and the exact percentages. Gumroad does not enforce who uses them.

Most of the confusion around Gumroad PPP pricing comes from expecting one of these to behave like the other. So let's take the toggle apart first.

Option 1: Gumroad's native PPP toggle

Where it actually lives

PPP is an account setting, not a per-product one. In your Gumroad dashboard:

1. Go to Settings (app.gumroad.com/settings) — the main Settings tab, not Advanced.
2. Scroll to the Local section. It sits with your time zone and your "Sell in..." currency selector.
3. Turn on Enable purchasing power parity. Its helper text reads "Charge customers different amounts depending on the cost of living in their country."
4. The toggle expands into three more controls (covered below).
5. Save.

That's the whole setup. There is no per-product PPP switch to hunt for — you configure it once for the account and then subtract the products you don't want it on.

The three controls hiding under the toggle

Turning PPP on reveals settings that most walkthroughs skip entirely, and they matter more than the toggle itself.

Maximum PPP discount. A single percentage field (its placeholder is 60). This is a ceiling applied across every country. Set it to 30 and no buyer anywhere gets more than 30% off, even if their country would otherwise qualify for 55%. Leave it empty and Gumroad's own per-country figures apply unchanged. This is the only lever you have over the size of the discount — there is no per-country percentage box.

Apply only if the customer is currently located in the country of their payment method. A switch, on by default. With it on, Gumroad compares the country of the buyer's payment card against the country detected from their IP address. Gumroad's help documentation describes the outcome plainly: if a buyer fails this check, "they will still be able to purchase the product at full price." Failing the check does not block the sale — it just removes the discount. Turning the switch off means anyone browsing from an eligible IP gets the discount regardless of where their card was issued, which is the VPN scenario people worry about.

Products to exclude. A tag field where you name specific products that should never be PPP-discounted, plus an All products checkbox that excludes everything at once. This is the control that makes the toggle more flexible than its reputation: you can run PPP across your catalog while keeping one premium product at full price everywhere.

How Gumroad calculates the discount

This is the part nobody explains, and it answers most of the "why is my PPP price weird" questions.

Gumroad pulls the World Bank's PPP conversion factor (indicator PA.NUS.PPP) and divides it by the current exchange rate for that country's currency to produce a factor — a multiplier applied to your price. A factor of 0.5 means the buyer pays half. Gumroad rounds that factor to two decimal places and refreshes the data on a recurring schedule; its help documentation describes the discounts as refreshing weekly.

Then it clamps the result at both ends:

• If the computed factor comes out above 0.8 — meaning the country would earn less than a 20% discount — Gumroad sets the factor to 1 instead. No discount at all. It doesn't hand out a 6% PPP discount; it rounds that down to nothing.
• If the factor comes out below 0.4, it's raised to 0.4. That's the hard floor: 60% off is the deepest discount the system will ever produce.

That's where the commonly quoted "discounts range from 20% to 60%" figure comes from. It isn't a policy statement, it's the shape of the clamp.

Your Maximum PPP discount field then layers on top as a second floor. Setting it to 40 means the factor can never drop below 0.6, so a country that would have qualified for 60% off gets 40% off instead.

The countries that never get a PPP discount

Gumroad maintains an explicit list of high-income countries and territories that are hard-excluded — their factor is forced to 1 regardless of what the World Bank data says. As of the current version of Gumroad's open-source codebase, that list covers 36 places:

If you've been wondering why a buyer in Portugal or South Korea never sees a parity price, this is why — and no setting on your end changes it. Gumroad can revise this list at any time, so treat it as current behavior rather than a permanent contract.

Reading your PPP prices programmatically

Once PPP is enabled, Gumroad's API exposes the computed result. The product object returned by GET /v2/products and GET /v2/products/:id includes a purchasing_power_parity_prices field — an object keyed by two-letter country code, with prices in cents:

"price": 100,
"purchasing_power_parity_prices": {
  "US": 100,
  "IN": 50,
  "EC": 25
}

That snippet is Gumroad's own sample response, so read the numbers as placeholders rather than live data — the EC value implies a 0.25 factor, which the 0.4 floor described above would never actually produce. Gumroad's docs note this field is "present when the seller has purchasing power parity enabled and the product has not opted out," and the same field appears on variant options and on membership recurrence_prices. If you run your own landing page outside Gumroad, this is how you show a visitor their local price before they ever reach checkout. You'll need an API access token to read it — see how to get your Gumroad API access token if you haven't set one up.

Four behaviors that surprise sellers

1. PPP and discount codes do not stack

This is the big one. In Gumroad's pricing logic, the PPP factor is applied only when no offer code is present on the purchase. The moment a buyer enters a discount code, the PPP adjustment drops out of the calculation and they pay your list price minus the code.

The practical consequence: if you run a 30%-off launch code and a buyer in Indonesia would have qualified for a 55% PPP discount, entering your launch code makes their price worse. They have no way of knowing that. If you promote codes to a global audience while PPP is on, expect this to bite someone.

2. Failing the location check costs the discount, not the sale

With the payment-method check switched on, a mismatch between card country and IP country removes the parity price — the buyer is shown full price and can still complete the purchase. Nobody gets locked out. It's worth knowing before you turn the check off "to avoid losing sales," because the sale wasn't at risk in the first place; only the discount was.

3. Deep discounts on cheap products hit the floor

Gumroad enforces a minimum paid price per currency — in USD it's 99 cents. A 60% PPP discount on a $1.99 product lands at about $0.80, which is under that floor, so the charge is rounded back up to 99 cents and your buyer never actually receives the full parity price. And even when a discounted price clears the minimum, the fee math gets ugly fast: Gumroad's platform fee on direct sales is 10% + $0.50 per transaction, and per Gumroad's own documentation that figure excludes payment processing (roughly 2.9% + $0.30 on a domestic card) charged on top. That's close to eighty cents of fixed cost on every sale no matter how deep the discount went. If your catalog sits at low price points, run the numbers before enabling PPP — our breakdown of Gumroad's fees walks through the effective-rate math at different prices.

4. It's IP-based, and it's invisible to you

Country detection comes from the buyer's IP address. You don't set it, you can't override it per customer, and there's no "give this person the India price" button. If a specific creator, community, or partner needs a guaranteed price, the toggle simply cannot do it — that's a discount code's job.

Option 2: Explicit per-region discount codes

If you want your own regions and your own percentages, you build them out of Gumroad's offer codes: one code per region, shared with the relevant audience.

Step 1: Write your region → discount table first

These percentages are illustrative — pick numbers you're comfortable with. The point is deciding once, on paper, instead of improvising per product.

Step 2: Create the codes

Discount codes live on a dedicated account-level page, not inside each product editor: Checkout → Discounts → New discount. Enter the code, choose which products it applies to (pick specific products, or check All products), choose a percentage, set the value, optionally add a usage limit, save. One code covers every product you select — so a region is one code, not one code per product. Repeat per region.

Under the hood that's POST /v2/products/:product_id/offer_codes, which takes name (the string buyers type), amount_off, and offer_type — note the values are "percent" or "cents", and it defaults to "cents", so a percentage code without an explicit offer_type becomes a cents-off code. Optional parameters are max_purchase_count, minimum_amount_cents, and universal (a universal code applies to all your products rather than one). Note the asymmetry: the API route is scoped to a single product, so through the API a code is either that one product or universal — there's no "this subset of eight products" the way the dashboard form offers.

Step 3: Accept what codes can't do

Two honest limits, both worth knowing before you commit:

Offer codes have no country field. Nothing in Gumroad's offer-code API or dashboard restricts a code to a region. INDIA60 is just a string — anyone who finds it in a forum, a Reddit thread, or a coupon-scraper site can use it from anywhere. Per-region codes are a pricing convention, not geographic enforcement. If leakage is unacceptable, cap each code with max_purchase_count or use the native toggle, which at least verifies location.

The API can't edit a code's discount amount. PUT /v2/products/:product_id/offer_codes/:id accepts offer_code, max_purchase_count, and minimum_amount_cents — and that's it. There is no parameter to change a percentage, so anything driven through the API has to delete the code and create a replacement. The dashboard is better here: its Discounts edit form does let you change the percentage in place. So moving India from 60% to 55% is one manual edit per code — fine for six regions, a chore for twenty, and impossible to script. Plan your table properly the first time either way.

If a code isn't applying the way you expect, the causes are usually mundane — common reasons a Gumroad discount code stops working covers the checklist.

Step 4: Hit the wall

First, the good news that a lot of guides get wrong: the multiplier is regions, not regions × products. Because one discount code can cover every product you select, six regions across ten products is six codes, not sixty. If your table is five or six rows, the dashboard handles it and you don't need anything else.

The wall is real, it's just a different wall. Each region is its own trip through the New discount form — code, product selection, percentage, limits, save — because the entire point is that every region gets a different number, so the "All products" checkbox saves you nothing. Twenty regions is twenty passes. Revising the table next quarter is twenty more edits. That's where sellers either fall back to the toggle or quietly never finish. It isn't hard. It's just repetitive enough to die in a to-do list.

Toggle vs codes: a straight comparison

When not to use PPP pricing at all

Fair regional pricing isn't automatically the right move. Skip it, or narrow it, when:

• Your product is priced low already. Below roughly $5, the floor and the fixed per-transaction fee do more damage than the discount does good.
• You sell B2B or to funded teams. A company buying a license isn't spending a local salary. PPP mostly leaks margin here.
• Your product includes real per-buyer cost — support hours, 1:1 calls, physical fulfillment, a seat on a paid platform. PPP logic assumes near-zero marginal cost.
• You run frequent global promo codes. Because codes override PPP, you'll be quietly showing your lowest-income buyers your worst price during every sale.
• Your audience concentrates in excluded countries. If most of your traffic is US, UK, and EU, the toggle will do almost nothing.

A common middle path: leave the toggle on for the catalog, add your premium or high-touch products to Products to exclude, and set a Maximum PPP discount you can live with.

Doing the manual method without the manual labor

The honest read is that explicit per-region codes are the better strategy for most growing sellers — real codes, exact percentages, and per-product control the toggle can't match. If your table is five or six regions, the dashboard does this fine and you should just go do it. It's when the table grows — a dozen-plus regions, revised every quarter, across a catalog you keep adding to — that the form-by-form grind starts eating afternoons. So the goal isn't to avoid per-region codes, it's to avoid retyping the same table.

That's the gap GumKit fills. It's an independent Chrome extension for Gumroad sellers — not affiliated with, endorsed by, or operated by Gumroad — that calls the official Gumroad API directly from your browser. You paste your own access token, created under Settings → Advanced → Applications in your Gumroad account, and GumKit uses the same official endpoints you'd hit by hand, just batched.

For PPP specifically:

1. Edit a region → percentage table — the same plan you'd sketch on paper, each row a label, a code, and a discount you choose.
2. Select the products the codes should apply to.
3. Run it. GumKit creates the region-specific offer codes across every selected product in one paced pass, instead of you filling out the New discount form once per region.

Because it uses Gumroad's official write API, bulk actions run as a paced queue that keeps going if you close the popup. Gumroad rate-limits writes and returns 429 Too Many Requests, but it doesn't publish a ceiling for offer-code creation — the one number in its API docs, 30 PUTs per minute per token, is documented for the custom-HTML landing-page endpoint, not for discount codes. So GumKit assumes a deliberately conservative ~30 writes per minute of its own and paces one write every 2.4 seconds (about 25 a minute), shows a progress bar, waits out the server's Retry-After on any 429, and survives you closing the popup mid-run. Your token lives only in your browser's extension storage. There's no server in the middle, no scraping, and no UI automation pretending to click buttons.

One honest difference from the dashboard route: the API creates codes per product, so GumKit writes one code per region per selected product rather than a single code covering the set. That's more codes in your Discounts list, and reporting per region is split across them. What you're buying back is the form-filling, not the row count.

GumKit handles the adjacent repetitive jobs the same way: bulk discount codes, bulk price changes (a flat price or a ± % adjustment), and customer CSV export.

If you're weighing this against a subscription parity service, we wrote a separate comparison of ParityDeals alternatives for Gumroad sellers.

FAQ

Does Gumroad have built-in PPP pricing?

Yes. It's an account-level toggle under Settings → Local, labelled "Enable purchasing power parity." Once on, Gumroad detects the buyer's country by IP and applies its own discount at checkout automatically.

How much of a discount does Gumroad's PPP give?

Between 20% and 60%. Gumroad computes a factor from World Bank PPP data divided by the current exchange rate, then clamps it: anything that would produce less than a 20% discount is dropped to zero, and anything deeper than 60% is raised to 60%. You can lower the ceiling with the Maximum PPP discount field, but you can't raise it above 60% or set per-country numbers.

Can I set different PPP discounts for different countries?

Not with the native toggle. It gives you one global ceiling, not per-country percentages. If you need India at −60% and Mexico at −35% exactly, you have to build per-region offer codes yourself.

Does the PPP discount stack with a discount code?

No. Gumroad applies the PPP factor only when no offer code is present on the purchase. If a buyer enters any discount code, they get that code's discount instead of the parity price — which can leave them paying more than they would have with no code at all.

Why doesn't my buyer in Japan (or Germany, or Portugal) get a PPP discount?

Gumroad hard-excludes a list of high-income countries from PPP regardless of the underlying data — 36 countries and territories including Japan, South Korea, Taiwan, Singapore, the Nordics, most of Western Europe, the Gulf states, Australia, New Zealand, the US, and Canada. Nothing in your settings changes that.

What happens if someone uses a VPN?

By default the switch "Apply only if the customer is currently located in the country of their payment method" is on, which compares the card's country against the detected IP country. On a mismatch the buyer loses the parity price and sees full price — the purchase itself is not blocked. Turning that switch off removes the check entirely.

Can I turn PPP off for just one product?

Yes. Add it to Products to exclude in the PPP settings. There's also an All products checkbox to exclude everything at once without flipping the main toggle off.

How do I make a region-specific discount on Gumroad manually?

Go to Checkout → Discounts → New discount in your dashboard — it's an account-level page, not something inside each product. Enter a code (e.g. INDIA60), select the products it should cover (or check All products), choose a percentage discount, set the value, and save. One code covers every product you selected, so the work scales with the number of regions, not regions × products. There's still no way to create several different codes in one action, so each region is its own pass through the form.

Can I restrict an offer code to one country?

No. Gumroad's offer codes have no geographic parameter — a region code is a naming convention, not enforcement. Anyone who finds the string can redeem it from anywhere. Use max_purchase_count to cap the damage, or rely on the native toggle when you need location actually checked.

Can I change a discount code's percentage later?

In the dashboard, yes — the Discounts edit form lets you change the percentage in place. Through the API, no: the offer-code update endpoint only accepts the code string, the usage cap, and the minimum order amount, with no field for the discount amount, so an API-driven change has to delete the code and create a replacement.

Will bulk-creating discount codes get my account rate-limited?

Not if you pace your writes. Gumroad returns 429 Too Many Requests when you push too fast, but it doesn't publish a rate ceiling for offer-code creation, so there's no documented number to design against. GumKit assumes a conservative ~30 writes per minute and runs at roughly 25, retries the same item using the server's Retry-After rather than skipping it, can be cancelled mid-run, and resumes on its own if you close the popup. It behaves like a careful human rather than a flood of requests, and it only uses the official Gumroad API, with no scraping.

Is GumKit affiliated with Gumroad?

No. GumKit is an independent Chrome extension. It uses Gumroad's official public API with your own access token and is not affiliated with, endorsed by, or operated by Gumroad.

The bottom line

Gumroad PPP pricing isn't one feature, it's two approaches with different failure modes. The native toggle is genuinely good if you want parity handled automatically and you're fine with Gumroad's numbers — and its exclusion list plus discount ceiling give you more control than most guides admit. But it caps at 60%, ignores 36 high-income countries, gives you nothing shareable, and silently loses to any discount code a buyer types in.

Explicit per-region codes fix all of that and introduce one problem of their own: they don't verify anything, and every region is another pass through the same form.

Pick the toggle if hands-off is the goal. Pick codes if control is. And if it's the labor that's been stopping you, GumKit turns the per-region method into one batched run on Gumroad's official API. It's free to use — bulk jobs included, and your token never leaves your browser. Plan your region table once, select your products, and let the codes go out — then get back to making things worth buying.