更改计划 API 参考
访问完整的 API 文档,以交互方式测试更改订阅计划的请求。
预览计划变更 API
在提交计划变更之前,预览确切的收费金额。
订阅集成指南
通过我们的综合集成指南,了解如何从头开始创建和管理订阅。
什么是订阅升级或降级?
更改计划允许您在订阅层级或数量之间移动客户。使用它来:- 根据使用情况或功能调整定价
- 从按月计费转为按年计费(或反之)
- 调整基于座位的产品数量
计划变更可能会根据您选择的按比例计费模式触发立即收费。
何时使用计划变更
- 当客户需要更多功能、使用量或座位时进行升级
- 当使用量减少时进行降级
- 在不取消订阅的情况下将用户迁移到新产品或价格
前提条件
在实施订阅计划变更之前,请确保您拥有:- 一个具有活跃订阅产品的 Dodo Payments 商户账户
- 从仪表板获取的 API 凭证(API 密钥和 Webhook 密钥)
- 一个现有的活跃订阅以进行修改
- 配置好的 Webhook 端点以处理订阅事件
有关详细的设置说明,请参见我们的 集成指南。
分步实施指南
按照此综合指南在您的应用程序中实施订阅计划变更:选择您的按比例计费策略
选择与您的业务需求相符的计费方法:
- prorated_immediately
- difference_immediately
- full_immediately
最佳适用:希望公平收费未使用时间的 SaaS 应用程序
- 根据剩余周期时间计算确切的按比例金额
- 根据周期中剩余的未使用时间收取按比例金额
- 为客户提供透明的计费
处理 Webhook 事件
设置 Webhook 处理以跟踪计划变更结果:
subscription.active: 计划变更成功,订阅已更新subscription.plan_changed: 订阅计划已更改(升级/降级/附加更新)subscription.on_hold: 计划变更收费失败,订阅已暂停payment.succeeded: 计划变更的即时收费成功payment.failed: 即时收费失败
预览计划变更
在提交计划变更之前,使用预览 API 向客户显示他们将被收取的确切金额:- Node.js SDK
- Python SDK
更改计划 API
使用更改计划 API 修改活跃订阅的产品、数量和按比例计费行为。快速入门示例
- Node.js SDK
- Python SDK
- Go SDK
- HTTP
Success
像
invoice_id 和 payment_id 这样的字段仅在计划变更期间创建立即收费和/或发票时返回。始终依赖 Webhook 事件(例如,payment.succeeded, subscription.plan_changed)来确认结果。管理附加组件
在更改订阅计划时,您还可以修改附加组件:附加组件包含在按比例计算中,并将根据所选的按比例计费模式收费。
按比例计费模式
选择在更改计划时如何向客户收费:prorated_immediately
- 当前周期的部分差额收费
- 如果在试用期内,立即收费并切换到新计划
- 降级:可能会生成一个按比例计算的信用额度,适用于未来的续订
full_immediately
- 立即收取新计划的全额
- 忽略旧计划的剩余时间
使用
difference_immediately 进行降级所创建的信用是订阅范围内的,并且与 客户信用 不同。它们会自动应用于同一订阅的未来续订,并且不可在订阅之间转移。difference_immediately
- 升级:立即收取旧计划和新计划之间的价格差
- 降级:将剩余价值作为内部信用添加到订阅中,并在续订时自动应用
示例场景
升级:基础 ($30) → 专业 ($80) 使用 difference_immediately
升级:基础 ($30) → 专业 ($80) 使用 difference_immediately
降级:加 ($50) → 入门 ($20) 使用 difference_immediately
降级:加 ($50) → 入门 ($20) 使用 difference_immediately
中途升级使用 prorated_immediately
中途升级使用 prorated_immediately
使用 full_immediately 重置计费
使用 full_immediately 重置计费
处理 Webhook
通过 Webhook 跟踪订阅状态以确认计划变更和付款。需要处理的事件类型
subscription.active: 订阅已激活subscription.plan_changed: 订阅计划已更改(升级/降级/附加更改)subscription.on_hold: 收费失败,订阅已暂停subscription.renewed: 续订成功payment.succeeded: 计划变更或续订的付款成功payment.failed: 付款失败
我们建议根据订阅事件驱动业务逻辑,并使用付款事件进行确认和对账。
验证签名并处理意图
- Next.js 路由处理程序
- Express.js
有关详细的有效负载架构,请参见 订阅 Webhook 有效负载 和 付款 Webhook 有效负载。
最佳实践
遵循以下建议以确保可靠的订阅计划变更:计划变更策略
- 彻底测试:在生产之前始终在测试模式下测试计划变更
- 仔细选择按比例计费:选择与您的商业模式相符的按比例计费模式
- 优雅地处理失败:实现适当的错误处理和重试逻辑
- 监控成功率:跟踪计划变更的成功/失败率并调查问题
Webhook 实施
- 验证签名:始终验证 Webhook 签名以确保真实性
- 实现幂等性:优雅地处理重复的 Webhook 事件
- 异步处理:不要用繁重的操作阻塞 Webhook 响应
- 记录所有内容:保持详细的日志以便调试和审计
用户体验
- 清晰沟通:告知客户有关计费变更和时间的信息
- 提供确认:发送成功计划变更的电子邮件确认
- 处理边缘情况:考虑试用期、按比例计费和付款失败
- 立即更新 UI:在您的应用程序界面中反映计划变更
常见问题及解决方案
解决在订阅计划变更过程中遇到的典型问题:创建收费但未更新订阅
创建收费但未更新订阅
症状:API 调用成功,但订阅仍保持在旧计划上常见原因:
- Webhook 处理失败或延迟
- 收到 Webhook 后应用程序状态未更新
- 状态更新期间的数据库事务问题
- 实施强大的 Webhook 处理和重试逻辑
- 对状态更新使用幂等操作
- 添加监控以检测和警报未接收的 Webhook 事件
- 验证 Webhook 端点是否可访问并正确响应
降级后未应用信用
降级后未应用信用
症状:客户降级但未看到信用余额常见原因:
- 按比例计费模式的期望:降级时使用
difference_immediately全额信用计划价格差,而prorated_immediately根据周期内剩余时间创建按比例计算的信用 - 信用是特定于订阅的,不能在订阅之间转移
- 客户仪表板中不可见的信用余额
- 在希望自动生成信用时,使用
difference_immediately进行降级 - 向客户解释信用适用于同一订阅的未来续订
- 实施客户门户以显示信用余额
- 检查下一个发票预览以查看应用的信用
Webhook 签名验证失败
Webhook 签名验证失败
症状:由于无效签名而拒绝 Webhook 事件常见原因:
- Webhook 密钥不正确
- 在签名验证之前修改了原始请求体
- 错误的签名验证算法
- 验证您是否使用了仪表板中的正确
DODO_WEBHOOK_SECRET - 在任何JSON解析中间件之前读取原始请求体
- 使用您平台的标准Webhook验证库
- 在开发环境中测试Webhook签名验证
计划变更失败,返回 422 错误
计划变更失败,返回 422 错误
症状:API 返回 422 无法处理的实体错误常见原因:
- 无效的订阅 ID 或产品 ID
- 订阅不在活动状态
- 缺少必需的参数
- 产品不适用于计划变更
- 验证订阅是否存在且处于活动状态
- 检查产品 ID 是否有效且可用
- 确保提供所有必需的参数
- 查看 API 文档以获取参数要求
计划变更期间立即收费失败
计划变更期间立即收费失败
症状:计划变更已启动,但立即收费失败常见原因:
- 客户的支付方式资金不足
- 支付方式过期或无效
- 银行拒绝交易
- 欺诈检测阻止了收费
- 适当地处理
payment.failedwebhook事件 - 通知客户更新付款方式
- 实施临时故障的重试逻辑
- 考虑允许在即时收费失败的情况下进行计划更改
计划变更后订阅暂停
计划变更后订阅暂停
症状: 计划变更收费失败,订阅转到需要监控的Webhook事件:
on_hold状态发生了什么:
当计划变更收费失败时,订阅会自动置于on_hold状态。订阅将不会自动续订,直到更新付款方式。解决方案:更新支付方式以重新激活订阅要从on_hold状态重新激活订阅,需在计划变更失败后:- 使用更新付款方式API更新付款方式
- 自动创建收费: API会自动为剩余欠款创建收费
- 生成发票: 为收费生成发票
- 处理付款: 使用新付款方式处理付款
- 重新激活: 在成功付款后,订阅重新激活为
active状态
subscription.on_hold: 订阅被暂停(当计划变更收费失败时接收)payment.succeeded: 剩余欠款的付款成功(在更新付款方式后)subscription.active: 在成功付款后重新激活订阅
- 在计划变更收费失败时立即通知客户
- 提供有关如何更新支付方式的清晰说明
- 监控 Webhook 事件以跟踪重新激活状态
- 考虑为临时付款失败实施自动重试逻辑
更新支付方式 API 参考
查看更新支付方式和重新激活订阅的完整 API 文档。
测试您的实现
按照以下步骤彻底测试您的订阅计划变更实现:测试不同的按比例计费模式
- 测试
prorated_immediately与各种计费周期位置 - 测试
difference_immediately用于升级和降级 - 测试
full_immediately以重置计费周期 - 验证信用计算是否正确
错误处理
优雅地处理实现中的常见 API 错误:HTTP 状态代码
200 OK
200 OK
计划变更请求已成功处理。订阅正在更新,付款处理已开始。
400 Bad Request
400 Bad Request
无效的请求参数。检查所有必需字段是否已提供并正确格式化。
401 未授权
401 未授权
无效或缺失的API密钥。请验证您的
DODO_PAYMENTS_API_KEY是否正确并具有适当的权限。404 Not Found
404 Not Found
未找到订阅 ID 或该 ID 不属于您的账户。
422 Unprocessable Entity
422 Unprocessable Entity
无法更改订阅(例如,已取消、产品不可用等)。
500 Internal Server Error
500 Internal Server Error
发生服务器错误。稍后重试请求。
错误响应格式
下一步
- 查看 更改计划API
- 探索 客户信用
- 实施对
subscription.on_hold的警报 - 查看我们的 Webhook集成指南