I Built a PPP Tool. Here’s Why Every Merchant of Record Should Build It Natively.
After integrating with four payment providers, I’m convinced: purchasing power parity belongs in the payment layer, not a third-party script. Here’s what native PPP should look like.
The $49 Problem
I grew up in Bangladesh. When I was learning to code, I found a course that would have changed my trajectory overnight. It cost $49.
$49 in San Francisco is lunch. In Dhaka, it was three days of my father's salary. I didn't buy the course. Neither did millions of people across South Asia, Africa, Latin America, and Southeast Asia who ran into the same wall.
This isn't a sad story. It's a market failure. Over 80% of the world's population lives in countries where US-priced software is unaffordable relative to local income. A $49 tool sold at $19 in Brazil is $19 more than the $0 you collect when they bounce. Companies that adjust prices for local purchasing power consistently see 20–30% more revenue from emerging markets.
When OpenAI launched ChatGPT Go in India at ₹399/month (under $5, vs. $20 in the US), paid subscribers more than doubled. That's not charity. That's price discovery.
How PPP Works Today: Scripts, Banners, and Coupon Codes
I built Evendeals to solve this. It detects a visitor's country, shows a discount banner, and auto-creates coupon codes in the merchant's payment provider. We integrate with Stripe, Lemon Squeezy, Dodo Payments, and Creem. ParityDeals works similarly.
These tools work. But after building integrations with four payment providers, I'm convinced the third-party approach has a ceiling:
- No access to hosted checkouts. The script runs on the merchant's site. If they use a hosted checkout or storefront (which most MoR platforms provide), there's no surface to run on.
- Coupon codes leak. A visitor in India gets a 40% off code, shares it on Reddit, and someone in New York uses it. Auto-rotating codes help, but it's a patch.
- Banners add friction. See banner, copy code, go to checkout, paste it. Every step is a drop-off point.
- It adds a dependency. If the PPP tool goes down, the merchant's pricing breaks.
These aren't bugs in the tools. They're structural constraints. The real solution isn't a better banner. It's native PPP in the payment layer.
The MoR Landscape: Who Has PPP and Who Doesn't
I've studied every major Merchant of Record platform's approach to purchasing power parity. The landscape is thin.
Paddle
Paddle has truly native regional pricing. Their unit_price_overrides API lets merchants set specific prices per country at the price level. A customer from Brazil sees the Brazilian price at checkout automatically. No scripts, no banners, no coupon codes.
But there's no pricing intelligence. Merchants have to research what discount is appropriate per country and set every override manually. No recommended rates, no PPP index data. Most merchants don't know that 35% is right for Thailand but 60% is right for Nigeria, so they don't set any overrides at all.
Lemon Squeezy and Polar
Both rely entirely on ParityDeals or Evendeals for PPP—banner + coupon approach with all the limitations above. We built Evendeals' Lemon Squeezy integration the same way. Since Stripe acquired Lemon Squeezy in 2024 and launched Stripe Managed Payments as its own MoR product, Lemon Squeezy's long-term future is uncertain and many indie hackers are evaluating alternatives. Polar is developer-focused and growing, but PPP isn't on their public roadmap either.
Dodo Payments
Dodo markets PPP as a feature, but their own documentation tells the real story: the PPP page recommends ParityDeals and Evendeals as the implementation path. The docs even note that custom scripts aren't supported on Dodo's own storefront.
Creem
Creem—the fastest-growing MoR, hitting $1M ARR in 10 months with no sales team—has zero PPP support. Their discount API supports percentage and fixed-amount codes scoped to products, but there's no country awareness, no geo-pricing, no automatic application at checkout. I built Evendeals' Creem integration to fill this gap.
Kelviq: The One MoR That Actually Built It
Kelviq is the most interesting case here—and the strongest proof that native PPP belongs in the payment layer.
Kelviq was founded by the same team behind ParityDeals—the most popular third-party PPP tool on the market. After years of building ParityDeals integrations across Lemon Squeezy, Polar, and Dodo, they hit the ceiling. Banners, coupon codes, client-side scripts—all fundamentally limited. So they built an entire MoR with first-party PPP baked into the checkout.
Kelviq's checkout suite localizes currency, payment methods, and billing details by region. Their anti-abuse layer goes deep: VPN protection, Tor blocking, proxy detection, Apple Relay protection, crawler blocking, and—critically—strict country matching that requires the credit card billing address to match the discount country.
That last one is the killer feature. Here's ParityDeals co-founder Sachin Neravath announcing it:
“We used to refresh discount coupons constantly to prevent abuse. Now that's no longer required.”
That single sentence captures the entire third-party-to-native evolution. When PPP lives in the payment layer, you can verify the buyer's country against their payment method—something no external script can do. Coupon rotation becomes unnecessary because enforcement happens at the point of payment, not the point of display.
Apple's App Store: The Quiet Gold Standard
While the web MoR ecosystem debates whether PPP is worth building, Apple has been doing it at planet scale for years. The App Store lets developers set one base price and auto-generates comparable prices across 175 storefronts and 44 currencies, adjusting periodically for exchange rates, taxes, and local purchasing power.
Mobile developers get localized pricing out of the box. No scripts, no coupon codes, no manual overrides for 175 countries. Apple treats regional pricing as a platform feature—because that's what it is. A developer in Austin sets $4.99 and a customer in Jakarta sees Rp 79.000. Done.
If the world's two largest app marketplaces treat this as a platform feature, why doesn't a single web MoR?
The Gap That Remains
Apple proved native PPP works at planet scale. Kelviq proved it's viable for a web MoR. But Kelviq is still the only web MoR that has built it. Paddle has price overrides without intelligence. The rest outsource to third parties.
Native PPP with pricing intelligence remains a category-defining opportunity.
What Native PPP Should Actually Look Like
After building a PPP tool that covers 249 countries across 10 purchasing power tiers and integrating with four payment APIs, I have a concrete opinion on what native MoR-level PPP should look like.
The core insight is that the MoR already has everything it needs: geolocation (for tax), payment processing (card issuing country, billing address), checkout flow control (can modify prices server-side), and transaction data (can attribute revenue to PPP). The infrastructure exists. It just needs to be connected.
1. Country-Aware Checkout
Every MoR already detects the customer's country for tax—VAT in Germany, GST in Australia, sales tax in Texas. Native PPP uses that same signal to apply a purchasing power adjustment server-side, at checkout, automatically. No script on the merchant's site. No banner. The customer from India sees the Indian price. Period.
2. Pricing Intelligence
This is where every current implementation falls short. Paddle lets you set overrides, but you need to figure out the right discount per country yourself.
The MoR should ship with pre-calculated recommended discounts based on the World Bank's International Comparison Program data—open, updated annually, covering 176 economies. The merchant experience: flip a switch, get sensible defaults, customize if you want. Not: research PPP ratios for 190 countries and manually enter overrides.
This already works at scale—Apple's App Store and Google Play have been doing exactly this for years, as covered above. The infrastructure pattern is proven. It just hasn't made the jump to web MoRs.
3. API-First Implementation
Two clean API approaches:
- Price-level overrides (Paddle's model): a
country_price_overridesarray on the Price entity. The checkout resolves the correct price based on the customer's country. - Discount-level country scoping: a
country_codesarray on the Discount entity. The discount applies only when the customer's detected country matches.
The first approach gives merchants full control. The second is faster to ship within existing discount infrastructure. Either way: zero merchant-side code. Everything available via API for programmatic control, with a dashboard toggle for merchants who want simplicity.
4. Payment-Layer Anti-Abuse
VPN detection is table stakes. The MoR's real advantage is payment method country matching—cross-referencing IP geolocation with the card's issuing country and billing address. Third-party tools can only check IP and browser signals. The MoR has the payment instrument itself. Kelviq proved this works: strict country matching made coupon rotation unnecessary overnight.
5. Analytics That Prove the ROI
The number one merchant objection is: “Am I just giving away margin?” Native analytics should answer this directly:
- PPP-attributed revenue: “You earned $4,200 from countries that had zero sales before PPP.”
- Conversion lift by country: “India went from 0.3% to 4.1%.”
- Abuse rate: “0.4% of PPP transactions flagged.”
When merchants see “PPP recovered $X from Y countries this month,” the feature sells itself.
Why This Matters Now
The Lemon Squeezy Migration
Stripe acquired Lemon Squeezy in 2024 and has since launched Stripe Managed Payments, its own MoR product. Lemon Squeezy's roadmap is uncertain. For the subset of LS merchants who had PPP through ParityDeals, the deciding question is: “Does my new platform support regional pricing?” The MoR that answers “yes, natively” wins those merchants.
AI Agents Don't Browse Websites
As commerce increasingly involves AI agents completing transactions, the banner-based PPP approach breaks entirely. An AI agent won't see a discount banner or paste a coupon code. It will hit an API endpoint, and the price it gets back needs to already be adjusted. Geo-aware pricing has to be infrastructure, not a UI widget. The platforms building coordination layers for economic activity—where AI agents transact alongside humans—need pricing that works at the API level.
The Emerging Market Opportunity
India alone has nearly a billion internet users. Southeast Asia, Latin America, and Africa are the fastest-growing digital markets on earth. These are current visitors bouncing off checkout pages because $29/month costs more than they earn in a day. The MoR that makes it trivially easy to sell to these markets—one toggle, smart defaults, zero merchant-side code—captures a segment every other platform is ignoring.
Beyond Discounts: A Global MoR That Feels Local
PPP discounts are just the entry point. The MoR that truly wins emerging markets will make the entire purchase experience feel local.
Local Currencies and Custom Prices
Showing $49 USD to a buyer in Brazil adds friction before they even consider the price—mental conversion, exchange rate anxiety, bank fees. Displaying R$249 in Brazilian Real removes all of that. And a 40% discount on $49 gives you $29.40—a weird number in any currency. True local pricing means setting the Indian price at ₹499 or the Brazilian price at R$49. Round numbers that feel intentional, not like a coupon was applied. This is what Paddle's unit_price_overrides enables and what every MoR should support.
Local Payment Methods
Credit cards are the default in the US. They're not the default everywhere. UPI dominates in India. PIX dominates in Brazil. iDEAL in the Netherlands. SEPA in the EU. A checkout that only shows Visa and Mastercard is losing conversions in every market where cards aren't the norm.
Localized Checkout
Button text, form labels, error messages, legal copy—all in the buyer's language. The MoR already knows the country. Serving the checkout in the local language is a translation layer, not a rewrite. Kelviq's checkout suite already routes payment methods by region and adapts billing fields—the right direction.
The Full Picture
The endgame is a MoR where a merchant flips one switch and their product is automatically priced in local currency, displayed in local language, accepting local payment methods, with purchasing power adjustments applied server-side at checkout. No scripts, no banners, no manual configuration per country. That's what “global by default” actually means.
The Bottom Line
I built Evendeals because native PPP didn't exist in the payment platforms I wanted to use. It works—our merchants see real revenue lifts from emerging markets. But every integration I build is a workaround for something that should live in the payment layer.
The right architecture is server-side price resolution at checkout, powered by open economic data, with payment-method-level fraud prevention, exposed through an API. That's not something a third-party script can do. That's something the Merchant of Record can do.
Whichever MoR builds this first gets a moat. They become the default for every SaaS founder who wants to sell globally without leaving 80% of the market on the table.
Until then, tools like Evendeals bridge the gap. If you sell through Creem, Stripe, Lemon Squeezy, or Dodo Payments, you can set up country-based pricing today. It takes about 10 minutes.
But I'd rather make myself unnecessary.
Try Evendeals Free
