I'm a solo developer in Bangladesh. I built a Chrome extension, priced it at $5 one-time, and got rejected by Lemon Squeezy before I sold a single copy.
The rejection email said:
"We don't allow services of any kind. We have to prove to our payment processors that something was delivered at the time of purchase. Since services happen off our site, it's impossible for us to verify what buyers actually received."
My product isn't a service. It's a browser extension. But my store description said "subscription license" — and that one phrase was enough.
What actually went wrong
The reviewer wasn't reading my product. They were reading my words.
To a Merchant of Record, the difference between a "service" and a "digital good" is a legal and financial one. They're the seller of record. They have to prove to Visa, Mastercard, and their acquiring banks that a customer received something at the moment they paid. A "service" is unverifiable and chargeback-prone. A file or a key delivered at checkout is verifiable.
I had described a one-time software license using subscription vocabulary. So they classified it as a service and declined.
The fix took one paragraph
I replied and reframed it — not by changing my product, but by describing it accurately:
Roost isn't a service. It's a one-time software license (a digital product). The deliverable is a license key generated and emailed at the moment of purchase; the buyer activates it in the extension. This is the same model as a desktop-app or plugin license.
Approved.
Same product. Same price. Different words.
The rule I now follow
Never use these words for a one-time software product: subscription, SaaS, service, plan, membership.
Always use these: one-time software license, delivered instantly as a license key, digital product, no subscription.
If your delivery is verifiable at checkout, say so explicitly. That single sentence is what a payment reviewer is looking for.
What I'd do differently
I'd have read the processor's prohibited-items page before writing my store description, not after being rejected by it. It cost me a week of launch momentum and a scramble to stand up a backup processor.
There's a broader lesson in this that I keep relearning as a solo dev: the gatekeepers — payment processors, app stores, communities — aren't evaluating your product. They're evaluating the signals around it. Get the signals wrong and a perfectly legitimate product gets bounced.
What I built while waiting
Because I didn't want to be dead in the water, I set up a second processor (Paddle) in parallel and made my licensing backend provider-agnostic: the webhook from either processor writes a signed license into the same store, and my extension validates against that — so it doesn't care which processor sold the license. Switching providers now takes one line on my landing page, not a rebuild.
That turned out to be worth the effort on its own. If you sell software as a solo dev, don't hard-code a single checkout provider into your product. You will need to switch one day, probably at the worst possible moment.
I'm building Roost — a private, local-only Chrome tab manager. $5 once, no subscription, no account. Happy to answer any questions about the payments side; it ate more of my launch than the code did.
Top comments (0)