用户取消了订阅，昨晚提交的视频却还在生成。页面说订阅已取消，他以为处理也会停；作者担心交付后收不到费用。双方缺的是对正在进行的订单怎样处理的共同说明。
现有订阅平台可以管理续费和到期，业务系统管理已接受的订单。只提供偶尔按次处理的服务，也许根本不需要订阅。不要让一个取消按钮同时含糊地代表停续费、停新任务和停所有执行。
新请求进入时，由权益服务核验调用者的订阅状态，再决定是否通过 EasyNet 提交处理。订单一旦被接受，就保存当时的权益和处理状态，不能仅凭当前订阅页面反推它是否应该继续。
对在途任务，需要明确是完成交付、请求取消还是转人工协商。上游是否支持取消、取消后是否仍收费，要逐一核对；撤销后续调用权限不等于已经停止远端生成，更不等于退款完成。
订阅方负责到期时间，订单方负责交付，运行方反馈实际停止状态，支付方处理退款。用户应能看到哪些订单继续、哪些正在取消，以及什么时候再查；运行连接的有效期不能替代这套约定。
在到期时刻附近同时提交和取消一项测试任务，再让上游暂时无法查询。检查已接受订单没有凭空消失、新请求按规则拒绝、未知状态没有被写成已退款，账目最终也能与处理结果对上。
- 01
昨晚的视频订单
记录接单时的权益与费用约定
- 02
今天取消订阅
按生效时间检查新提交
- 03
逐单处理
继续交付或确认取消，不猜退款
把新任务和已接订单分开判断
这个例子选择“已接单继续交付”的业务规则。它不向上游发送取消，也不执行退款。实际规则应在购买前说明。
本地示例 · python
from datetime import datetime, timezone
cutoff = datetime(2026, 9, 7, 12, tzinfo=timezone.utc)
submitted = datetime(2026, 9, 7, 13, tzinfo=timezone.utc)
accepted_order = {"id": "V-88", "state": "running"}
print("reject_new" if submitted >= cutoff else "check_entitlement")
print(accepted_order["id"], "finish_accepted_order")预期结果：输出 reject_new 和 V-88 finish_accepted_order。新任务被拒绝不会抹掉原订单。
接入时的检查项
- 生效后的新请求被执行前拒绝，旧任务仍按已公布规则处理。
- 收到取消请求但上游继续运行时，界面不会提前宣称全部停止。
- 退款或剩余权益与支付系统记录一致，订阅状态不覆盖未交付订单。