What to Do When a WeChat Mini Program Fails Review: Category, Content, Permissions, and Privacy
After rejection, teams often delete a few sensitive words and resubmit or hide functions reviewers cannot reach. Feedback keeps changing and delays grow.
Review asks whether the entity and category may offer the service, whether pages genuinely work, and whether data and permissions are transparent. Validate each point in the rejection.
01 Preserve the Rejection and Version Evidence
Record review time, version, screenshots, feedback, and submitted code. Do not overwrite while changing or you cannot identify effective adjustments.
Rules and platform capabilities change; follow the current WeChat Official Accounts Platform and developer-tool guidance.
02 Match Entity, Category, and Qualifications
Real functionality must fit selected service categories, with industry qualifications where required. Copy cannot present ordinary information as unlicensed business.
For multiple businesses, check core and supporting functions, not only home.
Common Rejection Categories
| Category | Typical Problem | Response |
|---|---|---|
| Category and Qualifications | Service conflicts with category | Adjust scope or add valid qualifications |
| Functional Completeness | Blank, placeholder, or inaccessible login | Provide a test account and complete path |
| Content Compliance | Inducement, false claims, or prohibited transactions | Revise content and business mechanism |
| Privacy and Permissions | Unexplained purpose or excessive authorization | Add privacy guidance and contextual explanations |
| Payments and Transactions | Unclear pricing, orders, or refunds | Complete transaction and after-sales rules |
| External Navigation | Prompts to download or leave the platform | Review entries against platform rules |
03 Let Reviewers Complete the Core Flow
Provide valid test accounts, instructions, and data for login or role-based features. Do not block review with verification codes, allowlists, or empty accounts.
Explain time, region, or device restrictions in release notes and provide a verifiable path.
04 Request Permissions in Context
Request location, photos, or camera only when users start the task, explaining purpose. After refusal, provide alternatives or guidance without repeated forcing.
Privacy guidance, code, and page copy must align; recheck after adding plugins or SDKs.
05 Do Not Submit an Obviously Incomplete Product
Placeholders, test copy, unresponsive buttons, empty lists, and broken links prevent evaluation.
Test end to end in production with different accounts and real devices, especially orders, refunds, support, and closure.
06 Appeal with Evidence When Necessary
If review appears mistaken, explain feature location, business nature, qualifications, and changes with clear screenshots and paths. Emotional appeals rarely help.
When issues recur, add the review checklist to releases instead of handling it immediately before launch.
Frequently Asked Questions
Does Rejection Affect Future Submissions?
Address feedback promptly. Repeated unresolved submissions waste time; current platform rules determine further impact.
Must a Test Account Be Provided?
Yes when login or special permissions are required for core functionality.
Can an Empty Shell Be Submitted Before Features Are Added?
It is not recommended. Pages and core workflows should be genuinely complete.
Does Writing Privacy Guidance Guarantee Approval?
No. It must match real permissions, SDKs, and business behavior.
Where Are the Most Accurate Review Rules?
Use the WeChat platform, developer tools, and current rejection; third-party articles may age.
| Service | View |
|---|---|
| Related Services | View Service Details |
| Project Inquiry | Contact JVDS Design Studio |
| Design and Website Development Articles | View Service Details |
Link copied
