摘要

  • Shopify 当前说明明确：Pause and Build 不再接受新订阅，已经使用的店铺可以继续保留。
  • 用密码限制网上店铺访问，订阅及其他经常性费用仍会继续；停用店铺也不能替店主取消所有外部合同。
  • 卸载应用可以停止后续相应收费，却可能留下待付账单，并带走重新开店时需要的设置和数据。

行李装好了，店还没有收拾完

设想一位卖陶器的店主。最后一个包裹已经封箱，旅行箱靠着打包桌。她想做的事情很简单：休息几周，不接新订单，回来继续卖杯子。

这是一间虚构的小店。真正的 Shopify 帮助文件，却给这种朴素愿望安排了好几份作业。有人负责挡住新顾客，有人负责订阅账单，有人保管应用数据，旧订单还会沿着自己的时间表找回来。店主只有一个假期，这些安排没有共同的休假表。

她若先去找一个叫“暂停”的便宜位置，会碰上第一处转折。Shopify 当前的 Pause and Build 说明写明，该方案已经不向新订阅开放，其他套餐也不能切换过去；原本就在这个方案里的店铺可以继续使用。计费说明页重复了这个区别。

所以，“朋友以前就是这么休假的”已经不足以安排今天的店铺。需要先看自己的账户究竟坐在哪张椅子上。现有暂停用户与打算第一次暂停的商家，拿到的是两份不同的菜单。

还有暂停资格的人，也没有一张总暂停键

已经使用 Pause and Build 的店铺，可以在较低费用下保留管理后台，编辑商品，查看基础报告。顾客可以看商品，但不能结账；停掉的是所有销售渠道的结账，包括 POS。即使发出草稿订单发票，也不能靠它在结账页面或后台把订单完成。

这个安排把店面保留在“可以整理，暂不营业”的状态。对正在调整产品、等下一季再开门的商家，它很具体：柜子还在，钥匙还在，收银台不收钱。

应用却不会跟着一起暂停。官方说明要求店主逐个处理不再需要的应用订阅。一个帮助发营销邮件的应用，或为店铺增加功能的服务，不会因为主店暂时不接单就自动理解店主的预算。

重新营业也需要选择一个新套餐，原来的套餐不再有效。因此，保留暂停方案有价值，但价值来自当前这家店能保留的经营状态，不能把它想成一张能随时退出、再按原条件回来的通票。

对没有暂停资格的新申请者，这整套便利已经不是可选项。官方休假指引给短假与长假提出了另外两条路。

密码挡住顾客，挡不住续费

Shopify 没有专门的休假设置。短期离开，可以给网上店铺加上私人密码。没有密码的访客无法进入相关商品和页面，也不能从这个网上店铺下单。

这很适合那位不想在火车上处理新订单的店主。她能解释何时回来，保留店铺，省去拆装的麻烦。但订阅费和其他经常性费用继续发生。密码是一道门禁，收费合同没有被锁在门外。

范围也要看准：这里控制的是网上店铺访问，不能顺手推断其他销售渠道和应用都停了。店主的愿望是“别再给我工作”，软件执行的却是某一个具体设置。

于是短假里有一笔经常被忽略的购买：店主付钱保留的是回来后比较容易接着营业的状态。没有新销售收入时，这笔支出看起来格外刺眼；可若一周后就要重新包装、发货，它也可能比重新搭起一串服务省事。

真正的比较应当是留下这些东西需要多少钱，拆掉再接起来需要多少工作。只盯着假期内的零订单，会把第二笔账漏掉。

一张 Shopify 账单，几只应用时钟

应用收费最容易把人绕进去的地方，是它看起来集中，实际各过各的日子。Shopify 计费的应用有独立的三十天周期，使用量费用还可能横跨两张 Shopify 账单。所有数字出现在同一个账单入口，不代表所有服务都在同一天重新起算。

卸载应用可以阻止之后的相应经常性收费周期，但已经生成的待付费用仍然可能到来。店主在出发前删除了一个应用，休假期间看见它的费用，并不能只凭出现时间判断那是卸载后的新服务。要追到生成费用的那个周期。

如果开发者同意调整，未支付费用可以通过额度抵扣处理，已经支付的费用则涉及退款；应用退款由开发者决定，Shopify 并不控制。总账入口的便利，到这里没有变成统一的退款权。

外部计费又是另一回事。直接向开发者或其他服务商付款的应用，可能根本不在 Shopify 账单里。卸载它，不会替店主终止那份外部付款安排。反过来，只在应用里取消订阅，也不等于把应用从店铺卸载；要停止 Shopify 计费的相应后续收费，还需要完成卸载。

这让“清理应用”成为一项比点击垃圾桶更细的工作：这笔钱付给谁，已经承诺到哪一天，取消动作在哪一边才算完成。店主原本只是想去看海，最后先研究了一遍供应商组织结构。

少一笔续费，可能多一个重装任务

假期前最有诱惑的方案，是把暂时不用的应用都卸掉。屏幕立即干净，后续支出也可以减少。可软件留下的空位不会保证原样等人回来。

Shopify 的卸载说明提醒，依赖应用的自动化、集成和功能会停止；部分应用数据在卸载后可能无法恢复。重新安装，未必能找回原来的设置和数据。有些应用写进主题的代码则可能继续留着，需要另行处理。

这是一种很别扭的拆装：该走的代码可能没走，想留下的设置却可能回不来。对小店而言，重建工作通常不会自动分配给一个专门团队。回来以后，还是同一个人，一边打包杯子，一边找之前的配置。

因此，某个应用是否值得保留，要看它保存了什么、导出能保住什么，以及重建要付出什么。没有实际用途的订阅当然可以停止。把所有应用一视同仁地留下，会把方便养成固定成本；一口气全拆，也可能把节省的费用换成返工。

长假可以停店，旧生意还会敲门

对于更长的离开，当前休假指引提出停用店铺。符合条件的店主可以取消套餐，店铺在当前计费周期结束时停用；Shopify Plus 走自己的支持或客户成功团队流程。

取消时，应用会自动卸载，待付的应用使用费、交易费或运单费用等会被结算。当前周期内继续发生的活动仍可能带来费用。点下取消与周期真正结束，是两个不同的时间点。

店铺停用之后，外部应用和域名合同也不会自动消失。域名续费需要单独查看，外部注册商的安排还得在对方那里处理。为了一次旅行匆忙丢掉仍需要的域名，显然比支付一笔本来想省的账单更难收拾。

旧客户也没有跟着店主进入暂停状态。礼品卡、预售订单和订阅订单等已有承诺，需要安排。Shopify Payments 的待付结算仍按原有银行账户和计划继续；如果出现失败或负结算问题，需要重新启用后台处理。

拒付同样可能来自关店前的交易。计费周期结束后，店主失去后台访问，若要提交相关证据，需要重新启用店铺。不过历史 Shopify 账单可以在不重新启用的情况下查看。把这些不同入口一概说成“所有记录都被锁了”，会误判真正需要准备的工作。

保留两年的，是店铺信息

Shopify 说明会保留店铺信息两年，便于重新启用；提前要求删除客户数据，则可能让恢复和重新开店变得不可行。这个保存期给回头留了空间。

它没有把每个已经卸载的应用、每一项外部设置都装进保险箱。店铺记录还在，与应用愿意保存并恢复什么，是两种承诺。等回来时才发现两者不同，假期后的第一天就容易变成维修日。

恢复时间也影响账单。如果在已经支付的周期结束前撤回取消并重新启用，原有月度或年度周期可以继续，不另收一笔重新启用费用。已经真正停用后再回来，需要选择套餐，并处理应付余额。不能把前一种情况的便利延伸到所有回归。

要替这家虚构小店算出最省的路径，还缺它实际的套餐资格、已付周期结束日、应用与外部合同、数据恢复需求和未完成客户承诺；这些记录会改变选择。

但主张已经足够清楚：别把“店主不在”当成软件会自动懂得的经营指令。休假的成本，藏在为了回来继续开门而保留的东西里，也藏在为了停付而拆掉的东西里。旅行箱可以一次合上，网店不行。

官方原始资料