01 个人主体可以申请，但只适用于虚拟商品和数字服务。
02 Android 等终端费率 1%，iOS 端佣金 12%。
03 发货必须以服务端推送和查单结果为准。
核心判断 一个人做工具类小程序，现在可以先用个人主体接入虚拟支付，验证有没有用户愿意付费。公司可以晚一点注册，但认证、备案、类目、发货和退款规则一项也不能少。 2026 年 8 月底，微信开放文档新增了「虚拟支付：个人」页面。微信开始在符合条件的类目范围内，向个人主体小程序开放虚拟支付能力。 这次变化最直接的影响是：个人开发者做 AI 工具、图片处理、文件转换、效率工具等小程序时，可以先用个人身份跑通收费，不必为了验证一个小需求，先去注册公司、申请普通商户号。 微信开放文档「虚拟支付：个人」页面截图 不过，标题里的「不用注册公司」有明确边界。开放的是个人主体小程序的虚拟支付，适用于虚拟商品和数字服务。它不等于完整的普通微信支付商户能力，也不代表所有个人小程序都能收费。 01 SCOPE · 开放边界 这次到底开放了什么 微信官方给个人开发者开了一条更短的商业化路径：注册个人主体小程序，完成认证和备案，在工具类目下申请虚拟支付，然后通过道具直购卖数字权益。 常见场景包括：AI 生成次数、图片或文件处理额度、会员高级功能、工具内的数字内容，以及付费解锁某项能力。 个人主体虚拟支付的准入条件 开通需要同时满足四个条件： 小程序主体为个人，开发者持有居民身份证； 小程序服务类目包含「工具」； 已完成小程序认证和备案； 接受个人主体小程序全终端月支付限额 10 万元。 官方还特别写明，不支持需办理电信业务相关资质的服务，例如电子邮件、语音信箱、储存转发、信息发布平台、信息搜索查询等。具体商品能否上架，仍以小程序后台和审核结果为准。 虚拟支付的适用范围和边界 这条能力适合卖虚拟商品和数字服务。实物商品仍走对应的普通支付链路；涉及特殊许可、资质或不在工具类目内的业务，也不能靠虚拟支付绕过去。 还有一个容易忽略的点：10 万元是月支付限额，不是免税额度。收到经营收入后，仍要按实际情况处理申报和纳税问题；拿不准时，直接咨询当地税务机关。 02 COST · 两端规则 费率、结算和退款先算清 个人开发者最需要提前算的是两端成本。按微信官方个人虚拟支付页面在 2026 年 9 月 3 日展示的规则： 不同终端的费率、结算与退款差异 Android 等终端收取 1% 的腾讯技术服务费，资金按 T＋3 结算。开发者可以在小程序后台操作退款，也可以调用 refund_order 接口。支付时间在 180 天以内的退款，平台退还手续费；超过 180 天，手续费不退。 iOS 端走 Apple IAP，佣金为 12%，结算周期约 45～60 天。iOS 退款由用户向 App Store 申请，开发者不能主动发起。准备做 iOS 付费时，还要先在后台配置小程序简称，再开通苹果 IAP 支付。 如果用户主要来自 iPhone，12% 的佣金和更长账期会直接影响定价。先按真实用户结构算一遍，再决定卖单次、次数包还是会员。 03 SETUP · 后台开通 第一步：在后台开通虚拟支付 个人主体虚拟支付后台开通流程 登录微信公众平台，进入对应小程序后台： 支付与交易 → 虚拟支付 → 开通 接着按顺序完成下面几件事： 阅读并同意《微信小程序虚拟支付功能开启及使用须知》； 填写个人身份信息、提现账户和支付管理员； 提交审核。官方文档写的是一般 5 分钟内出结果，实际时间以页面显示为准； 审核通过后刷新页面，由管理员扫码签约； 进入「道具管理」，创建要卖的商品，填写道具 ID 和价格并发布； 如果要支持 iOS，在基础配置中设置小程序简称，并开通苹果 IAP 支付。 开通完成后，先记下三个参数： AppID：小程序的身份标识，在小程序后台「设置」中查看； OfferID：虚拟支付账号，在「虚拟支付 → 基本配置」中查看； 现网 AppKey：支付密钥，也在「虚拟支付 → 基本配置」中查看。 AppKey 必须只保存在服务端。不要写进小程序代码，不要提交到公开仓库，也不要打印到线上日志。 04 TUTORIAL · 技术接入 第二步：把支付接进现有业务 一条安全的支付链路分为六步： 个人虚拟支付的前后端接入链路 用户点击购买，小程序前端向自己的服务端发起下单请求； 服务端生成唯一的 outTradeNo，保存待支付订单，生成并签名 payData； 前端调用 wx.requestVirtualPayment 拉起支付； 支付成功后，微信平台向服务端推送 xpay_goods_deliver_notify； 服务端验签，以平台单号 wx_order_id 做幂等，再给用户发放权益； 前端查询自己的业务订单，确认权益到账后展示购买成功。 平台推送可能丢失，所以服务端还要定时调用 query_order 查单补发。前端 success 回调也可能因为用户异常退出而丢失，它只适合触发查询和更新页面，不能作为唯一发货依据。 前端：先检查接口，再拉起支付 wx.requestVirtualPayment 从基础库 2.19.2 开始支持。低版本要通过 wx.canIUse('requestVirtualPayment') 再判断一次。个人虚拟支付的 iOS 支付还要求微信客户端 8.0.68 及以上。 下面是一段可以直接改造的前端骨架： compareVersion 可以直接使用微信官方 API 文档里的版本比较函数。线上还要把错误码转成用户能看懂的提示，例如取消支付、客户端不支持、道具未发布、订单号重复等。 服务端：生成 payData 和两套签名 前端需要的 payData 由服务端生成，核心字段如下： signData：支付参数组成的 JSON 字符串； mode：道具直购固定填 short_series_goods； paySig：用现网 AppKey 生成的支付签名； signature：用当前用户 sessionKey 生成的用户态签名。 signData 内需要包含 offerId、购买数量、道具 ID、价格、订单号和透传数据。金额单位是「分」，正式环境的 env 固定为 0，币种固定为 CNY。 下面是 Node.js 的签名骨架： 这里有三个不能省的检查： outTradeNo 每次下单重新生成，长度 8～32 位，不能以下划线开头； goodsPrice 必须与后台已发布道具的价格一致； 用来计算签名的原始字符串，必须和真正发出的字符串完全一致，不能在签名后重新格式化 JSON 或改变键顺序。 sessionKey 通过服务端调用 auth.code2Session 获得。它和 AppKey 一样，只留在服务端。 服务端：收到推送后再发权益 在小程序后台进入： 虚拟支付 → 基本配置 → 基础配置 → 发货推送配置 填写服务端回调 URL。支付完成后，平台会推送 XML，事件类型固定为 xpay_goods_deliver_notify。服务端至少要读取这些字段： OpenId：给谁发货； OutTradeNo：自己的业务订单号； WeChatPayInfo.MchOrderNo：平台单号，也就是 wx_order_id； GoodsInfo.ProductId：购买的道具； GoodsInfo.Quantity：购买数量。 处理顺序固定为：验签，查订单，检查幂等，发放权益，更新订单状态，最后返回成功 XML。 幂等键优先使用 wx_order_id。同一笔订单即使收到多次推送，也只能发一次权益。建议把「订单状态更新」和「权益发放」放进同一事务，或者使用唯一键和可靠消息，防止只改了一半。 服务端：用 query_order 做补发 准备一个定时任务，扫描长时间停留在「待支付」状态的订单，每 5 分钟查一次支付状态。请求核心字段如下： 查到已支付后，仍然走同一套幂等发货逻辑。这样回调偶发丢失时，用户也能自动拿到权益。 05 CHECK · 真单验收 第三步：用一笔小额真单验收 代码能编译，只说明接口接上了。支付、推送、发货、补单、退款和对账至少各走一遍，才能上线。 个人虚拟支付上线前检查清单 重点检查这几项： 个人主体、工具类目、认证和备案全部满足； AppID、OfferID、现网 AppKey 使用正确，密钥没有进入前端； 道具已发布，价格单位按「分」处理； 每次下单都生成新的 outTradeNo； 发货推送能够访问，验签逻辑已通过； 同一 wx_order_id 重复推送时，只发一次权益； query_order 查单补发任务已启用； 小额真单完成「支付 → 推送 → 发货 → 后台账单核对」； Android 退款和 iOS 退款路径都已向客服写清； 页面已向用户说明商品内容、价格、退款规则和交付结果。 ∞ SUMMARY · 起步建议 写在最后 这次开放最适合验证一个足够具体的小工具。先解决一个高频问题，做出免费额度和付费道具，再观察有没有真实用户付钱。 个人主体月限额 10 万元，足够覆盖多数产品的早期验证。当收入和订单逐步稳定，再考虑升级个体工商户或公司主体，把税务、合同、客服和团队协作补齐。 公司可以晚一点注册，商业系统不能省。订单、会员、权益、幂等、退款、对账和风控最好在第一笔真单前搭好。收钱入口变简单之后，决定产品能不能继续的，还是需求和交付。
