定义
套餐下发是用户完成套餐订购并支付成功后，平台根据运营商映射向运营商发起指令，将套餐下发至物联网卡的过程。下发成功后卡获得对应流量，欠费卡可自动复机。与支付回调联动，实现「支付即生效」。
下发流程
- 支付确认：用户支付成功后，支付回调通知平台，平台校验订单状态与金额。
- 映射转换：根据平台流量套餐与运营商映射，将自有套餐转换为运营商侧产品编码、资费编码。
- 指令下发：调用运营商API（如移动OneLink、联通Jasper、电信等），将套餐下发至指定ICCID或MSISDN。
- 结果回执：运营商返回下发结果，平台更新订单状态、卡套餐信息，若为欠费卡则触发复机。
异常处理
下发失败时（如运营商侧异常、卡状态异常），平台需支持重试、人工介入。建议记录下发日志，便于排查。若多次重试仍失败，需通知用户并支持退款或人工处理。
下发与计费
套餐下发成功后，卡获得对应流量或权益，流量计费从此时起算。平台需更新卡套餐信息、用量余额等。若为欠费停机卡，下发成功后触发复机。下发是套餐订购流程的关键环节，与支付回调紧密联动。下发延迟或失败会直接影响用户体验，需保障运营商API对接稳定、重试机制完善。
下发与运营商映射
套餐下发依赖运营商映射，将平台流量套餐转换为运营商侧产品编码、资费编码。映射错误会导致下发失败或下发错误套餐。平台需在套餐包装时配置映射，支持多运营商（移动、联通、电信）差异化映射。下发时根据卡所属运营商选择对应映射。下发成功后，套餐周期从生效日起算，账单、运营商对账均依赖准确的下发记录。
下发与复机
套餐下发成功后，若为欠费停机卡，平台自动触发复机，实现「支付即复机」。下发失败时需支持重试、人工介入。下发是套餐订购流程的关键环节，与支付回调紧密联动。平台需保障运营商API对接稳定、重试机制完善。套餐下发是物联网云平台连接运营商与自有业务的核心能力。
支付成功但回执未到时订单停在哪
套餐下发是把已支付订单上的自有套餐，按映射转成运营商产品编码，写到指定的卡上，并保存回执。支付通知只说明钱到了，回执才说明卡上有了这块流量。回执未到，订单是「下发中」，余量不变，欠费停机的卡也不要先改成已复机。查询运营商若发现其实已经写上，应把查询结果当成回执补记，而不是再写一次。再写一次可能叠成两份套餐或被拒绝后把订单打成失败。失败且确认未开通，才进入退款或人工重试。重试必须换用当前仍有效的映射，并让操作者看到编码相对下单时有没有变化。和停复机的关系是：下发成功之后，若停机原因是欠费或流量用尽，再送复机；其他原因保持断网。
写到识别码还是写到号码
接口有的认集成电路卡识别码，有的认号码。下发记录里两个都存，实际提交按该运营商接口的要求取其中一个。号码尚未分配的库存卡不能下发，应先完成开户。卡已注销、已报废、或正处在另一笔下发中，新的下发要拒绝。批量下发按卡清单逐张回执，一张失败不代表整批失败，也不要把未回执的卡标成成功。使用者页面上的「已到账」只在回执成功后出现。到账用量等于套餐档位，若运营商返回的总量和档位不一致，订单标成异常，不要先给使用者展示一个对不上的余量。周期起点按下发规则选用支付时间或回执时间，和首次激活时间的规则不要各写各的。
下发日志要能回答对账时的三个问题
对账问的是：这块流量有没有真正开通、开通的是哪个资费编码、开通时刻落在哪个账期。日志里因此要有订单号、卡标识、运营商、产品编码、资费编码、请求时间、回执时间和原始返回码。只有「成功」两个字，无法解释账单上的编码差异。原始报文可以脱敏保存，但编码和返回码要能检索。下发成功后若立刻变更套餐，两笔都要留下，不能互相覆盖。支付已退款的订单如果下发仍成功，要有补偿任务去退订或停用这块流量，不能只在支付单上标记退款就结束。任务堆积时优先处理支付已成功的下发，查询类同步靠后，避免卡在已扣款状态下长时间没有套餐。超过约定等待仍无回执的，自动转人工队列并停掉同一张卡的新支付，防止使用者以为没成功又付一次，叠出两笔待下发。