上架、权限、支付，为什么必须在软件方案阶段一起设计

上架、权限、支付，为什么我们坚持在方案阶段就一起定下来

做定制软件时，客户通常会把注意力放在“功能清单”上：登录、订单、报表、消息通知，一项一项对得很细。但项目真正卡住的地方，往往不在这张清单里。

我们做过的小程序、App 和后台系统里，最容易在最后一个月集中爆发的三类问题，分别是上架、权限和支付。它们的共同点是：看起来像技术问题，实际上是由平台规则、企业资质和业务流程共同决定的。技术只是把它们实现出来。

所以滚水科技的做法是：这三件事在方案阶段就要一起设计，不是等开发做完再补。

一、上架：它决定了这套软件“能不能被用户装到”

很多人以为上架是最后一步，开发完成、打包提审，几天就过了。实际情况是，审核判断的不是“你有没有做完”，而是“这个产品对用户有没有价值、各项材料是否对得上”。

几个真实会遇到的判定点：

功能是否足够独立。 Apple 的 App Review Guidelines 4.2 条（Minimum Functionality）要求 App 提供足够价值，不能只是网页的简单封装，也不能只有少量功能。这条规定意味着：如果你的产品本质上是“把我们已有的网页包一层”，iOS 版本从设计上就要调整，而不是提审时再改。

隐私说明是否到位。 同一份指南 5.1.1 条要求说明收集哪些数据、用途是什么，涉及第三方数据必须披露，并提供隐私政策入口。这件事的前提是：你在方案阶段就清楚这套系统会收集哪些数据——这属于需求设计的一部分，不是提交申请时填的表。

类目与资质是否匹配。 微信小程序要求开发者在提交审核前选择开放服务类目，不同类目对应的资质要求不同（微信开放社区《小程序开放的服务类目》页面在 2026 年 10 月 30 日仍在更新）。做餐饮的选了“工具”、做在线问诊的选了“教育”，代码再干净，审核也会卡在资质上。

这里的取舍

我们通常会建议客户在方案阶段做一次“上架可行性预判”：确定目标平台、确定类目、列出需要准备的主体资料与资质。这一步会多花几天，可能推迟开发启动。

代价是很清楚的：如果放在提审时才发现问题，你要么改产品定位，要么重新办资质，两者都按周计。我们倾向于先花几天，把这条路上的确定性拿到手。

二、权限：它不是加个字段，是一份要签字的业务规则

权限在方案里常常被写成一句话：“支持多角色权限管理”。但开发真正要写的，是具体规则：谁能看到什么数据、谁能改什么、谁批准、出问题谁负责。

这些规则不来自技术，来自业务。同一张订单，销售看到金额、财务看到成本、区域经理只看到自己区域——这些区别如果不提前定，开发只能按理解去猜，验收时一定被推翻，然后进入返工。

我们的处理方式是：在方案阶段把它落成一页“角色—数据—操作”的表格，由业务方确认。这一步把模糊的口头约定变成可签字的东西，好处不只是少返工：

• 数据边界：同一张单据，不同角色看到的字段是否相同，金额、成本、联系方式是否要分开
• 操作边界：谁可以创建、修改、删除，删除要不要二次确认或审批
• 范围边界：区域、门店、供应商这些维度是否构成数据隔离，跨范围访问是否要审批
• 留痕要求：关键操作是否记录操作人、时间与变更前后内容，用于对账、追责或审计

这里的取舍

把权限做细，第一版开发的工时一定增加：多一层数据隔离、多一套审批流、多一份留痕记录。

我们的判断标准是看这套系统会不会被“事后追查”。如果它涉及钱、涉及客户数据、涉及多人协作，留痕和数据隔离就是必要的成本；如果只是内部几个人用的工具，强行上复杂权限只会让所有人多绕几步。权限设计的目标不是“越严越好”，而是把风险控制在能承受的地方，同时不拖慢日常操作。

三、支付：前置条件在企业侧，不在代码侧

支付是三类问题里最容易被低估的。开发上“接个支付”听起来是一个接口的事，但真正决定进度的，是资质审核。

按微信支付官方接入指引（2026 年 10 月 31 日核对），商户需提交主体资料并完成审核，审核通常需要 1–2 个工作日；商户号还要与对应 AppID 完成绑定，才能在小程序或 App 内正常发起支付。资质补件、主体信息不一致，都会让审核重新开始。

也就是说，支付能否按时上线，主要取决于你在银行和平台侧的资料齐不齐，不取决于代码写到哪。这就是为什么我们会在方案阶段就把支付通道、主体一致性、结算方式一起确认下来。

费率是预算问题，要在方案里出现

国内支付通道的手续费率通常在 0.6%–1%，取决于行业与通道类型。这个数字不影响开发，但决定你“卖一单实际到手多少”。提前写进预算表，比上线后再解释容易接受得多。

苹果生态的额外一层

App 内售卖订阅、虚拟商品或付费内容，Apple 的 App Review Guidelines 3.1.1 条（In-App Purchase）要求通过应用内购买完成，平台按 15%–30% 抽取佣金。如果商业模式包含虚拟商品，iOS 的价格结构要单独设计——这属于定价和产品设计问题，不是开发末期能补的。

这里的取舍

支付通道的选择通常在三者之间权衡：到账速度、手续费率、接入与对账的复杂度。我们不建议只比费率——如果某条通道的结算周期和对账方式跟你的财务流程不匹配，省下的手续费很可能被每月的人工对账吃掉。

四、为什么必须一起设计，而不是分开做

如果分开处理，最典型的结果是：功能都做完了，三件事才开始——去提审、去定权限、去申请支付。而这三件事的周期都不由开发方控制，于是上线时间被最不熟悉的那部分决定。

一起设计，价值在三个地方：

1. 共享同一份事实。 类目决定资质，资质决定主体，主体决定支付能否绑定，支付又反过来影响定价和产品形态。这四件事是一条链，分开问会得到四个互相矛盾的答案。
2. 把不确定性挪到前面。 资质办理、审核沟通都有外部等待时间。放在方案阶段，它们能在开发并行推进；放在收尾阶段，它们就是纯粹的等待。
3. 让责任边界清楚。 平台规则、资质申请、审核沟通由谁负责，在方案里写清楚，就不必在上线前争论。

滚水科技做的项目里，小程序、App 与后台系统常常是同一套业务的三端。任何一端规则卡住，整条业务链路都不成立，所以我们把上架、权限、支付放进第一版方案，而不是当成收尾工作。

五、我们具体怎么实施

方案阶段的这一段，我们通常用一次半天的梳理会完成，产出三份文件：

这三份文件进入项目范围，成为开发和验收的依据。之后开发按它们推进，提审和接入时材料是现成的——不需要在上线前临时补。

以上平台规则与费率来自官方公开文档，核对时间为 2026 年 10 月 31 日，实际提交前请以各平台当日规则为准。