Why a Finished Mini Program or App Still Cannot Go Live
Feature acceptance passed, the test cases ran green, the demo went smoothly — and then everything stops: the mini program review comes back rejected because the filing is incomplete; the app is packaged but the distribution platform demands a filing number first; payments are integrated and work in the test environment, yet the production merchant account is still unsigned. The team's first instinct is "where else is there a bug", but the root cause is usually not in the code — it is treating "development finished" as "ready to launch".
The short answer: for a custom mini program, app or software system to actually serve users, four tracks run in parallel — entity qualifications and filings, function and personal-information boundaries, payments and settlement, and a delivery that can be accepted and operated. The four are independent; if any one is unfinished, the product stays in a state that demos fine but cannot be used. Of the four, only the second and the fourth rest mainly on the engineering team. The first two depend more on the buyer's entity documents and business definition, and the third on merchant qualification and money-flow design. So they should not start when development ends; they belong on the same schedule from the first week.
Below, in the order real projects trip over them: why the tracks disconnect, how to tell which one you are stuck on, and for each track the rule basis, the failure modes and what to actually do.
1. Between "features done" and "live" lie four tracks
Taken apart, the four steps differ in who is responsible, how long they take and what happens when they fail:
- Filings and qualifications: borne by the buyer as the registrant, with the vendor helping prepare materials, submit and correct them. Failure means the product cannot be listed, cannot publish new versions, or even loses existing access services.
- Function and personal-information boundaries: decided jointly by product and engineering. Failure means a rejected review, a demand to rectify, or compliance exposure during operations.
- Payments and settlement: the buyer's entity signs with the platform, engineering does the technical integration. Failure means "orders accepted, money not collected" — or money collected that cannot be settled out.
- Acceptance and operations: agreed between the two parties in the contract and deliverables. The failure is quieter — the system is live, but nobody can change it, fix it, or take the data away.
The key difference: the first three have an external approver, so their timelines are not fully under the project team's control. A filing is reviewed by the communications administration, a payment account by the platform, and both count in working days. If you only start preparing when development is done, the project slips by roughly the approval time. The controllable approach is to run approvals in parallel with development and bury the waiting period inside the build.
2. First diagnose which category you are stuck in
The same symptom — "we cannot go live" — can have completely different causes. Locate by symptom first, then fix; it saves a lot of detours.
| What you see | More likely cause | Check first |
|---|---|---|
| Review rejected, filing incomplete or information inconsistent | Filing never started, entity details differ from the business licence, responsible-person verification incomplete | Registrant entity, filing progress, responsible person's mobile number and real-name details |
| Review says "collects unnecessary personal information" or the privacy policy does not match | Login or registration forces a mobile number, permissions requested up front, SDKs not disclosed in the privacy policy | Definition of core functions, field-to-function mapping, third-party SDK list |
| Payment sheet opens but settlement fails, or merchant binding fails | Merchant entity differs from the mini program / app entity, business category does not match the actual business | Licence entity, settlement account, business category |
| Demo environment fine, production errors | Domain not filed, certificate expired, allowlist not configured, production keys not swapped | Domain filing status, certificate validity, third-party console settings |
| Nobody can change anything after launch | Source code, database, deployment docs or platform accounts never handed over | Deliverables list and account ownership |
The point of this table is not to be exhaustive but to make one thing obvious: these five categories are not solved by the same person. The first goes to admin and finance, the second to product, the third to finance and the platform, the fourth to operations, and the fifth back to the contract. A project owner who only talks to the engineering team keeps looking for answers at the wrong level.
3. Filing: not a development task, but it must start during development
Who needs a filing
Under the Ministry of Industry and Information Technology's Notice on Carrying Out Filing for Mobile Internet Applications (MIIT XG [2023] No. 105), APP registrants providing internet information services in mainland China must complete filing; without it, they may not provide APP internet information services. Filing is done through the system set up by the provincial communications administration where the registrant is domiciled, and where materials are complete and accurate the filing is granted and a number issued within 20 working days. The APP must also display the filing number prominently and link it to the filing system.
The same notice requires network access providers and app distribution platforms not to provide access, distribution or pre-installation services for unfiled APPs. The practical consequence is direct: filing is not a formality to catch up on after launch; it is a precondition for distribution and access. Without a number, app stores will not list the app and cloud or CDN providers should not keep serving it.
Mini programs use a different entrance: you submit through the WeChat Open Platform filing flow, the platform does a first review, then forwards it to the communications administration. According to WeChat's Mini Program Filing Guide (page edited 18 August 2026), filing types are new filing, change of filing and cancellation; materials include the entity's certificate, the identity documents of the entity's responsible person and the mini program's responsible person, pre-approval documents where applicable, authorisation letters and other supplementary materials, an undertaking letter and an authenticity verification form, plus face verification. Platform first review takes about 1–2 working days, after which MIIT sends a verification SMS (from 12381) that the registrant must complete within 24 hours — overdue submissions are rejected automatically and must be resubmitted; the communications administration then reviews in about 1–20 working days.
How the two filings differ
| Dimension | APP filing | Mini program filing |
|---|---|---|
| Registrant | The app registrant (consistent with the business licence entity) | The mini program registrant, consistent with its registered entity |
| Submission entrance | Provincial communications administration system where the registrant is domiciled | WeChat Open Platform filing entrance, first review by the platform, then forwarded |
| Key timelines | Complete and accurate materials, done within 20 working days | Platform first review 1–2 working days; SMS verification within 24 hours; administration review 1–20 working days |
| Launch dependency | Distributors and access providers may not serve unfiled apps | Cannot submit for review or publish until filing is complete |
| Common rejection points | Entity details inconsistent with certificates, wrong responsible-person details, business description not matching actual functions | Verification timeout, unacceptable document photos, name or category inconsistent with the entity |
Platform announcements have set different milestones for existing and new mini program filings at different times; the exact deadlines are those on the platform's current page. This article cites only the process and material requirements and does not treat an earlier announcement's timeline as the current rule.
Why filings get rejected, and what to prepare in advance
In practice a filing is rarely returned because "policy forbids it"; most returns are basic document problems:
- Entity details inconsistent. The name or unified social credit code on the licence differs from what was submitted, or a brand name was used instead of the registered name.
- Responsible-person verification failed. The mobile number is not registered to that person, the SMS was not filled in within 24 hours, or the face-verification environment was unacceptable. For mini program filings this is the most common loss of time.
- Business description not matching functions. The filing says "corporate showcase" but the product takes orders online, or the category is so far from the actual business that extra qualification requirements are triggered.
- Missing pre-approval. Businesses involving news, publishing, education, healthcare, pharmaceuticals or medical devices need the competent authority's approval document before filing.
- Mini program name not matching the entity. A name that involves a trademark or third-party rights, or is plainly unrelated to the entity's business scope, may have to be changed.
For a buyer, the time-saving move is to have these ready in the first week of development: business licence, legal representative's ID, responsible person's ID and real-name mobile number, corporate account details, business scope and business description, and any pre-approval licences. Preparing documents usually takes longer than the review, and it can run in parallel with requirements work.
4. Permissions and "necessary information": one field fewer may pass, one field more may fail
What the rule actually says
The Provisions on the Scope of Necessary Personal Information for Common Types of Mobile Internet Applications (GXB [2021] No. 14, issued 12 March 2021) sets two key points: necessary personal information means the personal information required for the normal operation of an APP's core functions — without it the core function cannot be delivered — and it covers consumer-side user information only; an APP may not refuse a user the use of its core functions because the user declines to provide unnecessary personal information. The provisions also state that APPs include mini programs built on an open platform's interfaces that users can use without installing anything.
The rule is often misread as "you may not collect personal information"; what it actually requires is that the collection scope map onto the core functions. It lists the necessary scope per common category: for online shopping, the core function is "purchasing goods" and the necessary information includes the registered user's mobile number, the recipient's name, address and contact number, and payment information such as payment time, amount and channel; for instant messaging it includes the registered mobile number and account information (the account and the contact account list). Information outside those lists that is not required for the core function cannot be made a precondition of use.
Turning "core functions" into fields
In practice "core functions" cannot stay a sentence in a product document; it has to be broken down to the field level:
- Write the core functions first. Not "an e-commerce platform" but "users browse products, place orders, pay and track deliveries". The more concrete the function definition, the clearer the boundary of necessary information.
- Annotate the purpose of every field. Next to each collected item, state which function it supports, what breaks without it, and whether it can be deferred. Any field justified by "operations would like to see it" or "it may be useful later" stays out of the required set.
- Make optional information actually optional. Marketing preferences, avatar and nickname, location (where not needed for delivery), contacts, photo library — all should be skippable without affecting the main flow.
- Request permissions on demand, not with a pop-up. Asking for camera, location or notification permission at first open is a frequent cause of rejection and bad reviews. Request when the user triggers the relevant function, and explain the purpose.
- Third-party SDKs count too. Analytics, push, maps, customer service and payment plug-ins all collect data. Before launch there should be an SDK list naming each SDK, what it collects and why, disclosed in the privacy policy, with initialisation following a "notice first, then start" order.
- Account deletion and data removal must really work. The entrance must be reachable and the flow completable; "contact customer service" is not a substitute.
One trade-off that gets overlooked
Asking for a mobile number before anyone can browse buys user numbers in the short term and costs review risk and conversion. The Personal Information Protection Law requires a lawful basis and notice for processing personal information, and separate consent when providing information to third parties. For most products built around browsing content or selecting goods, allowing browsing first and requiring sign-in at checkout or on interaction both satisfies the necessary-information principle and usually converts better. Only where the core function itself depends on an account — instant messaging, or financial services needing identity checks — is a registration mobile number necessary.
5. Payments: accepting money is not the same as settling it
Merchant qualification decides whether you can take money
Following WeChat Pay's official mini program integration guide, the documents fall into two groups: sole proprietorships need a business licence, a corporate account or the legal representative's personal account, and the legal representative's ID; companies need a business licence, an organisation code certificate (waived under the three-in-one licence), a corporate account and the legal representative's ID. Review takes about 1–2 working days, after which you sign online and bind the merchant number to the mini program's APPID, or enable the commercial collection edition to integrate without development. Applying is free; transaction fees run about 0.6%–1% depending on industry category.
What is most underrated here is entity consistency: the merchant number entity, the mini program or app entity, the settlement account and the invoicing entity must be the same set, or related in a way the platform allows. Otherwise binding fails, or settlement is restricted after signing. Brand authorisation, agency collection and intra-group collection all need additional authorisation documents; a written note will not get you through.
Fees are a cost, not the whole cost
A few basis points make almost no difference to low-frequency business and a real margin difference to high-frequency small-ticket business. But more worth settling at design stage than the rate:
- Settlement cycle and receiving account: settlement terms are those shown at signing; finance must confirm the cash-flow rhythm in advance.
- Refunds and reconciliation: whether refunds return to the original channel, how partial refunds are booked, and which statement is authoritative at day end. Without agreement during development, someone reconciles by hand every day after launch.
- Split payments and multi-party collection: platform businesses paying out to merchants must use the platform's split-payment capability, not have users pay an individual who then transfers the money on. The latter is "second clearing", an explicitly prohibited way of pooling funds.
- Invoices: who invoices, in which category, at what tax rate — finance has to decide before integration.
How we usually sequence this step
The technical integration is not complicated; the process is. A sensible order: the buyer prepares entity documents and applies for the merchant number, while engineering uses a test merchant number to complete the full chain of ordering, payment, callback, refund and reconciliation; when the production merchant number arrives, only the configuration is swapped and one real small-amount transaction verifies it. The review wait then does not block development, and production never sits half-integrated.
A boundary worth stating: merchant qualification review, fee determination and settlement cycles are decided by the payment platform. A vendor can help prepare documents and rectify issues, but cannot promise review outcomes or timelines.
6. Data and accounts: where pre-launch risks usually hide
Technical acceptance passes and the system runs, and six months later, when the vendor is to be replaced or the team brought in-house, you find the domain is in someone else's name, the mini program administrator is an outsourced individual, the merchant number is bound to a third party, the database has no export permission and the source code is incomplete. These problems are invisible at signing and extremely expensive at handover.
Ownership checklist before launch:
- Domain and certificates: registered under the buyer's entity, DNS control transferable, HTTPS certificate validity and auto-renewal defined.
- Filing registrant: APP filing, mini program filing and website ICP filing all name the buyer as registrant; the vendor only assists.
- Platform accounts: mini program and official account administrators, developer permissions, merchant number administrator, cloud accounts, SMS and push accounts — all registered as the company and held at the highest permission level by the buyer.
- Source code and database: code complete and buildable, dependencies installable, deployment documented; database schema and data exportable, including scheduled jobs and configuration files.
- Third-party services: maps, SMS, OCR, AI models — account ownership, quota and billing terms written down, so nobody discovers at quota exhaustion that no one can top up.
- Data security baseline: production and test data separated, sensitive fields encrypted or masked, operation logs retained, backups restorable (only counts after a restore drill).
This section reads like a handover checklist but actually decides whether you still have bargaining power when the cooperation ends. Rolling Water's default delivery on custom projects includes source code, database, deployment documents and platform accounts, with maintenance quoted separately by agreed scope — not as a gesture, but because a system you cannot operate yourself locks you to a single supplier for every future change.
7. Acceptance: how to accept a custom system that has no physical form
Accept in layers, not with a single demo
A demo that works shows the main flow works, not that the system is usable. Accept in four layers and keep records for each:
| Layer | What to verify | Example pass criterion |
|---|---|---|
| Functional | Walk through the requirement list item by item | Each requirement has an operation path and expected result; all pass or have a documented disposition |
| Boundary and exception | Empty data, over-long input, duplicate submission, network loss, concurrency conflict | No dirty data or crashes; error messages are understandable |
| Permission and data | Role-permission matrix, data visibility, unauthorised access | Each role sees and acts only within its authorisation, enforced at the API layer too |
| Non-functional and launch drill | Concurrency, response time, backup and restore, release and rollback | Agreed performance targets met; rollback completes within agreed time |
Permissions deserve a separate test. Hiding a menu is not access control; without API checks, changing one request parameter returns someone else's data. Test by calling the API directly, not by looking at the screen.
Acceptance criteria must be executable
"Beautiful interface, runs smoothly" is not a criterion; it only pushes the dispute to the week before launch. Executable phrasing: the order list renders its first screen within 2 seconds with 10,000 records; a user submitting the same order twice creates one record; after an administrator deletes a product, the storefront returns a clear "no longer available" message instead of an error page. Written before development, such items need no argument at acceptance.
Defect handling needs rules too: classify as blocker, major, minor, agree fix times and closure criteria per level, and write into the contract who handles defects during the trial period (say two weeks after launch) and whether they count as maintenance.
A trial run is part of acceptance
For systems handling real transactions or real data, run a small group of real users first, then open fully. In a trial run the three things to watch are not features but performance under real data, how exception paths actually behave, and whether operations procedures work (does anyone read the alerts, is the on-call number answered). None of these can be tested in a test environment.
8. Operations: from day one to year one
Launch is not the end. Most first-year problems in custom systems come from "nobody owns this", not from technical difficulty.
- Observability: at minimum error rate, response time and key business volumes (orders, payment success rate) monitored and alerted, with someone receiving the alerts. Without monitoring, users tell you about outages.
- Backup and restore: state frequency and retention, and run a restore drill every quarter. Backups without drills are not backups.
- Release and rollback: every release has a version record and rollback plan; database change scripts are reversible. Hot-patching production files directly is a common start of later incidents.
- Certificates, filings and qualification changes: certificate expiry, entity changes and business-scope adjustments must be reflected in filings and platform records — and filing changes take review time too.
- Accounts and people: revoke permissions when staff leave, do not concentrate administrator accounts in one person, log critical operations.
- Maintenance boundary: response times, service hours, included change volume and billing beyond it — written down, this is more credible than "24/7 online".
Rolling Water's practice is to write the maintenance scope as a list: which monitoring is included, which incident types are handled within response times, which count as new requirements quoted separately. With that list a buyer can tell whether they bought "someone answers the phone" or "someone is accountable end to end".
9. Choosing between self-built, custom development and an SaaS template
How much pre-launch work you face depends directly on how you build. The three paths have no absolute ranking; it depends on business differentiation and internal capability.
| Dimension | SaaS template / off-the-shelf | Custom development | In-house team |
|---|---|---|---|
| Speed to launch | Fastest, days to weeks | Moderate, usually months | Slowest, hire first |
| Fit to the business | Limited by template features; the process bends to the tool | Designed around your process | Designed around your process |
| Filing and qualifications | Platform usually holds them; buyer still needs entity documents | Buyer is the registrant, vendor assists | Same as custom |
| Data and account ownership | Data on the platform, limited export | Code, data and accounts belong to the buyer | Fully owned |
| Long-term cost | Subscription grows with scale | High initial, then iterate as needed | Fixed but high headcount cost |
| Fits when | Generic business, fast validation, limited budget | Clear differentiation, long evolution, sensitive data | Multiple product lines, internal technical management |
A suggested order of judgement: first ask "is this process our competitive advantage?" If it matches the industry norm, a mature product is cheaper; if the process itself is the difference, or the data cannot live in someone else's system, custom development is more sensible; only if several products must iterate in parallel within a year is an in-house team worth considering.
10. Next steps: a sequence you can run before launch
- Confirm entity and qualifications. List the licence entity, legal representative, responsible person and corporate account; make sure the mini program/app registrant matches the receiving entity; for businesses needing pre-approval, find out which licence is required.
- Write the core function list. Use "what the user can do" sentences, mark the information fields each function needs, and demote non-essential fields to optional.
- Draw the timeline of the four tracks. When filing, payments, development and acceptance start, and where the approval waiting periods sit. Filing and merchant applications start as early as possible.
- Build the platform and account list. Domain, certificate, mini program, merchant number, cloud services, third-party APIs — verify registrant and highest-permission holder for each.
- Fix acceptance criteria before development. Convert the requirement list into executable items, including the permission matrix and performance targets, confirmed in writing by both sides.
- Run one real drill before launch. Use the production environment, production accounts and one real small transaction through the whole flow; check callbacks, reconciliation, invoicing and alerts.
- Put handover and maintenance on paper. List source code, database, deployment docs and accounts to be transferred; write maintenance scope, response times and billing into the contract.
When Rolling Water takes on custom software, mini program, app, AI application and agent projects, we usually start with the first two items on this list: pin down the entity qualifications and core functions with the buyer, then decide the technical approach. The reason is that once these two churn, design and scheduling have to be redone. We can handle document preparation, submission follow-up, technical integration, acceptance organisation and post-launch maintenance, but filing and payment review outcomes are decided by the authorities and the platform, and the launch date should be aligned with that fact rather than promised first and reverse-engineered later.
FAQ
Q: The mini program is already live — do we still need a separate APP filing?
Yes. Mini program filing and APP filing are two entrances and two sets of materials. The same entity distributing an app must still file with the communications administration where it is domiciled under the APP filing rules, obtain a number and display it prominently in the app.
Q: Can we run a canary release or internal test while the filing is pending?
Distributors and access providers should not provide distribution or access services for unfiled applications. Canary releases also depend on platform review, so the safer approach is to keep testing on your own channels (internal test builds, the trial version) and wait for the filing before releasing externally.
Q: If the user refuses to give a mobile number, can they still use the product?
It depends on whether the number is necessary for the core function. For browsing and shopping, allow browsing first and require sign-in only for account-dependent actions (ordering, interaction, after-sales). If the core function itself depends on an account, the registration number is necessary information, but the purpose still has to be explained in the privacy policy.
Q: Can the payment fee be negotiated lower?
The rate is set by the platform by industry category, and some categories and channels differ. A vendor cannot promise a rate on the platform's behalf; what it can help with is aligning the business category with the actual business, so that signing does not fail or get repriced later because of a wrong category.
Q: Does passing acceptance end the project?
Passing acceptance means the deliverables meet the agreement, not that no further investment is needed. Define maintenance scope, response times and how later requests are billed at the same time; otherwise the first small change becomes a new dispute.
Sources
- Ministry of Industry and Information Technology, Notice on Carrying Out Filing for Mobile Internet Applications (MIIT XG [2023] No. 105): the APP filing obligation, filing authority and the 20-working-day limit, the requirement to display the number, and the rule that access providers and distribution platforms may not serve unfiled APPs.
- WeChat Open Documentation, Mini Program Filing Guide (page edited 18 August 2026): filing types, material list, platform first review of 1–2 working days, MIIT SMS verification within 24 hours with rejection on timeout, communications administration review of 1–20 working days. Exact deadlines and latest requirements follow the platform's current pages.
- WeChat Pay mini program integration guide (pay.weixin.qq.com): the two sets of application materials for sole proprietorships and companies, review of about 1–2 working days, online signing and APPID binding, no application fee and transaction fees of about 0.6%–1% by industry category.
- Cyberspace Administration of China, MIIT, Ministry of Public Security and State Administration for Market Regulation, Provisions on the Scope of Necessary Personal Information for Common Types of Mobile Internet Applications (GXB [2021] No. 14, issued 12 March 2021): the definition of necessary personal information and its consumer-side scope, the prohibition on denying core functions because a user declines unnecessary information, the inclusion of mini programs in APPs, and the necessary scope listed per common type.
- Personal Information Protection Law of the People's Republic of China: lawful basis and notice duties for processing personal information, and the requirement for separate consent when providing personal information to third parties; Measures for the Administration of Internet Information Services: businesses requiring pre-approval must first obtain the competent authority's consent.
- The process timelines, fee rates and material requirements cited were checked against public pages on 10 November 2026; platform and authority rules may change. Filing, payment and compliance judgements for a specific project should follow the latest official pages and the authorities' replies. Statements about the brand and delivery approach come from Rolling Water's public information and project practice.