用户已经付款，生成页面转了很久后提示超时。他不知道钱退没退、图片做没做完，也不知道再点一次会不会再扣款。这里首先需要的是找回这笔订单，而不是给生成按钮加一次重试。
支付平台的交易查询、订单状态和退款流程应继续负责收款事实。如果一个按次服务靠人工就能及时核对，先把客服处理做好。网络调用的成功或失败，不应该直接充当已支付或已退款。
可以让订单服务把已确认付款的订单提交给通过 EasyNet 接入的生成函数，同时保存调用关联和上游任务编号。返回的产物归到原订单，买家重新打开页面时查询它，而不是创建一份新的收费任务。
付款、生成和交付需要分别表示：可能款已收到、图已做好，只是下载回复丢了。提供方身份负责执行，买家身份决定能查看哪张订单；查询结果不应泄露其他人的文件或付款资料。
上游支持任务查询或幂等请求时应接好；不能确认外部执行结果时，转入核查，而非自动再跑。退款、补交付和人工联系还需要订单与支付系统完成，不能把一条调用记录展示为退款凭证。
测试一次生成完成但页面没收到回复，再连续点击重试。系统应找回同一结果或明确等待核查，不新增不明费用。另一笔真正失败的订单，则要能沿约定的补交付或退款路径结束。
- 01
原订单 O-85
付款已确认，保留上游任务号
- 02
浏览器没收到回复
按原任务查询，不创建第二次购买
- 03
回收原产物
结果不明则核查，退款另走支付流程
页面重试先决定查什么
用虚构订单演示分支，不调用支付或生成服务。生产版本需要持久订单、身份检查、并发控制及真实上游查询。
本地示例 · python
order = {"id": "O-85", "paid": True, "job_id": "J-85",
"generation": "completed", "artifact": "poster-85.png"}
def retry_action(order):
if not order["paid"]:
return "verify_payment"
if order["generation"] == "completed" and order["artifact"]:
return "retrieve:" + order["artifact"]
return "reconcile:" + order["job_id"]
print(retry_action(order))预期结果：输出 retrieve:poster-85.png。把 generation 改为 unknown 则输出 reconcile:J-85，不新建收费任务。
接入时的检查项
- 连续点击重试只查询或恢复原订单，不产生第二笔未知扣款。
- 生成成功但回包丢失时仍能找到产物，不重复启动收费处理。
- 退款金额与实际支付记录匹配，用户看见的是售后终态而非仅调用终态。