接入必读

商户接入规范标准化

接口调用规范

  • 针对唤起收银台的交易确保能够及时获得用户支付结果

    • 原因:对于等待支付的交易,商户如果无法及时确认顾客付款是否成功,容易引起资损和纠纷。

    • 建议方案:对所有唤起收银台的交易(支付宝返回状态10003)发起轮询,并且建议轮询总时间设为30秒,轮询平均间隔设为3秒。在让用户再次支付前,必须通过查询确认当前订单的状态。

  • 同一订单的部分退款确保退款请求号不重复

    • 原因:同一笔交易如果不改变退款请求号 out_request_no,会因为请求号冲突,导致部分退款失败。

    • 建议方案:同一笔交易若发起多次部分退款,每一次都需要改变 out_request_no。

异常处理

  • 避免不合法的传参

    • 原因:传参错误会导致支付异常。

    • 建议方案:对所有返回 INVALID_PARAMETER 的响应进行监控,一旦发现请停止调用并检查请求参数,修改后重新发起请求。

  • 接口调用发生异常时能够正确处理

    • 原因:接口的大量调用错误,商户带宽被无效调用占用,容易导致访问支付宝速度变慢,并且容易引发商户端处理错误,造成系统无法正常使用,严重影响系统稳定性及用户体验。

    • 建议方案:在调用支付宝接口时,可能会遇到网络超时或支付宝未知异常(接口返回 code=20000,sub_code=isp.unknow-error 或 ACQ.SYSTEM_ERROR),此时业务处理结果是未知的,需要根据具体API采取一下措施。具体措施如下:

      • A. 查询接口 alipay.trade.query 和撤销接口 alipay.trade.cancel 调用异常:

        • 立即重试一分钟,如果仍然返回超时或未知异常,需要记录该异常交易并走人工处理流程。
      • B. 预下单接口 alipay.trade.precreate 调用异常:

        • 使用新的商户订单号 out_trade_no 重新调用预下单接口。
      • C. 退款接口 alipay.trade.refund 调用异常:

        • 使用相同的参数重试一分钟,如果仍然返回超时或未知异常,需要记录该异常交易并走人工处理流程,不能简单的推断为退款成功或失败。
      • D. 支付接口 alipay.trade.pay 调用异常,立即调用查询接口,如果:

        • 查询的交易不存在(错误码 ACQ.TRADE_NOT_EXIST),使用相同的参数重新调用支付接口。

        • 网络超时或未知异常,继续查询一分钟,如仍然超时或未知异常,需要记录该异常交易并走人工处理流程,不能简单的推断为付款失败。

支付体验

  • 合理的轮询间隔以及轮询总时间

    • 原因:如果轮询总时间太短,而用户输入密码时间较长,商户可能无法获得支付结果,导致资损和纠纷。如果轮询时间太长,会产生不必要的资源消耗,降低服务器性能。同样,轮询间隔如果过短,会给服务器带来压力,降低性能,反之,会无法及时得到支付结果,增加不必要的排队等待时间。

    • 建议方案:建议轮询总时间设置在30秒,轮询间隔设为3秒。

  • 提高订单支付成功率

    • 原因:支付失败现象增多会引起商户收银问题,增加顾客等待时间,引起单边账,降低顾客满意度。

    • 建议方案:对支付接口的返回进行监控,如果有较高比例的支付失败,需要及时排查原因。条码支付成功率建议保持在95%以上。

  • 新建的订单都需要改变订单号

    • 原因:外部订单号重复会导致交易失败,不予以控制将增大服务器开销,增加顾客等待时间。

    • 建议方案:对新建的订单进行跳号处理。

资金安全

  • 未支付订单请及时撤销

    • 原因:未支付订单如果不及时关闭,顾客可能会误支付,从而导致顾客资损,引起单边账

    • 建议方案:对于未支付的订单,请及时通过调用撤销接口关闭订单(注意:超过24小时的订单无法撤销);另外一种方法是为每笔订单设置超时时间,超过时间未支付的订单会自动关闭。

  • 不要将撤销接口用于退款业务

    • 原因:退款接口用于正常退款业务,撤销接口用于在订单出现问题时候将其撤销并关闭。两者的业务场景完全不同,错用会导致订单状态与业务状态不匹配,在监控下无法准确地发现系统异常。

    • 建议方案:所有退款业务都必须调用退款接口。

  • 单品总金额与订单总金额要一致

    • 原因:单品总金额与订单金额不一致会导致实收金额与应收金额不匹配,从而引起资损。

    • 建议方案:在传入单品的情况下,订单总金额需要基于单品的单价和数量计算出来。

  • 不要在没有获得交易结果的时候要求用户再次付款

    • 原因:商户端没有获得交易结果,很有可能是用户已经付款成功只是商户端单方面原因(网络问题)导致没有获得支付结果,再次支付会导致用户资损。

    • 建议方案:对于商户端没有获得交易结果的订单,请和用户确认支付结果,如果用户已经支付成功,请先退款然后让用户再次支付。

入参规范

  • auth_code 用户付款码建议做好设计预留工作

    • 原因:由于业务发展需要,支付宝将会在2017年9月底对支付宝的用户付款码做升级处理。付款码将由原来的28开头扩充到25-30开头,长度由原来的16-18位扩充到16-24位。未来随移动支付产业的发展,用户付款码可能会有所加长,建议开发者做好设计预留工作。

    • 建议方案:如果开发者在对接当面付条码支付接口时,有对支付宝条码做码段和长度的限制,请务必完成相关升级。

  • storeid 不要含有中文字符

    • 原因:中文有可能引起乱码,在有营销活动的情况下,会导致营销活动无法生效。

    • 建议方案:建议 storeid 全部用字母和数字的组合。

  • 支付请求需要传入 storeid

    • 原因:如果不传,会导致在商家自营销活动发放的券无法核销。

    • 建议方案:建议所有支付订单都加入 storeid 参数。

  • 机具接入请传入 terminalid

    • 原因:在机具支付异常的情况下无法跟踪,无法得到后续保障,也会导致营销活动无法生效。

    • 建议方案:所有机具接入的支付请求需要带入terminal_id参数。

  • 需要返佣的 ISV (独立软件开发商)请确保传入正确的返佣参数

    • 原因:系统商接入如果不传入正确的 sys_service_provider_id,会导致无法获得返佣。

    • 建议方案:建议系统商接入的所有订单都加入 sys_service_provider_id参数,并检查参数是否正确。

  • 确保带有折扣参数的订单可以正常享受优惠

    • 原因:订单里的不可打折金额(undiscountable_amount)如果设置成全额,该笔订单将无法享受折扣。

    • 建议方案:在传入打折参数的情况下,请确认 discountable_amount 不为0或者 undiscountable_amount 不是全额。

  • 参与单品活动的交易需要传入正确的 goodsdetail 信息

    • 原因:如果交易参数中的 goodsdetail 为空或者有误,将无法参与单品活动。

    • 建议方案:参与单品活动的商户请检查请求是否包含 goodsdetail,并确保 goodsID 和口碑后台所配置的相一致。

监控保障

  • 交易保障接口接入

    • 原因:如果没有接入交易保障接口,商户/ISV将无法通过支付宝提供的自助平台监控自身收银端问题,失去了支付宝提供的一项保障能力。

    • 建议方案:每30分钟(或小于30分钟)将收银终端的交易性能和异常等数据同步至支付宝。支付宝将该数据和支付宝内大数据有机整合为商户/ISV提供实时监控能力,为线下收银保障护航。交易性能和交易异常数据必须要从收银终端统计,不能在服务端统计。因为这样才可以监控到真实的性能和异常。

支付结果异步通知

  • 异步通知验签
    商户接受到异步通知后,一定要先做验签,来确保该通知确实是从支付宝发出的。验签的详细规则见异步通知验签,同时建议您参考以下代码使用支付宝提供的开发平台服务端SDK来辅助验签:
Map<String, String> paramsMap = ... //将异步通知中收到的所有参数都存放到map中
boolean signVerified = AlipaySignature.rsaCheckV1(paramsMap, ALIPAY_PUBLIC_KEY, CHARSET,SIGN_TYPE) //调用SDK验证签名
if(signVerfied){
    // TODO 验签成功则继续业务操作,最后在response中返回success
}else{
    // TODO 验签失败则记录异常日志,并在response中返回failure.
}

注意
出于安全考虑,验签完成后,请开发者务必检查通知中的 appid、外部订单号和订单金额与预下单时传入的是否一致。

避免单边账

场景介绍

单边账是指对于一笔交易,商户端和用户端的结果不一致,分为两种情况:

  • 商户资损单边账:用户实际未付款成功,但商户系统判定支付成功;或用户支付成功后,商户系统由于逻辑问题发起了撤销。

  • 用户资损单边账:用户付款成功,但商户系统未得到支付成功的结果,误认为付款失败,再次扫用户付款码发起支付,导致用户多支付了一笔。在用户手机网络不好的情况下,支付成功后用户手机不一定会显示支付成功页面,用户自己也不知道已经付成功了。这种情况在小额场景下尤其容易出现,且难以发现,需要商户和系统商特别注意。

为了避免单边账,建议商户和系统商采取以下措施:

  • 每一笔交易一定要闭环,即要么支付成功,要么撤销交易,一定不能有交易一直停留在等待用户付款的状态。

  • 轮询+撤销的流程中,如轮询的结果一直为未付款,撤销一定要紧接着最后一次查询,当中不能有时间间隔。

  • 门店收银系统应该具备独立的手动查询功能作为兜底,输入商户订单号(可从用户手机账单中获得)调用支付宝查询接口获得确切的支付状态。

  • 当遇到网络超时和未知异常时,参考异常处理流程正确处理,对于每一笔交易或退款,一定要得到确切的结果。

  • 撤销接口调用成功后,需要在收银台页面为收银员展示撤销成功的强提示文案,且按实际业务情况引导收银员进行手工订单查询。如果撤销接口没有明确返回处理结果,如遇到网络超时或支付宝未知异常等情况,则需要在收银台提示文案中表明,撤销正在处理中;若该笔订单已经支付则后续会有发生退款的可能,并和用户做好线下沟通。

  • 对于经过轮询和撤销仍然无法确认结果的(例如系统故障或门店断网),应上报总部IT或财务,由IT(从系统内)或财务(从支付宝后台),确认支付结果后,通过后台发起退款。或让顾客查询手机支付宝账单,如顾客手机没网络,可拨打支付宝客服热线95188确认支付结果。

  • 在上述基础上,业务流程培训时应强调支付结果必须以商户端为准,用户手机上的支付宝结果或账单只能做参考,不能作为最终识别标准。如果商户未正确处理业务逻辑和业务流程培训,存在潜在的风险,商户自行承担因此而产生的所有损失。

退款

场景介绍

商户因业务原因需要退款时,可通过成功交易的商户订单号或支付宝交易号进行退款 ,支持部分退款。

调用流程

商户系统调用 交易退款接口 alipay.trade.refund,传入商户订单号或支付宝交易号、退款请求号、退款金额等参数请求退款,并同步获得退款结果。具体流程如下图所示:

注意
退款接口会根据外部请求号 out_request_no 幂等返回,因此同一笔需要多次部分退款时,必须使用不同的 out_request_no。

使用SDK快速接入

交易退款接口 alipay.trade.refund

AlipayClient alipayClient = new DefaultAlipayClient("https://openapi.alipay.com/gateway.do", APP_ID, APP_PRIVATE_KEY, "json", CHARSET, ALIPAY_PUBLIC_KEY, "RSA2"); //获得初始化的AlipayClient
AlipayTradeRefundRequest request = new AlipayTradeRefundRequest();//创建API对应的request类
request.setBizContent("{" +
"    \"out_trade_no\":\"20150320010101001\"," +
"    \"trade_no\":\"2014112611001004680073956707\"," +
"    \"out_request_no\":\"1000001\"," +
"    \"refund_amount\":\"1.00\"}"); //设置业务参数
AlipayTradeRefundResponse response = alipayClient.execute(request);//通过alipayClient调用API,获得对应的response类
System.out.print(response.getBody());
//根据response中的结果继续业务逻辑处理

关键入参:

参数名称 参数说明
out_trade_no 支付时传入的商户订单号,与trade_no必填一个
trade_no 支付时返回的支付宝交易号,与out_trade_no必填一个
out_request_no 本次退款请求流水号,部分退款时必传
refund_amount 本次退款金额

关键出参:

参数名称 参数说明
refund_fee 该笔交易已退款的总金额

对账

场景介绍

商家/系统商可通过接口下载指定日期(当天除外)的业务明细账单文件,并结合自身业务系统实现自动对账。

调用流程

  1. 商户系统调用查询对账单下载地址接口 alipay.data.dataservice.bill.downloadurl.query,传入指定日期,获得该日期账单文件的下载地址。

  2. 商户系统通过HTTP方式后台访问账单下载链接,将账单csv文件下载到本地后自行处理。注意该下载链接仅30秒,在得到链接后系统需要立刻请求下载账单文件。

  3. 账单示例
    20887027411111110156_20180105.csv.zip
    具体流程如下图所示:


使用SDK快速接入

查询对账单下载地址接口 alipay.data.dataservice.bill.downloadurl.query

AlipayClient alipayClient = new DefaultAlipayClient("https://openapi.alipay.com/gateway.do", APP_ID, APP_PRIVATE_KEY, "json", CHARSET, ALIPAY_PUBLIC_KEY, "RSA2");//获得初始化的AlipayClient
AlipayDataDataserviceBillDownloadurlQueryRequest request = new AlipayDataDataserviceBillDownloadurlQueryRequest();//创建API对应的request类
request.setBizContent("{" +
"    \"bill_type\":\"trade\"," +
"    \"bill_date\":\"2016-04-05\"}"); //设置业务参数
AlipayDataDataserviceBillDownloadurlQueryResponse response = alipayClient.execute(request);//通过alipayClient调用API,获得对应的response类
System.out.print(response.getBody());
//根据response中的结果继续业务逻辑处理

关键入参:

参数名称 参数说明
bill_type 固定传入trade
bill_date 需要下载的账单日期,最晚是当期日期的前一天

关键出参:

参数名称 参数说明
bill_download_url 账单文件下载地址,30秒有效

下载账单文件:

//将接口返回的对账单下载地址传入urlStr
String urlStr = "http://dwbillcenter.alipay.com/downloadBillFile.resource?bizType=X&userId=X&fileType=X&bizDates=X&downloadFileName=X&fileId=X";
//指定希望保存的文件路径
String filePath = "/Users/fund_bill_20160405.csv.zip";
URL url = null;
HttpURLConnection httpUrlConnection = null;
InputStream fis = null;
FileOutputStream fos = null;
try {
    url = new URL(urlStr);
    httpUrlConnection = (HttpURLConnection) url.openConnection();
    httpUrlConnection.setConnectTimeout(5 * 1000);
    httpUrlConnection.setDoInput(true);
    httpUrlConnection.setDoOutput(true);
    httpUrlConnection.setUseCaches(false);
    httpUrlConnection.setRequestMethod("GET");
    httpUrlConnection.setRequestProperty("CHARSET", "UTF-8");
    httpUrlConnection.connect();
    fis = httpUrlConnection.getInputStream();
    byte[] temp = new byte[1024];
    int b;
    fos = new FileOutputStream(new File(filePath));
    while ((b = fis.read(temp)) != -1) {
        fos.write(temp, 0, b);
        fos.flush();
    }
} catch (MalformedURLException e) {
    e.printStackTrace();
} catch (IOException e) {
    e.printStackTrace();
} finally {
    try {
        if(fis!=null) fis.close();
        if(fos!=null) fos.close();
        if(httpUrlConnection!=null) httpUrlConnection.disconnect();
    } catch (IOException e) {
        e.printStackTrace();
    }
}

异步通知(仅用于扫码支付)

当收银台调用预下单请求API生成二维码展示给用户后,用户通过手机扫描二维码进行支付,支付宝会将该笔订单的变更信息,沿着商户调用预下单请求时所传入的通知地址主动推送给商户。

参数 参数名称 类型 必填 描述 范例
notify_time 通知时间 Date 通知的发送时间。格式为yyyy-MM-dd HH:mm:ss 2011-12-27 06:30:30
notify_type 通知类型 String(64) 通知的类型 trade_status_sync
notify_id 通知校验ID String(128) 通知校验ID ac05099524730693a8b330c5ecf72da9786
sign_type 签名类型 String(10) 商户生成签名字符串所使用的签名算法类型,目前支持RSA2和RSA,推荐使用RSA2 RSA2
sign 签名 String(256) 请参考异步返回结果的验签 601510b7970e52cc63db0f44997cf70e
trade_no 支付宝交易号 String(64) 支付宝交易凭证号 2013112011001004330000121536
app_id 开发者的app_id String(32) 支付宝分配给开发者的应用Id 2014072300007148
out_trade_no 商户订单号 String(64) 原支付请求的商户订单号 6823789339978248
out_biz_no 商户业务号 String(64) 商户业务ID,主要是退款通知中返回退款申请的流水号 HZRF001
buyer_id 买家支付宝用户号 String(16) 买家支付宝账号对应的支付宝唯一用户号。以2088开头的纯16位数字 2088102122524333
buyer_logon_id 买家支付宝账号 String(100) 买家支付宝账号 15901825620
seller_id 卖家支付宝用户号 String(30) 卖家支付宝用户号 2088101106499364
seller_email 卖家支付宝账号 String(100) 卖家支付宝账号 zhuzhanghu@alitest.com
trade_status 交易状态 String(32) 交易目前所处的状态 TRADE_CLOSED
total_amount 订单金额 Number(9,2) 本次交易支付的订单金额,单位为人民币(元) 20
receipt_amount 实收金额 Number(9,2) 商家在交易中实际收到的款项,单位为元 15
invoice_amount 开票金额 Number(9,2) 用户在交易中支付的可开发票的金额 10.00
buyer_pay_amount 付款金额 Number(9,2) 用户在交易中支付的金额 13.88
point_amount 集分宝金额 Number(9,2) 使用集分宝支付的金额 12.00
refund_fee 总退款金额 Number(9,2) 退款通知中,返回总退款金额,单位为元,支持两位小数 2.58
send_back_fee 实际退款金额 Number(9,2) 商户实际退款给用户的金额,单位为元,支持两位小数 2.08
subject 订单标题 String(256) 商品的标题/交易标题/订单标题/订单关键字等,是请求时对应的参数,原样通知回来 当面付交易
body 商品描述 String(400) 该订单的备注、描述、明细等。对应请求时的body参数,原样通知回来 当面付交易内容
gmt_create 交易创建时间 Date 该笔交易创建的时间。格式为yyyy-MM-dd HH:mm:ss 2015-04-27 15:45:57
gmt_payment 交易付款时间 Date 该笔交易的买家付款时间。格式为yyyy-MM-dd HH:mm:ss 2015-04-27 15:45:57
gmt_refund 交易退款时间 Date 该笔交易的退款时间。格式为yyyy-MM-dd HH:mm:ss.S 2015-04-28 15:45:57.320
gmt_close 交易结束时间 Date 该笔交易结束时间。格式为yyyy-MM-dd HH:mm:ss 2015-04-29 15:45:57
fund_bill_list 支付金额信息 String(512) 支付成功的各个渠道金额信息,详见资金明细信息说明 [{"amount":"15.00","fundChannel":"ALIPAYACCOUNT"}]

交易状态说明

枚举名称 枚举说明
WAIT_BUYER_PAY 交易创建,等待买家付款
TRADE_CLOSED 未付款交易超时关闭,或支付完成后全额退款
TRADE_SUCCESS 交易支付成功
TRADE_FINISHED 交易结束,不可退款

通知触发条件

触发条件名 触发条件描述 触发条件默认值
TRADE_FINISHED 交易完成 false(不触发通知)
TRADE_SUCCESS 支付成功 true(触发通知)
WAIT_BUYER_PAY 交易创建 false(不触发通知)
TRADE_CLOSED 交易关闭 false(不触发通知)

资金明细信息说明

参数 参数名称 类型 参数说明 是否可为空 样例
fundChannel 支付渠道 String 支付渠道,参见下面的“支付渠道说明”。 可空 ALIPAYACCOUNT
amount 支付金额 String 使用指定支付渠道支付的金额,单位为元。 可空 15.00

支付渠道说明

支付渠道代码 支付渠道
COUPON 支付宝红包
ALIPAYACCOUNT 支付宝余额
POINT 集分宝
DISCOUNT 折扣券
PCARD 预付卡
FINANCEACCOUNT 余额宝
MCARD 商家储值卡
MDISCOUNT 商户优惠券
MCOUPON 商户红包
PCREDIT 蚂蚁花呗

服务器异步通知页面特性

  1. 必须保证服务器异步通知页面(notify_url)上无任何字符,如空格、HTML标签、开发系统自带抛出的异常提示信息等;

  2. 支付宝是用POST方式发送通知信息,因此该页面中获取参数的方式,如:request.Form("out_trade_no")、$_POST['out_trade_no'];

  3. 支付宝主动发起通知,该方式才会被启用;

  4. 只有在支付宝的交易管理中存在该笔交易,且发生了交易状态的改变,支付宝才会通过该方式发起服务器通知(即时到账中交易状态为“等待买家付款”的状态默认是不会发送通知的);

  5. 服务器间的交互,不像页面跳转同步通知可以在页面上显示出来,这种交互方式是不可见的;

  6. 第一次交易状态改变(即时到账中此时交易状态是交易完成)时,不仅会返回同步处理结果,而且服务器异步通知页面也会收到支付宝发来的处理结果通知;

  7. 程序执行完后必须打印输出"success"(不包含引号)。如果商户反馈给支付宝的字符不是 success 这7个字符,支付宝服务器会不断重发通知,直到超过24小时22分钟。一般情况下,25小时以内完成8次通知(通知的间隔频率一般是:4m,10m,10m,1h,2h,6h,15h);

  8. 程序执行完成后,该页面不能执行页面跳转。如果执行页面跳转,支付宝会收不到 success 字符,会被支付宝服务器判定为该页面程序运行出现异常,而重发处理结果通知;

  9. cookies、session 等在此页面会失效,即无法获取这些数据;

  10. 该方式的调试与运行必须在服务器上,即互联网上能访问;

  11. 该方式的作用主要防止订单丢失,即页面跳转同步通知没有处理订单更新,它则去处理;

  12. 当商户收到服务器异步通知并打印出 success 时,服务器异步通知参数 notify_id 才会失效。也就是说在支付宝发送同一条异步通知时(包含商户并未成功打印出 success 导致支付宝重发数次通知),服务器异步通知参数 notify_id 是不变的。

异步返回结果的验签

某商户设置的通知地址为 https://api.xx.com/receive_notify.htm,对应接收到通知的示例如下:

https://api.xx.com/receive_notify.htm?gmt_payment=2015-06-11 22:33:59&notify_id=42af7baacd1d3746cf7b56752b91edcj34&seller_email=testyufabu07@alipay.com&notify_type=trade_status_sync&sign=kPbQIjX+xQc8F0/A6/AocELIjhhZnGbcBN6G4MM/HmfWL4ZiHM6fWl5NQhzXJusaklZ1LFuMo+lHQUELAYeugH8LYFvxnNajOvZhuxNFbN2LhF0l/KL8ANtj8oyPM4NN7Qft2kWJTDJUpQOzCzNnV9hDxh5AaT9FPqRS6ZKxnzM=&trade_no=2015061121001004400068549373&out_trade_no=21repl2ac2eOutTradeNo322&gmt_create=2015-06-11 22:33:46&seller_id=2088211521646673&notify_time=2015-06-11 22:34:03&subject=FACE_TO_FACE_PAYMENT_PRECREATE中文&trade_status=TRADE_SUCCESS&sign_type=RSA2
  1. 在通知返回参数列表中,除去sign、sign_type两个参数外,凡是通知返回回来的参数皆是待验签的参数。

  2. 将剩下参数进行url_decode, 然后进行字典排序,组成字符串,得到待签名字符串:

gmt_create=2015-06-11 22:33:46&gmt_payment=2015-06-11 22:33:59&notify_id=42af7baacd1d3746cf7b56752b91edcj34&notify_time=2015-06-11 22:34:03&notify_type=trade_status_sync&out_trade_no=21repl2ac2eOutTradeNo322&seller_email=testyufabu07@alipay.com&seller_id=2088211521646673&subject=FACE_TO_FACE_PAYMENT_PRECREATE中文&trade_no=2015061121001004400068549373&trade_status=TRADE_SUCCESS
  1. 将签名参数(sign)使用 base64 解码为字节码串。

  2. 使用RSA的验签方法,通过签名字符串、签名参数(经过 base64 解码)及支付宝公钥验证签名。

  3. 需要严格按照如下描述校验通知数据的正确性。

商户需要验证该通知数据中的 out_trade_no 是否为商户系统中创建的订单号,并判断 total_amount 是否确实为该订单的实际金额(即商户订单创建时的金额),同时需要校验通知中的 seller_id(或者seller_email) 是否为 out_trade_no 这笔单据的对应的操作方(有的时候,一个商户可能有多个 seller_id/seller_email),上述有任何一个验证不通过,则表明本次通知是异常通知,务必忽略。在上述验证通过后商户必须根据支付宝不同类型的业务通知,正确的进行不同的业务处理,并且过滤重复的通知结果数据。在支付宝的业务通知中,只有交易通知状态为 TRADE_SUCCESS 或 TRADE_FINISHED 时,支付宝才会认定为买家付款成功。

注意

  • 状态 TRADE_SUCCESS 的通知触发条件是商户签约的产品支持退款功能的前提下,买家付款成功;

  • 交易状态 TRADE_FINISHED 的通知触发条件是商户签约的产品不支持退款功能的前提下,买家付款成功;或者,商户签约的产品支持退款功能的前提下,交易已经成功并且已经超过可退款期限。

自助工具

如果需要验证当前接入质量是否符合我们所罗列的标准规范,可以访问商户自助监控平台查看集成健康度。

onlineServer