✨ 利用 AI 安装
✨ 利用 AI 安装
将此提示复制到你的 AI 代码编辑器(Cursor、Copilot 等)中,即可创建收银台集成:
你将构建什么
收银台会话是一个动态生成的支付页面。相比分享静态的产品链接,你可以:- 预填客户邮箱
- 使用自定义 metadata 追踪订单
- 设置自定义成功 URL
- 为订阅产品启用试用期
- 按受众定制语言和支付方式
前置条件
- Waffo Pancake 账户
- API 密钥(Dashboard → API 与开发)
- 至少创建一个产品
基础收银台会话
最简单的收银台会话需要产品 ID 和货币。使用 TypeScript SDK(推荐)
直接使用 REST API
checkoutUrl 完成支付。
重定向最佳实践
推荐方式:successUrl。successUrl 原样使用,不替换任何占位符;要在成功页识别这笔购买,请在创建会话前把自己的标识(如内部订单号)写进 successUrl 的查询参数,并以 Webhook 为准确认付款。
预填客户邮箱
通过预填邮箱跳过邮箱输入步骤:按受众定制收银台
默认情况下,托管收银台是为全球受众配置的:开放该货币支持的全部支付方式、跟随买家浏览器语言、表单留空。面向全球销售时这是合理的默认值。但如果你的买家大多来自同一个市场,就应该收窄——买家只看到自己天天在用的那一种钱包、界面是母语、邮箱已经填好,犹豫和流失都会少得多。 收银台会话上有四个参数控制这件事,全部可选、互不依赖:做法
- 用买家实际付款的货币定价。 决定收银台能开放哪些支付方式的是货币,不是买家所在地。选货币前先看对应表。
- 把
language设成买家的语言。 买家分布在多个市场时可以不传,浏览器语言检测已经能处理。 - 把支付方式收窄到该市场在用的。 单一市场用
includePaymentMethods,只列买家认识的方式;多个市场更适合excludePaymentMethods——该货币本就不支持的取值会被忽略,同一份黑名单可跨货币复用。 - 买家已登录时一律预填
buyerEmail。 买家在你这里已经有账号,再让他填一次邮箱只会引出犹豫(「要不要和注册邮箱保持一致?」)。走已认证收银台时把buyerIdentity和buyerEmail一起传。 - 除非需要预填税务信息,不要传
billingDetail。 传了会把收银台锁定到该国的支付市场,买家无法切换。
示例
中国大陆
买家用微信支付、读简体中文。微信支付适用于以 CNY 或 USD 定价的一次性产品,单笔上限约 ¥1,000(≈ $140)。includePaymentMethods,让买家用卡支付。
日本
买家习惯 JPY 定价和日文界面。卡和各钱包都支持 JPY,没有需要收窄的——设好货币和语言,支付方式保持默认即可。多个市场
在请求时根据你已有的信号——账号所在国家、界面语言、买家选择的套餐——按买家挑配置。推断不出来的就不传,让收银台回落到默认行为。includePaymentMethods 里的每个取值都必须被你传入的「产品类型 × 货币」支持,否则请求会以 400 Payment methods not supported 失败。某种方式也可能在单笔订单上被隐藏——例如微信支付超过单笔上限——所以只开放一种方式时,确保定价落在它的限额内。使用 Metadata 追踪
将收银台会话与你的内部系统关联:orderMetadata 字段中传回。商户凭证(API Key)不能用 GraphQL 查询 checkoutSession。
订阅试用
为订阅产品启用试用期:按座位数量功能尚未通过 API 支持。一次性商品、新购订阅与更换方案可传
couponId 应用优惠券、传 promotionCode 预填码,或传 allowPromotionCodes: true 显示输码框 —— 见优惠与促销。订阅预填账单信息
为税费计算预填消费者的账单信息:动态成功 URL
将数据传递到成功页面:successUrl 会原样跳转,不会替换 {SESSION_ID} 之类的占位符。请自己把需要的标识拼进 URL,并以 Webhook 为准确认付款。
完整示例:SaaS 升级流程
这是一个使用 SDK 升级用户订阅的真实示例:参数参考
下一步
处理 Webhooks
在支付完成时获得通知
验证支付
安全验证 Webhook 签名