Shopify 订阅迁移上线前 QA 检查清单

Shopify 订阅迁移不是简单换一个 app。它会影响重复订单如何创建、扣款、编辑、暂停、取消、履约、报表和客服处理。只要漏掉一个边界场景，问题通常会在上线后第一次真实续费时出现。

这篇文章适合准备迁移订阅系统的电商负责人、Shopify 开发者、会员运营团队和客服负责人。你可以在上线前使用一次，在第一轮扣款周期中再用一次，并在上线后 14 天做复盘。

Shopify 的订阅模型会涉及 selling plan、subscription contract、customer payment method、billing attempt、webhook 和客户管理界面。QA 时要把这些层级拆开检查，目标是保护 recurring revenue，而不只是证明新订阅可以下单。

先导出所有有效、暂停、取消、预付、赠品、付款失败和即将续费的订阅记录。每条记录都要包含客户、商品、变体、数量、周期、折扣、配送方式、税务规则、付款方式状态、下次扣款日期、源平台 ID、Shopify customer ID 和客服备注。

不要只看汇总数字。一个有 5,000 个订阅的店铺，也可能因为 40 个预付 contract 使用特殊配送规则、80 个历史折扣无法复现、或 12 个高价值客户的付款方式无法自动关联而翻车。

迁移前先确定 QA 样本。至少选 25 条真实订阅，覆盖常见状态和高风险状态，然后在导入、客户门户、扣款、分析追踪和客服复核时一直使用同一组样本。

• 按有效、暂停、取消、付款失败、预付、试用、赠品、组合商品和 VIP 客户状态拆分订阅。
• 记录源平台 ID 和 Shopify ID，让每个 QA 问题都能追溯到原始记录。
• 标记自定义折扣、自定义配送、已下架变体、人工备注和 7 天内即将续费的订阅。
• 开发前固定至少 25 条 QA 样本，并包含 5 个边界案例。

Selling plan 决定商品如何按订阅方式销售，包括配送周期、计费周期和价格策略。Shopify Dev Docs 中也把 subscribe-and-save 和 prepaid 作为常见 selling plan 类型，所以迁移 QA 需要同时证明营销规则和结账规则仍然一致。

逐一检查订阅商品、变体、市场、销售渠道和组合商品。产品页、购物车、结账页、订单确认页、客户账户和后台视图中，对订阅周期的描述应该一致。如果前台写的是 every 30 days，而导入后的 contract 是 monthly，要在上线前决定是否接受这个差异。

也要确认哪些商品不能被订阅。缺货商品、未发布变体、停产 SKU、一次性组合、礼品卡、试用装和市场限制商品，如果适用规则过宽，可能会造成续费失败。

• 测试 subscribe-and-save、prepaid、一次性购买、组合商品和只适用于特定变体的订阅展示。
• 确认价格、折扣、配送周期、计费周期和市场可售范围与源平台一致。
• 检查产品页、购物车、结账页、订单确认页、客户账户和后台文案是否一致。
• 记录必须排除订阅的商品，并确认它们不会进入新的 contract。

一次顺利的 checkout 测试是必要的，但它不能证明迁移成功。Shopify 会在订阅商品购买后生成 subscription contract，之后的续费订单会通过这些 contract 和 billing attempt 继续运行。导入或重建的 contract 需要单独 QA。

检查 contract line、数量、折扣、配送方式、配送地址、计费计划、下次扣款日期、客户关联、币种、税务规则和状态。然后测试修改流程，例如更换商品、调整数量、改变周期、添加或移除折扣、暂停、恢复、取消和重新启用。

尽量在草稿或 staging contract 中测试，不要让 QA 动作触发真实扣款或客户通知。如果必须做生产环境 dry run，每个样本 contract 都要有明确负责人和预期结果。

• 导入后逐项对比源订阅记录和 Shopify contract 字段。
• 测试有效、暂停、预付、取消、付款失败和即将续费的 contract。
• 确认地址、商品、数量、周期、折扣、暂停、恢复、取消和重新启用流程。
• 确保客服能从 Shopify contract 或迁移日志找到原始源记录。

付款方式是订阅迁移里风险最高的部分，因为团队通常不能直接查看或移动完整卡信息。Shopify 订阅工具包含 customer payment method API，新的 customer account 流程也强调让买家自行更新订阅付款方式，而不是让商家保存卡资料。

QA 要覆盖有效付款方式、过期卡、被撤销的付款方式、PayPal 或钱包类付款、缺失付款方式、付款更新邮件、客户门户更新、重试逻辑和催付消息。目标不只是扣款成功，而是客户和客服都能顺利走完恢复路径。

上线前先决定付款方式无法干净迁移时怎么处理。这个决定需要客户邮件、客服话术、标签规则和报表视图。缺少这些准备，第一轮续费就会变成大量人工排查。

• 确认已迁移的 payment method reference 能支持下一次 billing attempt。
• 测试过期、撤销、缺失、PayPal、钱包、预付和付款失败样本。
• 确认客户能通过合规的账户或门户流程更新付款方式。
• 提前准备付款更新链接、续费失败、重复扣款和订单缺失的客服话术。

重复订单会触发的不只是产品页。你需要测试 billing attempt、订单创建、履约路由、库存预留、配送费、税费、折扣、客户通知、交易邮件、仓库规则和订阅 webhook。Shopify 的订阅生命周期文档也说明，app 会处理续费排程、billing attempt、失败情况、webhook 和管理界面。

至少做三类续费模拟：一次正常续费、一次付款失败续费、一次库存或履约异常。如果店铺有组合商品、试用装、订阅赠品、预付计划或区域配送规则，就把它们拆成独立场景。

QA 输出应该包含事件顺序。例如 billing attempt 创建、交易结果记录、订单创建、库存调整、履约 app 收到订单、客户邮件发出、analytics event 触发、客服看板更新。

• 测试成功续费、付款失败、库存不足、配送异常和暂停订阅路径。
• 确认订单标签、line item property、履约服务路由、仓库规则和客户通知。
• 检查 webhook 和下游任务是否有重复订单、漏事件、延迟重试或已取消 contract。
• 上线后前 3 天和前 14 天每天复核续费结果。

即使 URL 不变，订阅迁移也可能改变前台体验。移动端和桌面端都要测试订阅选择器、购物车摘要、结账文案、账户页、客户门户链接、取消原因、暂停选项、商品推荐、邮件链接和帮助中心内容。

分析追踪也要做迁移前后对比。建议追踪订阅加购、开始结账、订阅购买、一次性购买、取消、暂停、付款更新、续费订单、续费失败和客服咨询事件。订阅和一次性购买要用独立事件名或属性，避免广告和运营报表混在一起。

SEO 方面，确认商品 URL、canonical、结构化数据、merchant listing、商品 feed 和集合页仍然准确描述商品。订阅选择器不能破坏一次性购买路径、可索引商品文案或投放渠道使用的 feed 字段。

• QA 移动端和桌面端订阅选择器、客户门户链接、账户页、邮件和取消流程。
• 追踪订阅购买、续费、取消、暂停、付款失败和付款更新事件。
• 主题改动后检查商品结构化数据、canonical、merchant feed 字段和集合页陈列。
• 如果店铺跨市场销售，要和 checkout QA、product feed QA、Shopify Markets 定价 QA 一起检查。

订阅迁移不能没有回滚标准。提前定义哪些问题数量、扣款失败率、重复订单数、客服量或续费差异会触发暂停。并为商品数据、主题问题、app 配置、付款问题、履约问题、分析追踪和客户沟通分别指定负责人。

上线前就要建好 14 天监控看板。至少监控有效订阅数、已导入 contract、跳过 contract、下次扣款日期、成功 billing attempt、失败 billing attempt、重试结果、续费订单、重复订单、取消 contract、付款更新请求、客服工单和受影响 SKU。

每天维护迁移 QA 日志，记录问题、受影响订阅 ID、客户状态、严重程度、负责人、修复方式、复测结果和客户沟通状态。这份日志会成为客服和维护交接的重要依据。

• 上线前先定回滚标准，不要在真实续费问题发生时临时争论严重程度。
• 为商品数据、contract、付款、履约、通知、分析和客服指定负责人。
• 上线后 14 天每天监控第一轮续费，再在 30 天后复盘一次。
• 把 QA 日志放进维护文档，避免未来 app 更新重复踩同样的问题。