摘要：支付巨头们纷纷布局订阅支付领域，试图通过技术创新和业务拓展来抢占市场份额。本文将深入探讨订阅支付的业务流程、风控要点、技术实现方式以及主流支付平台的接口对比分析，帮助大家全面了解这一支付领域的竞争格局和发展趋势。
支付巨头们纷纷布局订阅支付领域，试图通过技术创新和业务拓展来抢占市场份额。本文将深入探讨订阅支付的业务流程、风控要点、技术实现方式以及主流支付平台的接口对比分析，帮助大家全面了解这一支付领域的竞争格局和发展趋势。
目录概览
主要参与方典型信息流风控与合规要点案例：微信支付周期扣费产品业务流程商户接口调用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事件更新订阅状态。接口功能：支持固定周期扣款、账单协议管理。
核心请求参数：
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 重试成功
else 重试失败
支付平台 -> 商户系统: Webhook发送PAYMENT_FAILED事件
本文由 @支付唧唧咋咋 原创发布于人人都是产品经理。未经作者许可，禁止转载
题图来自Unsplash，基于CC0协议
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务
来源：人人都是产品经理
