支付宝订阅支付接入：从签约到自动续费

做面向国内用户的线上产品，收款很难绕开支付宝，微信支付也是同一层面的选择。用户买一张月卡，希望用手机里已经装好的支付工具完成付款。支付宝、微信支付也被列在人民银行的在华支付指南里，作为常用的移动支付选项。

假设应用卖一张 99 元的月卡，付款成功后，商户把用户的会员有效期延长一个月。改成连续包月，就还要安排下期扣款，处理用户在这期间的套餐变更和退订。

以退订为例：用户 9 月 1 日开通，9 月 20 日关闭自动续费。商户需要停掉下一期扣款，但已经收过钱的这期服务仍要保留到 10 月 1 日。

这时如果用户表里只有一个 is_vip，取消时把它改成否，就会提前结束本期服务；保留为是，又记不下用户已经要求停止续费。

支付宝面向 AI 行业提供的 Token Pay 连续订阅，有商品、价格、签约、续费和套餐变更接口。商户用它管理用户订了什么、何时到期、是否继续续费，再把结果接到自己的会员系统里。

下面用一个假设的 AI 作图工具举例：花店用它给新到的花束换背景、做海报，基础版每月 99 元，进阶版每月 199 元。价格、额度和日期都是示例。

支付宝订阅支付怎么开通

先从AI 连续订阅产品页进入，确认应用能否申请，再开始写接口。已经能用支付宝收取单笔费用，并不代表已经开通连续订阅。

个人开发者能接吗

Token Pay 当前公开准入条件要求支付宝企业账号，还需满足经营类目要求并通过审核。个人支付宝账号不在这份准入范围里；独立开发者以企业主体申请时，也需要核对账号、类目和审核条件。

软件开发服务、互联网数据服务、在线工具等在列，完整范围可在官方产品介绍的“准入条件”中核对。不符合所列条件的商户，产品页另有信息提交入口。

接入要做哪几步

完成产品开通、应用与签名配置，以及所需的代调用授权后，接入顺序可以分成四步：

1. 创建商品和价格，确定金额、周期与服务内容。
2. 建立客户与业务账号的对应关系，创建订阅。
3. 展示支付宝签约支付入口，接收购买结果。
4. 处理续费、升级和取消通知，同步业务权益。

官方也提供低代码商品列表和用户门户。页面可以交给平台，图片生成额度和业务账号仍由应用管理。

接入前，先建好商品和价格

花店老板看到的是一张套餐页：基础版每月 99 元，或者一年 990 元。两种付款方式买到相同的功能；进阶版则给更多生成额度，月费 199 元。

支付宝用 Product 记录商品，用 Price 记录售价和循环计价规则。基础版可以是一个 Product，下面挂月付、年付两个 Price。套餐页上的连续包月、连续包年，在这里对应不同的价格与周期。选年付的用户还在使用基础版，用不着把商品说明再抄一遍。

用户选好价格后，商户创建 Subscription。请求里的 customer_id 指向客户，items 列出订阅项，每一项用 price_id 指定要购买的价格。于是，同一个基础版月付价格可以被一千人选中，每个人都有自己的订阅，也各有续费日期。

图中的字段来自公开接口；连线表示对象关系，省略了与这里无关的字段。

把它放回作图工具的数据库，商户还要保存业务账号与 customer_id 的对应关系。支付平台知道这位客户订了基础版，图片服务知道他已经生成了多少张图。这两边通过账号关联起来，花店老板才会在付费后看到可用额度。

如果商品说明写着“每月 300 张”，额度发放和扣减仍由图片服务执行。支付接口里的商品说明只是文字，不能替模型调用计数。

年付用户还会遇到一个差别：钱一年收一次，额度每月发一批。续费周期和额度周期不能共用同一个日期字段。否则，程序等了一年才收到下一次续费通知，用户却从第二个月起就在等新额度。

支付宝订阅接口：创建订阅与签约支付

创建基础版月付订阅，可以把业务参数写成这样。这里省略公共签名参数，ID 使用占位值：

{
  "customer_id": "CUSTOMER_ID",
  "items": [{ "price_id": "BASIC_MONTHLY_PRICE_ID" }],
  "deduct_type": "SUBSCRIBE_DEDUCT"
}

调用的是 alipay.trade.subscription.create。返回值里有 subscription_id、order_no，以及供跳转或生成二维码使用的链接。用户还要进入支付宝，确认签约并完成首笔支付。拿到创建结果时，他可能还没拿起手机。

这里有三个容易混用的编号。subscription_id 标识订阅；order_no 是创建或升级时生成的支付请求单号；trade_no 是支付宝交易号，可用于查询支付明细。一份订阅会经历首购、续费、升级，不能只在数据库里留一个“订单号”来装下这些记录。

支付后，支付宝发来 alipay.trade.subscription.changed 通知。change_type 说明发生了什么，订阅对象里的 subscription_status 说明目前是什么状态。前者有首次生效的 active、续费成功的 period_extend、升级成功的 item_update；后者则使用 ACTIVE 等状态值。大小写不同，含义也不同。

续费成功时，订阅仍可处于 ACTIVE，但本期结束时间已经向后移动。如果程序只在状态从“未生效”变成“生效”时发放额度，它就会漏掉第二个月。

自动续费与周期扣款由谁发起

创建参数里的 SUBSCRIBE_DEDUCT 是默认托管模式，后续由支付宝自动扣款。接口也提供 MERCHANT_DEDUCT，由商户发起扣款。同一套订阅对象，允许商户选择是否把扣款安排交给平台。

在托管模式下，作图工具接收续费结果，按新的周期延续服务。它不用为每位花店老板安排下一次扣款，却仍要处理生成额度：按月到账的 300 张不能漏发，也不能多发。

续费失败以后，服务到哪天

支付宝公开接入指南描述了默认托管流程：平台发送扣款预通知，在到期前尝试扣款并重试；到期仍未成功，则停止扣款并解约。商户收到结果后，需要核对订阅状态与有效期，再决定停止哪些服务。

作图工具若准备给欠费用户保留几天下载时间，这段宽限由应用自己执行。收款重试、订阅期限和文件保留时间，各自解决不同的问题。

套餐升级、取消续费与退款怎么处理

到了节日前，花店要上架一批花束。背景、包装和文案要试几个版本，基础版的额度开始不够用，老板准备换成进阶版。

如果这时恰好用完半个周期，商户允许按时间抵扣，并保留原续费日期，费用可以这样算：基础版剩下的半期值 49.50 元，进阶版的半期费用是 99.50 元，补 50 元。下期再收完整的 199 元。

支付宝通过订阅修改接口处理升级。modify_type=UPGRADE 指明操作；preserve_billing_cycle=true 保留周期；不传 pay_amount 时按平台规则计算，商户也可传入自定义金额，单位是分。升级会返回确认支付入口，用户完成支付后再通知商户变更结果。

图里选半个周期，是为了把差价算清楚。实际金额要按平台时间规则计算。但还有一个比计算精度更早的问题：如果这家花店已经用完本月 300 张额度，商户还愿不愿意退抵一半月费？按时间抵扣适合某些服务，按次数消耗的工具却可能已经付出了大半成本。接口能接受一个金额，金额背后的生意还得自己算。

取消续费则不用碰这笔差价。回到开头那张月卡，商户可以通过修改接口设置 modify_type=CANCEL、cancel_at_period_end=true，让订阅在本期结束后取消。当前服务期限和下期续订意愿分别保存，is_vip 装不下的信息，在这里有了位置。

取消下一期续费和退还本期费用要分别处理。上面的周期末取消保留本期服务；如果要立即取消并退款，需要按订阅修改接口的相应参数与退款规则操作。

对图片服务来说，下一步是拿到 current_period_end，按约定保留本期权限。老板关闭续费后，可能还在下载已经做好的海报。程序若一收到取消安排就封掉下载入口，账算对了，服务却少给了。

与 Stripe 的订阅实现有哪些差异

支付宝与上一篇介绍的 Stripe都有商品、价格和订阅，也都能处理续费、升级与取消。比较这两家，要看的是费用怎样记录、支付怎样衔接，以及一次套餐变更什么时候生效。

账单与支付请求

Stripe 把订阅放在 Billing 里。每个计费周期，Subscription 生成 Invoice，列出本期应收费用，再进入支付流程。月费、升级补差和额外的一次性收费，都可以成为账单项目。这里的 Invoice 是计费账单。订阅账单、账单项目

支付宝公开的这套接入围绕订阅操作展开：创建或升级订阅，取得支付请求单号和确认入口，支付完成后接收订阅变更通知。商户沿着 subscription_id、order_no 和 trade_no，关联订阅、支付请求与交易。

虽然都和收费有关，order_no 与 Invoice 不能一一对应：前者用来追踪一次支付请求；后者记录客户应付哪些费用，有自己的账单项目和状态。图中按公开产品与接口归纳职责，展示普通付费订阅的主要关系。

同样补 50 元，接口怎么走

把前面的升级放进 Stripe：旧套餐剩余时间的抵扣、新套餐剩余时间的费用，会形成按比例计费的账单项目。生成这些项目以后，什么时候出账、什么时候收钱，还受配置控制。例如，在自动收款的订阅更新中设置 proration_behavior=always_invoice，就会为补差出账并尝试收款。按比例计费、更新订阅

“更新了套餐”也不必然表示“升级款已付清”。如果要求付款后才生效，Stripe 提供 payment_behavior=pending_if_incomplete，在支持的自动收款场景中，让变更等待新账单付款成功；需要用户补充认证时，还要处理相应的支付流程。Pending updates

支付宝公开指南给出的升级流程则是：商户提交 UPGRADE，平台计算差价或使用商户传入的金额，返回支付宝确认支付入口，用户付款后发出升级结果通知。商户按这一过程接好“升级”按钮，再根据结果开通新套餐。

对按固定月费销售的作图工具，支付宝这组操作能对应购买、升级、取消几个页面动作。如果以后要把月费、额外服务费放进同一张应收账单，再安排账期，Stripe 的 Invoice 模型就有了用处。它也带来更多需要理解的账单状态和收款配置。两套设计各有取舍，要用自己的收费规则去试，不能数一数接口层次就决定谁更合理。

与微信通用代扣相比，订阅方案省了哪些工作

在国内做自动续费，微信支付是另一个需要认真看的方案。它的通用委托代扣支持自动续费业务，也有扣费前通知、用户解约和扣款结果通知。接入前需要申请代扣权限及模板，普通收款权限不能替代它们。

都能自动续费，每期请求由谁发起

微信的自动续费模式要求商户发起每期扣款申请，传入协议标识、订单号和金额。选用“通知后 24 小时扣费”模式时，商户提交申请，微信向用户发送通知，等待后执行这笔扣款。这里讨论后续续费，首次签约后的首笔扣款另有规则。

另一种“预扣费通知”模式把通知接口分开：商户先提交预计金额，经过等待期，再在可扣费期内请求扣款。金额、时间窗口和重试都受到规则约束。微信承担了这些支付侧工作，不能把它理解成任意时候传一个金额就能扣钱的接口。

支付宝的默认托管订阅则接过了后续周期扣款安排，商户接收订阅变化。下面用微信的“通知后 24 小时扣费”模式画一次续费分工：

微信还有预约扣费、保险代扣等接入路径，它们有各自的场景和准入。这里的对照范围是软件会员会用来评估的通用委托代扣自动续费模式。

少维护哪些订阅程序

支付宝的 Product、Price 和 Subscription 可以记录用户买了哪个套餐、按什么周期续费，升级与取消也有相应接口。微信这套通用代扣接入围绕模板、签约协议和扣款订单展开；作图工具的套餐、会员期限和升级规则，主要保存在商户自己的系统里。

假设作图工具有一千位付费用户，有人月付、有人年付，还有人刚升了套餐或关掉续费。走微信通用代扣，商户要从自己的订阅记录里找出本期该收谁的钱、收多少，再按规则发起申请。接入支付宝托管订阅后，后续收款按平台记录的套餐和周期安排；升级和期末取消有对应操作，应用接收结果，再更新期限与额度。

托管订阅省下的开发工作，就在续费调度、套餐变更和扣款结果衔接这些地方。原本需要自己维护的通用逻辑，有一部分可以交给平台。图片额度怎么算、生成失败是否返还次数，仍是作图工具自己的业务。

如果商户已经有成熟的会员与计费系统，或需要兼容多个支付渠道，沿用自己的订阅记录、让微信代扣执行收款，也有道理。这时引入另一套商品与价格记录，还要做同步；保留现有计费系统可能更省事。支付宝也提供 MERCHANT_DEDUCT 模式，商户可以保留扣款发起权；上面列出的托管优势，须结合所选模式来看。

支付宝订阅回调：验签、去重与权益同步

剩下一段程序在商户这边。

假设支付宝已经收到 99 元，作图工具给账号发了 300 张额度，但返回通知处理结果时网络断了。支付宝没有收到确认，稍后重发通知。如果程序再加一次额度，用户只付了一次钱，却拿到了 600 张。

公开通知协议提供 notify_id，要求商户验签，并用 success 应答；处理失败会重试。对应到商户实现，我会先核验签名及应用归属，把通知持久化，再确认接收。后续处理除按通知 ID 去重，还要让同一笔续费的额度发放保持幂等，例如按已确认的交易号记录发放结果。这里是一种商户实现思路，具体键值仍需结合交易与权益规则。

订阅快照和额度流水也值得分开。前者保存现在的套餐、状态、周期和取消安排；后者记录哪次购买发了多少额度、哪次生成用了多少。收到通知后，可结合订阅查询核对当前记录。这样客服查“付过钱为什么不能用”时，能沿着交易、订阅和额度三处往下找。

花店老板不需要知道这些编号。他需要的是 99 元付出去以后能继续做图，升套餐时旧月费没有白付，关掉续费以后还能下载本月的海报。商户接入订阅平台，最后交付的仍是这几件事。

文中依据截至 2026 年 9 月 20 日的公开官方资料，图示及代码均作了节选。实际接入条件与参数以官方说明为准。支付宝部分可参阅《个体订阅接入指南》，微信部分可从《委托代扣接入流程》查起。

返回订阅专题