Mini-program review rejections: the compliance checklist we built from ours
Across our mini-program portfolio we have submitted dozens of reviews and collected more than a dozen rejections. Laid out in one table, the pattern is unmistakable: most rejections trace back to explicit rules, not reviewer whim. This post is the checklist we reverse-engineered from our own rejection records.
Category one: category mismatch
The most common rejection. Your chosen category determines the lens the reviewer applies: under "Tools" the page must not surface social-matching entries; under "E-commerce" merchant qualifications and payment entities must line up. We once listed an emotion-tracking tool under Social and got rejected three times; relabeling it Tools passed on the first try.
Practical advice: check the categories already approved in your mini-program console, make the heaviest feature match them, and add a category before shipping a feature that needs one.
Category two: description and screenshots don't match the build
Reviewers treat version descriptions and screenshots as promises. Write "supports export" without a working export, instant rejection. Our descriptions now follow a strict two-part format — "added in this version / changed in this version" — and every claim must map to a screenshot.
Category three: payments and virtual goods
For virtual goods (memberships, coins, unlocks), iOS virtual-payment restrictions must be handled: hide purchase entry points on iOS, or integrate Apple's IAP middleware for mini programs. We conditionally compile payment entry points by platform; iOS shows but does not sell, and the review notes say so.
Another red line is withdrawal features: coin-to-cash or referral cashback triggers a qualifications review almost every time. Our final design converts coins into in-app virtual benefits only (membership trials, themes, items) with the cash exit removed entirely — the gameplay survives, the red line doesn't get touched.
Category four: UGC content safety
Anywhere users can publish (community, comments, anonymous walls), reviewers will sample. Our pipeline has four gates: client-side keyword filtering → contact-information blocking → server-side content-safety API → human review before publishing. The critical clause: when the safety API errors out, content must queue for human review — never default to publish. Auto-approving on API failure means gate four doesn't exist.
Category five: inducement and marketing language
"Share to three groups to unlock" and "invite friends for cash" are near-guaranteed rejections under Tools. Our copy rules now: sharing may only unlock functional convenience (one extra use), no monetary amounts, no mandatory share counts.
Category six: ad integrations
Once you're in the traffic program, ad compliance can also trigger rejection: rewarded videos must be genuinely watchable, interstitials must not appear without user expectation, banners must not obscure close buttons. Our check: trigger every ad type on a real device once and attach screenshots to the submission notes.
Turning the list into a process
Before every release we now walk the table in order: category match → description/screenshot consistency → payments and virtual goods → UGC gates → copy language → real-device ad verification. Twenty minutes total. It raised our consecutive-pass rate from roughly sixty percent to over ninety.
Rejections aren't scary; the same reason rejecting you twice is. Write every rejection reason down, and in three months you'll own a review guide more accurate than any public one.