Before you make any payments, it is important to understand how Alipay API works and how requests and responses are structured. This section presents general information (such as message structure, message fields, and message transmission) of online message between your system and Alipay. A message refers to the request message or the response message.
#Request message structure
The following figures illustrate the request message structure:
Figure 1. Request structure
The request URL is:
host is the standard domain name assigned by Alipay.
restfulPath is the path to the interface.
An interface can be uniquely identified by restfulPath and majorVersion.
POST method is used to make an HTTP request.
The request header mainly contains fields such as Client-Id, Signature, Encrypt, Content-Type, Request-Time, and Agent-Token.
Client-Id is used to identify a client, and is associated with the keys that are used for signature and encryption.
Signature contains key-value pairs that are separated by comma (,). Each key-value pair is an equation, which is a key joined with its value with an equal sign (=).
The following keys can be configured:
- algorithm: Specifies the digital signature algorithm that is used to generate the signature. The value is not case-sensitive. RSA256 and ECC224 are supported, and RSA256 by default.
- keyVersion: Specifies the key version that is used to generate or validate the signature. By default, the value is the latest version of the key associated with Client-Id.
- signature: Contains the signature value of the request.
This field is required when a message need to be encrypted. Encrypt contains key-value pairs that are separated by comma (,). Each key-value pair is an equation, which is a key joined with its value with an equal sign (=).
The following keys can be configured:
• algorithm: Specifies the symmetric key algorithm that is used to encrypt message. The value is not case-sensitive, and currently only RSA_AES is supported.
• keyVersion: Specifies the symmetric key version that is used to encrypt message. By default, the value is the latest version of the key associated with clientId.
• symmetricKey: Contains the encrypted symmetric key.
Optional. Content-Type indicates the media type of the body of the request, as defined by RFC2616. In which, charset is used for generating/validating signature and encrypting/decrypting content.
Specifies the time when the request is sent, as defined by RFC3339. Note: This field must be accurate to milliseconds.
An agent can obtain the token from Alipay, and then use this client authorized token to interact with Alipay.
The request body contains the detailed request information in a JSON format. Fields enclosed in the request body section vary depending on services. For more information, see instructions of the specific message interface.
The following figures illustrate the response structure:
Figure 2. Response structure
Response header carries additional information about the response, such as the signature and the encryption. Most fields in the response header are the same as that of the request header, except:
Specifies the time when the response is sent, as defined by RFC3339.
Response body contains the information responding to the client. Fields in this section vary depending on services. However, the result parameter, which indicates the result of an interface call, is always contained.
Read the following chapter for general information of message fields, such as data type, common data structure, and processing rules of special characters.
This following table describes the data types supported by Alipay.
A sequence of bytes.
Date time as defined by RFC3339. For example, 2020-01-01T23:59:59+08:00
A three-part value (yyyyMMdd) designating a time point in time.
The boolean value can be either true or false.
A numeric value without a decimal.
A numeric value with a decimal.
A homogeneous data structure (elements have same data type) that stores a sequence of consecutively numbered objects--allocated in contiguous memory.
Table 1. Data type
#Process rules of special characters
The following rules are about how to process special characters enclosed in the message.
For byte data, such as the signature and the encrypted content, encode the data with the base64 algorithm before transmitting.
For URL data, perform URL encoding first before transmitting. For example: