1.1The purpose
Provide corresponding access and development guidance for the cooperation platform.
1.2Scope of application
The applicable objects of this document are the technical developers and daily maintenance personnel of the cooperation platform.
2.1Communication specification
All packets initiate the request through HTTP Post in key_value format. During the request, Content-Type is the GBK in the request header, and the interface response returns the data in JSON format in braces.
2.2Safety specification
In order to prevent malicious tampering by hackers during the API call process, calling any API needs to carry a signature, and the response message will also carry a signature. The server will verify the signature according to the request parameters, and the signature is illegal request will be rejected.
2.2.1Signature for the request messages
The signature processing mechanism for request messages is as follows:
First, all the data elements outside the signature domain (sign) in the message are sorted in the ascending order to form the signature string;
second, use the SHA-256 algorithm to summarize the RSA for the signature (SHA-256 for the signature);
finally, the signature results are transferred to 16 bases, and the 16-imal signature string is placed in the signature (sign) field and other data are transmitted through HTTP Post.
2.2.2The checking mechanism of the return message
The checking and processing mechanism for return message is as follows:
The return message is in json format. SHA-256 algorithm is used to summarize the response field, and then the public key provided by the platform is used to do the RSA signature verification operation of the summary and the message (SHA-256 is selected for the algorithm). When the errorcode value is not 0000, there is no response field, and no signature checking is required.
The types of gateway payment available to include:
Checkout payment: Our company provides the cashier page to simplify the customer docking process;
API payment: the customer defines the cashier page to make the customer system more smooth.
3.1Checkout payment
The checkout payment is the fastest way to seamlessly integrate our payment. Through one integration, we can provide all the supported payment methods on the cashier page.
as the figure shows:
Step1: consumer creates an order;
Step2: The merchant system requests our gateway to create a payment order
Step3: Our gateway returns the cashier payment_url
Step4: Merchant system displays the cashier page
Step5: Fill in the payment information and complete the payment
Step6: Our gateway returns the payment result and notifies the result of the payment
3.2API payment
Merchants with PCI certification can connect with our company through the API payment method:
Step1: Consumption creates an order and fills in the payment information on the merchant page
Step2: Merchants initiate a payment request through the Api payment interface
Step3: Our gateway returns the payment result
If the merchant enables 3DS verification, the process is as follows:
Step4: Our system pushes the 3DS verification address
Step5: The merchant system page jumps to the verification page, and the consumer completes the verification
Step6: Our gateway returns the payment result and notifies the result of the payment
http://119.23.247.113:8680/mapi/n_web_pay.api
field |
length |
Y/N/C |
explain |
syscode |
8 |
Y |
Distribution when online Test with:20000023 |
merchant_id |
10 |
Y |
Merchant number,Provided during system docking. |
charset |
8 |
C |
give tacit consent to GBK |
trans_time |
14 |
Y |
Transaction time:YYYYMMDDHHMMSS |
amount |
20 |
Y |
Transaction amount, unit points |
currency |
3 |
Y |
CNY |
Tax |
20 |
C |
Some countries or regions need to send the tax field |
Shopping |
20 |
C |
transportation expenses |
payment_type |
2 |
Y |
01:checkout payment 02:api payment |
app_id |
32 |
Y |
Merchant transaction order number should not be repeated on the merchant side; format: merchant mark+8 digit transaction date (day)+9digit order number specifically emphasizes that the 8 digit date requirement here is the same day. |
callback_url |
128 |
C |
The front-end page jumps back to the address after the payment is completed, without carrying the parameters |
notify_url |
128 |
Y |
Receive unified payment asynchronous notice callback address, notification url must be directly accessible url, cannot carry parameters |
terminal_ip |
32 |
C |
The Client Access IP |
subject |
120 |
C |
product description |
body |
120 |
C |
product details |
expire_date |
14 |
C |
The validity date of the order payment, if the format YYYYMMDDHHMMSS has no special requirements, shall be valid within 30 minutes |
time_expire |
10 |
C |
The latest payment time allowed for this order, the transaction will be closed. Value range: 1m~15d. M-minutes, h-hours, d-days, 1c-day (1c-day, closed at 0, whenever when the transaction is created). This parameter value does not accept decimal points, such as 1.5h, which can be converted to 90m. |
When filling in the payment_type=02 |
|||
cardNo |
40 |
Y |
|
CVC/CVV |
4 |
C |
cardtype=01,02,Y; |
validity |
10 |
C |
cardtype=01,02,Y;,MM-YYYY,如08-2026 |
cardtype |
2 |
C |
01:Visa 02:MasterCard 03:Unionpay |
firstname |
120 |
C |
cardtype=01,02,Y; |
lastname |
120 |
C |
cardtype=01,02,Y; |
eamil |
120 |
C |
cardtype=01,02,Y; |
country |
2 |
C |
cardtype=01,02,Y;country code,For example: China, fill in CN |
city |
120 |
C |
cardtype=01,02,Y;ciyt english name |
address |
120 |
C |
cardtype=01,02,Y |
postcode |
20 |
C |
cardtype=01,02,Y |
phone |
20 |
C |
cardtype=01,02,Y |
3ds |
2 |
C |
01:need 3ds;00:non-essential 3ds |
memo |
40 |
C |
Note of order |
sign |
varchar |
Y |
Sha256WithRSA sign |
field |
length |
Y/N/C |
explain |
errorcode |
4 |
Y |
0000:success Other:failures |
errormessage |
256 |
Y |
Return code and only return description information |
trans_id |
16 |
Y |
Numbers or letters |
app_id |
32 |
Y |
Merchant transaction order number |
amount |
20 |
Y |
Unit: points |
currency |
3 |
Y |
CNY |
url_type |
2 |
Y |
1:checkout_url 2:results_url 3:3dsValidation page |
payment_url |
varchar |
Y |
Page jump address |
sign |
varchar |
Y |
Sha256WithRSA sign |
After the user pays successfully, it will jump to the merchant's payment completion page. The web jump is only for the user experience, not as the final result of the payment.
It is recommended to develop only the successful display page and do not read the parameters.
After receiving the notification of the result, the merchant must return the capital SUCCESS, indicating receiving the notification result.
After the merchant RSA verification passes, please be sure to do consistency verification on the key information such as serial number, amount and merchant serial number, to ensure that the key parameters are not changed. If you cannot confirm, please use the Payment Status Query Interface for confirmation. Aynchronous notification fields may increase, to be compatible with returned more fields, not limiting fixed fields.
field |
length |
Y/N/C |
explain |
merchant_id |
10 |
Y |
merchant number |
trans_id |
16 |
Y |
transaction serial number |
result |
1 |
Y |
1: Success 2: Fail3: pending payment 4: invalid 5: Refund or partial refund |
amount |
20 |
Y |
Unit: points |
app_id |
32 |
Y |
Merchant transaction order number |
sign |
varchar |
Y |
Sha256WithRSA sign |
http://119.23.247.113:8680/mapi/n_get_pay_result.api
field |
length |
Y/N/C |
explain |
syscode |
8 |
Y |
Distribution when online |
trans_time |
14 |
Y |
Transaction time:YYYYMMDDHHMMSS |
merchant_id |
10 |
Y |
merchant number |
app_id |
32 |
Y |
Merchant transaction order number |
sign |
varchar |
Y |
Sha256WithRSAsign |
field |
length |
Y/N/C |
explain |
errorcode |
4 |
Y |
0000:success Other:failures |
errormessage |
256 |
Y |
Return code and only return description information |
trans_id |
16 |
Y |
transaction serial number |
result |
1 |
Y |
1: Success 2: Fail3: pending payment 4: invalid 5: Refund or partial refund |
trans_time |
14 |
Y |
Transaction time:YYYYMMDDHHMMSS |
amount |
20 |
Y |
Unit: points |
app_id |
32 |
Y |
Merchant transaction order number |
sign |
varchar |
Y |
Sha256WithRSA sign |
http://119.23.247.113:8680/mapi/n_single_refund.api
field |
length |
Y/N/C |
explain |
syscode |
8 |
Y |
Distribution when online |
trans_time |
14 |
Y |
Transaction time:YYYYMMDDHHMMSS |
charset |
8 |
C |
give tacit consent to GBK |
merchant_id |
10 |
Y |
merchant number |
pay_amount |
20 |
C |
Original transaction amount, unit points |
amount |
20 |
Y |
Refund amount, unit points |
app_id |
32 |
Y |
Merchant refund serial number Special emphasis: the refund request flow should not be the same as the original merchant order number app_id |
trans_id |
16 |
Y |
Original transaction serial number |
notify_url |
128 |
Y |
The url address that the merchant implements for receiving an asynchronous notification cannot have parameters |
memo |
40 |
C |
Note instructions |
sign |
varchar |
Y |
Sha256WithRSA sign |
field |
length |
Y/N/C |
explain |
errorcode |
4 |
Y |
0000:success Other:failures |
errormessage |
256 |
Y |
Return code and only return description information |
refund_id |
16 |
Y |
Channel refund serial number |
trans_id |
16 |
Y |
Original transaction serial number |
app_id |
32 |
Y |
Merchant refund serial number |
amount |
20 |
Y |
Unit: points |
result |
1 |
Y |
1: Success 2: Fail3: Processing |
note |
128 |
Y |
Reasons for the Failof refund |
sign |
varchar |
Y |
Sha256WithRSA sign |
After receiving the notification of the result, the merchant must return the capital SUCCESS, indicating receiving the notification result.
After the merchant RSA verification passes, please be sure to do consistency verification on the key information such as serial number, amount and merchant serial number, to ensure that the key parameters are not changed. If you cannot confirm, please use the "Gateway Refund Status Query" to cooperate with the confirmation.
field |
length |
Y/N/C |
explain |
merchant_id |
10 |
Y |
merchant number |
refund_id |
16 |
Y |
Channel refund serial number |
trans_id |
16 |
Y |
Original transaction serial number |
result |
1 |
Y |
1: Success 2: Fail3: Processing |
amount |
20 |
Y |
Unit: points |
app_id |
32 |
Y |
Merchant refund serial number |
sign |
varchar |
Y |
Sha256WithRSA sign |
http://119.23.247.113:8680/mapi/n_get_refund_result.api
field |
length |
Y/N/C |
explain |
syscode |
8 |
Y |
Distribution when online |
trans_time |
14 |
Y |
Transaction time:YYYYMMDDHHMMSS |
merchant_id |
10 |
Y |
merchant number |
app_id |
32 |
Y |
Merchant refund serial number |
sign |
varchar |
Y |
Sha256WithRSA sign |
field |
length |
Y/N/C |
explain |
errorcode |
4 |
Y |
0000:success Other:failures |
errormessage |
256 |
Y |
Return code and only return description information |
refund_id |
16 |
Y |
Channel refund serial number |
trans_id |
16 |
Y |
Original transaction serial number |
result |
1 |
Y |
1: Success 2: Fail3: Processing |
Trans_date |
14 |
C |
Transaction time:YYYYMMDDHHMMSS |
amount |
20 |
Y |
Unit: points |
app_id |
32 |
Y |
Merchant refund serial number |
create_time |
24 |
Y |
Refund time, format:yyyy-MM-dd HH:mm:ss |
trade_time |
24 |
Y |
Completion time, format:yyyy-MM-dd HH:mm:ss |
note |
128 |
C |
Reasons for the Failof refund |
sign |
varchar |
Y |
Sha256WithRSA sign |
http://119.23.247.113:8680/mapi/n_pay_cancel.api
field |
length |
Y/N/C |
explain |
syscode |
8 |
Y |
Distribution when online |
trans_time |
14 |
Y |
Transaction time:YYYYMMDDHHMMSS |
charset |
8 |
C |
give tacit consent to GBK |
merchant_id |
10 |
Y |
merchant number |
app_id |
32 |
Y |
The transaction closing request flow represents the unique serial number format of this request: merchant mark + 8-bit date (that day) + 9-digit order number, and the column number specially emphasizes that the 8-digit date requirement here is the same day. |
trans_id |
16 |
Y |
Original transaction serial number |
memo |
40 |
C |
Cancel the instructions |
sign |
varchar |
Y |
Sha256WithRSA sign |
field |
length |
Y/N/C |
explain |
errorcode |
4 |
Y |
0000:success Other:failures |
errormessage |
256 |
Y |
Return code and only return description information |
trans_id |
16 |
Y |
Transaction serial number |
app_id |
32 |
Y |
Merchant transaction order number |
result |
1 |
Y |
1: Success 2: Fail3: Processing 4: Failure |
sign |
varchar |
Y |
Sha256WithRSA sign |
errorcode |
meaning |
0000 |
success |
1234 |
Transaction failure, the specific reason of the Failview:errromessage |
3329 |
sign not go |
3341 |
parameter error |
3342 |
Failed to create order |
3343 |
The communication is abnormal |
3344 |
Response data format error |
3003 |
The payment channel is not configured, please contact the business manager |
3005 |
Merchant number error |
3040 |
The amount of error |
3031 |
Order number repeated |
merchant_id |
9265000021 |
syscode |
20000207 |
Test private key |
9265000021-prikey-only.pem |
Test public key |
pubkey.pem |
JAVA DEMO |
WebPay_Java_Demo_Develop reference |
Test private key 9265000021-prikey-only.pem(sign), Test public key test5-pubkey.pem(checking sign)
9265000021-prikey-only.pem pubkey.pem
JAVA decryption reference DEMO
PHP decryption reference DEMO
The merchant generates a pair of RSA secret keys, and the private key merchant retains them for the message sign, and transmits the public key to the docking business personnel.
The business personnel will pass the platform public key to the merchant, and the merchant is used to check and sign the return message and the asynchronous notification message.