This page helps you understand the full lifecycle of a HaiPay subscription. Read the summary first, then review each stage diagram, and finally move back to the Subscription Payment API and API Reference for implementation details.Documentation Index
Fetch the complete documentation index at: https://doc.haipay.net/llms.txt
Use this file to discover all available pages before exploring further.
Create Subscription
The user authorizes the subscription, completes the first payment, and a platform subscription number is created.
Recurring Charges
HaiPay charges automatically on schedule and sends the result to the merchant asynchronously.
Cancel and End
The subscription ends when the user cancels, the max cycle count is reached, or failure rules terminate it.
Flow Summary
User starts a subscription
The merchant calls the subscription-create API, HaiPay returns an authorization URL or frontend payment capability, and the user completes authorization plus the first charge.
Subscription becomes active
After the first successful payment, the platform generates a
subscriptionNo. All future recurring charges are tied to that subscription number.HaiPay charges on schedule
When the billing cycle arrives, HaiPay automatically initiates the recurring deduction and sends the result to the merchant through asynchronous notifications.
Key Status Interpretation
| Stage | What you should pay attention to |
|---|---|
| Subscription creation | Whether authorization can be launched and whether the user completes the first payment |
| Active subscription | Whether subscriptionNo is stored correctly in your system |
| Recurring charges | Whether every asynchronous deduction callback is received and processed correctly |
| Cancellation | Whether the user has a clear cancellation entry and the cancellation result is synced locally |
| Retry and failure | Whether your business has clear handling for failed charges, risk control, and service fallback |
Create Subscription
Goal: complete user authorization, charge the first payment, and establish the subscription relationship. Implementation focus for this stage- Store the mapping between merchant subscription ID and platform subscription number
- Do not trust the frontend result page alone; confirm the result through callbacks or query APIs
- Make sure the user can clearly understand the amount, cycle, and cancellation method
Recurring Charges
Goal: renew the subscription automatically while it remains active. Implementation focus for this stage- Your server must handle the callback and return uppercase
SUCCESS - It is strongly recommended to notify users outside the platform before and after each charge
- If a charge fails, define a clear retry, downgrade, or service-suspension policy
Cancel Subscription
Goal: stop future recurring charges when the user cancels or the business ends the subscription. Implementation focus for this stage- The user-facing product must include a clear and accessible cancellation entry
- Update your local subscription state immediately after cancellation succeeds
- If charges are still pending around cancellation time, define the entitlement boundary clearly in your business logic
Full Lifecycle Diagram
Recommended Reading Order
- Start with the Subscription Payment API to choose the right frontend integration mode.
- Then read Subscription Create and Subscription Query for field definitions and response structure.
- Finish with Subscription Cancel for cancellation handling. For refunds, use the unified Card Refund API.

