支付宝分阶段担保交易如何避免二清？

2026-10-24支付老李

结论

通常情况下，并没有一种面向普通商户开放的支付宝接口，能直接实现“企业一次冻结全部款项，之后由平台按 30%/40%/30%分期支付给人才”，并且天然避免二清风险。

目前主要有三种可行路径：

支付宝直付通等平台型产品：由支付宝处理收款、分账和结算，平台负责传递订单信息及资金分配指令。这类产品最接近上述需求。
资金预授权：先冻结企业资金，再根据业务结果扣款或解冻。但预授权不等于第三方资金托管。是否支持多次扣款、是否能向不同人才结算，取决于支付宝为商户实际开通的产品能力。
持牌机构提供的托管、监管账户或薪酬代发方案：如果支付宝现有产品无法覆盖该业务模型，应由银行、支付机构或人力资源服务机构处理资金。

不能使用普通转账、留存商户余额或平台内部余额账本，自行拼装所谓的“担保交易”。资金没有进入平台银行账户，也不代表一定不存在二清。监管判断还会考虑平台是否实际控制资金、是否决定收款人和金额，以及资金是否在平台形成沉淀。

为什么简单的“冻结后分三次解冻”行不通

支付宝的“冻结”“扣款”“解冻”分别对应不同操作：

冻结：限制付款方使用部分资金。
扣款：将冻结资金转化为一笔实际支付。
解冻：解除资金限制，相关资金通常恢复至原付款方的可用余额。
分账：在支付机构支持的产品框架内，按照既定规则将交易款结算给多个接收方。

所以，“解冻 30% 给人才”并不是准确的技术描述。实际需求通常是：

冻结全部金额
    ├── 达成阶段一：从冻结金额中完成 30% 支付
    ├── 达成阶段二：从剩余冻结金额中完成 40% 支付
    └── 达成阶段三：完成剩余 30% 支付

预授权产品通常用于保障付款方与商户之间的履约，不能默认支持以下能力：

同一笔授权分三次完成支付；
每次支付结算给不同自然人；
平台自由决定最终收款人；
冻结期限覆盖整个招聘履约周期；
人才个人账户作为该产品的结算接收方。

是否具备这些能力，必须以支付宝与商户签署的产品协议、开放平台权限及接口实际返回结果为准，不能只看接口名称。

推荐的实施方案

方案一：使用直付通或同类平台型产品

如果平台负责撮合企业和人才，并根据履约情况计算各方应得金额，应优先向支付宝确认平台型收付和分账方案。

典型流程如下：

企业通过支付宝支付订单款项。
支付宝承载交易资金。
平台维护业务订单及各阶段的履约状态。
条件满足后，平台向支付宝提交分账或结算指令。
支付宝将相应金额结算给已签约并完成实名验证的接收方。
退款、分账回退和争议处理仍通过原交易链路完成。

在这种模式下，平台不应先将款项收进自己的银行账户，再通过转账支付给人才。即使使用分账产品，也只能按照审核通过的业务场景、分账比例、接收方类型和结算周期操作。

方案二：预授权加阶段性支付

如果支付宝确认商户当前权限支持“同一授权下多次完成支付”，可以考虑使用预授权模式：

企业授权冻结合同总额。
平台记录支付宝授权单号，但不保存支付密码等敏感信息。
每个阶段完成后，由企业确认，或按照双方约定的规则触发扣款。
订单取消时，解冻尚未支付的金额。
到期前仍未履约的订单，进入取消、重新授权或争议处理流程。

支付宝资金预授权的相关接口通常包括冻结和解冻，例如：

alipay.fund.auth.order.app.freeze
alipay.fund.auth.order.unfreeze

实际使用哪个接口完成支付、同一笔授权能否多次支付，以及单次与累计金额限制，都应以商户后台当前可见的文档和签约权限为准。在确认产品能力之前，不能将“多次扣款”作为系统设计的前提。

预授权也不会自动解决收款主体问题。如果完成支付后，资金只能结算至签约商户，再由平台付款给人才，仍可能形成二次清算链路。

方案三：不冻结总额，企业分阶段直接支付

如果不要求全额冻结，最简单的资金结构是由企业在每个阶段直接向人才付款：

阶段一完成：企业直接支付 30%
阶段二完成：企业直接支付 40%
阶段三完成：企业直接支付 30%

平台只保存合同、验收记录和支付结果，不代收、不代付，也不提供可提现余额。

这种方案的资金路径最清楚，但不能保证企业在后续阶段仍有足够余额。如果必须提供履约保障，可以结合银行保函、保证保险、授信或持牌机构托管，不应由平台自行冻结资金。

订单系统应如何设计

无论最终采用哪种支付宝产品，业务状态和支付状态都应分开管理：

业务状态：
CREATED
SIGNED
STAGE_1_ACCEPTED
STAGE_2_ACCEPTED
STAGE_3_ACCEPTED
COMPLETED
DISPUTED
CANCELLED

资金状态：
NOT_AUTHORIZED
AUTHORIZED
PARTIALLY_PAID
FULLY_PAID
PARTIALLY_REFUNDED
RELEASED

金额应使用最小货币单位计算，避免浮点数误差：

long totalFen = 100_00L;

long stage1Fen = totalFen * 30 / 100;
long stage2Fen = totalFen * 40 / 100;
long stage3Fen = totalFen - stage1Fen - stage2Fen;

最后一期用总金额减去前两期金额，可以避免比例换算产生尾差。

阶段支付代码示例

以下是业务层伪代码，主要展示状态控制和幂等处理。AlipayGateway 中的具体接口需要按照实际签约产品实现，示例中的方法名不是支付宝官方 API。

@Transactional
public PaymentResult payStage(
        String orderId,
        int stage,
        String enterpriseId,
        String idempotencyKey) {

    Order order = orderRepository.lockById(orderId);

    if (!order.getEnterpriseId().equals(enterpriseId)) {
        throw new ForbiddenException("无权操作该订单");
    }

    StagePayment payment =
        stagePaymentRepository.findByIdempotencyKey(idempotencyKey);

    if (payment != null) {
        return payment.toResult();
    }

    long amountFen = order.getStageAmountFen(stage);

    if (!order.canPay(stage)) {
        throw new IllegalStateException("当前阶段不允许支付");
    }

    if (order.getPaidAmountFen() + amountFen > order.getTotalAmountFen()) {
        throw new IllegalStateException("累计支付金额超过订单总额");
    }

    String requestNo = orderId + "-STAGE-" + stage;

    StagePayment created = StagePayment.pending(
        requestNo,
        idempotencyKey,
        orderId,
        stage,
        amountFen
    );
    stagePaymentRepository.save(created);

    AlipayResult result = alipayGateway.captureAuthorizedAmount(
        order.getAuthorizationNo(),
        requestNo,
        amountFen
    );

    created.updateFrom(result);
    stagePaymentRepository.save(created);

    return created.toResult();
}

处理异步通知时，不能只根据请求参数更新订单，至少需要完成以下验证：

public void handleAlipayNotify(Map<String, String> params) {
    if (!alipaySignatureVerifier.verify(params)) {
        throw new SecurityException("支付宝通知验签失败");
    }

    String requestNo = params.get("out_request_no");
    StagePayment payment = stagePaymentRepository.lockByRequestNo(requestNo);

    verifySellerIdentity(params);
    verifyApplicationIdentity(params);
    verifyAmount(payment, params);
    verifyCurrency(params);

    if (payment.isSuccess()) {
        return;
    }

    payment.markSuccess(params.get("trade_no"));
    orderRepository.increasePaidAmount(
        payment.getOrderId(),
        payment.getAmountFen()
    );
}

不同产品和接口使用的字段名称可能不同，应以实际接入文档为准。无论使用哪种接口，都要验证签名、商户身份、订单号和金额，并确保重复通知不会造成重复入账。

必须提前向支付宝确认的问题

开发前，应将完整的资金路径图提交给支付宝客户经理或服务商，并通过书面方式确认以下问题：

业务是否允许企业向自然人或灵活用工人员付款；
收款人才是否需要开户注册、实名认证或签署电子协议；
是否支持一次冻结后分多次完成支付；
冻结的有效期及到期后的处理规则；
支付结果最终结算给人才、平台商户还是其他主体；
是否支持分账、分账回退和部分退款；
发生劳动争议或服务争议时，由谁决定扣款或解冻；
平台是否需要人力资源服务、劳务派遣等相关资质；
相关款项属于工资、劳务报酬还是平台服务交易；
个人所得税申报、代扣代缴和发票链路由谁负责。

如果支付宝不能明确支持“一次冻结、三次支付给人才”，就不应使用普通转账接口模拟这种能力。

注意事项

二清取决于资金链路和业务控制权，不只是使用了哪个接口。以下设计的风险较高：

企业先将款项支付至平台商户号，再由平台转账给人才；
将商户余额作为人才的虚拟账户余额；
平台允许人才充值、提现或相互转账；
使用红包、转账到支付宝账户等接口代替正式分账；
平台自行长期留存待结算资金；
名义上是平台服务交易，实际资金却属于企业应付给人才的报酬。

如果企业与人才之间构成劳动关系，相关款项可能属于工资，而不是普通电商交易款。工资支付时间、工资账户、个人所得税和用工责任，都需要根据实际合同关系判断。支付机构同意开放某个接口，不代表整个用工和清算模式已经合规。

最终方案需要同时通过支付宝的产品审核，并由熟悉支付清算、劳动用工和税务的专业人员审查。针对上述需求，建议按以下顺序选择方案：直付通等平台型产品 → 经确认支持的预授权方案 → 银行或持牌机构托管方案。不建议自行组合冻结、转账和平台余额来实现担保交易。