近期在做微信支付那方面的工作,由于要在之前开发人员的基础上进行开发,其中使用到了ping++这个第3方支付的SDK。不得不说,ping++的SDK做的挺简单的,但是其文档真心写的有点坑。不过相对其他的接入,坑少了那么一些。
下面梳理下正常开发的流程,请点击下面的链接付款。
可以看到主要有5个步骤:

1. 设置 API-Key

2. SDK 验证签名设置

3. 发起支付请求获取支付凭据

4. 将获得的支付凭据传给 Client

5. 接收 Webhooks通知(开启Live模式才有用)

然后再看下SDK交易流程,可以发现写的还是挺通俗易懂的。
个人觉得比较坑爹的是它API文档的部分,完全就是逗你玩的。为什么这么说,请往下看。
官方说Ping++的API采用REST风格设计,真的是REST风格,完全停留在CURD的阶段,离后面的发展还有很长的路要走。实话说,Github API写的还比较像REST些,而这个ping++的就不想说了。

入坑

下面我们正式入坑,其最简单的方式如下,使用curl进行请求:

curl https://api.pingxx.com/v1/charges \\
  -u sk_test_ibbTe5jLGCi5rzfH4OqPW9KC:

官方采用Authentication Basic的方式进行验证,一般都会过的,返回你要的数据。但是官方提供的例子真心的简单,而且只用uncap这种方式,而我们公司要使用的是微信公众支付,那么坑就出来了。当时我是这样请求的:

c@y-pc:~$ curl https://api.pingxx.com/v1/charges   -u sk_test_ibbTe5jLGi5rzfH4OqPW9KC:   -d order_no=123456789   -d amount=100   -d app[id]=app_1Gqj58ynP0mHeX1q   -d channel=wx_pub   -d currency=cny   -d client_ip=127.0.0.1   -d subject=\"Your Subject\"   -d body=\"Your Body\"   -d extra=\'{\"open_id\":\"xxxxx\"}\'
{
    \"error\": {
        \"type\": \"invalid_request_error\",
        \"message\": \" 无效的参数 extra: 必须是一组键值对\",
        \"param\": \"extra\"
    }

注意,这里我们将channel修改为wx_pub了,因此必须添加1个extra字段,在该字段中有1个open_id必填的玩意。结果,总是提示extra必须是1组键值对。很明显,难道extra=\'{\"open_id\":\"xxxxx\"}不是1个键值对吗,但是机器看不出来它是。

出坑

后面,我们准备跳出这个坑,我们去看官方给我们提供的SDK中的例子,可以发现app[id]这里的id是以{\”id\”:\”xxxx\”}这样的方式存在的,而不是理解为app[id]这样1个字段,因此我们换个方式进行请求:

curl https://api.pingxx.com/v1/charges   -u sk_test_ibbTe5jLGi5rzfH4OqPW9KC:   -d order_no=123456789   -d amount=100   -d app[id]=app_1Gqj58ynP0mHeX1q   -d channel=wx_pub   -d currency=cny   -d client_ip=127.0.0.1   -d subject=\"Your Subject\"   -d body=\"Your Body\"   -d extra[open_id]=xxxxx
{
    \"id\": \"ch_C4O4CKXHCK48rnvn5CH8iP4G\",
    \"object\": \"charge\",
    \"created\": 1460257030,
    \"livemode\": false,
    \"paid\": false,
    \"refunded\": false,
    \"app\": \"app_1Gqj58ynP0mHeX1q\",
    \"channel\": \"wx_pub\",
    \"order_no\": \"123456789\",
    \"client_ip\": \"127.0.0.1\",
    \"amount\": 100,
    \"amount_settle\": 100,
    \"currency\": \"cny\",
    \"subject\": \"Your Subject\",
    \"body\": \"Your Body\",
    \"extra\": {
        \"open_id\": \"xxxxx\"
    },
    \"time_paid\": null,
    \"time_expire\": 1460264230,
    \"time_settle\": null,
    \"transaction_no\": null,
    \"refunds\": {
        \"object\": \"list\",
        \"url\": \"/v1/charges/ch_C4O4CKXHCK48rnvn5CH8iP4G/refunds\",
        \"has_more\": false,
        \"data\": []
    },
    \"amount_refunded\": 0,
    \"failure_code\": null,
    \"failure_msg\": null,
    \"metadata\": {},
    \"credential\": {
        \"object\": \"credential\",
        \"wx_pub\": {
            \"appId\": \"wxmbrpg8tm1k04yzbt\",
            \"timeStamp\": 1460257030,
            \"nonceStr\": \"25c7de13570a1b5f6d23614bdf49443d\",
            \"package\": \"prepay_id=1101000000160410rtepylz1surl5uzd\",
            \"signType\": \"MD5\",
            \"paySign\": \"10F1AACE79C0ED0E10EB4080D140F913\"
        }
    },
    \"description\": null

这里我们将open_id放在extra中就成功了,这样才可以接收到。不得不说,这API调用完全就是1个坑。主要是官方没有提供明确的请求头信息给我们,导致我们一直在兜圈。
所以,我不排除这文档就是1个实习生写的。不得不说,官方给我们提供了1个不知名的REST的scheme,如果不是过这个坑完全就是不知道它在弄哪样。比如jsonapi提供了这样1种请求方式,预计如果不说明,你也看不懂它写的是什么:

GET /posts?include=author&sort[posts]=-created,title&sort[people]=name

下面是上述请求的响应头信息:

c@y-pc:~$ curl https://api.pingxx.com/v1/charges   -u sk_test_ibbTe5jLGCi5rzfH4OqPW9KC:   -d order_no=123456789   -d amount=100   - app[id]=app_1Gqj58ynP0mHeX1q   -d channel=wx_pub   -d currency=cny   -d client_ip=127.0.0.1   -d subject=\"Your Subject\"   -d body=\"Your Body\"   -d extra[open_id]=xxxxx -v
*   Trying 121.43.74.100...
* Connected to api.pingxx.com (121.43.74.100) port 443 (#0)
* ALPN, offering http/1.1
* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/certs/ca-certificates.crt
  CApath: none
* TLSv1.2 (OUT), TLS header, Certificate Status (22):
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Server hello (2):
* NPN, negotiated HTTP1.1
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Client hello (1):
* TLSv1.2 (OUT), TLS handshake, Unknown (67):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS change cipher, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256
* ALPN, server did not agree to a protocol
* Server certificate:
*      subject: C=CN; ST=Shanghai; L=Shanghai; O=Shanghai Jianmi Network Technology Co., LTD; OU=IT; CN=api.pingxx.com
*      start date: Nov 19 00:00:00 2015 GMT
*      expire date: Jan 17 23:59:59 2017 GMT
*      subjectAltName: api.pingxx.com matched
*      issuer: C=US; O=Symantec Corporation; OU=Symantec Trust Network; CN=Symantec Class 3 Secure Server CA - G4
*      SSL certificate verify ok.
* Server auth using Basic with user \'sk_test_ibbTe5jLGCi5rzfH4OqPW9KC\'
> POST /v1/charges HTTP/1.1
> Host: api.pingxx.com
> Authorization: Basic c2tfdGVzdF9pYmJUZTVqTEdDaTVyemZINE9xUFc5S0M6
> User-Agent: curl/7.47.1
> Accept: */*
> Content-Length: 163
> Content-Type: application/x-www-form-urlencoded
> 
* upload completely sent off: 163 out of 163 bytes
< HTTP/1.1 200 OK
< Date: Sun, 10 Apr 2016 03:26:51 GMT
< Content-Type: application/json;charset=utf-8
< Content-Length: 1229
< Connection: keep-alive
< X-Powered-By: PHP/5.6.2
< Access-Control-Allow-Methods: GET, POST, HEAD, OPTIONS, DELETE
< Access-Control-Max-Age: 300
< Access-Control-Allow-Credentials: true
< Cache-Control: no-cache, no-store
< Strict-Transport-Security: max-age=31536000; includeSubDomains

我们使用-v选项查看了其详细的内容,甚至连TCP的3次握手过程都可以看到。
还有就是出错信息,最好看下面的链接报错信息。

参考文章:

https://www.pingxx.com/document/api/#api-charges