发货链路的末端是订单到账:支付平台的回调到了游戏侧,元宝何时到账、掉单怎么补、重复回调怎么挡——发货链路的严谨程度直接决定付费玩家的信任。
---支付回调的验证与发货
function Pay.callback(body)
-- 验签:回调必须来自支付平台
if not Pay.verifySign(body) then
Ops.alert("回调验签失败", body.orderId)
return false
end
-- 幂等:订单只发一次货
if Pay.delivered(body.orderId) then
return true
end
local player = getplayerbyname(body.roleName)
if not player then
Pay.pending(body) -- 玩家不在线,转补单
return true
end
sendmail(body.roleName, 8007, "充值到账",
"感谢支持," .. body.amount .. " 元宝已到账",
"元宝|" .. body.amount)
Pay.markDelivered(body.orderId)
return true
end
回调的三道闸:验签挡住伪造的回调、幂等标记挡住平台的重复通知、玩家不在线转补单队列。发货走 sendmail 的附件通道,元宝以附件形式到账,到账的时刻有邮件为证。角色名的匹配按玩家名转对象(getplayerbyname 查无此人的转 Pending),改过名的角色按 userId 的映射表兜底。
---补单轮询:每 5 分钟扫未发货订单
setontimerex(85, 300)
function Pay.recover()
local rows = Pay.pendingOrders()
for _, o in ipairs(rows) do
if o.tryCount >= 6 then
Ops.alert("补单超限,转人工", o.orderId)
else
local player = getplayerbyname(o.roleName)
if player then
sendmail(o.roleName, 8008, "充值补发",
"延迟到账请查收", "元宝|" .. o.amount)
Pay.markDelivered(o.orderId)
end
end
end
end
补单每 5 分钟扫一轮未发货队列:玩家上线即补发,6 次尝试仍无法交付的转人工工单——补发的动作与原发货同源,元宝不多不少。回调的时序仿真在测试环境的 Mock 里覆盖:正常回调、重复回调、超时补发三条路径全绿才允许联调验收。对账的日任务把游戏侧的发货流水与平台账单核对,差额在 24 小时内清账到单。
回调的到达率与发货成功率监控,发货失败率的突增即为支付通道异常;补单的积压量告警,积压超过 50 单人工介入。
验签的算法曾经与平台文档不一致,上线首日全部回调被拒,玩家的钱到了元宝没到,算法按平台的示例代码逐字段对齐。幂等的标记曾经写在发货之后,发货失败重试时订单已标已发,标记移到发货成功之后。角色名曾经直接匹配,改名的玩家补单永远找不到人,userId 的映射表兜底。
发货的时效承诺写进充值页面:5 分钟内到账,超时可自助查询订单。回调的日志全量留存,资纠纷的追溯有完整的链路证据。测试环境的支付 Mock 与生产的配置物理隔离,Mock 的回调地址永远进不了生产。
本文由 996 技术组基于 996 引擎官方知识库与浮生梦老师课程体系整理。团队长期从事传奇类引擎 Lua 后端逻辑、客户端界面与商业版本交付,内容以官方知识库与真实项目为出处,按版本持续修订。
全站技术干货持续更新:996 引擎 / Lua 实战帖,语法、参数与示例一篇讲透。进入文章地图 · 查看全部 →
学员常见误区 Lua函数可返回多个值,学员用固定变量数接收时如果变量少于返回值,多余返回值被静默丢弃;如果变量多于返回值,多…
设计初衷 行会建筑的死穴是一次全解锁:会员没有逐步建设的过程感。梯度设计让每栋建筑都有前置条件和资源门槛。 数值模型 建筑分…
设计初衷 婚姻系统的属性加成是社交玩法的经济锚点:加成太弱没人结婚,太强则"为了属性被迫结婚"扭曲了社交本质。婚姻边界的设计…
设计初衷 宝箱类玩法的信任危机都源于同一句话:"概率是不是骗人的。"期望公示把概率从事后争议变成事前契约:奖池概率表全量公示…
设计初衷 流拍物(拍卖未成交的退回物品)堆积在卖家背包里成为死资产:低价值物流拍后无人问津,高价值物流拍后卖家不愿降价重拍。…
业务场景 沙巴克战功榜每周结算,玩家提交战功前不知道"再打多少能进前 10、前 10 的奖励是什么"。名次预览:输入自己的战…