定义
支付回调是用户完成微信支付或支付宝后，支付渠道向平台发送的异步通知。平台收到回调后更新订单状态、触发套餐下发、复机等业务联动，需确保幂等处理避免重复执行。
回调流程
用户支付成功后，微信/支付宝服务器向平台配置的回调URL发起POST请求，携带订单号、支付流水号、支付金额、支付状态等参数。平台需：①验签确保请求来自支付渠道；②根据订单号查询订单并校验金额；③幂等处理（同一笔支付可能收到多次回调，需根据支付流水号去重）；④更新订单为已支付，触发后续业务（套餐下发、复机、支付分账等）。
注意事项
- 异步性：回调为异步通知，可能延迟数秒，前端需通过轮询或WebSocket获取支付结果，不可仅依赖回调。
- 重试机制：支付渠道对未响应的回调会多次重试，平台需快速返回成功（如200 OK），业务逻辑异步处理。
- 安全：必须验证签名，防止伪造回调导致资金风险。
回调与业务联动
支付回调成功后，平台需触发一系列业务：更新订单状态为已支付、执行套餐下发、若为欠费卡则执行复机、若接入支付分账则调用分账接口。这些操作需可靠执行，任一环节失败都影响用户体验。建议采用消息队列异步处理，支持失败重试。回调处理需幂等，同一笔支付多次回调时只执行一次业务逻辑。支付回调是物联网卡套餐订购流程的核心枢纽。
支付回调与订单
支付回调需根据订单号、支付流水号关联订单，校验金额一致。订单需记录销售归属，便于结算分润或支付分账。回调成功后，套餐下发根据运营商映射调用运营商API；复机将停机卡恢复联网。支付回调是B2B2C模式下「支付即复机」的关键环节，需保障可靠性、幂等性。
回调处理
支付回调需验签确保请求来自微信支付或支付宝；需幂等处理，同一笔支付多次回调时只执行一次业务逻辑。建议采用消息队列异步处理，支持失败重试。回调处理需快速返回成功（如200 OK），业务逻辑异步执行。支付回调是物联网卡套餐订购流程的核心枢纽，与套餐下发、复机紧密联动。
通知报文里必须核对的字段
支付回调在卡管理里不是“报文里出现成功二字就可以开通”。渠道投递的异步通知至少要能对上四件事：商户订单号能找到平台里那笔待支付订单；标价金额与下单金额一致，以分为单位时不能把元和分换算反；交易状态是支付成功，而不是支付中、已关闭或已转入退款；渠道交易单号可以作为幂等键，同一单号重复投递只允许把套餐下发和复机做一次。通知时间与订单创建时间相差过远时，应先向渠道查单，确认这笔钱确实入账，再改卡侧状态。
判断可以收成一条门槛：签名通过、订单仍待支付或已按同一流水处理过、金额一致、状态为成功，四项同时成立才进入开通。签名失败或金额不一致时，只留原文和失败原因，不改卡的联网状态。金额少付却复机，会造成已消耗流量没有对应实收；金额多付却不开通，用户会反复支付，后续对账出现一单多付。
页面轮询与异步通知谁先到达
用户在自助页付完款，页面通常先轮询订单，异步通知可能晚数秒，渠道在收不到明确应答时还会按自己的间隔重试。连接管理要把“款已确认”和“套餐已下发、卡已恢复联网”拆成两个状态。通知还没到时，页面只能显示支付结果确认中，不能把卡画成已复机。通知先到、运营商停复机接口超时，订单仍应记为已支付，开通动作进入重试队列，避免用户以为失败又付一笔。
处理线程若同步死等运营商接口，容易错过渠道要求的应答时限，同一笔支付会被反复投递。回调地址写成内网、路径写错或证书域名不匹配，表现为渠道一直重试、平台订单永远停在待支付。沙箱密钥拿去验生产通知，会把真支付全部判成伪造。退款通知和支付通知若共用一个入口却不按交易类型分支，已退款的订单可能被再次下发套餐。
达希连接管理中的支付通知落点
达希物联把支付结果接在卡业务闭环上：通知验签通过后，按订单上的卡标识和套餐执行下发；若该卡因欠费处于停机，再发起复机。分账订单可以在同一笔支付上带出接收方，但分账接口失败不应回滚已经成功的收款，而应进入补分账，避免用户钱已付、卡却被关掉。日终用渠道账单里的交易单号回查通知记录，核对实收、分出金额和套餐生效时间是否闭合。
这块能力落在达希的支付接入。实施时把通知原文、验签结论、订单号和后续开通结果分开留存，排查时才能分清“钱已收、卡未开”和“卡已开、渠道没有这笔收款”。