Rejected twice, approved on try three: my app is live on the Stripe App Marketplace today. What I learned about Stripe app review
Today RecoveryMRR went live on the Stripe App Marketplace. It recovers failed subscription payments with branded dunning emails for a flat $99 a month, and one click installs it into a Stripe dashboard.
Getting through Stripe's app review took three submissions over two weeks, and the reasons it failed are useful if you ever plan to ship a Stripe app:
-
First rejection: my drawer crashed on real invoices. The cause was unsafe access to userContext plus no error boundary. Stripe reviews on live dashboards, not on your test data.
-
Also first rejection: marketing copy. Anything that sounds like a promise has to go or be provable. Rewrite everything factual.
-
Second rejection: the app fetched from my backend but I had no content_security_policy in the manifest, so the sandbox blocked every request and the panel just showed an error. The CSP block goes inside ui_extension, not at the manifest root.
-
Also second rejection: my listing screenshot was a mockup. They detect fabricated images. Screenshot the real app in a real dashboard.
-
During review, their QA found two production bugs I had missed: my CORS allow list did not include the stripe signature header, and I was verifying signatures against the wrong payload. If Stripe's reviewers email you bug reports, treat it as free QA, fix fast, and reply with specifics.
Approved on submission three. The listing went live this morning: https://marketplace.stripe.com/apps/com.recoverymrr.app
Question for anyone running a subscription SaaS here: what do you currently do when a customer's card fails? Stripe's smart retries, a dunning tool, or nothing? Genuinely curious what the default is these days, it shaped my whole roadmap.
What stood out to me is that the review process wasn't just checking compliance—it was forcing the product to become more trustworthy.
Between the marketing claims, real screenshots, and production QA, it seems Stripe was evaluating whether users could rely on the app as much as whether it technically worked. That's a much more interesting lesson than simply "how to get approved."