Skip to main content
@dodopayments/express 适配器为 Express 应用提供三个路由处理程序:checkoutHandler 返回 checkout URL,CustomerPortal 将客户发送到 Customer Portal,而 Webhooks 则验证 webhook 请求并调用事件处理程序。

Checkout Handler

从 Express 应用创建 payment links 和 checkout sessions。

Customer Portal

让客户管理其订阅和详细信息。

Webhooks

验证并处理 Dodo Payments webhook 事件。

安装

1

Install the Package

在项目根目录中运行以下命令:
2

Set Up Environment Variables

在项目根目录中创建一个 .env 文件:
在 Developer → API Keys 下创建 API key。在 Developer → Webhooks 下添加 webhook endpoint,并将其 signing secret 复制到 DODO_PAYMENTS_WEBHOOK_KEY 中。构建期间,请将 test mode API key 与 DODO_PAYMENTS_ENVIRONMENT=test_mode 一起使用,因为 test mode key 只能用于 test mode。DODO_PAYMENTS_RETURN_URL 是可选的。
切勿将 .env 文件或 secrets 提交到版本控制系统。

路由处理程序示例

这些示例会在使用 express() 创建的 Express 应用上注册路由。POST checkout 处理程序和 webhook 处理程序会读取 req.body,因此每个示例都会在其路由之前注册 express.json()。
使用此处理程序将 Dodo Payments checkout 集成到 Express 应用中。支持 static(GET)、dynamic(POST)和 session(POST)payment flows。请为每个 POST flow 注册独立路径,因为针对某一路径注册的第一个处理程序会响应该路径的所有请求。

Checkout 路由处理程序

该适配器支持全部三种 Dodo Payments checkout flows。在处理程序配置中将 type 设置为要由路由提供的 flow。每种 flow 都会返回包含 checkout_url 的 JSON,供客户打开。
  • Static Payment Links: type: "static",GET。根据 query parameters 为一个产品创建 payment link,并先检查该产品是否存在。
  • Dynamic Payment Links: type: "dynamic",POST。根据产品是否为 recurring,通过 payment link 创建一次性 payment 或 subscription。
  • Checkout Sessions: type: "session",POST。根据 product cart 和 customer details 创建 checkout session。新集成应使用此 flow。
checkoutHandler 接受以下选项: 当 type 为 static 时,为 GET 注册处理程序;当其为 dynamic 或 session 时,为 POST 注册处理程序。对于其他方法,处理程序会返回 405。

支持的 Query Parameters

string
必填
产品标识符,例如 ?productId=pdt_nZuwz45WAs64n3l07zpQR。
integer
默认值:"1"
产品数量。
string
客户的全名。如果提供了 firstName 或 lastName,则忽略此项。
string
客户的名字。
string
客户的姓氏。
string
客户的电子邮件地址。
string
客户所在国家/地区,使用 ISO 3166-1 alpha-2 代码。
string
客户的街道地址。
string
客户所在城市。
string
客户所在州或省。
string
客户的邮政编码或 ZIP code。
boolean
设置为 true 以禁用全名字段。
boolean
设置为 true 以禁用名字字段。
boolean
设置为 true 以禁用姓氏字段。
boolean
设置为 true 以禁用 email 字段。
boolean
设置为 true 以禁用 country 字段。
boolean
设置为 true 以禁用 address line 字段。
boolean
设置为 true 以禁用 city 字段。
boolean
设置为 true 以禁用 state 字段。
boolean
设置为 true 以禁用 ZIP code 字段。
string
支付货币,例如 USD。
boolean
默认值:"true"
显示或隐藏 currency selector。
number
固定收取的金额(以主要货币单位表示),例如 12.5 表示 $12.50。仅适用于 Pay What You Want 产品;如果金额低于产品最低价格,则会被忽略。
boolean
默认值:"true"
显示或隐藏 discounts 部分。
string
所有以 metadata_ 开头的 query parameter 都会作为 metadata 传递给 checkout,例如 metadata_orderId=123。
只有当 disable flag 为 true 且对应字段有值时,该 flag 才会生效,例如 email 与 disableEmail 一起使用时。处理程序会将这些参数传递给 static payment link。
如果缺少 productId,处理程序会返回 400 响应。无效的 query parameters 或账户中不存在的产品也会导致 400 响应。

响应格式

Static checkout 返回包含 checkout URL 的 JSON 响应:
  • 在 POST 请求中将参数作为 JSON body 发送。
  • 支持一次性 payment 和 recurring payments。处理程序会获取产品,然后在产品为 recurring 时创建 subscription,否则创建一次性 payment。
  • body 需要 billing(包括 street、city、state、country 和 zipcode)以及 customer,另外还需要 product_id(可选的 quantity)或 product_cart。Subscriptions 需要 product_id。
  • 处理程序还会转发 metadata、allowed_payment_method_types、billing_currency、discount_codes(或已弃用的 discount_code)、return_url、show_saved_payment_methods 和 tax_id。对于 subscriptions,还会转发 addons、on_demand 和 trial_period_days。其他字段会被忽略。
  • 有关字段详情,请参阅:
Dynamic Checkout 会调用已弃用的 POST /payments 和 POST /subscriptions endpoints。新集成请使用 Checkout Sessions。

响应格式

Dynamic checkout 返回包含 payment link(作为 checkout URL)的 JSON 响应:
将 checkout session payload 作为 JSON body 发送。处理程序会创建 checkout session,该 session 会处理一次性购买和 subscriptions 的完整 payment flow,并返回其 checkout_url。product_cart 是必需的,并且必须至少包含一个产品。每个 checkout_url 只能使用一次,并会在 24 小时后过期;如果传递 confirm: true,则会在 15 分钟后过期。使用 payment_method_id 创建的 session 不会返回 checkout_url,因此处理程序会返回 400。如需更多详情及完整的支持字段列表,请参阅 Checkout Sessions Integration Guide。

响应格式

Checkout sessions 返回包含 checkout URL 的 JSON 响应:

Customer Portal 路由处理程序

Customer Portal 路由处理程序会为 customer_id 中的客户创建 Customer Portal session,并将请求重定向到 portal link。CustomerPortal 接受 bearerToken 和 environment 选项,与 checkoutHandler 相同。如果 Dodo Payments 无法创建 session,处理程序会返回 500。

Query Parameters

string
必填
portal session 的 customer ID,例如 ?customer_id=cus_123。
boolean
如果设置为 true,则会向客户发送包含 portal link 的 email。
如果缺少 customer_id,则返回 400。处理程序不会对请求进行身份验证,并会为其接收到的任何 customer_id 打开 portal,因此请将该路由置于你自己的身份验证机制之后,并仅传递已登录用户的 customer ID。

Webhook 路由处理程序

Webhook 处理程序使用作为 webhookKey 传入的 webhook secret 验证每个请求,然后调用你的事件处理程序。
在 webhook route 之前注册 express.json()。处理程序会根据 req.body 验证 signature,因此除非 body 是经过解析的 JSON,否则会拒绝所有请求。不要在此 route 中使用 express.raw()。
  • Method: 仅支持 POST 请求。其他方法返回 405。
  • Signature Verification: 根据 Standard Webhooks specification,使用 webhookKey 验证 webhook-id、webhook-timestamp 和 webhook-signature headers。验证失败时返回 401。
  • Payload Validation: 使用 Zod 验证。payload 无效时返回 400。
  • Error Handling:
    • 401:无效 signature
    • 400:无效 payload
    • 500:验证期间发生内部错误
  • Event Routing: 对每个事件调用 onPayload,然后调用该事件类型对应的处理程序,并在处理完成后返回 200。处理程序不会捕获你的事件处理程序抛出的错误。

支持的 Webhook 事件处理程序

每个处理程序都是可选的 async 处理程序。有关每个事件的 payload,请参阅 Webhook Event Guide。

LLM 提示词

最后修改于 2026年9月26日