支付宝sdk工具，支付SDK？

接入支付宝支付SDK

可以说支付宝支付接入是所有SDK最好接入的，没有之一。

客户端不用签名，也不用管包名，也不用管签名文件，就接口返回订单，把订单交给支付宝SDK调用就行，成功或者失败都在当前界面返回给你。你再去通知接口。

支付流程图

官方文档地址

！支付宝支付官方文档地址

按照文档说明接入SDK和相关配置，在这就不重复了

客户端支付关键代码===》支付接口的调用(调起支付弹框)

记住支付接口的调用必须在独立的非ui线程中执行，即需新开线程里面调用。可以想官方demo一样用new Thread方式。

下面我给出用Observable方式示例代码

在PayUtils中

/**

* desc:支付宝支付

* Created by congge on 2018/8/27 17:20

* @param orderInfo 接口返回的订单

**/

public static void aliPay(final Activity activity, final String orderInfo, final OrderListener orderListener) {

Observable.just(orderInfo)

.map(new Function () {

@Override

public String apply(String orderInfo) throws Exception {

//用户在商户app内部点击付款，是否需要一个loading做为在钱包唤起之前的过渡，这个值设置为true

return new PayTask(activity).pay(orderInfo, true);

}

})

.subscribeOn(Schedulers.io())

.observeOn(AndroidSchedulers.mainThread())

.subscribe(new Consumer () {

@Override

public void accept(String payResult) throws Exception {

orderListener.onPayResult(payResult);

}

});

}

支付结果返回处理

返回例子：

resultStatus={9000};memo={};result={{"alipay_trade_app_pay_response":{"code":"10000","msg":"Success","app_id":"2016091300503896","auth_app_id":"2016091300503896","charset":"utf-8","timestamp":"2018-08-28 17:51:11","out_trade_no":"nVElbd74TW6WnEyxQwvX8A","total_amount":"0.01","trade_no":"2018082821001004680500208879","seller_id":"2088102175487650"},"sign":"W0Hg9k4GxL8Oaxymvqk2i65WNDQxYp6HGve32ek6VjSRnymmI3GQTjpQVbZuDzvjcwQ/HIkM97PoBGAVlTmi/wiJcqDgSSDzDY7AFnNN0OcK0ehWGwKQINA4IDGh51A7yY/vYKmR0VW+2OwGhlRPPMMZtQOEqh8a9/aIijzT6ZLwy9Hl4ayG/fVKhdC1VdckF6+C25BFNp3fIxarg5tfEunm7N9iWngKCUsnP+IZz05OHdvynimgYPcBnbBERHG97GVqRT/EdBWTQyIDMc0LemScAYxJixTVgXDkRddQjzWZ7HgLdBfjs0nXY24puHudT76ERxVY+8NkoKle/QI+FA==","sign_type":"RSA2"}}

也可以自己打log看看

处理示例代码：

//支付宝支付

PayUtils.aliPay(this, result.getSignDataStr(), new PayUtils.OrderListener() {

@Override

public void onPayResult(String payResult) {

PayResult pr = new PayResult(payResult);

String rs = pr.getResultStatus();

String r = pr.getResult();

switch (rs) {

case AliPayResultStatus.PAY_SUCCESS:

ToastUtils.show(R.string.pay_success);

//通知接口支付成功

break;

case AliPayResultStatus.PAY_PROCESSING:

case AliPayResultStatus.PAY_UNKNOWN:

ToastUtils.show(R.string.pay_fail);

//支付可能成功，要接口去查询

break;

default:

ToastUtils.show(R.string.pay_fail);

//通知接口支付失败，取消订单

}

});

上面方法中：

//通知接口支付成功 //支付可能成功，要接口去查询 //通知接口支付失败，取消订单。根据你产品需求要不要通知你服务器做的操作。正常是要的，用来改变订单状态

PayResult.class

public class PayResult {

private String resultStatus;

private String result;

private String memo;

public PayResult(String rawResult) {

if (TextUtils.isEmpty(rawResult))

return;

String[] resultParams = rawResult.split(";");

for (String resultParam : resultParams) {

if (resultParam.startsWith("resultStatus")) {

resultStatus = gatValue(resultParam, "resultStatus");

}

if (resultParam.startsWith("result")) {

result = gatValue(resultParam, "result");

}

if (resultParam.startsWith("memo")) {

memo = gatValue(resultParam, "memo");

}

@Override

public String toString() {

return "resultStatus={" + resultStatus + "};memo={" + memo

+ "};result={" + result + "}";

}

private String gatValue(String content, String key) {

String prefix = key + "={";

return content.substring(content.indexOf(prefix) + prefix.length(),

content.lastIndexOf("}"));

}

public String outOrder() {

String order = ""out_trade_no"";

if (result.contains(order)) {

String begin = result.substring(result.indexOf(order));

String ss = begin.split(",")[0];

String newS = ss.replace(""", "")

.replace("}", "")

.replace(":", "")

.replace("out_trade_no", "");

try {

return newS;

} catch (Exception e) {

e.printStackTrace();

}

return "";

}

/**

* @return the resultStatus

public String getResultStatus() {

return resultStatus;

}

/**

* @return the memo

public String getMemo() {

return memo;

}

/**

* @return the result

public String getResult() {

return result;

}}

最后给下支付返回码表

AliPayResultStatus.class

public class AliPayResultStatus {

/**

* 订单支付成功,唯一肯定是支付成功的

public static final String PAY_SUCCESS = "9000";

/**

* 正在处理中，支付结果未知（有可能已经支付成功），请查询商户订单列表中订单的支付状态

public static final String PAY_PROCESSING = "8000";

/**

* 订单支付失败

public static final String PAY_FAIL = "4000";

/**

* 重复请求

public static final String PAY_REPEAT = "5000";

/**

* 用户中途取消

public static final String PAY_PROCESS_CANCEL = "6001";

/**

* 网络连接出错

public static final String PAY_NET_ERROR = "6002";

/**

* 支付结果未知（有可能已经支付成功），请查询商户订单列表中订单的支付状态

public static final String PAY_UNKNOWN = "6004";}

还有一个直接弃用沙箱调试模式，否则提示支付失败也有可能不知道错在那，怕金额大，和接口商量，测试服务器就用0.01测试。

四、公钥和私钥，加密和数字签名

本文涉及到支付宝SDK的内容，均摘自支付宝开放平台。

因为支付宝SDK使用RSA来加密和生成数字签名，所以本文中涉及到的概念也都是针对于RSA的。

一对儿密钥生成后，会有公钥和私钥之分，我们需要把私钥保存下来，而把公钥发布出去。一对儿公钥和私钥，不能由其中一个导出另一个。

比如使用支付宝SDK的时候，我们商户端会生成一对儿密钥A和B，A是私钥，B是公钥，支付宝也会生成一对儿密钥C和D，C是私钥，D是公钥。我们商户端需要把商户端私钥A保存下来，而把商户端公钥B发布出去给支付宝，支付宝需要把支付宝私钥C保存下来，而把支付宝公钥D发布出去给我们商户端。

加密是指我们使用一对儿密钥中的一个来对数据加密，而使用另一个来对数据解密的技术，需要注意的是公钥和私钥都可以用来加密，也都可以用来解密，并不是规定死了只能用公钥加密私钥解密，但是加解密必须是一对儿密钥之间的互相加解密，否则不能成功。

加密的目的是为了保证数据的不可读性，防止数据在传输过程中被截获。

知道了加密这个概念，我们先看一下支付宝的加密过程，再引出数字签名这个概念。接着第1小节的例子，当我们商户端和支付宝互相发布了公钥之后，我们商户端手里就有商户端私钥和支付宝公钥两个密钥，支付宝手里也有商户端公钥和支付宝私钥两个密钥。现在假设我们商户端要给支付宝传输订单信息，那么为了保证传输订单信息时数据的安全性，结合我们商户端手里所拥有的密钥，可以有两套加密方案

貌似这两套加密方案都能达到对订单信息加密的效果，而且如果采用方案二，我们商户端甚至只需要存储支付宝公钥这一个密钥，都不用去申请一对儿商户端的公私钥来维护，支付宝也不用保存我们一堆商户那么多的商户端公钥了，这不是更简单吗，那为什么支付宝开放平台让我们采用的是方案一而不是方案二呢？下面来回答一下。

支付宝开放平台说明：当我们采用RSA（1024位密钥）来加密的时候，支付宝分配给所有商户的支付宝公钥都是一样的，即支付宝针对那么多的商户只负责维护一对儿支付宝公私钥，这就意味着支付宝公钥随便什么人拿到后都是一样的；而当我们采用RSA2（2048位密钥）来加密的时候，支付宝会分配给每个商户单独的一个支付宝公钥，即支付宝为每一个的商户单独的维护一对独立的支付宝公私钥，当然一个商户下的多个App的支付宝公钥是一样的。RSA是早就支持的，RSA2是最近才支持的。

知道了上面这段话，现在假设我们采用的是方案二，并且采用RSA加密（很多老业务并没有使用RSA2加密），业务逻辑将会是下面这样。

这就出问题了， RSA加密下，支付宝公钥是公开发布的，而且所有的商户用的都是同一个支付宝公钥（上面声明了RSA2加密下，支付宝才针对每个商户维护了一对儿公私钥），攻击者很容易就能获取到，而 notify_url 也很容易被截获，那攻击者拿到这两个东西就可以做和商户一样的操作来发起支付请求，这样就会一直给小明充钱了。

所以支付宝就需要确认支付请求确实是商户发给他们的，而不是攻击者发给他们的。这就用到了数字签名，我们会通过方案一的实现流程来引出数字签名的具体概念。如果我们采用的是方案一，我们商户端保存的就是商户端私钥和支付宝公钥，而支付宝保存的就是需要存着商户端公钥和支付宝私钥的，业务逻辑将会是下面这样。

这样就可以保证交易的安全性了，我们也可以看出使用支付宝SDK保证交易的安全性注重的其实不是订单信息是否加密，而是如何确保商户端和支付宝能够互相确认身份，订单信息是明文的，但是后面拼接了数字签名。

数字签名其实就是明文数据加密之后得到的一个密文，只不过它是用私钥加密生成的而已，我们一般会把数字签名拼接在明文数据后面一起传递给接收方，接收方收到后用公钥解密数字签名，从而验证发送方的身份、以及明文数据是否被篡改。数字签名的生成过程其实就是一个加密过程，数字签名的验签过程就是一个解密过程。

数字签名的目的有两个：一、发送方和接收方互相验证身份；二、验证数据是否被篡改。

从上面第一部分我们知道为了确保商户和支付宝交易的安全性，约定采用的是给订单信息加数字签名传输的方式。支付宝也为我们提供了一键生成RSA密钥的工具，可以帮助我们很快的生成一对商户端公私钥。以下会对支付宝SDK的支付流程做个大概的解释，并点出实际开发中我们使用支付宝SDK时应该注意的地方。

由我们商户端自己生成的RSA私钥（必须与商户端公钥是一对），生成后要保存在服务端，绝对不能保存在客户端，也绝对不能从服务端传输给客户端。

用来对订单信息加签，加签过程一定要在服务端完成，绝对不能在客户端做加，客户端只负责用加签后的订单信息调起支付宝来支付。

由我们商户端自己生成的RSA公钥（必须与商户端私钥是一对），生成后需要填写在支付宝开放平台。

用来给支付宝服务端验签经过我们加签后的订单信息，以确保订单信息确实是我们商户端发给支付宝的，并且确保订单信息在传输过程中未被篡改。

这个和我们就没关系了，支付宝私钥是他们自己生成的，也是他们自己保存的。

用来对支付结果进行加签。

支付宝公钥和支付宝私钥是一对，也是支付宝生成的，当我们把商户端公钥填写在支付宝开放平台后，平台就会给我们生成一个支付宝公钥，我们可以复制下来保存在服务端，同样不要保存在客户端，并且不要传输给客户端。

用来让服务端对支付宝服务端返给我们的同步或异步支付结果进行验签，以确保支付结果确实是由支付宝服务端返给我们服务端的，而且没有被篡改，对支付结果的验签工作也一定要在服务端完成。

上面已经说过了：订单信息的加签和支付结果的验签是一定要在服务端做的，绝对不能在客户端做。

下面是在客户端对订单信息加签的过程，仅仅是为了模拟服务端来表明订单信息是如何通过加签最终转变为orderString的，千万不要觉得订单信息的加签过程也可以放在客户端完成。