Pay the Treasure Pole simple cashier (Wireless quick payment) sdk,php Service end Access Experience ____php

Since July 2012 Alipay officially announced that the PC fast payment and mobile end through, after several versions of iterations. Then Alipay launched a minimalist checkout counter.

Compared to the old version of the wireless Fast Payment SDK, the minimalist request and callback parameters and verification methods are very different.

In the process of docking with Alipay also encountered a lot of problems, and we share the process of solving.

Legacy SDK: Wireless Quick Payment (a version of November 2012 ago, I did not participate)

New SDK: Wireless Quick payment minimalist Cashier (June 2014)

Pre-Preparation:
Merchant Public key, private key (generated by the merchant itself, Alipay will provide the generation tool, also can use OpenSSL generation), the merchant retains the merchant key to be used, the merchant public key is uploaded to the Alipay platform.

Alipay public key, private key, Alipay own keep Alipay private key. Alipay Public key will be obtained when Merchant's public key is uploaded.

That is: Merchant owned: Merchant private key, Alipay public key
Alipay owned: Merchant public key, Alipay private key

The process of wireless payment:

1, the mobile end to generate orders and payment parameters (such as order amount, etc.), the use of merchant private key signature parameters, and then request Alipay payment.
2, Alipay received the request after the use of merchant public key Verification request parameters, verification after the approval of the user to pay, the user paid after the payment treasure to generate callback parameters, and Alipay private key signature parameters, and then callback merchant.
3, the callback is divided into 2 parts, synchronous callback (callback to mobile end), asynchronous callback (callback to the merchant's server). If the mobile end is in the parameter that generates the payment request by Notify_url, example: notify_url=http://www.testpay.com/act=notify_return?order_id=12345, Then Alipay will callback this address asynchronously after payment is completed.

The business logic of my Project:
Because the payment signature needs to use the merchant private key, store in the mobile phone side app has the security problem, therefore in my project has placed the merchant private key on the service side, the payment request's parameter signature is completes by the service side.

1. Mobile phone to import Alipay SDK, when you need to pay the phone to generate some payment related parameters, to the merchant service end
2. The service side receives the request to generate the actual order in the database, then uses the merchant private key to sign the payment parameter, after completes synchronously returns the handset end
3. Phone end received after return using the Payment Treasure SDK provided by the function request Alipay payment, pay treasure check through to allow users to pay after the completion of the payment after the synchronization callback mobile phone end (mobile phone end of the message to tell users to pay the success of the payment over there), asynchronous callback Merchant Server (merchant Server received callback after verification, After verification, change your order status and some other subsequent business.

The entire wireless payment business has been completed thus far.

Here are some of the problems encountered during access:

1. The difference between the new and old SDK payment requests for signature parameters

Old version:
$notify _url = UrlEncode (pay_center_domain. '/notify?oid= '. $out _trade_no); Asynchronous callback Address

Assemble the data to be signed
$signData = ' partner= '. $partner. ' & ';
$signData. = ' seller= '. $seller. ' & ';
$signData. = ' out_trade_no= '. $out _trade_no. ' & ';
$signData. = ' subject= '. $subject. ' & ';
$signData. = ' body= '. $body. ' & ';
$signData. = ' total_fee= '. $totalFee. ' & ';
$signData. = ' notify_url= '. $notify _url. ‘”‘;

New:

$notify _url = UrlEncode (pay_center_domain. '/notify?oid= '. $out _trade_no); Asynchronous callback Address

Assemble the data to be signed
$signData = ' _input_charset= ' utf-8″& '; New required parameter coded character Set default value: Utf-8
$signData. = ' body= '. $body. ' & ';
$signData. = ' notify_url= '. $notify _url. ' & ';
$signData. = ' out_trade_no= '. $out _trade_no. ' & ';
$signData. = ' partner= '. $partner. ' & '; Partner ID
$signData. = ' payment_type= ' 1″& '; New required Payment Type default value: 1 (product purchase)
$signData. = ' seller_id= '. $seller. ' & '; Change Required seller Alipay account parameter name changed from seller to seller_id
$signData. = ' service= ' mobile.securitypay.pay ' & '; New Required entry interface name. Fixed value. Default: Mobile.securitypay.pay
$signData. = ' subject= '. $subject. ' & ';
$signData. = ' total_fee= '. $totalFee. ‘”‘;

The comparison can be seen in addition to some of the new parameters and seller parameters modified to seller_id, the most obvious difference between the old version of the parameter support unordered, the new version of the parameter to sort in ascending order.

2. Synchronous callback has no sign value, asynchronous no callback

Request Alipay Payment Successful after the correct flow should be the phone end received Alipay synchronization callback, the server received an asynchronous callback. But we have a problem.
Synchronization callback, but the value of the sign parameter in the callback is empty, and there is no asynchronous callback service side.
Consulted the Alipay technician after being told that the security check code was not uploaded (merchant RSA public Key).
The old version of the SDK has been used until now, the merchant RSA public key has been uploaded, how did not upload it. After the http://b.alipay.com view PID found that the original RSA public key did upload, in the "Application Access Information" column. But now in the "PID and Key" One more "security check Code", which also has the RSA public key upload.
After uploading, the callback is normal.

But let me baffled is that the process said merchant public key private key only in the request to pay the treasure to use, can be successful payment on the payment treasure in the verification of the request to use the merchant to upload the public key, then why callback also need "security check code" in the upload RSA public key.

3. Asynchronous callback, server verification but

For the new and old version 2 SDK, Alipay offers 2 different Alipay public keys. So when you have multiple apps, the old app uses the old SDK, the new app, but the asynchronous callback server is one, how can you tell what version of the SDK the callback is using to check it with the right Alipay public key? Asked 2 Alipay techniques to give a different answer, A minimalist checkout callback is a service parameter that is not available in the old version. One says that the old and new version of the callback parameters are the same.

See the code found through the "notify_data" to determine whether the new and old SDK, only the old version of the SDK has this parameter, while the old version is directly with the "Notify_data" to do the verification, such as:

"Notify_data": "Xxx@xxx.com<\/seller_email> 2088xxxxxxxxxxxx<\/partner>1<\/payment_type> 1xxxxxxxx10<\/buyer_email>
20140616xxxxxxxx<\/trade_no>2088xxxxxxxxxxxx1<\/quantity>30.00<\/total_fee>n<\/use_coupon >y<\/is_total_fee_adjust>30.00<\/price>20140616xxxxxxxxxxxx<\/out_trade_no>2014-06-16 XX: Xx:xx<\/gmt_create>2088xxxxxxxxxxxx<\/seller_id>xxxxxxxxxxxxxxxxxxxxx<\/subject>
Wait_buyer_pay<\/trade_status>0.00<\/discount><\/notify> "

As you can see, the value is in XML format (the escape chart cares, in order to show convenience, the actual is not). The object of verification is Notify_data= "Notify_data_value".

And the minimalist checkout is not, for the service side, to their own stitching verification parameters, that is: remove sign,sign_data parameters, remove Notify_url parameters, such as your callback address is http://www.aaa.com/notify?order_id =123456, then the Alipay callback is actually shaped like this:

Http://www.aaa.com/notify?order_id=123456&dicount=0.01&seller_email=xxx@xxx.com&seller_id= 2088xxxxxx ...

Then there will be $_post[' order_id ' in the $_post because of the parameters in the Notify_url, so there is no need for verification.
If your notify_url is shaped like: http://www.bbb.com/1234567.html, then there is no such problem.

All others remain (including notify_id), and the reserved fields are sorted in ascending order of the key names. And then to & splicing, such as: K1=v1&k2=v2& This string of characters is the object that you want to check.

Transfer from (http://www.momohaha.com)