同一购物车重试付款应复用PaymentIntent
结账中断后重试付款，应复用同一个 PaymentIntent，而不是新建。Stripe 文档对“结账过程被打断、稍后恢复”的场景给出的建议就是：尝试复用同一个 PaymentIntent。每个 PaymentIntent 都有唯一 ID，应用可以把该 ID 存在购物车或客户会话的数据模型上，恢复结账时据此取回原对象。这样做的直接收益是，对象自身状态有助于跟踪该购物车或会话上的失败付款尝试；如果每次重试都新建对象，历史尝试会分散在多个 PaymentIntent 上，难以沿同一购物车串联观察。
复用不等于金额固定不变。文档说明，金额发生变化时可以更新 PaymentIntent 的 amount。典型情形是客户退出结账流程后又往购物车加了商品，重新进入结账时需要更新金额。也就是说，同一购物车对应的 PaymentIntent 可以随购物车内容调整，但对象身份保持稳定，这正是复用的含义。
新建路径的主要风险是重复创建。文档提醒，应提供幂等键（idempotency key），防止同一笔购买被创建出多个 PaymentIntent。这个键通常基于应用为购物车或客户会话分配的 ID 构造。这样即便创建请求因超时或重试被再次提交，服务端也能把它识别为同一笔购买，避免产生第二个对象。复用已有 PaymentIntent 与创建时携带幂等键，处理的是两个不同场景：前者处理“对象已存在”的恢复，后者处理“创建请求被重复提交”。
从客户端完成付款的角度看，PaymentIntent 内含一个 client secret，这是该对象独有的密钥。客户端侧 Stripe.js 在调用完成付款的函数时，会把 client secret 作为参数传入。因此恢复结账时，应用需要把原 PaymentIntent 的 client secret 重新下发到客户端，而不是依赖一个新对象。复用同一对象意味着 client secret 保持一致，客户端逻辑不必在每次重试时切换到新密钥。
把上述机制落到一个具体任务上。假设某开发者在服务端为购物车创建 PaymentIntent，并把其 ID 写入购物车记录。用户在支付页面放弃，随后返回并修改了商品。此时应用读取购物车上的 PaymentIntent ID，取回原对象；如金额已变，则更新 amount；再把该对象的 client secret 下发客户端完成付款。若创建请求因网络原因被重复触发，则依靠基于购物车 ID 构造的幂等键阻止第二个对象生成。这个假设只用于说明流程，其中的字段选择和存放位置需按自身应用的数据模型确定。整个流程中，购物车与 PaymentIntent 保持一一对应，失败尝试的记录也集中在这一对象上。
需要限定的是，以上内容来自 Stripe 文档对 PaymentIntent 复用与幂等键机制的说明，属于接口层面的通用做法，不涉及具体业务的金额规模、成功率或转化效果。文档没有给出适用于所有集成的统一参数或默认值，开发者应结合自身应用的数据模型决定 ID 的存放位置与幂等键的构造方式。对于文档未覆盖的版本差异与地区性要求，应以对应环境的官方说明为准。