Dodo Payments 转化漏斗优化

这个技能解决什么问题

把 Dodo Payments 接进真实业务，通常会同时碰到四类问题：

• 怎么收款：后端直接调 REST API 取款 / 创建订阅，还是用托管 Checkout Session、可嵌入 Checkout 或框架适配器？
• 事件可不可信：Dodo 会往你的 endpoint 推 payment / subscription / refund / license 等生命周期事件，收到后如何验签、防重放，并据此开通权益？
• MoR 取舍：Dodo 作为 Merchant of Record 替你申报并代缴全球销售税 / VAT / GST，费率约 4% + $0.40；裸支付处理器约 2.9% + $0.30。这笔钱值不值得多付？
• 数字商品交付：如何用 license keys 与 entitlements 接口完成软件授权的签发、激活、吊销和数字交付？

技能如何工作

它不是一段会背文档的提示词，而是一份分阶段的路由手册：

• Step 1 收集上下文：若存在 references/learnings.md 先读它，再用问题清单确认目标是取款、搭 Checkout、验 webhook、卖数字商品、处理税务退款，还是做 MoR 选型；上下文足够时直接跳到下一步。
• Step 2 路由或直接回答：跨厂商选型交给 /sales-merchant-of-record，Checkout 转化策略交给 /sales-checkout，数字商品销售交给 /sales-digital-products，接到 CRM/ESP 交给 /sales-integration，并输出确切的调用命令。
• Step 3 查平台参考：按需查阅 references/platform-guide.md（MoR 责任边界、订阅/用量/额度/一次性计费、API 与托管对象的划分）和 references/dodo-payments-api-reference.md（test / live.dodopayments.com、Authorization: Bearer 鉴权、只读与读写密钥、分层限流、端点目录、Standard Webhooks 签名、9 个 SDK 与 MCP server），只取相关段落，不整篇倾倒。
• Step 4 给工程结论：能上官方 SDK 或框架适配器就别手写 HTTP（TS/Python/Go/PHP/Java/Kotlin/C#/Ruby/React Native，以及 Next.js、Express、Hono、SvelteKit 适配器）；用 standardwebhooks 库验签而不是手写 HMAC；开发期用 dodo wh trigger 在本地触发事件联调。

适用边界与注意点

• MoR 费用确实高于裸处理器，换来的是免除多司法辖区税务注册与申报；若你想自己扛税务合规来压低费率，这个技能会建议走别的路径。
• test.dodopayments.com 对测试密钥、live.dodopayments.com 对正式密钥，主机与密钥模式混用会返回 401；写操作还要用读写密钥。
• 限流是双窗口分层（默认 40/秒 + 240/分），需要读 X-RateLimit-* 响应头并在 429 时退避。
• MoR 不等于即时到账：Dodo 按排期结算付款，现金流模型要照此设计。
• webhook 事件名必须按官方文档确认，不能凭猜测写分支；dodo wh trigger 的 mock 是未签名的，unsafe_unwrap() 只能在测试里用。
• 资料来自 2026-06 的调研，API 与定价对照 docs.dodopayments.com 核验，最终要以账户内现行条款为准。
• 超出 Dodo 自身能力面的跨厂商策略问题，会被路由给相关 /sales-* 技能，本技能不做完整的多厂商决策。