member.suspended
商户级停用状态变化(停用与恢复共用这一条)
何时发
POST /v1/members/{id}/suspend 真的改动了 merchant_status 之后。
恢复也发这一条,带 status: normal —— 方向靠 status 区分。
给恢复另造一条事件会让「这个人现在能不能用」需要看两条事件流才答得出。
这一位只影响该会员在你这边的可用性,平台级封禁是另一套、你看不到。
⚠ status_version 恒为 0,而这一条会来第二次(停用 → 恢复 → 再停用)。
所以这里是全部事件里唯一真的要按 created_at 排序的地方 ——
别写「version 相等就跳过」,那会让恢复那条被丢掉,你这边的人永远解不开。
事件体
{
"event_id": "evt_7c93a1d05e6b4a2f9d81c4e0f2a37b56",
"event_type": "member.suspended",
"created_at": "2026-08-12T10:02:11Z",
"merchant_id": "acme",
"livemode": true,
"data": {
"object": "member",
"id": "4b7c1e02-9a3d-4f18-8c55-2d61ab0f9e77",
"external_member_id": "u_88123",
"status": "suspended",
"status_version": 0
}
}
事件体字段
| 字段 | 类型 | 说明 |
|---|---|---|
id | string | 去重用这个。evt_…,同一事件重投时不变。 |
type | string | 固定为 member.suspended |
created_at | string | 事件产生时刻(RFC3339)。不是投递时刻 —— 重投时它不变。 |
data.object | string | 对象类型,决定 data.id 该拿去查哪个端点 |
data.id | string | 对象 ID,拿它回查详情 |
data.status | string | 认不出的值按未知处理并告警,不要 fallback 成「处理中」 |
data.status_version | number | 单调递增,用它把慢到的旧状态丢掉 |
验签与去重
验签用原始请求体字节,不要先解析再重新序列化 —— 你的 JSON 库与我方的键顺序、空格几乎一定不同,重新序列化出来的签名一定对不上, 而那个错误长得像「密钥配错了」。
// Node · 放在解析 JSON 之前
const raw = await readRawBody(req); // Buffer / string,别用已解析的 req.body
const expect = crypto.createHmac("sha256", WEBHOOK_SECRET).update(raw).digest("hex");
const got = req.headers["z-signature"]; // 形如 t=<unix>,v1=<hex>
if (!timingSafeEqual(expect, parseV1(got))) return res.status(400).end();
// 去重:用信封的 id,不是 data.id
if (await seen(JSON.parse(raw).id)) return res.status(200).end();
完整做法(含时间戳容差与重投语义)见 Webhook 指南。