Stripe Webhook签名、幂等键、Event ID、对象ID和Request ID有什么区别？
Webhook 签名用于验证回调请求确实由持有端点密钥的一方生成且原始请求体未被篡改；幂等键用于客户端重试 API 写请求时避免同一操作被重复执行；Event ID 标识一条 Stripe Event，可用于记录和初步去重；对象 ID 标识 PaymentIntent、Charge、Customer 等业务对象；Request ID 标识一次 Stripe API 请求，主要用于日志关联和支持排障。
本文目录（21 节）
直接答案
Webhook 签名用于验证回调请求确实由持有端点密钥的一方生成且原始请求体未被篡改；幂等键用于客户端重试 API 写请求时避免同一操作被重复执行；Event ID 标识一条 Stripe Event，可用于记录和初步去重；对象 ID 标识 PaymentIntent、Charge、Customer 等业务对象；Request ID 标识一次 Stripe API 请求，主要用于日志关联和支持排障。
五者不能互换。验签通过不代表事件从未处理过；Event ID 相同不等于底层业务对象只会出现一种事件；对象 ID 不是幂等键；Request ID 也不是支付订单号。
一张表看懂五种标识或机制
| 名称 | 由谁产生 | 绑定对象 | 主要用途 | 是否应作为密钥保密 |
|---|---|---|---|---|
| Webhook签名 | Stripe 使用端点密钥计算 | 一次回调的时间戳与原始正文 | 验证来源与完整性 | 签名头不是密钥，端点密钥必须保密 |
| 幂等键 | API 调用方生成 | 一个业务写入意图 | 安全重试 API 请求 | 通常不当作认证秘密，但不可乱复用 |
| Event ID | Stripe | 一条 Event | 事件日志、检索和去重 | 否 |
| 对象 ID | Stripe | 一个 API 资源 | 查询和关联业务对象 | 否，但仍需防止越权访问 |
| Request ID | Stripe | 一次 API 请求 | 日志追踪、定位请求 | 否 |
安全性来自 API 密钥、Webhook 端点密钥、TLS 和访问控制，而不是因为某个 ID “看起来随机”。
Webhook签名是什么？
Stripe 向端点发送事件时，在 Stripe- 请求头中包含签名信息。服务端使用对应 Webhook endpoint secret、原始请求体和官方库进行验证。签名验证成功说明请求在允许时间窗口内与该端点密钥匹配，并且参与计算的正文没有被改动。
不同端点和测试/正式模式可能使用不同 secret。Dashboard 管理的端点与 CLI 本地转发也有各自密钥。把一个环境的 secret 用于另一个端点，会稳定地产生签名失败，不能通过重复发送解决。
为什么验签必须使用原始请求体？
签名针对请求到达时的精确字节计算。JSON 中的空格、换行、字段顺序或字符编码被中间件重新序列化后，语义可能相同，字节却已不同，验签就会失败。
框架应在 JSON body parser 改写正文之前保留原始 bytes，并把它直接交给官方构造事件函数。不要先解析成对象，再用 JSON.stringify 试图还原。代理层也不应在不知情时转换请求体。
验签通过是否代表可以立即发货？
不一定。验签只解决来源与完整性。业务处理仍需确认事件类型、事件所属账户或环境、对象当前状态、订单映射、金额和币种，并确保重复处理不会重复发货。
某些状态可能继续变化，事件也不保证按业务想象的顺序到达。关键动作应以当前对象状态和本地状态机为依据，而不是只看一条回调的名称。
幂等键是什么？
幂等键由 API 客户端为写请求生成，并通过 Idempotency-Key 请求头发送。网络超时后，客户端可以使用相同键和相同参数重试；服务端据此返回首次执行结果，而不是再次创建相同操作。
键应对应一个明确业务意图，例如“为订单 123 创建一次 PaymentIntent”，并在完成或确认失败前持久化。随机生成后若请求超时就丢弃，再次生成新键重试，无法实现原操作的幂等性。
幂等键能跨不同参数复用吗？
不应。Stripe 会比较后续请求参数与第一次请求，防止一个键被用于不同操作。把固定字符串作为全站幂等键，会让无关订单相互冲突；把用户 ID 单独作为键，也会错误合并同一用户的多次合法购买。
键的生命周期还受服务端保留策略影响。业务系统不能把第三方的临时幂等缓存当作永久订单数据库，应同时使用本地唯一约束、订单状态和支付对象 ID。
幂等键和Webhook去重是一回事吗？
不是。幂等键保护“你的系统向 Stripe 发出的 API 写请求”；Webhook 去重保护“Stripe 向你的系统发送的事件”。方向相反，存储表和生命周期也不同。
即使创建支付时使用了幂等键，同一结果事件仍可能被 Webhook 多次投递。端点必须独立实现事件幂等处理，例如对已处理 Event ID 建立唯一约束，并让发货、记账等副作用也有业务级唯一键。
Event ID是什么？
每个 Stripe Event 有自己的 id 和 type，并在 data.object 中携带相关 API 对象。Event ID 标识事件记录，不等于事件中对象的 ID。
例如同一个 PaymentIntent 可经历多个状态并产生多条不同 Event；这些 Event ID 不同，而 data.object.id 可能相同。反过来，不能仅按 PaymentIntent ID 去重所有事件，否则后来的有效状态变化会被误删。
Event ID足以处理所有重复吗？
它是重要的第一层，但业务副作用仍应有独立幂等约束。处理流程可能在“已经发货”后、“记录 Event 已完成”前崩溃；重试时仅查看事件表可能无法准确恢复。
更稳妥的设计是在同一数据库事务中记录事件状态和可事务化的业务变更；对外部副作用使用 outbox、任务唯一键或接收方幂等接口。Event ID 去重与订单级状态机应同时存在。
对象ID是什么？
对象 ID 标识 Stripe API 资源，常见前缀有 pi_、ch_、cus_、pm_ 等。前缀帮助人和程序识别对象类型，但不应仅靠字符串前缀决定授权或业务状态。
一个业务订单可能关联多个 Stripe 对象：Checkout Session 引用 PaymentIntent，PaymentIntent 可能关联 PaymentMethod 和 Charge，退款又有自己的对象。日志和数据库应分别存字段，不能把它们都塞进一个含糊的 stripe_id 列。
对象ID可以公开吗？
对象 ID 一般不是 API 凭据，单独知道它通常不能直接调用受保护 API。但仍不应把“不是秘密”理解为“可以无条件展示”。它可能泄露业务关系，也可能在应用自身存在越权漏洞时成为枚举目标。
服务端查询对象时必须根据当前商户、账户和订单做授权校验，不能因为用户提交了格式正确的 pi_ ID 就返回支付详情。
Request ID是什么？
Stripe 为 API 请求提供 Request ID，可在响应头和 Dashboard 请求日志中用于定位一次请求。应用应把它与自身 trace ID、订单 ID 和操作名称一起记录，以便出现 4xx、5xx、超时或结果疑问时串联证据。
Request ID 标识一次请求尝试，而不是业务意图。相同幂等键的重试可能涉及不同网络尝试和请求日志；业务上仍应围绕幂等键与对象状态判断是否重复执行。
Request ID和Event ID有什么关系？
两者属于不同链路。Request ID 对应同步 API 请求；Event ID 对应异步事件。一次 API 请求可能引发多个后续事件，某个事件也可能反映在请求之外发生的状态变化。
不能假设通过字符串或时间即可一一映射。需要关联时，应记录请求返回的对象 ID，再在 Event 的 data.object 及业务元数据中建立可验证联系。
Webhook为什么会重复投递？
Webhook 是网络上的异步投递。端点响应超时、返回非成功状态、连接中断，或响应已经发出但发送方未可靠收到，都可能触发重试。即便系统平时稳定，也必须把重复当作正常情况，而不是异常边角。
端点应快速验签、做最低限度校验、持久化事件或入队，然后尽快返回成功。耗时的邮件、库存、ERP 和发货操作放到可重试的后台任务中，避免请求超时放大重复投递。
事件顺序为什么不能想当然？
多个事件在分布式系统中可能走不同队列与重试路径，到达顺序不一定等于业务状态发生顺序。端点如果收到“成功”后又处理较早的“处理中”并直接覆盖状态，就会回退订单。
处理器应定义允许的状态转换，必要时按对象 ID重新查询当前状态。事件创建时间可作为证据之一，但不能单独替代对象版本、业务规则和幂等事务。
推荐的数据表设计
Webhook 收件表至少保存 Event ID 唯一键、事件类型、环境或账户、关联对象 ID、接收时间、处理状态、尝试次数和脱敏错误码。原始正文的保存需根据审计、隐私和保留政策决定，不能无限期存储敏感载荷。
API 操作表可保存业务操作 ID、幂等键、请求参数摘要、返回对象 ID、最近 Request ID 和最终结果。订单表再保存自己的支付状态与唯一业务约束。三张表职责分离后，排障不必从一列混合 ID 中猜测。
安全处理顺序
- 通过 HTTPS 接收请求，并读取原始请求体。
- 使用正确环境和端点的 secret 验证签名与时间容差。
- 解析事件，确认账户、模式和允许的事件类型。
- 以 Event ID 执行原子接收或识别重复。
- 根据对象 ID 和本地订单映射检查当前业务状态。
- 将副作用转换为带唯一键的可重试任务。
- 快速返回成功，异步完成耗时操作。
- 记录 Event ID、对象 ID、内部 trace ID；同步 API 侧另记 Request ID 和幂等键。
日志不得记录 API secret、Webhook endpoint secret、完整卡数据或不必要的个人信息。
常见误区
签名相同就表示事件相同吗？
不应这样判断。应由官方库验签，并用解析后的 Event ID 识别事件。签名属于具体投递的验证材料，不是业务主键。
Event ID可以当幂等键调用Stripe API吗？
技术上它是字符串，但语义不正确。幂等键应标识你发起的业务写入意图，Event ID标识收到的事件。
同一个对象ID只处理一次可以吗？
不可以一概而论。同一个对象会产生多种合法状态事件。应按事件与业务状态转换决定处理方式。
Request ID可以用来查询支付状态吗？
Request ID主要用于定位一次 API 请求日志。查询支付状态应保存并使用相应 PaymentIntent、Charge 等对象 ID。
Webhook返回200后就不会再收到重复吗？
不能依赖这一假设。网络与投递状态存在不确定性，处理器始终应具备幂等性。
结论
Webhook 签名证明投递来源与正文完整性，幂等键保护出站 API 写入重试，Event ID 标识异步事件，对象 ID 标识支付资源，Request ID追踪一次同步 API 请求。把五者分别存储、分别校验，再用订单状态机和唯一约束控制业务副作用，才能在超时、重试、乱序和重复投递下保持支付与发货一致。
参考来源
- Stripe Docs, Receive Stripe events in your webhook endpoint：https:
/ / docs. stripe. com/ webhooks - Stripe Docs, Resolve webhook signature verification errors：https:
/ / docs. stripe. com/ webhooks/ signature - Stripe API Reference, Idempotent requests：https:
/ / docs. stripe. com/ api/ idempotent_ requests - Stripe API Reference, The Event object：https:
/ / docs. stripe. com/ api/ events/ object - Stripe API Reference, Request IDs：https:
/ / docs. stripe. com/ api/ request_ ids