# 结账会话与直接重定向：你应该选择哪一种？

> 结账会话和直接重定向链接可以解决相近的问题。了解各自适合的场景、需要做出的取舍，以及如何为你的 SaaS 做出选择。
- **Author**: Ayush Agarwal
- **Published**: 2026-05-17
- **Category**: Checkout, API
- **URL**: https://dodopayments.com/blogs/zh/checkout-sessions-vs-redirect

---

现代结账集成主要有两种模式。较早的一种是简单地重定向到支付 URL，买家在那里付款，然后返回。无论采用哪种方式，如果你通过程序创建会话，都应该在支付 API 中附加 [幂等键](https://dodopayments.com/blogs/idempotency-keys-payment-api)，这样重试请求就不会重复创建扣款。较新的一种是结账会话：你的代码创建一个会话对象，并全面控制产品、客户详情、账单信息、元数据和行为，然后将买家发送到生成的 URL，或在页面中以内嵌方式呈现结账界面。

两种模式都可以提供可用的结账流程。它们的区别在于：你能配置什么、能预览什么、支付携带哪些状态，以及最终流程能多顺畅地融入其余账单体系。本文将介绍每种模式实际做了什么、各自适合什么场景，以及如何为你的 SaaS 或 AI 产品做出选择。

## 直接重定向到底是什么

直接重定向有时也叫支付链接，是一个固定 URL，指向某个特定产品的结账页面。你可以在控制台中生成链接，也可以通过简单的 API 调用生成。然后将链接放到任何需要的位置。买家点击链接后，平台会呈现结账页面；买家完成付款后，平台会发送 webhook。

直接重定向的优势在于简单且持久。链接是固定的，你可以通过电子邮件发送、发布到社交媒体、交给销售人员，或嵌入按钮中。你不需要在购买时调用 API，整个集成甚至可以只是一个锚点标签。

它的不足也正是来自这种简单性。链接指向固定的一个或一组产品。你无法在买家点击时针对其进行自定义，也无法注入元数据，将最终支付关联到特定用户、操作或上下文。你不能传入计算出的价格，也不能预填客户字段。任何随结账而变化的内容，都必须通过为每种变化映射不同链接来处理，或者由平台在结账时向买家收集信息。

当结账流程基本固定时，直接重定向就是合适的工具：每次都是相同的产品、相同的价格和相同的流程。营销页面、简单的销售漏斗、捐赠按钮和社交媒体活动都适合这种方式。任何链接本身就是完整集成的场景，也都适合直接重定向。

## 结账会话到底是什么

结账会话是一个 API 调用创建的对象，创建时机通常是买家即将付款时。该调用接受丰富的参数，包括包含多个产品和数量的产品购物车、用于预填表单的客户详情、用于确定税费的账单地址、贯穿整个支付生命周期并出现在最终 webhook 中的元数据，以及能够改变页面行为的配置标志。你还可以设置成功 URL 和取消 URL，并使用可选的 confirm 标志，以确认状态创建会话并立即结账。

平台会返回会话标识符和 URL。你可以将买家重定向到该 URL，也可以基于该会话呈现内嵌结账界面。买家完成付款后，平台会触发 webhook。你在创建会话时附加的元数据也会随流程传递，让你的代码能够将支付匹配到系统中对应的对象。

结账会话的优势在于可配置性和状态管理。你可以针对每位买家设置结账流程的各个方面。元数据让你能够可靠地将支付与应用中的记录对应起来。包含不同数量的多产品购物车是原生支持的。税费会根据你传入的地址计算，因此可以在买家到达结账页面前预览总额。会话可以提前创建、立即使用，也可以在买家放弃后丢弃。

它的不足在于集成成本和运维工作量。你需要使用服务端代码创建会话，需要处理会话创建失败、重试和幂等性，还要确保元数据结构足够清晰，以便 webhook 到达时真正有用。同时，你需要跟踪已创建的会话，避免已放弃的会话在没有上下文的情况下不断累积。

当结账流程存在任何针对买家或上下文的变化时，结账会话就是合适的工具。例如 SaaS 升级、动态购物车、具有自定义总额的 B2B 流程、提供不同规格预付额度包的 AI 产品，以及所有取决于应用已知信息的结账场景。

## 实用的决策框架

最清晰的选择方法，是依次回答以下五个问题。

### 无论买家或上下文如何变化，价格是否始终相同？

如果是，直接重定向就可以满足需求。如果不是，结账会话可以通过动态定价或按会话调整数量，简洁地处理可变金额。

### 你需要将元数据附加到支付上吗？

如果你需要将最终支付匹配到特定用户、应用中的某项操作、某个活动或任何其他上下文，就需要使用结账会话。直接重定向可以在 URL 参数中携带一些元数据，但可用范围更有限，也更脆弱。

### 你想预填客户信息吗？

如果是，你应该使用结账会话。直接重定向要么要求买家填写所有信息，要么依赖平台设置的 Cookie 进行预填，这两种方式都无法让你的应用真正掌控流程。结账会话允许你明确传入客户的电子邮件、姓名和地址。

### 你想在买家到达前预览总额或运行计算逻辑吗？

结账会话支持预览功能，可以返回计算后的总额、税费和已应用的折扣，而无需创建真实会话。这对于在将买家发送到结账页面前，在你的 UI 中显示价格非常有用。直接重定向不提供这一能力。

### 结账流程需要与你的账单体系集成得多紧密？

如果你的应用拥有自己的客户模型、订阅模型或交易历史，结账会话可以通过传递元数据和客户标识符实现干净的集成。直接重定向则需要你编写更多胶水代码，将最终支付拼接到自己的数据模型中。

如果你的大多数答案都指向结账会话，那就是你应该使用的工具。如果大多数答案都指向直接重定向，你就可以省下集成工作。许多产品最终会同时使用两者：营销和活动使用直接重定向，因为链接本身就是完整集成；应用内流程使用结账会话，因为结账属于应用逻辑的一部分。

## 结账会话相比直接重定向增加了什么

以下几个能力值得特别说明，因为团队一旦了解到它们，往往就会改变选择。

### 预览价格和税费

预览端点接受与创建端点相同的参数，并返回计算后的总额，而不会创建会话。你可以使用它在买家点击结账前显示包含税费的准确价格，从而提升转化率和信任度。

### 创建时确认

在创建会话时传入 confirm 标志，意味着会话会以已确认状态创建，并具有更短的有效期。这对于受严格控制的流程很有用：你可以缩短会话被放弃或重放的时间窗口。

### 多产品购物车

结账会话接受包含多个行项目的产品购物车。这比串联多个结账流程或将套餐创建为新产品简洁得多。附加项、多席位购买和可配置套餐都可以通过单个会话完成。

### 可贯穿流程传递的元数据

每个会话都可以携带任意元数据。这些元数据会出现在最终支付、适用时的最终订阅以及 webhook 负载中。无需依赖客户电子邮件或其他间接标识符，这是将支付匹配回应用中对应对象的最简洁方式。

### 可配置的成功 URL 和取消 URL

每个会话都可以拥有自己的成功 URL 和取消 URL。这意味着应用中的不同流程可以在结账完成后将买家返回不同页面。营销流程可以跳转到感谢页面，应用内升级流程可以跳转到设置页面。直接重定向则使用链接上配置的固定返回 URL。

### 在同一原语中支持订阅和一次性购买

订阅产品和一次性产品都可以通过结账会话销售。会话会根据产品配置处理正确的账单原语，让不同产品类型共用统一的集成代码。

## 直接重定向仍然更有优势的场景

尽管结账会话功能丰富，但在一些场景中，直接重定向确实更好。

当链接本身就能完成任务时：社交媒体上的活动 URL、群发营销邮件，或销售人员递出一张带二维码的卡片。链接本身就是集成，让它承担更多功能反而过度设计。

当你没有服务端代码时：没有后端的静态营销网站无需任何基础设施，就可以放置支付链接。接入结账会话则需要服务端调用来创建会话，至少要搭建一个小型服务器。

当你希望获得最大的持久性时：一次生成的支付链接可以持续使用数月甚至数年。结账会话是在购买时创建的，因此创建时的任何临时问题都会阻止买家继续购买。对于可靠性比可配置性更重要的高风险活动，链接更加简单。

当你不需要元数据或匹配时：如果最终支付会由人工查看，或通过买家电子邮件进行匹配，那么会话的元数据优势就没有意义。

这些都是真实的使用场景，但它们只占 SaaS 和 AI 产品结账流程中的少数。大多数应用内流程都能从会话中获得足够多的好处，因此值得承担相应的集成成本。

## Dodo Payments 如何看待这两种方式

Dodo Payments 同时支持这两种模式。对于稳定 URL 就是完整集成的简单场景，你可以使用支付链接。对于其他场景，你可以使用结账会话，它提供丰富的配置参数、预览支持、元数据、多产品购物车，以及与内嵌和托管式结账界面的集成。

对于应用内的产品结账流程，我们建议使用结账会话。你可以获得更清晰的数据流、更准确地将支付匹配到应用记录，并灵活处理业务实际需要的各种定价或产品变化。对于简单性比可配置性更重要的营销和活动，支付链接仍然非常实用。

创建调用的完整参考位于 [结账会话指南](https://docs.dodopayments.com/developer-resources/checkout-session)。本文介绍的是整体思路和模式；文档则包含请求和响应结构、预览端点以及完整参数列表。

## 总结

直接重定向和结账会话并不是竞争关系，而是针对不同集成形态的不同工具。直接重定向是一个链接，结账会话是一个 API。正确的选择取决于你的结账流程基本固定，还是会根据买家或上下文真正发生变化。

对于包含任何应用内升级、套餐变更、充值或按用户定价的 SaaS 或 AI 产品，结账会话几乎总是正确选择。集成成本确实存在，但并不高；而且在每个使用它的流程中，运维收益都会不断累积。当链接本身就是完整集成时，选择直接重定向。当结账属于应用逻辑的一部分时，选择结账会话。

## 常见问题

### 我可以在支付链接和结账会话中使用相同的产品吗？

可以。产品目录是共享的。你只需在控制台中创建一次产品，然后根据流程选择合适的界面进行销售。一个产品既可以作为稳定的支付链接用于营销，也可以作为结账会话用于应用内购买，无需重复创建。

### 结账会话的有效期有多长？

默认情况下，会话从创建起二十四小时内有效。如果创建会话时设置了 confirm 标志，有效期会缩短至十五分钟。当你希望降低过期会话被使用的可能性时，较短的有效期很有用；当买家可能稍后回来完成已开始的购买时，较长的有效期则更合适。

### 会话中的元数据与客户对象有什么区别？

客户对象包含标准账单信息，例如电子邮件、姓名和地址。元数据是你为自身用途附加到会话上的任意键值数据。平台会读取客户对象，用于驱动税费和账单逻辑；元数据对平台而言是不透明的，并会在 webhook 中原样返回给你。

### 我可以在创建会话前预览税费吗？

可以。预览端点接受与创建端点相同的参数，并返回包含税费在内的计算总额，但不会创建真实会话。这是在买家点击结账前向其展示准确总额的最简洁方式。

### 我应该在每次产品页面浏览时创建结账会话，还是只在买家点击结账时创建？

应在买家点击时创建，而不是在页面浏览时创建。如果买家并未实际进入结账流程，会话会消耗一些平台资源并产生不必要的状态。在点击时创建会话带来的性能影响很小，因此几乎适用于所有流程。
---
- [More Checkout articles](https://dodopayments.com/blogs/category/checkout)
- [All articles](https://dodopayments.com/blogs)