搜索入口与读者问题
Shopify 套餐与账单设置：选套餐、审 App 费用、留好发票
先把套餐、试用、Billing profile、App 费用和发票放进同一张决策表，再决定是否升级或安装工具。官方页面用于确认产品入口和规则，不能替代当前店铺的费用、税费、付款责任、第三方订阅或未来扣款回读。
新店怎样按真实需求选最低够用的 Shopify 套餐？
试用结束前，谁要确认会不会转为收费？
Billing profile 的主体、税务资料和品牌名不一致时先核对什么？
Shopify 发票周期、App 周期和银行扣款日怎样分开记录？
App 推荐、可安装和费用审批之间有什么区别？
卸载 App 后下一张账单还有费用，怎样判断是已产生费用还是新续费？
开发者直接收款的订阅为什么要单独取消和留证？
每月复核账单时，哪些字段要留下才能让财务回查？
官方来源与复核边界
这些页面用于确认 Billing、账单资料、发票和第三方 App 费用的官方入口；它们不能证明当前店铺的实际套餐、扣款、税务、退款、外部订阅或会计处理已经完成。保留脱敏的账单字段和复核记录，不公开完整发票、付款信息或账号细节。
第一阶段 · 账户与基础资料
套餐与 Billing：先看费用边界，再开始装 App
查看当前套餐和试用状态，按业务条件选择计划，完成 Billing profile，拆解账单，并为 App 建立费用和权限审批门。
做到什么程度才算完成
沿着 Settings > Plan and Settings > Billing 找到正确页面，再完成设置、保存、验证和记录。完成不是看过页面，而是能指出保存状态、验证结果和继续条件。
- 后台路径
- Settings > Plan and Settings > Billing
- 产出
- 一份套餐与账单决策表，包含当前 Plan、试用、Billing profile、费用拆分、App 审批卡、发票归档和月度复核。
- 可以继续
- 套餐满足首发条件，账单主体正确，费用可拆分，App 有审批门，发票和复核责任清楚。
- 必须暂停
- 如果试用/费用无法解释、Billing profile 不一致或 App 没有任务和预算，先暂停扩展。
证据边界：Plan 页面或 App 安装按钮不证明长期成本、账单主体、权限、用量费或下个月扣费结果；要按账单和业务条件回读。
为什么现在先做这一步
套餐和 App 是持续成本，不是一次性设置。试用会结束、用量会变化、权限会扩大，账单主体和发票还要能让财务回查；先建立费用边界，后面才不会被“推荐功能”牵着走。
开始前准备
- 列出首发订单、员工、Location、Markets 和报告需求。
- 准备 Billing profile 主体和账单联系人。
- 列出当前 App、试用结束和固定/用量费用。
跟着英文后台一步一步做
每做完一步就刷新页面或从前台验证一次。后台显示已保存，不代表客户看到的结果一定正确。
查看当前 Plan 与试用状态
进入 Settings > Plan，记录当前套餐、试用结束时间、包含能力、限制和升级/降级影响。不要因为按钮可见就认为功能和成本都适合。
做完后应该看到或拿到：得到套餐、试用、限制、月度成本和下一次决策日期。
怎样算完成：团队能解释为什么当前套餐支持首发，不把试用状态误当长期成本。
如果结果不对或入口没出现：计划名称或试用状态不清时，确认当前店铺和 billing 权限，回到完整 Plan 区域，不要用 App 页面猜套餐。
留下证据：记录套餐、试用结束、限制、价格摘要和负责人，不公开账单或付款数据。
固定选择套餐的业务条件
把订单量、员工账号、Locations、Markets、报告、结账和 App 依赖写成可复核条件。套餐选择不能只看“有没有功能”，还要看收入、毛利、操作复杂度和退出成本。
做完后应该看到或拿到：得到套餐选择门槛、成本上限、升级触发和降级后果。
怎样算完成：套餐决定能回到真实业务条件和 owner，而不是凭偏好。
如果结果不对或入口没出现：团队只因“以后可能用到”而升级时，先把能力写成触发条件并验证当前套餐替代方案。
留下证据：保存条件表、月度成本、触发阈值和复核日期。
完成 Billing profile
核对 Billing profile 的法定主体、地址、税务信息和账单联系人。品牌名和法定主体可以不同，但账单和主体对应必须清楚；公开记录只保留脱敏状态。
做完后应该看到或拿到：得到账单主体、地址、税务和联系人对应表。
怎样算完成：发票、套餐、App 费用和支付责任都能落到正确主体。
如果结果不对或入口没出现：账单资料保存后有误，先确认权限、主体和税务字段，再修正并保留版本，不要公开真实资料。
留下证据：记录脱敏字段、发票抬头、税务状态、联系人和时间。
看懂账单明细和时间
在 Billing 明细里逐项区分 Shopify 套餐费、应用周期费、用量费、交易费、税费和 credits。应用可能有独立的计费周期，不与 Shopify 发票日期重合；开发者直接收取的外部订阅也可能不出现在 Shopify 账单中。为每项费用写明收款方、计费依据和复核日期，不能只记一个总额。
做完后应该看到或拿到：得到按来源、周期、币种和责任人的账单拆分。
怎样算完成：账单可以与发票、App、订单和财务报表对上，异常有处理人。
如果结果不对或入口没出现：账单金额异常时，按周期和来源拆分，核对试用转付费、用量和 credits，不要直接删除 App 或改套餐。
留下证据：保存脱敏发票、账单周期、费用分类、异常和复核时间。
为 App 建立审批门
安装前写清用途、成功指标、权限、周期费或用量费、试用结束日、负责人和退出条件。关闭 App embed 或不再使用功能，不等于取消订阅。对通过 Shopify 计费的应用，按适用流程取消并卸载，检查实际账单状态；开发者直接计费的订阅要另外向开发者取消。不要等到试用结束后才确认由谁处理。
做完后应该看到或拿到：得到一张 App 费用和权限审批卡。
怎样算完成：每个保留应用都有明确任务和审批记录；决定退出的应用保留卸载确认及适用的外部取消凭证，已产生费用另列，不因组件消失就标记费用结清。
如果结果不对或入口没出现：费用或权限无法解释时保持未安装/暂停，先让 owner 补齐信息，不要先装后问。
留下证据：记录 App 名称、费用类型、试用、权限摘要、owner 和 review date，不记录 secret。
失败处理：试用将结束但没有达到成功指标时，负责人应在截止前完成取消或卸载并核对计费方。已经产生的费用可能仍进下一张账单；先对照周期和时间，有争议再向开发者申请核对或退款，不能承诺自动免除。
下载发票并安排每月复核
下载并逐项检查发票，核对主体、费用类别、币种、期间、支付结果和 credits。应用卸载后仍出现费用时，先看它属于卸载前已经开始的周期，还是新的续费；外部账单单独核对。设定下一次复核时间和负责人，保留开发者的实际回复，不把退款申请当成已到账。
做完后应该看到或拿到：得到发票归档、每月检查表、异常处理和下次复核日。
怎样算完成：财务能回查费用来源，业务能在下次扣费前决定保留、降级或取消。
如果结果不对或入口没出现：发票、App 和付款记录对不上时，先冻结非必要扩展并逐项对账，不要用信用卡总额判断。
留下证据：记录发票归档路径、复核人、异常、动作和复核日期，不公开完整账务。
现在把判断用到你的店铺
先记录当前 Plan、试用结束和月度成本，再给每个 App 写任务、权限、固定费/用量费、成功指标和退出条件。下载发票，安排每月在扣费前复核。
这一步先给出后台位置，再用一个实际情境检查你是否能做出决定。
把这一步用到你的店铺
完成后应得到：一张月度技术成本表，包含 Shopify 套餐、域名、邮箱、主题、必要 App、可选 App、按用量费用、账单负责人和取消日期。
相关后台路径：Settings > Plan and Settings > Billing
先做判断，再对照原因
这不是记忆题。先选出能解决问题的动作，再看解释。
在店铺里逐项确认
按当前店铺的实际值逐项确认；这份清单不会替你保存设置或执行测试。
这一步还不能说明：Billing 页面能显示当前或历史收费，不证明未来按用量费用、汇率、税费或第三方账单已经封顶
继续条件：套餐选择有业务依据，Billing profile 正确，所有试用和 App 费用都有负责人、结束日和月度复核
暂停条件：如果付款资料不属于经营主体，或未知 App 正在扣费，先定位费用和权限，不要继续安装工具
下一步：下一步连接域名和发件邮箱，分别验证访问路径与邮件身份。
先补齐判断或核对项。没有足够信息时，保持暂停比猜一个通过更安全。
为什么卸载后账单里仍有费用
下面是按每个应用周期 20 美元计算的假设案例，不是某个应用的报价。先分清已产生的本期费用与未来续费，不能把卸载日当成整张发票的截止日；卸载也不表示自动退款。真实处理仍以费用批准记录、周期和开发者回复为准。
| 看到的情况 | 先核对什么 | 可以得出什么结论 |
|---|---|---|
| 每周期 20 美元的应用，进入新周期两天后卸载，下一张账单仍有 20 美元。 | 对照该应用自己的周期起点、已产生费用的时间和卸载确认，不只看 Shopify 发票日期。 | 这可能是卸载前已产生的 20 美元，不证明又续了下一个周期。确认后续周期停止，争议费用另向开发者核对。 |
| 主题里关闭了 App embed，但应用仍安装着。 | 检查订阅状态和计费入口，而不是用前台组件是否消失判断。 | 停用展示不等于取消订阅。完成适用的取消或卸载流程，再保留确认记录。 |
| Shopify 里已卸载，但开发者另行收款的账户仍显示续费。 | 到开发者的计费账户确认订阅和取消凭证，分别记录 Shopify 与外部状态。 | 外部订阅需要向开发者直接取消。请求退款不代表退款已获批或已到账。 |
当前设置需要确认的决定
按行填写当前店铺的实际值，不要把示例或计划值当成完成。实际值符合条件并有保存或测试证据，才可以标记通过。
| 项目 | 推荐设置 | 为什么 |
|---|---|---|
| 当前 Plan | 满足首发条件 | 不为假设需求提前付费 |
| 升级触发 | 订单/员工/市场等阈值 | 用业务条件而非偏好决定 |
| App 审批 | 任务、权限、费用、owner | 控制固定费和数据风险 |
| 每月复核 | 发票、App、交易费、税费 | 在扣费前发现异常 |
这些地方先不要乱动
- 不要因为功能按钮存在就升级套餐。
- 不要把 App 推荐或可安装当作审批通过。
- 不要在公开证据里展示完整发票、支付或账单资料。
常见问题
功能越多，套餐越高越好吗？
不是。按订单、员工、市场、毛利、App 和实际业务条件设触发门槛，避免为假设需求付费。
推荐的 App 可以直接安装吗？
不可以直接等同批准。先写任务、权限、费用、成功指标、owner 和卸载条件。
为什么每月还要看账单？
试用会结束、用量费会变化、App 会变更套餐或费用，月度复核才能在下一次扣费前处理。
为什么应用已经卸载，下一张账单仍可能有费用？
应用周期与 Shopify 发票周期可能不同，卸载前已产生的费用仍可出现在下一张账单。核对周期起点、费用批准时间和卸载确认，再判断是否是新续费；开发者直接收款的订阅需要另外取消。请求退款也不代表已经获批或到账。
当前结论与继续条件
Billing 验收不是看到可升级按钮，而是知道谁付费、为什么付费、何时扣费、App 是否值得、异常谁处理。继续前确认套餐条件、账单主体、费用拆分、审批卡、发票和月度复核都可回查。