支付宝如何实现用户直接付款给平台商家且资金不经过平台

2026-10-24支付老李

结论

可以实现，但不能设计成“用户向任意支付宝账号转账”。

平台型业务通常有两种合规做法：

服务商代商家调用支付接口：商家授权平台应用后，平台携带该商家的 app_auth_token 创建交易，由商家收款。
申请支付宝的平台型收款产品：符合准入条件时，可以申请“直付通”等产品。平台负责管理二级商户，交易资金按照产品规则直接结算给实际商家。

“商家分账”一般不是这类需求的首选。分账处理的是一笔交易按规则分配给多个参与方，并不等于“资金完全不进入平台账户”。资金是否经过平台、谁是收款主体、何时结算，都要根据具体产品合同和交易模式判断，不能只看接口名称。

正式方案以支付宝审核通过的产品权限和签约关系为准。申请失败通常不是代码问题，而是业务类型、主体资质、商家管理能力或申请材料不符合产品准入要求。

推荐方案一：商家授权，平台代调用支付接口

如果平台内的每个商家都有支付宝商家主体，并能独立签约支付产品，可以采用支付宝开放平台的第三方应用授权模式。

基本流程如下：

平台以服务商或第三方应用身份接入支付宝开放平台。
每个商家完成支付宝商家认证，并签约所需的支付产品。
商家通过支付宝授权页面，将相关接口权限授予平台应用。
平台通过授权回调取得 app_auth_code。
平台使用 app_auth_code 换取该商家的 app_auth_token。
用户下单时，平台根据订单所属商家选择对应的 app_auth_token。
平台携带该令牌调用支付接口。
支付宝根据授权商家的签约关系处理收款、退款和账单。

重点不是在支付请求中随意填写某个商家的支付宝账号，而是以合法、有效的商家授权身份发起交易。

换取商家授权令牌

下面是流程示意。具体字段和 SDK 方法应以接入时使用的支付宝开放平台文档及 SDK 版本为准：

AlipayOpenAuthTokenAppRequest request =
        new AlipayOpenAuthTokenAppRequest();

request.setBizContent("""
{
  "grant_type": "authorization_code",
  "code": "%s"
}
""".formatted(appAuthCode));

AlipayOpenAuthTokenAppResponse response = alipayClient.execute(request);

if (!response.isSuccess()) {
    throw new IllegalStateException(
        response.getCode() + ": " + response.getSubMsg()
    );
}

String appAuthToken = response.getAppAuthToken();
String refreshToken = response.getAppRefreshToken();

平台需要将令牌与商家内部编号绑定并安全保存。令牌过期或失效后，应按支付宝规定刷新，或者要求商家重新授权。

代商家创建支付订单

以电脑网站支付为例：

AlipayTradePagePayRequest request =
        new AlipayTradePagePayRequest();

request.setReturnUrl("https://platform.example.com/pay/return");
request.setNotifyUrl("https://platform.example.com/pay/notify");

request.setBizContent("""
{
  "out_trade_no": "M202609090001",
  "total_amount": "100.00",
  "subject": "商家订单",
  "product_code": "FAST_INSTANT_TRADE_PAY"
}
""");

AlipayTradePagePayResponse response =
        alipayClient.pageExecute(request, null, appAuthToken);

if (!response.isSuccess()) {
    throw new IllegalStateException(
        response.getCode() + ": " + response.getSubMsg()
    );
}

String paymentForm = response.getBody();

不同版本的 Java SDK 可能采用不同的重载方法，但核心要求不变：调用接口时必须正确传入当前商家的 app_auth_token，不能把多个商家的订单都放在平台自身的授权上下文中。

手机网站、当面付或 App 支付需要选择对应产品允许的接口，例如：

alipay.trade.wap.pay
alipay.trade.page.pay
alipay.trade.precreate
alipay.trade.app.pay

这些接口能否代商家调用，取决于平台应用权限、商家授权范围，以及商家实际签约的产品。

推荐方案二：申请平台型收款产品

如果商家数量较多、商户入驻由平台统一管理，或者商家无法逐一完成普通应用的签约与授权，可以评估支付宝为平台型业务提供的产品方案，例如直付通。

这类方案通常包括：

二级商户入驻和资质审核；
商户及门店管理；
平台创建交易；
资金按照产品约定直接结算给实际商家；
退款、对账和交易查询；
平台服务费或多方资金分配能力。

能否接入、商家是否必须持有营业执照、个人经营者能否入驻，以及平台能否收取服务费，都取决于行业、主体类型和当时的产品准入政策。仅凭公开 API 无法判断产品一定能够开通。

商家分账是否适用

如果一笔订单只有一个实际收款商家，目标又是避免平台成为资金收款方，应优先考虑“商家授权代调用”或“平台型直收产品”。

商家分账更适合以下场景：

一笔订单需要向商家、供应商、服务商等多个参与方分配资金；
平台需要从交易中按比例收取技术服务费；
交易完成后，再根据履约结果确定分配金额；
支付产品允许先冻结资金或形成待分账资金，再执行分账。

使用分账前，必须确认三个问题：

原始交易的收款主体是谁；
分账前的资金记录在哪个主体名下；
分账完成前，这笔资金在会计和税务上如何认定。

如果原始交易仍由平台收款，只是在支付完成后再将资金分给商家，就不一定能解决“资金不经过平台”以及税务主体不清的问题。

沙箱无法测试时如何开发

部分涉及商家授权、二级商户入驻、资金结算或分账的能力，在沙箱中可能并不完整，甚至只向已签约的正式应用开放。遇到这种情况，不能通过伪造 seller_id、商家账号或授权令牌来绕过限制。

可以分层测试：

本地测试

封装支付宝客户端，并通过 mock 验证：

订单与商家授权令牌的映射；
不同商家的订单隔离；
请求参数生成；
异步通知验签；
重复通知的幂等处理；
支付失败、超时和关闭；
退款权限及退款状态；
授权失效后的错误处理。

沙箱联调

沙箱支持哪些接口，就测试对应的基础能力，例如创建交易、验签、异步通知和订单查询。对于沙箱不支持的商家授权或资金链路，应明确记录为正式环境待验证项目，不能声称已经通过沙箱验证实际结算结果。

正式环境验证

取得正式权限后，建议按以下步骤验证：

先接入一个内部商家或合作测试商家；
使用小额真实订单进行验证；
核对支付宝交易详情中的收款主体；
核对商家账单和结算记录；
验证退款是否由原收款商家执行；
检查平台账单中是否出现不应归属于平台的交易资金；
经财务和税务人员确认后，再扩大商家范围。

正式申请无法通过时的处理方式

先向支付宝确认申请在哪个环节被拒绝，例如应用审核、产品签约、服务商准入、二级商户入驻或接口权限申请。不同环节要求的材料并不相同。

申请材料通常需要说明：

平台提供什么服务，属于哪个行业；
用户、平台和商家之间是什么关系；
商品或服务由谁实际提供；
售后和退款责任由谁承担；
平台是否参与定价；
平台如何审核及管理商家；
完整的支付、结算和退款资金流图；
发票由谁向用户开具；
平台收入属于货款还是技术服务费；
商家资质、平台协议和业务页面截图。

不要将业务描述成“替商家收钱后再转账”，也不能为了通过审核而提交与实际业务不符的说明。申请材料与真实业务模式不一致，即使正式上线，相关权限仍可能受到限制。

如果无法通过自助渠道确认原因，可以通过支付宝开放平台工单、业务产品页面提供的咨询渠道，或者具备相应资质的支付宝服务商，确认适用的产品。在申请通过前，只能完成接口封装和模拟测试，无法通过技术手段直接获得正式资金能力。

注意事项

不要使用转账接口模拟商品支付。转账和交易支付在退款、投诉、对账、风控及消费者保障方面属于不同业务。
不要只修改 seller_id 来改变收款方。收款主体必须与应用身份、授权关系和签约产品一致。
app_auth_token 是敏感凭证，需要加密保存，禁止写入前端、URL 或日志。
异步通知必须验签，同时校验 app_id、订单号、金额和收款主体等重要字段。
支付状态应以支付宝异步通知和主动查询结果为准，不能只依赖同步跳转页面。
每个商家的订单、退款、账单和授权令牌都必须隔离管理。
“实时收款”不一定意味着“实时到账银行卡”。交易成功、支付宝账户入账和银行卡结算可能发生在不同时间。
资金在技术系统中的流转路径不能单独决定税务处理。最终应由财务或税务顾问结合合同、交易主体、发票和账单进行确认。