支付巨头们纷纷布局订阅支付领域，试图通过技术创新和业务拓展来抢占市场份额。本文将深入探讨订阅支付的业务流程、风控要点、技术实现方式以及主流支付平台的接口对比分析，帮助大家全面了解这一支付领域的竞争格局和发展趋势。

目录概览

• 主要参与方
• 典型信息流
• 风控与合规要点
• 案例：微信支付周期扣费产品业务流程
• 商户接口调用process
• 订阅支付的UML流程概览
• 主流竞品接口对比分析

主要参与方

• 用户：就是你我这样的消费者，想订阅个服务，比如会员、自动续费啥的，就得先发起请求，授权支付方式（比如绑卡），然后等着接收扣款通知。
• 商户：就是提供那些订阅服务的商家，比如视频网站、软件开发商。他们得配置好订阅计划，等收到支付结果后，就给你开通服务。
• 支付公司（聚合支付平台）：这帮家伙就像是支付界的“中间人”，把各种支付渠道都集成起来。他们得处理订阅的那些事儿，比如周期性扣款、扣款失败了咋办，还得负责资金清算和对账。
• 银行/卡组织：他们是“真金白银”的搬运工，负责实际的资金划转，还提供代收付接口和风控支持。
• 第三方服务商：比如 WildCard（虚拟卡）、Stripe（支付网关）这些，他们在一些特定场景下，给支付能力“加把劲”。

典型信息流

订阅发起阶段

用户（就是你咯）在前端页面上选好订阅计划，然后授权支付方式（比如填个虚拟卡信息）。

支付公司就会调用银行或支付网关的 API，生成一个订阅协议（比如 PayPal 的 Billing Agreement），顺便把扣款周期和金额给记下来。

做了8年产品经理后，我是这么看产品经理的

我个人是从非常初级的产品经理做起，再到负责一个大产品的项目管理，现在有幸跳出了日常基础的工作更多的去看产品的PMF，product strategy...

查看详情 >

商户收到订阅 ID 后，就会给你开通服务权限，你就能开始享受服务啦。

周期性扣款阶段

到了该扣款的时候，支付公司就会按周期触发扣款请求，通过银行或卡组织把钱划走。

扣款结果会通过 Webhook 通知商户（成功了就继续服务，失败了就提醒一下，具体细节流程见下文：订阅支付UML流程）。用户（还是你）会收到扣款通知，还能通过支付公司或商户平台管理订阅状态，比如查看、修改或者取消订阅。

异常处理阶段

支付失败：系统会自动尝试重试，要是还是不行，就暂停服务。这时候，得把失败原因（比如余额不足、风控拦截）记录下来，并且通知用户（还是你）。后续如能扣到款是否支持恢复服务？

取消订阅：要是用户（你）不想订阅了，发起取消请求后，支付公司就会终止扣款计划，并且把状态同步给商户。

业务方面：

如扣款周期已过，仍然没有扣款成功，是否立即停止用户的服务，具体业务场景措施肯定不同？

更改订阅计划：

• 正好在扣款等待期更改订阅计划，如订单金额和周期，如何处理。
• 扣款等待期是否允许修改，或者是否需要定义扣款等待期的变更计划下月生效？

Webhook消息丢失

商户系统检测到订阅一直处于pending状态（超过30分钟）。

调用支付平台提供的「订阅状态查询接口」主动补偿：

GET /v1/subscriptions/{subscription_id}

Response:

{

“status”: “active”,

“last_payment_time”:

“2024-05-20 14:00:00”

}

根据查询结果更新本地状态，并补发用户通知。

风控与合规要点

• 反欺诈：支付公司会结合 IP 检测、交易行为分析（比如有没有高频小额扣款这种异常行为）来拦截异常交易。像 WildCard 这种，还会针对高风控平台（比如 OpenAI）优化支付渠道。
• 数据隐私：大家都得遵循 GDPR 这些法规，把用户支付信息加密存储好。尤其是虚拟卡服务，得注意别让敏感信息泄露（比如 WildCard 就没有 KYC 选项）。
• 资金存管：支付公司要和银行合作，实现资金分账，确保商户结算合规，别出现什么二清风险。

案例：微信支付周期扣费产品业务流程

下发扣费前通知后，在约定时间内：

• 若用户拒绝续费，可关闭扣费服务
• 若用户接受续费，则无需额外操作

注意：目前支持通知后24小时自动扣费、或提前使用独立的通知接口两种模式。（支付中签约：pay/contractorder是独立接口，以下扣款规则只适用于申请扣款接口：pay/pappayapply，两种模式只能二选一）

微信周期扣费商户接口调用流程

1）商户在1号调用预扣费通知。

2）2号为扣费等待期，商户不可扣费，用户可随时关闭。

3）3～9号共7天为可扣费期

• • 扣费期内仅在每天7:00～22:00期间可以发起扣费
  • 扣费期内可多次尝试扣费
  • 扣费期内实时扣费
  • 扣费失败用户无感知
  • 扣费成功后用户可收到扣费凭证，扣费成功后，当前周期提前结束

订阅支付的实现方式

1. 技术集成方案

• 支付SDK/API对接：通过集成支付网关（如Stripe、PayPal）或银行提供的订阅接口，实现周期性扣款。例如，Laravel Cashier通过Stripe API管理订阅计划，支持创建、取消订阅及处理失败支付。
• 智能合约与区块链：基于Cardano的Revuto平台利用智能合约自动执行订阅扣款，用户可通过质押代币（如REVU）或稳定币（EURR）支付，同时引入DeFi借贷功能降低费用。
• 虚拟卡解决方案：针对跨境支付场景，WildCard等虚拟卡服务支持绑定国际订阅平台（如Patreon、ChatGPT Plus），通过支付宝/微信充值，规避国内银行卡限制。

2. 核心功能模块

• 订阅计划管理：支持灵活设置周期（月/季/年）、价格阶梯及试用期，例如PayPal需提前24小时创建订阅协议并设置首次扣款费用7。
• 支付失败处理：自动触发邮件提醒、重试扣款或冻结服务，需结合Webhook接收支付状态通知（如PAYMENT.SALE.COMPLETED）7。
• 合规与用户通知：根据《消费者权益保护法实施条例》，需显著提醒自动续费条款，并在扣款前通过多通道（短信、邮件）通知用户

主流竞品接口对比分析

Stripe订阅支付接口

接口功能：支持创建订阅计划、周期性扣款、试用期设置及失败重试。

核心请求参数：

• customer（必填）：用户唯一标识，需通过创建客户接口获取。
• items[price]（必填）：订阅计划价格ID，需预先在Stripe后台配置。
• payment_behavior：控制首次扣款行为（如允许失败后自动重试）。
• trial_period_days：试用期天数。

响应参数：

• id：订阅ID，用于后续管理。
• status：订阅状态（如active、past_due）。
• current_period_start/end：当前计费周期起止时间。

调用流程：

1. 用户选择订阅计划并授权支付。
2. 商户调用POST /v1/subscriptions创建订阅。
3. Stripe验证支付方式并生成首次扣款。
4. 商户通过Webhook接收invoice.payment_succeeded事件更新订阅状态。

PayPal定期付款接口

接口功能：支持固定周期扣款、账单协议管理。

核心请求参数：

• plan_id（必填）：订阅计划ID，需通过产品创建接口生成。
• subscriber：用户信息（如邮箱、姓名）。
• application_context：定义支付流程的返回URL及取消页面。

响应参数：

• subscription_id：订阅唯一标识。
• status：状态码（如APPROVAL_PENDING、ACTIVE）。
• links：包含用户授权支付的跳转链接。

调用流程：

1. 商户调用POST /v1/billing/plans创建订阅计划。
2. 用户通过授权链接完成支付授权。
3. PayPal通过Webhook通知商户激活订阅。
4. 周期性扣款自动执行，商户监听PAYMENT.SALE.COMPLETED事件。

支付宝自动扣款接口（alipay.fund.auth.order.app.freeze）

接口功能：基于预授权协议实现定期扣款。

核心请求参数：

• out_order_no（必填）：商户订单号，需唯一。
• auth_code：用户授权码（通过扫码或SDK获取）。
• product_code：固定为PRE_AUTH。
• amount：预授权金额。

响应参数：

• auth_no：支付宝资金授权号。
• status：授权状态（如SUCCESS）。
• gmt_trans：授权时间戳。

调用流程：

微信支付合约支付接口

接口功能：支持按周期或按次扣款，适用于会员订阅。

核心请求参数：

• contract_id（必填）：签约协议号，通过用户授权获取。
• body：订单描述（如“月度会员费”）。
• total_fee：扣款金额（单位：分）。

响应参数：

• transaction_id：微信支付订单号。
• time_end：支付完成时间。
• trade_state：交易状态（如SUCCESS）。

调用流程：

接口文档设计关键点

幂等性处理

• Token机制：通过唯一请求ID（如idempotency_key）避免重复扣款，需在请求头或参数中传递。
• 数据库约束：在扣款逻辑中使用update … where status=unpaid确保仅处理一次扣款。

有容错能力的序列设计

用户 -> 商户系统: 选择订阅计划并支付

商户系统 -> 支付平台: 调用创建订阅接口（携带idempotency_key）

支付平台 -> 支付平台: 校验幂等性（通过idempotency_key）

支付平台 -> 银行: 验证支付方式并扣款

alt 扣款成功

支付平台 –> 商户系统: 返回{“code”:0, “subscription_id”:”sub_123″, “status”:”pending”}

支付平台 -> 商户系统: Webhook发送PAYMENT_SUCCESS事件

商户系统 -> 商户系统: 更新状态为active，开通服务

商户系统 -> 用户: 发送成功邮件

else 扣款失败

支付平台 –> 商户系统: 返回{“code”:2001, “message”:”余额不足”}

支付平台 -> 支付平台: 记录待重试任务（定时触发）

loop 重试逻辑（最多3次）

支付平台 -> 银行: 重试扣款

alt 重试成功

支付平台 -> 商户系统: Webhook发送PAYMENT_SUCCESS事件

else 重试失败

支付平台 -> 商户系统: Webhook发送PAYMENT_FAILED事件