1.Introduction

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.Development specification

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.

3.Gateway type introduction

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

4.Payment interface

4.1Payment initiation request

1)Interface address

http://119.23.247.113:8680/mapi/n_web_pay.api

2)request message

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

3)Response message

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

4.2Pay Sync Page

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.

4.3Notice of payment results

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.

message format

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

4.4Payment status query

1)Interface address

http://119.23.247.113:8680/mapi/n_get_pay_result.api

2)request message

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

3)Response message

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

5.Refund

5.1Request for refund

1)Interface address

http://119.23.247.113:8680/mapi/n_single_refund.api

2)request message

field

length

Y/N/C

explain

syscode

8

Y

Distribution when online

trans_time

14

Y

Transaction timeYYYYMMDDHHMMSS

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

3)Response message

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

5.2Refund result notice

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.

1)message format

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

5.3Refund status query

1)Interface address

http://119.23.247.113:8680/mapi/n_get_refund_result.api

2)request message

field

length

Y/N/C

explain

syscode

8

Y

Distribution when online

trans_time

14

Y

Transaction timeYYYYMMDDHHMMSS

merchant_id

10

Y

merchant number

app_id

32

Y

Merchant refund serial number 

sign

varchar

Y

Sha256WithRSA sign

3)Response message

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 timeYYYYMMDDHHMMSS

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

5.4Cancel order

1)Interface address

http://119.23.247.113:8680/mapi/n_pay_cancel.api

2)request message

field

length

Y/N/C

explain

syscode

8

Y

Distribution when online

trans_time

14

Y

Transaction timeYYYYMMDDHHMMSS

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

3)Response message

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

6.Errorcode

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

7.Parameter configuration

7.1Test parameter

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

 

7.2Formal parameters

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.