支付巨头们纷纷布局订阅支付领域，试图通过技术创新和业务拓展来抢占市场份额。本文将深入探讨订阅支付的业务流程、风控要点、技术实现方式以及主流支付平台的接口对比分析，帮助大家全面了解这一支付领域的竞争格局和发展趋势。
目录概览
- 主要参与方
- 典型信息流
- 风控与合规要点
- 案例：微信支付周期扣费产品业务流程
- 商户接口调用process
- 订阅支付的UML流程概览
- 主流竞品接口对比分析
主要参与方
- 用户：就是你我这样的消费者，想订阅个服务，比如会员、自动续费啥的，就得先发起请求，授权支付方式（比如绑卡），然后等着接收扣款通知。
- 商户：就是提供那些订阅服务的商家，比如视频网站、软件开发商。他们得配置好订阅计划，等收到支付结果后，就给你开通服务。
- 支付公司（聚合支付平台）：这帮家伙就像是支付界的“中间人”，把各种支付渠道都集成起来。他们得处理订阅的那些事儿，比如周期性扣款、扣款失败了咋办，还得负责资金清算和对账。
- 银行/卡组织：他们是“真金白银”的搬运工，负责实际的资金划转，还提供代收付接口和风控支持。
- 第三方服务商：比如 WildCard（虚拟卡）、Stripe（支付网关）这些，他们在一些特定场景下，给支付能力“加把劲”。
典型信息流
订阅发起阶段
用户（就是你咯）在前端页面上选好订阅计划，然后授权支付方式（比如填个虚拟卡信息）。
支付公司就会调用银行或支付网关的 API，生成一个订阅协议（比如 PayPal 的 Billing Agreement），顺便把扣款周期和金额给记下来。
商户收到订阅 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：当前计费周期起止时间。
调用流程：
- 用户选择订阅计划并授权支付。
- 商户调用POST /v1/subscriptions创建订阅。
- Stripe验证支付方式并生成首次扣款。
- 商户通过Webhook接收invoice.payment_succeeded事件更新订阅状态。
PayPal定期付款接口
接口功能：支持固定周期扣款、账单协议管理。
核心请求参数：
- plan_id（必填）：订阅计划ID，需通过产品创建接口生成。
- subscriber：用户信息（如邮箱、姓名）。
- application_context：定义支付流程的返回URL及取消页面。
响应参数：
- subscription_id：订阅唯一标识。
- status：状态码（如APPROVAL_PENDING、ACTIVE）。
- links：包含用户授权支付的跳转链接。
调用流程：
- 商户调用POST /v1/billing/plans创建订阅计划。
- 用户通过授权链接完成支付授权。
- PayPal通过Webhook通知商户激活订阅。
- 周期性扣款自动执行，商户监听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事件
本文由 @支付唧唧咋咋 原创发布于人人都是产品经理。未经作者许可，禁止转载
题图来自Unsplash，基于CC0协议
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务
