支付宝接入开发摘记

这一篇主要记录一下支付宝开发过程遇到的一些坑,后面再开一篇文章讲讲支付的架构设计。
这一期的支付开发主要接入支付宝,包含了入账和出账。

流程图

入账的流程图如下:

出账的流程图如下:

支付宝接口

收款

为APP集成收款功能支付宝提供了两个接口,分别是App支付移动支付,据支付宝客服称App支付是新接口,移动支付会逐渐淡化。
这两个接口参数名大同小异,主要区别是App支付需要用bizcontent来包裹业务参数。
这里主要使用App支付

接口名称:mobile.securitypay.pay
文档地址:App 支付
费率:0.6%
额度:不限

坑:

  • 文档中声称需要对请求字符串的所有一级value(biz_content作为一个value)进行encode,实际测试发现只有生成的签名字段sign需要做encode
  • 订单金额total_amount携带的金额不能用,分隔,比如¥1000元要传入1000,传入1,000会导致异常
  • 支付宝的回调中total_amount的金额是保留了2位小数表示的,比如订单金额¥0.5元,支付宝的回调会回传为0.50

退款

即时到帐的退款是有无密和有密之分的,官方提供的文档中只有有密
无密接口需要联系客服开通,开通时间需要5天左右。
有密的接口需要在window+ie下输入密码才能完成退款操作。
这里主要使用无密接口。

接口名称:refund_fastpay_by_platform_nopwd
费率:0(不退服务费)

坑:

  • 回调的参数用了^分隔,如果通过java来做split处理,需要做转义处理为\\^
  • 回调的gmt_refund时间格式是yyyy-MM-dd HH:mm:ss.S
  • 退款使用密钥与收款不同,是合作伙伴下的密钥
  • 如果对某一条支付记录申请了部分金额的退款,支付宝同时会发出一条类型为trade_status_sync属于付款通知的回调,状态为TRADE_SUCCESS,注意不要与原支付记录的回调混淆,不同之处在于多了refund_feegmt_refund两个字段

付款

从支付宝账户付款出去分为到其他支付宝账户和到银行卡账户,官方提供的文档中只有到支付宝账户
到支付宝账户是有密接口,需要在window+ie下输入密码才能完成付款操作。
到银行卡账户是无密接口,需要联系客服开通,开通时间1-3天。

到银行卡账户接口名称:bptb_pay_file
费率分为T0T1到账:
T0: 0-2万元(不包含2万元)/2元每笔;2万元-5万元(不包含5万元)/4元每笔;5万元-10万元(不包含10万元)/6元每笔;10万元-20万元(不包含20万元)/10元每笔;20万元-50万元(不包含50万元)/20元每笔;50万元-100万元(不包含100万元)/30元每笔;100万元以上的/50元每笔
T1: 0-2万元(不包含2万元)/1元每笔;2万元-5万元(不包含5万元)/3元每笔;5万元-100万元(不包含100万元)/5元每笔;100万元以上的/20元每笔
额度:默认到个人和单位都是单笔500万,单日累计1000万元

坑:

  • 区分T0和T1的字段名为bussiness_type,是拼写错误的

到支付宝的接口名称:batch_trans_notify
费率:0 - 20000元/0.50元;20000(含) - 50000元/1.00元;50000元(含)以上/3.00元
额度:默认到个人是单笔500万,到单位是单笔500万,单日累计1000万元

坑:

  • 回调的参数用了^|分隔,如果通过java来做split处理,需要做转义处理为\\^\\|
  • 这个接口是有密的,表单提交之后需要在window+ie下输入密码才能完成付款操作,如果提交表单后未输入密码,这条付款记录会停留在待审核状态,没有超时或者关闭的回调,同一批次号无法重复提交,只能在支付宝网页端对已经提交的批次号进行审核处理:

查询

支付宝的付款回调是很及时的,所以这里查询主要针对付款操作。
开通了付款功能就默认开通了对应的查询功能。
查询付款到银行卡接口:bptb_file_query
查询付款到支付宝账户接口:btn_status_query

总体感受:
支付宝 = 劳动密集型接口 + 高昂费率