B2B 做不了订阅：purchase-option 之墙（以及墙上那扇 API 门）
Shopify 官方 B2B 文档一句话写明：B2B 不支持 purchase options——订阅、预售、先试后买。而社区里脱口而出的标准答案「用 draft order 绕」，打开 Admin GraphQL 参考文档就塌了：DraftOrder 和 DraftOrderLineItem 上根本没有 selling-plan 字段。本文是这堵墙的地图，以及真正能把 B2B 周期性收入跑起来的三道门。
TL;DR： B2B 不支持 purchase options——订阅包含在内。这是官方文档写明的平台限制，不是 bug，也不是没装对应用。社区最常用的绕行建议「用 draft order 卖订阅」在 API 层面不成立：Admin GraphQL API（latest stable 2026-07）里 DraftOrder 和 DraftOrderLineItem 都没有任何 selling-plan 字段。真正可行的路有三条：门一——让 company contact 关联的 retail customer 记录走 D2C checkout 买订阅；门二——不经 checkout，用 subscriptionContractCreate → subscriptionDraftCommit → subscriptionBillingAttemptCreate 直接建合约；门三——用 B2B 原生积木（draft order + paymentTerms + 发票收款）加自己的自动化模拟周期性。
本文是《Shopify B2B 生产实战》系列第 1 篇——系列开篇。需求证据来自一个进行中的社区线程：一个纯 B2B 商家（约 20 万 SKU，完全没有 D2C 业务）想把设备维护套装卖成按季度自动扣款的订阅，而整个帖子能给出的答案只有「每个月手工建一张 draft order」。
问题
放在普通 Shopify 店铺上，订阅是已解决的问题：装一个订阅应用，给产品挂上 selling plan group，收工。放到 B2B 上，这个功能直接不存在——订阅应用不会出现在 B2B 的采购流程里。Shopify Community 线程 657803 里那位商家，最后只拿到手工 draft order 的笨办法，以及一个他自己也很清醒的担忧：B2B 应用和订阅应用本来就不是为彼此设计的，硬叠两个应用只会更糟。
这不是商家不会用后台。这是官方文档里写明的平台边界。
根因：一句话砌成的墙
Shopify 官方 B2B 开发文档，Limitations 一节：
“B2B doesn’t support purchase options, such as subscriptions, pre-orders, and try before you buy.”（B2B 不支持 purchase options，例如订阅、预售、先试后买。）
purchase options 是个总称，订阅是通过 selling plan 实现的：SellingPlan 定义一个产品如何以周期性扣款的方式出售和购买——何时扣款、何时履约、价格如何调整——SellingPlanGroup 再把这些计划挂到产品和 variant 上。B2B 不支持 purchase options，意味着 B2B checkout 里没有 selling plan，于是 SubscriptionContract——那个定义客户周期性购买、跟踪扣款尝试、付款状态并生成订单的对象——根本没有机会被创建。
为什么「用 draft order 绕」在 API 层面不成立
draft order 是 B2B 的标准工具：API 可以为 company contact 创建草稿单供其审核确认，可以挂 paymentTerms，可以发 invoiceUrl 收款。所以社区的第一反应是「用 draft order 卖订阅」。
打开 Admin GraphQL 参考文档，把 DraftOrder 和 DraftOrderLineItem 的字段清单（latest stable 为 2026-07）从头读到尾：没有任何 selling-plan 字段——草稿单上没有，行项目上也没有。你无法把 selling plan 塞进 draft order，draft order 因此也生不出订阅合约。墙的这一面，一条缝都没有。
最小复现
确认这堵墙不需要 Plus 沙盒，只需要 schema。对任意店铺的 Admin GraphQL API 跑一条内省查询：
{
draftLineItem: __type(name: "DraftOrderLineItem") {
fields { name }
}
draftOrder: __type(name: "DraftOrder") {
fields { name }
}
}在结果里搜 sellingPlan：两个类型都是零命中，与公开的对象参考文档一致。你在 DraftOrder 上能找到的是 B2B 原生字段：paymentTerms、purchasingEntity、invoiceUrl，以及感知定金的金额字段（amountDueNowSet / amountDueLaterSet——有 payment terms 时，“due now” 是定金，“due later” 是余款）。
两次检查，五分钟，墙的存在完全由一手资料确认。
门一：D2C 通道（不需要装应用）
B2B 的对象模型自带一个逃生口：company contact 关联着一条 retail customer 记录。这条客户记录可以走普通的在线商店 checkout 下单，而那边是支持 purchase options 的。于是订阅由联系人的 customer 账号在 D2C 通道购买，其余业务关系维持 B2B 不变。
代价是真实的：这笔订阅订单不享受 B2B catalog 定价、不继承 payment terms、不计入 company 级报表。对纯 B2B 商家来说这是一条折中通道，不是原生能力——这正是帖子里告诉那位商家的结论，他也确认这符合他的预期。
门二：API 之门——不经 checkout 直接建合约
几乎没人提到的部分在这里：订阅合约并非只能诞生于 checkout。Admin GraphQL API 提供 subscriptionContractCreate，参考文档的原文是「创建一个订阅合约草稿，即创建新订阅的意向」。你提供客户、客户支付方式和 billing/delivery policy，然后用 subscriptionDraftCommit 定稿。全程不经过店面：
# 改写自官方 mutation 示例（API 版本 2026-07）
mutation createSubscriptionContract($input: SubscriptionContractCreateInput!) {
subscriptionContractCreate(input: $input) {
draft { id }
userErrors { field message }
}
}{
"input": {
"customerId": "gid://shopify/Customer/544365967",
"currencyCode": "USD",
"nextBillingDate": "2026-09-01T09:00:00Z",
"contract": {
"status": "ACTIVE",
"paymentMethodId": "gid://shopify/CustomerPaymentMethod/b7cc6e3267aace169e516ed48be72dff",
"billingPolicy": { "minCycles": 3, "maxCycles": 12, "intervalCount": 1, "interval": "MONTH" },
"deliveryPolicy": { "intervalCount": 1, "interval": "MONTH" }
}
}
}草稿 commit 之后，合约就存在了。扣款走 subscriptionBillingAttemptCreate：对当前（或指定的）billing cycle 扣款，成功时自动创建 Order；失败的尝试会带 processingError 字段；idempotencyKey 参数专门为防止重试导致重复扣款而设。
小字部分，全部可在参考文档核验：
- 这两个 mutation 都要求
write_own_subscription_contracts访问范围，操作用户还需manage_orders_information权限。 - 合约的
customerPaymentMethod必须已经存在——把卡 vault 进来是另一个问题，API 不替你解决。 - 合约属于客户，不属于 company。B2B 定价、条款、报表依然不适用。
- selling plan 及其关联记录在商家卸载创建它们的应用 48 小时后会被自动删除——如果你基于这套机制做开发，记得备份这些记录。
门三：用 B2B 原生积木模拟「周期性」
如果「真订阅」做不到，但业务真正要的只是「按周期收钱」，原生积木就是带 paymentTerms 的 draft order：amountDueNowSet/amountDueLaterSet 的定金语义、invoiceUrl 收款、purchasingEntity 关联公司。周期性的草稿单由你自己的自动化按日程生成，代替 billing policy 的角色。
同一线程里有一位社区贡献者给出了一种具体组装方式——为 B2B 客户 vault 一张卡，再用 Shopify Flow 的付款计划到期触发器配合「扣 vaulted 卡」的动作自动收款。我们把这套具体组装标注为 field report：它来自帖子里的一线从业者陈述，不是我们逐行在商家文档里复核过的内容，所以具体的触发器/动作名称请以你自己后台里的为准。
检查清单
- 承认墙的存在：B2B 不支持 purchase options（订阅、预售、先试后买）——这是文档写明的限制，不是 bug。
- 别再尝试把 selling plan 挂到 draft order 上：Admin GraphQL API 里
DraftOrder和DraftOrderLineItem都没有 selling-plan 字段。 - 先想清楚业务要的到底是什么：合约语义（门二），还是只要周期性收款（门三 / 门一）。
- 门一：让联系人的 retail customer 记录走 D2C checkout 买订阅；书面记录「B2B 定价/条款/报表不适用」。
- 门二：
subscriptionContractCreate→subscriptionDraftCommit→subscriptionBillingAttemptCreate；确认write_own_subscription_contracts范围 +manage_orders_information权限；先解决卡片 vault；针对「卸载应用 48 小时删除」规则备份 selling-plan 数据。 - 门三：用 draft order +
paymentTerms+ invoice 收款建模周期性；社区流传的 Flow 配方按 field report 对待，在自己后台核实。 - 无论走哪条门：在 B2B 之外创建的订阅订单不会出现在 company 级 B2B 报表里——提前向干系人书面说明。
Agent 能接手哪一段
选哪道门是一次性的架构决策。真正日复一日的是「周期性」本身：门三的按日程生成草稿单，门二的盯着 billing attempt 有没有 processingError，以及维护「哪些客户在哪种安排上」的台账。这是一个定时运营闭环——正是店铺运营 Agent 可以守的那类活：按日程生成、逐条核验、把异常连同证据一起交给人。
本文所有平台能力断言均于 2026 年 8 月对照 Shopify 官方文档核验（B2B 构建指南，SellingPlan / SubscriptionContract / SubscriptionDraft 对象参考，subscriptionContractCreate / subscriptionDraftCommit / subscriptionBillingAttemptCreate mutation 参考，Admin GraphQL latest stable 2026-07）。基于 Flow 的 vaulted 卡组装方式是社区 field report（Shopify Community 线程 657803），出现处均已标注。