Skip to main content
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.

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

1

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.
2

Subscription becomes active

After the first successful payment, the platform generates a subscriptionNo. All future recurring charges are tied to that subscription number.
3

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.
4

The subscription stops when an end condition is met

The subscription ends when the user cancels, the maximum cycle count is reached, or repeated failures hit the termination condition.

​
Key Status Interpretation

  • Save the relationship between subscriptionNo, merchant subscription ID, and user identity immediately after the first successful payment.
  • Do not rely only on the frontend result page. Subscription and recurring-charge status should be confirmed by server-side notifications and query APIs.
  • Always show the billing cycle, amount, cancellation method, and service agreement to the user.

​
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
If you rely only on whether the user opens a result page, you will miss the real recurring-charge outcome. Subscription renewals should always be confirmed by server-side callbacks and query APIs.

​
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

  1. Start with the Subscription Payment API to choose the right frontend integration mode.
  2. Then read Subscription Create and Subscription Query for field definitions and response structure.
  3. Finish with Subscription Cancel for cancellation handling. For refunds, use the unified Card Refund API.
Last modified on July 13, 2026