Submitting a Mini Program for Review: What Gets Rejected and Why

A Mini Program isn't published when you finish building it. It's submitted, reviewed by a human at Tencent against a published set of rules, and either approved or sent back with a reason code and a short explanation. First-time submitters often treat this as a formality and are surprised twice: once by the rejection, and again by how mechanical the reason turns out to be. Almost all of it is predictable, and nearly all of it is cheaper to handle while you're still designing than after you've been sent back.

The short version: rejections cluster into a few categories — wrong or unqualified business category, features that don't match the declared category, incomplete or unreachable content, missing account and privacy disclosures, payment and pricing problems, and content the submitter doesn't have the right to use. The category declaration is the single highest-leverage decision, because it determines which rules you're judged against and which documents you'll be asked for. Build the reviewer's path deliberately: they will open your Mini Program cold and tap through it like a first-time user.

The category declaration decides everything downstream

When you register the Mini Program you select a business category, and that choice does more work than it looks like. It determines which additional qualification documents you need to supply, which functions you're permitted to enable, and which rulebook the reviewer applies.

Two failure modes follow:

• Choosing a category you can't document. Some categories require industry licences or permits in addition to the company registration. Tourism-adjacent categories, medical and health, education and finance are the ones where extra paperwork is most commonly requested. If you can't produce what the category requires, the submission stalls regardless of how good the build is.
• Choosing a category that doesn't match what the Mini Program does. Reviewers compare the declared category against the actual screens. A Mini Program declared as informational that presents a booking flow, or declared in one industry while selling in another, tends to come back — not because the feature is forbidden but because the declaration is wrong.

The practical order is: confirm what category the entity can qualify for, then design within it. Doing this the other way round is how projects discover a blocker after the design is signed off.

For overseas entities there's a prior question — which countries and business forms are accepted as a registration subject at all, and which categories are available to them. That is worth confirming against the current registration flow before anything is promised around it, ours included.

Incomplete content is the most common avoidable rejection

Reviewers open the Mini Program and use it. So a build that's technically finished but content-empty reads as unfinished:

• Placeholder text and stock filler. Lorem ipsum, "coming soon", a product list with three test entries called Test 1.
• Dead ends. Buttons that do nothing, tabs that open a blank screen, a form that fails on submit.
• Content behind a wall the reviewer can't pass. If any part requires a login, an invite code or a paid membership, the reviewer needs a working test account — supplied with the submission. Not supplying one is a rejection waiting to happen, and it's purely administrative.
• Broken media. Images that don't load count as broken screens. If your assets are hosted somewhere unreachable from within mainland China, the reviewer sees exactly what your customers would see — which is the failure we described in the translation post and one of the most common quiet killers of overseas projects.

Rule of thumb: submit as though the reviewer were your least patient customer, because functionally that's the role they play.

Account information, privacy and the things you must state

A recurring cluster of rejections has nothing to do with your product:

• Who you are, on screen. The operating entity should be identifiable inside the Mini Program, not just in the account registration.
• A privacy declaration that matches behaviour. If the Mini Program collects a phone number, a name, a location or an image, that collection has to be declared and consented to, and the declaration has to match what the code actually does. Declaring less than you collect is a rejection; collecting things you don't need is an easy way to create the problem in the first place. Collect the minimum the enquiry genuinely requires — the habits in compliance basics apply directly.
• Contact and service information. A reachable contact route, and service terms where the product implies them: what's included, cancellation, who to contact when something goes wrong.

Payment, pricing and the "not included" trap

Payment is where scope creep meets the review process.

• Enabling payment functions requires its own qualification path, separate from getting the Mini Program approved. Overseas entities in particular should treat cross-border collection as a distinct project with its own prerequisites rather than a checkbox — see Alipay vs WeChat Pay for tourism merchants.
• Prices that can't be honoured. If a screen shows a fixed price for something that actually varies by date or party size, expect questions. The safer pattern for travel is a clearly-labelled price reference plus a structured enquiry, with the final quote coming from you.
• Routing payment outside the Mini Program without saying so. If the flow ends by sending the customer somewhere else to pay, that has to be presented honestly rather than dressed up as an in-app purchase.

Content you don't have the right to use

The last cluster is ownership. Reviewers do check:

• Images and video that aren't yours. Photos lifted from a booking platform, a partner hotel's marketing shots, or a supplier's brochure. If your own material is thin, that's a content problem to solve before submission — and traveller-supplied photos come with their own permission questions.
• Brand names and logos you don't own. Naming the airline, hotel chain or attraction you work with is not automatically permitted; using their marks generally requires authorisation.
• Maps, fonts and third-party components with licence terms that don't cover commercial use.
• Claims you can't substantiate. Superlatives ("the best", "number one"), unverifiable statistics, and fabricated reviews are all treatable as false advertising, and a manufactured testimonial is worse than none — see why Chinese consumers trust chat logs.

How to make review boring

• Settle the category and the qualification documents first, before design.
• Fill the Mini Program with real content — real products, real prices or clearly-labelled references, real photos you own.
• Walk the whole thing yourself on a cold device, tapping every button, as a first-time user with no context.
• Attach a working test account and short reviewer notes if anything needs explaining.
• Host media where it loads from inside mainland China.
• Budget for a rejection anyway. Treat one as information rather than a setback. What matters is whether the reason is administrative and fixable in a day or structural and fixable in a month — and that difference is what the preparation buys you.

Timelines vary and Tencent doesn't guarantee one, so any plan that depends on approval landing by a specific date needs slack in it. Building a launch campaign around an unconfirmed approval date is a self-inflicted wound.

Where CN1X fits

We handle the build and the submission, and the part that matters most is the sequencing: confirming what your entity can register and under which category before the design is settled, then building so the reviewer's path is clean — real content, working forms, images that load in the mainland, a test account, and a privacy declaration that matches what the code does. The account stays registered to your company, with you as the holder.

If you're weighing whether a Mini Program is the right container for your product at all, what a Mini Program cannot do is the more useful post to read first. If you already know it is, send us the product and we'll tell you what the category question looks like for your entity before anyone commits to a timeline.