OpenTest 项目：API 接口补齐与全业务逻辑规范

API Interface Completion and Business Logic Specification

Document Generation Date: 2026.01.16 | WordPress Billing and Backend Interfacing Specialized

1. ⚠️ Back-end API to-be-finished list

The following content for the current API documentation is missing, need to be developed with the complementary:

Interface 1 Add Signature Verification: Increase sign Fields. Since WordPress initiates asset release notifications, security must be verified by an MD5 signature.
Interface 1 Add original order association: In response to UPGRADE type, you must pass originalOrderNoThe back-end needs to locate the old assets and perform SKU updates accordingly. The backend needs to locate the old assets and perform SKU updates accordingly.
Interface 4 Add Device Name Return: need to return machineName. Otherwise, users cannot recognize different computers for unbundling operations in the Personal Center.
Interface 4 Increase in offline residuals: need to return remainingOfflineUnbindCountFor restricting offline authorizations to 3 unbundles per year. Used to limit offline licenses to 3 unbundles per year.

2. UPGRADE core compliance rules

Personal version of asset handling: In order to ensure the consistency of the authorization code, the personal version of the upgrade take "Override update" Logic.
1. After successful payment, WP sends a request containing orderType: UPGRADE up to originalOrderNoThe
2. The back-end locates the authorization code associated with the original order and updates only its skuCode fields.No new code is generatedThe
3. An upgrade is only a change of authority; the period of validity remains, in principle, unchanged.

3. Upgrade billing conversion formula (WP implementation)

Upgrades are only supported one way up. the WordPress plugin calculates the spread order amount according to the following formula:

Replacement Amount = New Package Price - ( Original Package Paid Price / Original Package Total Days * Remaining Available Days )

4. Summary of logical categories for authorization code generation

Business Dimension	Buying Scenarios	Description of back-end fulfillment actions
Personal Edition Package	New Purchase (NEW)	Generate a new authorization code and bind it automatically.
	Renewal (RENEW)	Does not generate a new code, updates the expiration time (EndTime) of the original code.
	UPGRADE	No new code is generated and the SKU code of the original code is updated.
Team Edition Package	All Scenes	A new authorization code is generated independently for each seat.
option kit	New Purchase/Team Purchase	Generate a corresponding number of new option pack authorization codes.

5. Authorization code binding/unbinding rules (Interface 3)

statelessness: Direct Execution BIND Operation.
Existing Package Status: The system needs to be bootstrapped andCall UNBIND first to unbind the old license code.If you do not want to use this code, you can use the new code BIND again.
Optional Package Status: Direct execution is permitted BIND, realizing the stacking of optional benefits.

Start your cross-border journeyContact us now

Website development customer service

Customer Service

Designer (making Figma prototypes)