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

流程图

入账的流程图如下：

出账的流程图如下：

支付宝接口

收款

为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_fee和gmt_refund两个字段

付款

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

到银行卡账户接口名称：bptb_pay_file 费率分为T0和T1到账： 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

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