SparkPay OpenAPI Docs
English
  • English
  • 简体中文
English
  • English
  • 简体中文
  1. Must-Read for Integration
  • Product Introduction
  • Quick Guide
    • Integration Preparation
    • Interface Signature Description
  • Must-Read for Integration
    • Interface Rules
    • Asynchronous Notification
    • Interface Error Codes
    • Network and Currency
  • Integration Scenarios
    • Payment
    • Close Order
  • API List
    • Payment Order Creation
      POST
    • Payment Order Query
      GET
    • Payment Order Closure
      POST
    • Payment Order Creation(Pro Edition)
      POST
    • Payment Order Query(Pro Edition)
      GET
  • Frequently Asked Questions
    • Notification Related Issues
    • Redirect Failure Issues
    • Interface Error Issues
    • Test Token Acquisition/Test Network Connection
  • Integration Example
    • Interface Signature Example - PHP
    • Interface Signature Example - Postman
  • Version Notes
    • Version Notes
  1. Must-Read for Integration

Interface Rules

Basic Rules#

1.
All API requests must use HTTPS.
2.
Please generate the request signature according to the Interface Rules. Be sure to generate the signature on the server side.
3.
Each time the caller initiates a request, the User-Agent HTTP request header must be used to identify itself. The payment platform will refuse to process requests without a User-Agent.

Data Format#

The payment platform API uses JSON as the data exchange format for the message body. Requests must set the HTTP headers:

Parameter Compatibility#

The success of the request does not depend on the order of request parameters.
The success of the request does not depend on the order of key-value pairs in the request JSON.
When handling responses, do not assume the order of key-value pairs in the response JSON.
New API versions may introduce new parameters or key-value pairs in the request or response.
New API versions will not remove required parameters or key-value pairs that already exist in requests and responses.
When the value of a JSON key-value pair in requests or responses is empty (null), it can be omitted.

Error Information#

The payment platform API uses HTTP status codes to indicate the result of request processing.
For successfully processed requests, if there is a response message body, it will return 200.
If request processing fails due to missing required parameters, insufficient balance during payment, etc., error codes within the 400 range will be returned.
If a server-side error occurs during request processing, a 500 status code will be returned. This situation is rare.

Error Codes and Messages#

When request processing fails, in addition to the HTTP status code indicating the error, the API will return a specific error message in the message body.
code: Interface Error Codes.
message: Error description, using easily understandable language to explain the reason for the error.

User Agent#

The HTTP protocol requires the client initiating requests to use the HTTP header User-Agent to identify itself in each request. The payment platform recommends that callers choose one of the following two methods:
1.
Use the default User-Agent of the HTTP client.
2.
Follow the HTTP protocol and use information such as the name and version of their system and application to create their unique User-Agent.
The payment platform API will refuse to process requests without a User-Agent.
Modified at 2024-10-12 07:01:03
Previous
Interface Signature Description
Next
Asynchronous Notification
Built with