客户发来错误链接时取消API订单

首先检查订单是否已传送给供应商

链接错误并不总是意味着推广已经启动。在本地数据库中订单可能已创建，但尚未通过API发送。在这种情况下，取消仅取决于您的处理逻辑：将订单标记为已取消、停止自动付款并且不启动传输即可。

请检查订单标识符、创建时间、链接、服务类型和API请求日志。如果请求尚未发送给供应商，请不要在旧订单之上创建新订单。首先确认原申请已取消，否则客户可能会针对不同链接获得两次启动。

确定订单在供应商处的状态

如果API请求已经发送，请向供应商查询当前状态。各状态的名称有所不同，但通常可以分为几组：等待、处理中、部分完成、已完成和已取消。对决策而言重要的不是您面板中的状态，而是启动服务一方的回复。

• 等待：订单可能仍允许取消。
• 处理中：有时可以停止，但部分量可能已经启动。
• 部分完成：如果供应商支持此类操作，只能取消剩余部分。
• 已完成：已无法通过取消来修正链接。

仅依据内部状态进行检查的缺点在于，它可能会延迟更新。请以最新的API响应及其接收时间为准。

在服务启动前取消订单

对于排队中的订单，如果供应商文档中提供了取消方法，请使用该方法。请传递创建订单时获得的标识符，而不是您的内部编号（如果两者不同）。请保存完整响应：操作代码、状态、错误文本和请求时间。

在API确认取消之前，不要认为订单已取消。 接受请求的响应和服务的实际停止可能是不同的事件。在某些集成中，首先会收到接受确认，而最终状态稍后才会变更。

此方案的缺点在于，供应商可能来不及将订单从处理中撤下。此时取消会返回拒绝，或仅对未执行部分生效。

未经确认不要更改已创建订单中的链接

在许多API中，链接在创建订单时即被固定。尝试用同一标识符传递新链接可能会被忽略、作为错误处理或造成不可预测的状态。不要指望重新发送请求会自动替换地址。

如果文档明确支持编辑链接，请先确认服务尚未开始执行。然后保存旧值、新值和API响应。这在客户或供应商发生争议时会派上用场。

编辑的缺点在于，即使方法可用，在更新之前部分操作可能已经发往旧页面。修正后的链接无法转移已经获得的结果。

部分完成时该怎么办

当错误链接上的推广已经开始时，请申请取消剩余部分。在致供应商的请求中注明订单标识符、错误链接、正确链接、当前状态和发现错误的时间。不要多次更改请求细节：这会使历史核查变得复杂。

如果剩余部分的取消已确认，请记录已完成的量。退款（如果供应商规则中有规定）通常仅涉及未执行部分。已完成的量在技术上无法从一个频道、视频或主页转移到另一个。

部分取消的缺点显而易见：客户可能已经在错误页面上获得了结果，而这部分订单的预算并不总能退回。

如果订单已完成，请以单独申请办理修正

已完成的订单通常无法通过API取消。在这种情况下，不要删除记录，也不要更改历史中的链接：原始数据需要用于核对。请确认服务是否确实在错误地址上提供了，而不仅仅是显示有延迟。

接下来有两条路径：按照供应商规则与其讨论补偿，或在征得客户同意后针对正确链接创建新订单。新订单应具有单独的标识符、金额和明确的创建原因标注。

重新启动的缺点在于需要额外预算，而已完成服务的补偿可能无法获得。

在重新启动前告知客户情况

如果链接属于客户且错误来自其一方，请不要自行决定启动替换。请向其发送原始链接、订单状态、取消可能性以及每种方案的后果。如果部分服务已经完成，这一点尤为重要。

• 如果订单尚未传送，请索取正确链接并确认取消旧申请。
• 如果订单在排队中，请告知取消已发出，但正在等待供应商回复。
• 如果存在部分完成，请说明只能停止剩余部分。
• 如果订单已完成，请协商新的启动或其他解决方式。

长时间协商的缺点在于，在此期间排队中的订单可能转入处理中。因此，如果存在取消可能，请先发送技术性取消请求，然后再明确后续操作。

保存操作日志和证据

对于每个有争议的订单，请保存客户提供的原始链接、接收日期、内部编号、供应商处的标识符、API请求和响应。如果客户在通信中发来链接，请不要在订单卡片中用编辑后的版本替换消息而不保存原件。

单独记录谁在何时发现了错误。这有助于将错误传输的数据与管理人员的错误、订单表单或自动填充区分开来。在多次联系供应商时，请使用同一数据链，以避免出现矛盾。

手动维护日志的缺点在于耗时。但没有历史记录，就更难确认取消状态并向客户解释为何无法全额退款。

检查集成中的错误处理

在此类事件之后，请检查系统如何将链接传递到API。错误可能不仅源于客户：有时表单会截断参数、从缓存中替换旧值、接受主页链接而非发布链接，或放过带有额外字符的链接。

在创建订单前添加格式检查：与平台、服务类型和预期对象的匹配。对于视频服务，系统应能区分视频链接和频道链接；对于社交网络，应能区分主页和单独发布。检查不能保证链接正确，但可以筛除部分明显错误。

最好通过简短的数据检查将订单传输与其创建分开。 额外步骤的缺点在于订单不会立即进入处理，但您将有时间发现错误地址。

为团队设置清晰的取消流程

描述统一的操作顺序：停止自动发送、检查供应商处的状态、发送取消、保存响应、通知客户，然后才协商重新启动。此流程不是为了形式，而是为了避免不同员工执行相互矛盾的操作。

不要在缺乏权限限制和操作日志的情况下授予取消访问权限。如果多名管理人员同时处理同一订单，一人可能请求取消，而另一人在收到响应前创建替换。这会导致额外费用和结算混乱。

严格流程的缺点在于紧急情况下灵活性较低。但对于API订单而言，更重要的不是单个操作的速度，而是控制实际进入工作的是哪个链接。