一、先确认对象，再怀疑字典
订单编号已经写入结账会话，查询支付对象时却发现元数据为空，这两件事并不矛盾。Stripe 的元数据属于具体对象，默认不会自动复制给相关对象；如果要读取关联对象的元数据，需要自行查找并检查那个对象。[1] 因此，排查的起点应当是“写给了谁、现在读的是谁”，而不是反复调整字典的序列化方式。
本文讨论的是对象之间的字段路由，不是支付完成判定、免费订单履约或通知去重指南。以下流程属于编辑建议，依据公开文档编写，并非真实支付测试结果，也不代表 PayIn 具有这些接口。建议先画出内部订单、结账会话、支付意图和扣款对象的关系，并在每个对象旁标明谁负责写入、谁负责读取。
二、明确区分会话字段与支付字段
创建结账会话时，顶层 metadata 参数附加到该会话对象上。[2] 如果目标是底层支付意图，文档规定使用 payment_。[1] 创建接口还明确说明，payment_intent_data 用于 payment 模式下创建支付意图时传入的参数。[2] 两种写法不是同一个字段的别名，而是两个不同的目的地。
如果处理会话的服务和处理支付的服务都需要订单编号，建议在创建时明确写入两个位置。下面只是说明字段路由的参数片段，不是完整可执行请求，也不是已经测试的返回结果：
mode=payment
metadata[order_id]=order_123
payment_intent_data[metadata][order_id]=order_123
建议使用稳定的内部订单标识，并由业务数据库保存订单明细及其变化。把同一个编号写两次，不意味着两份元数据从此建立了同步关系。评审时应逐一列出消费者需要的字段，避免为了方便而把整个订单复制到所有对象。
三、按照事件实际携带的对象读取
Stripe 说明，事件通知包含对应对象以及该对象持有的元数据；官方示例中，checkout. 携带的是结账会话的元数据。[1] 因此，处理会话事件时应读取会话字段，不能因为支付事件没有相同的键，就认定会话创建时写入失败。
建议在排查记录中保存事件类型、data.object.object、对象编号、预期键名以及最初的写入位置。先对齐这些信息，再检查参数拼写或重试逻辑。如果业务确实需要另一个关联对象的数据，就按文档要求实现显式查找，而不是假设事件会附带整条对象关系中的所有元数据。[1] 这里的字段是否存在，也不能单独替代支付状态或履约条件的判断。
四、自动复制只是一次快照
Stripe 对支付意图到扣款对象规定了一个例外：创建扣款对象时会复制支付意图的元数据，但这只是一次性快照；之后修改支付意图，不会更新已有扣款对象。[1] 因此，上游修正成功不能证明下游历史记录也已经修正。确认修复时，需要读取真正被下游服务使用的那个对象。
支付链接到结账会话也有类似边界：会话创建时复制支付链接的元数据，之后修改链接不会更新已有会话。[1] 建议区分“创建当时的归属信息”和“当前业务状态”。需要保留历史上下文时，不应为了让各处看起来一致而覆盖快照；确实需要跨对象纠错时，应先列出对象清单，再分别执行授权更新并验证结果。这个清单是应用自己的责任，不能依赖隐含同步。
五、订阅流程需要单独绘制字段关系
通过结账创建订阅时，subscription_ 会把数据写入底层订阅对象。[1] 不要因为两种流程都从结账开始，就把一次性支付模式的写法直接套用到订阅。建议先确定某个编号描述的是本次结账、持续订阅关系，还是后续账单，再选择写入位置。
当前文档说明，订阅生成账单时，会把元数据一次性复制到 parent.，之后的订阅修改不会应用到该账单。[1] 这个嵌套位置不是账单顶层的元数据字段。文档同时指出，类型为订阅的账单行项目呈现的是订阅当前的元数据。[1] 这两条规则并不相同，因此排查表必须记录精确字段路径，不能笼统写成“账单继承订阅信息”。维护旧集成时，也应核对实际接口版本和响应结构。
六、区分写入缺失与读取权限
Stripe 只在使用服务端密钥的请求中返回元数据；使用可发布密钥的客户端请求，包括浏览器或移动端请求，其响应中的元数据会被隐藏。[1] 因此，前端看不到字段不一定代表没有保存。建议在正确账户和环境中进行获授权的服务端读取，绝不能为了排查而把服务端密钥放入浏览器。
更新时，新增元数据使用合并机制，已有键可以改成新值。[1] 对某个键提交空值会删除该键，对整个元数据提交空值则会删除所有键。[2] 更新内容与传播范围是两项独立检查：即使更新请求完全正确，它也只解决目标对象本身的问题。不要用清空整份元数据的方式试探接口，否则会破坏正在核对的证据。
七、用可核对的路由表完成验收
建议在测试环境中分别检查：只写会话、只写支付意图、两个位置都写、扣款创建后再修改支付意图，以及订阅创建流程。每个场景都记录预期对象、精确字段路径、实际读到的值与读取身份。本文提供的是依据文档形成的预期，不提供虚构的通过记录；实际观察必须来自团队自己的执行。
字段也应保持精简：Stripe 允许最多五十组键值，键最长四十个字符，值最长五百个字符，并要求不要保存银行账户或银行卡等敏感信息。[1] 最终验收目标不是所有对象的元数据完全相同，而是每个业务编号都能按明确路径到达需要它的消费者。本文未执行支付测试；账户资格、市场支持和具体产品限制需要另行确认，不能从字段文档推导为全球可用。
来源与日期
来源为官方文档，站点可能返回本地化语言文本；未注明发布或更新日期，于2026-09-22读取核验。检索日期不等于原文发布日期。本文为文档研究，不是实际账户测试，不代表 PayIn 产品功能，也不是法律、税务或财务意见。