左辰勇
de1fd58749
要守住的不变量:弹窗数字 == 本轮实际到账之和 == 用户看到的余额涨幅。三者对不上, 用户就会认为少发了钱(走查现象:弹窗 240、余额只涨 40)。 - reward-result:按 ad_session_id 查本次实发金币,替代余额差 / coin_per_ad 估算。 S2S 异步未到账返 200+pending 而非 404(404 只表示路由不存在,混在一起客户端没法 区分「后端没部署」和「再等等」);同 session 多条时显式优先 granted——客户端先报 closed_early、S2S 后到时,granted 反而是后写的。 - boost_round_id:客户端经 mediaExtra 透传「这条广告属于哪一轮膨胀」,穿山甲 S2S 原样 带回后随发奖记录落库。**纯标签,不参与发奖判定**。reward-result 新增 round_coin,按 (user_id, boost_round_id) 对 granted 记录求和。之所以由服务端求和而非客户端自己累加 ——客户端进程被杀/重建后本地累计会丢,发奖记录不会。 · 求和恒带 user_id:轮 id 是客户端生成的,不带就等于让任何人拿别人的轮 id 查别人发了多少。 · 本条非 granted(capped 等)时仍返本轮累计、该条按 0 计,让限额 toast 有数可显。 · test-grant 加可选 boost_round_id:它不经 S2S 拿不到 extra,不补则 debug 包验不了累计。 · 客户端复用同一轮 id 只会把展示数字滚大,求和的是已发生的记录,不产生新入账,无资损。 - 下线 signin_boost(签到膨胀):它按固定 3000 金币发、与广告实际收益脱钩,产品确认从来 不是设计内的口径——奖励只有「签到」和「看视频」两种。签到弹窗的「看广告膨胀」改与福利页 看视频同走 reward_video(按 eCPM 公式)。摘除回调分支、POST /signin/boost、 SigninBoostRecord、signin_boost_coin 配置,并 drop signin_boost_record 表。 **coin_transaction.biz_type='signin_boost' 的历史流水保留不动**——钱是真发过的,账必须 留得住;admin 大盘那两项改从金币流水统计(一次膨胀 = 一笔,与原口径等价),继续能查回历史。 Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
4.6 KiB
GET /api/v1/ad/pangle-callback — 穿山甲 GroMore 激励视频发奖回调(S2S)
所属:Ad 组（前缀
/api/v1/ad） | 鉴权:无 JWT,靠验签（穿山甲 GroMore 服务器调用） | 限流:同 IP ≤300 次/分 | ← 返回 API 索引⚠️ 我们客户端用
useMediation(true)(GroMore 融合),回调走 GroMore 广告位层级(规范见 supportcenter/26240),不是联盟代码位层级(5416)。两者密钥、响应格式都不同,别混。后台配置入口:GroMore 聚合管理 → 搜广告位ID → 编辑 → 勾选「服务端激励回调」(广告位层级配了就别再在代码位层级重复配,会冲突)。集成实现:见 integrations/pangle（验签算法、m-key 来源、设计动机）。
入参（query，由 GroMore 拼装）
GroMore 以 GET 回调,关键参数:
| 字段 | 类型 | 说明 |
|---|---|---|
user_id |
string | 客户端 setUserID 传入的用户标识（须为数字 = 本系统 user.id） |
trans_id |
string | 交易号（幂等键 + 唯一参与签名的字段） |
reward_name |
string | 奖励名（广告位配置,入库备注） |
ecpm |
string|null | GroMore 回调携带的 eCPM。普通激励视频优先用它计算金币 |
extra / gromoreExtra / gromore_extra |
string | 客户端透传 JSON。支持 ad_session_id、reward_scene、srv_env、boost_round_id |
extra 里的 boost_round_id
客户端生成的「这条广告属于哪一轮膨胀」标签(32 位十六进制,同 ad_session_id 格式),随发奖记录存进 ad_reward_record.boost_round_id。
它不参与任何发奖判定 —— 发多少、发不发完全不受影响,只是让 /ad/reward-result 能把同一轮的 granted 记录求和成 round_coin(客户端「恭喜累计获得奖励」弹窗显示的数)。
轮次边界由客户端定(只有它知道用户点没点「放弃赚钱」):点「去膨胀」新生成一个 → 点「继续看视频膨胀」复用同一个 → 点「放弃赚钱」/ ✕ / 返回 / 到每日上限 / 跨天 则丢弃。不带此字段(老客户端 / GroMore 偶发丢 extra)时存 NULL,round_coin 返 null。
| mediation_rit | string | 代码位 ID（GroMore 带,目前仅入 raw 备查） |
| prime_rit | string | 广告位 ID（同上） |
| adn_name | string | 实际出广告的 ADN 名（同上,可用于收益分析） |
| ecpm | string | 本次广告 eCPM（同上,可用于收益分析） |
| sign | string | 签名,见下 |
验签:sign = SHA256("{m-key}:{trans_id}") 十六进制（只签 trans_id，其余参数不参与）。多激励位共用同一回调 URL → 服务端把各位的 m-key 都配上,verify_callback_sign_any 逐个试、任一过即接受。算法细节、m-key 配置项(PANGLE_REWARD_SECRET_TEST/_TEST_DEDICATED/_PROD)、为什么这样设计 → 见集成文档 integrations/pangle。
出参
响应 200,响应体必须是 {"is_verify": bool, "reason": int}（GroMore 规范）。
| 字段 | 类型 | 说明 |
|---|---|---|
is_verify |
bool | true=校验通过、发放奖励（发奖成功 或 当日达上限,均算已处理、不重试） |
reason |
int | is_verify=false 时的错误码,透传客户端 SDK:1=参数缺/坏,2=user 不存在;成功为 0 |
错误码
403验签失败（bad sign,留给真请求重试）503回调未配置（pangle_callback_configured=false）
说明
发奖唯一可信入口:验签 → 取 user_id/extra → 按 reward_scene 分流 → 幂等处理（按 trans_id 去重）。客户端不直接发奖,被破解也刷不到钱。
reward_scene=reward_video或缺省:普通激励视频。金币按eCPM / 1000 * eCPM因子 * 当日次数因子 * 10000计算;若回调没有ecpm,会按extra.ad_session_id查客户端/ad/ecpm-report的上报值;两边都没有 eCPM 时不发币,记录status=ecpm_missing。reward_scene=signin_boostreward_video。现在传signin_boost会落到「未知场景」分支(不发币,status=unknown_scene)。- 未知
reward_scene:不发币,记录status=unknown_scene,返回is_verify=false/reason=1。 - 验签过但参数缺/坏或 user 不存在 → 不发（
is_verify=false+reason）;granted / capped / ecpm_missing / 业务不满足已记录 →is_verify=true+reason=0。