订阅请求里的 scheduledAmounts 是什么意思？
scheduledAmounts 是 productInfo 内的一个可选列表，允许你在特定账单周期收取不同金额，而不是每期都收相同的 amount。每个条目恰好有两个字段：
amount，列出的周期不必连续——只列第 1 期和第 5 期也是合法的。
你可以在创建订阅时设置 scheduledAmounts，之后用 /api/v1/subscription/update 修改。
period 是从第一期算起，还是从试用期后的第一期算起？
从订阅的第一期算起。period 是覆盖每个账单周期的绝对、从 1 开始的索引，试用期也计入其中。
存在试用期时这一点很重要：如果你配置了 2 期试用，那么 period: 1 和 period: 2 指向的是两个试用周期，第一个正价周期是 period: 3。
任何地方都不应用偏移：Waffo 查出即将创建的扣款所在的周期号，并用这个确切的数字去读
scheduledAmounts。要查看生效中订阅当前所在位置，从 /api/v1/subscription/inquiry 读取 productInfo.currentPeriod——存储的计划以 productInfo.scheduledAmounts 在同一响应中返回，所以你在发送更新之前总能确认哪些周期号仍在未来。
Waffo 如何决定每期的金额？
按以下顺序查阅三个输入；最后匹配的规则胜出：
所以
scheduledAmounts 条目会覆盖该周期的试用金额。如果你希望试用期按 trialPeriodAmount 计费，不要在 scheduledAmounts 中列出试用周期号。
当某次扣款与你的预期不符时，这是首先要检查的：算出该扣款的周期号，然后按顺序走一遍这三条规则。
scheduledAmounts 的确切限制是什么？
两个值得指出的细节，因为常被反向假设：
- 金额是币种常规单位的十进制字符串，不是最小单位。是
"9.90"，不是"990"。多余的小数位会被拒绝，不会被舍入。 amount: "0"能通过字段校验，所以免费周期是可表达的——但该值仍须满足你协议上的最小金额，因此 0 是否被接受取决于你的合约。
我能直接上调下一期的订阅金额吗？
**不能——不能通过/api/v1/subscription/update。**默认情况下该接口拒绝任何上调。这在三个金额字段上都强制执行：
按周期的基线是当前存储的同一周期的排程金额，若该周期不在存储的计划中则是订阅的
amount。这堵住了显而易见的漏洞：你不能先把某期调低，再在第二次调用中调回去，因为第二次调用是与你刚写入的值比较的。
违规以参数错误返回，消息指出被拒绝的内容（amount is not allowed to increase、trialPeriodAmount is not allowed to increase，或 scheduledAmounts.amount is not allowed to increase for period N）。
要收更多，要么用 /api/v1/subscription/change 把用户迁到新套餐，要么——当上调属于席位加购时——在更新中带上 topupInfo 块：该路径立即收取当期差额，并允许从下一期起上调 amount（见下文按比例计费表）。通过 update 直接上调对账户不普遍开放；如果你认为你的集成需要它，请向集成支持提出，而不是绕着它设计。
我如何设置按比例计费（prorate）？
**没有按比例计费字段，Waffo 也不计算按比例计费。**如果你在找prorate / proration_behavior 参数，它不存在——/subscription/update 和 /subscription/change 上都没有。
以下是每种情况下实际发生的事，供你决定在自己这边实现什么：
简而言之：金额变更是周期边界事件，任何因变更落在周期中途而应当流动的资金，由你计算、由你收取。
/subscription/update 到底改什么，何时生效？
它只改金额，从下一个账单周期起。
它能改：amount、productInfo.trialPeriodAmount、productInfo.scheduledAmounts——单独或一起。三者至少要有一个，否则请求被拒绝。
**它不改：**套餐、periodType、periodInterval、剩余周期数、账单日期或支付方式。它不触发按比例计费，也不创建新订阅。
时间：新值从下一期起应用。当期已经生成或已在进行中的扣款不受影响。响应会告诉你变更落在哪个周期号：
金额更新何时会被直接拒绝？
最后一行意味着更新是按订阅串行化的。如果你要给大量订阅重新定价，请把”正在修改，请稍后重试”响应当作可重试的，而不是失败。
如果我在更新中发送 scheduledAmounts，会与现有计划合并吗？
**不会——你发送的列表整体替换存储的计划。**它不是补丁：旧计划中存在但你的请求中缺失的周期不再有排程金额，回退到 amount。
两个需要为之设计的后果：
- 始终发送你想定价的完整未来周期集合，而不只是你要改的那些。
- 因为更新只能针对当前周期之后的周期，替换计划时已扣款周期的条目会从存储中删除。这是预期行为，不会改变任何已发生的扣款。
/subscription/update 清空排程金额计划；要回到单一固定金额，请把每个剩余未来周期都列为你想要的金额，或用 /subscription/change 把用户迁到新套餐。
升级或降级时 scheduledAmounts 会怎样？
不继承任何东西。/subscription/change 创建一个新订阅，该新订阅的 amount 和 scheduledAmounts 完全来自变更请求。如果你在那里省略 scheduledAmounts，新订阅就完全没有按期计划，每期都按新的 amount 计费。
所以如果分级价格阶梯应该在升级后延续，你必须在变更请求中重新声明它。
终端用户会被告知金额变了吗？
会——金额更新成功后 Waffo 会给订阅者发邮件。邮件包含原金额、新金额、变更前后的按期计划，以及变更生效的周期号。 两个运营提醒：- 只有在你的账户和产品启用了金额变更通知时才发送邮件。关闭时不会向用户发送任何内容。
- 发送是尽力而为且异步的：邮件失败不会回滚金额变更。API 响应才是变更内容的记录。
金额更新成功时 Waffo 会给我发 Webhook 吗？
会。/subscription/update 成功后，Waffo 向订阅上存储的 notifyUrl 推送 SUBSCRIPTION_UPDATE_NOTIFICATION。对于普通金额变更，更新提交后立即发送；对于席位加购（见下文），在补款扣款成功并应用新金额后发送。报文是查询 API 返回形式的订阅，因此已经反映新金额。
为保持你自己的记录一致：
- 把
/subscription/update的响应当作主要记录——从中读取newAmount、newScheduledAmounts和nextEffectivePeriod并存储。Webhook 异步确认同一变更，是变更在你的即时请求路径之外提交时（补款场景）应使用的信号。 - 继续监听按期通知和订阅支付订单通知以获取每期的实际扣款金额——它们反映实际收取的数字，也是你应据以对账的数字。
哪些订阅可以使用按期金额？
按期金额和/subscription/update 可用于由 Waffo 驱动账单排程的订阅。对于某些支付方式，排程由支付方式自身驱动；这些订阅在创建时拒绝 scheduledAmounts，也不能进行金额更新。如果创建调用返回说该订阅不支持排程金额，原因就在此——解决方法是换支付方式，不是换请求形态。