The Business Reality2 min read

After the payment ban — dropping paid, pivoting to ads

Three overseas Merchant-of-Record processors rejected fortune-telling and astrology as a banned category. Dropping paid, flipping every app to free + AdSense — and the trap hiding in the deploy env.

#monetization#adsense#distribution#reality-check
Concept diagram: after processors banned the category, drop paid and pivot to free + AdSense
A concept diagram summarizing the post.

After payment processors blocked fortune-telling and astrology as a banned category, here's how the direction changed.

What happened

Three overseas Merchant-of-Record processors (Polar, Paddle, LemonSqueezy-class) treated fortune-telling and astrology as a banned category and rejected payments. The plan for three paid apps was blocked.

Dropping paid

Instead of re-appealing or working around it, I dropped paid entirely. If the category itself is banned, switching processors hits the same wall. I flipped every app to free + AdSense.

The trap hiding in the deploy env

Even after the switch, ads didn't show. The cause: across 34 production apps, NEXT_PUBLIC_ADSENSE_CLIENT was empty everywhere. It existed locally but never made it into the Vercel production env — and since NEXT_PUBLIC_ vars are inlined into the client bundle at build time, an empty env means the ad client ID is never baked into the bundle at all. A missing one doesn't even log; ads just don't appear. Bulk-adding it across the 34 and redeploying fixed it.

And the indexing bottleneck

ads.txt has to be reachable by crawlers to get approved, but for a while crawling was blocked (Mozilla-UA curl got a ModSec 403, Googlebot passed). Once the block was lifted, ads.txt was approved.

The honest conclusion: your monetization model is half-decided by your content category. Fortune-telling and astrology aren't welcome in the card-payment world, and ads were the realistic path. Better to accept the wall and pivot fast to the cheap route than to cling to paid hunting for a workaround.

Related