The Business Reality3 min read

Payment processors banned my apps — a fortune-telling category rejection

I built paywalls before checking whether my category was even allowed. Lemon Squeezy, Polar, and Paddle all said no. Then my pivot to ads hit a second wall I'd built myself.

#monetization#payments#merchant-of-record#adsense#indie
Payment processors banned my apps — a fortune-telling category rejection

I built the checkout flow before I checked whether anyone would let me charge. That was the mistake.

Some of my apps are in the fortune / astrology / tarot space. Small, free-to-try, with a paid detailed report. To take card payments as a solo dev outside my home country, the easy path is a Merchant of Record (MoR) — they handle tax and act as the seller. So I wired one up. Then I tried to get approved.

The wall

  • Lemon Squeezy — rejected. No reason given.
  • Polar — rejected, and this time explicit: astrology / fortune-telling / tarot / dream interpretation is a prohibited category.
  • Paddle — same prohibition.

This isn't a vendor quirk you fix by switching vendors. MoRs sit on top of the card networks, and the card networks treat fortune-telling as an elevated-risk category. Swapping providers just gets you the same "no" with a different logo. My domestic payment gateway would allow it — but at that point I'd already learned the real lesson and chose to stop charging entirely.

Prohibited-category line in a processor's policy Placeholder — real capture pending, PII redacted. "Prohibited" is a policy fact, not a support ticket you can appeal.

The pivot — and the second wall I built myself

So I flipped everything to free + ads. Remove the paywall, remove the checkout, remove the business-registration/refund boilerplate that only existed because I was charging. Publish the full report for free, monetize with ads.

Then the ad network couldn't approve me — because it couldn't crawl my site. My apex domain was sitting behind an aggressive bot-protection config (bot-fight mode + a WAF) that I'd turned on for other reasons. It blocked crawlers so thoroughly that even robots.txt came back refused. The verdict came back as "low-value content / can't be found." There was plenty of content. The problem was that nothing could read it.

I'd built a second wall myself, and it was harder to see than the first because it looked like a content rejection when it was really an infrastructure one.

The honest part: validate the policy before you build the paywall

Two lessons, both cheap in hindsight:

  1. Check monetization eligibility before you build monetization. Ten minutes reading a processor's prohibited-category list would have saved me the entire checkout implementation. Category risk is a policy fact — it doesn't care how good your app is.
  2. Your own infra can be the thing rejecting you. When a crawler-dependent service says "low value," check whether the crawler can actually reach you before you rewrite content. I removed the bot-protection gate on the relevant paths, moved the root to a plain static site that crawls cleanly, and the "no content" problem evaporated.

Free + ads turned out to be the right model for this category anyway. But I got there by building two walls and then knocking them both down — not by planning.

Related