How Alipay Handles Subscription Payments in China

A florist pays ¥99 for a month of an AI image tool. She uses it to replace backgrounds, try different wrapping paper, and make posters for the shop. On September 20, she turns off automatic renewal. There are still posters to download, and she has paid for access until October 1.

If the application stores membership in a single is_vip field, its developer has a problem. Setting the field to false cuts off service she has paid for. Leaving it true says nothing about her request to stop the next payment. The application needs to remember both the end of the paid period and the cancellation of renewal.

中文版

For a product serving customers in mainland China, Alipay and WeChat Pay belong in the payment discussion. Both appear as common mobile payment options in the People’s Bank of China’s payment guide for visitors to China. A customer may expect to pay with a wallet already on her phone, even if the software company has built its existing checkout around cards.

Alipay’s Token Pay subscription offering, aimed at AI businesses, provides products, prices, subscription records, renewals, and plan changes. It is an interesting case to study alongside Stripe Billing: the two expose some familiar objects, but organize the path from a plan change to a payment differently.

The image tool in this article is fictional. Its Basic plan costs ¥99 a month or ¥990 a year; Pro costs ¥199 a month. All amounts are in Chinese yuan (CNY), and the dates and allowances are examples.

Who can use Alipay Token Pay?

Start with the Token Pay product page and confirm eligibility before building against the APIs. The published requirements call for an Alipay business account, an eligible business category, and approval. A personal Alipay account does not meet those requirements. An independent developer applying through a business still needs to satisfy the account and category checks.

For an overseas team, this check comes before the architecture diagram. An existing way to accept Alipay payments, including through another payment provider, does not establish eligibility for this subscription product. Confirm which entity and application can be approved; an English description of the API is not evidence of worldwide availability.

Once approved, the merchant configures the application, signing keys, and any required authorization to call APIs on its behalf. The integration then follows the purchase: define products and prices, associate a customer with an application account, create the subscription, and send the customer to Alipay to authorize and pay. Subsequent notifications drive renewals and changes in the application.

Alipay also provides low-code product pages and a customer portal. Those can reduce checkout work. The image tool still has to count generated images and decide which account may use them.

Products, prices, and the customer’s subscription

The florist sees two ways to buy Basic: ¥99 each month or ¥990 for a year. The features are the same. Pro is a different plan, with a larger image allowance.

Alipay’s Product describes what is sold. Price supplies the amount and recurring interval. Basic can have one Product and two Prices, so adding an annual option does not require copying the product description.

When the customer chooses a price, the merchant creates a Subscription. Its customer_id identifies the customer; each entry in items selects a price_id. A thousand customers can choose the same monthly Price while retaining separate subscriptions and renewal dates.

The diagram shows selected public API fields and their relationships. The yellow box is an application record proposed for this example.

The merchant keeps a mapping between its own user ID and Alipay’s customer_id. Alipay records that the customer has subscribed to Basic. The image service records that she has generated 86 images. Linking the accounts lets a purchase unlock the right allowance.

Writing “300 images per month” in a product description does not implement that allowance. The application must grant it and subtract usage. Annual payment adds another date to manage: money arrives once a year, but the customer expects a new allowance each month. Waiting for the next payment notification would leave her with no new images for eleven months.

Creating a subscription and collecting the first payment

For a monthly Basic subscription, the business parameters can look like this. Signing parameters are omitted, and the IDs are placeholders:

{
  "customer_id": "CUSTOMER_ID",
  "items": [{ "price_id": "BASIC_MONTHLY_PRICE_ID" }],
  "deduct_type": "SUBSCRIBE_DEDUCT"
}

The endpoint is alipay.trade.subscription.create. The response includes subscription_id, order_no, and links for opening Alipay or presenting a QR code. The customer then authorizes the arrangement and completes the first payment in Alipay. A successful create response can arrive before she has picked up her phone.

Three identifiers matter here. subscription_id tracks the subscription. order_no tracks a payment request generated during creation or an upgrade. trade_no identifies an Alipay transaction and can be used to query payment details. A subscription may accumulate an initial payment, renewals, and upgrade payments; one database column called “order ID” will not describe all of them.

Alipay reports changes through alipay.trade.subscription.changed. The notification’s change_type describes the event: active for initial activation, period_extend for a successful renewal, or item_update for a successful upgrade. The subscription’s subscription_status describes its current state, using values such as ACTIVE.

On renewal, the state can remain ACTIVE while the period end moves forward. Code that grants an allowance only when the state changes from inactive to active will miss the second month.

Who initiates automatic renewal?

SUBSCRIBE_DEDUCT selects the default managed collection mode. Alipay arranges subsequent charges from the subscription record. MERCHANT_DEDUCT leaves initiation with the merchant. The recurring payment responsibilities therefore depend on the mode selected, even within the same subscription product.

In managed mode, the image tool receives renewal results and updates access and allowances. It does not submit a new collection request for every customer each month.

The public guide describes advance payment notices, collection attempts before expiry, and retries. If payment has still not succeeded by expiry, the default flow stops collection and terminates the agreement. The application needs to check the resulting subscription state and service period before changing access.

It might allow a few extra days to download finished posters. Alipay’s collection retries do not implement that file-access policy; the image service does.

Upgrades, cancellation, and refunds

Before a holiday, the florist needs more images and switches to Pro halfway through her billing period. Suppose the business allows credit for unused time and keeps the original renewal date. Half of Basic’s ¥99 fee is ¥49.50; half of Pro’s ¥199 fee is ¥99.50. The upgrade costs ¥50 now, followed by ¥199 at the next renewal.

Alipay handles this through subscription modification: modify_type=UPGRADE selects the operation, and preserve_billing_cycle=true keeps the cycle. Without pay_amount, the platform calculates the charge under its rules. The merchant can also supply a custom amount in fen, or hundredths of a yuan: ¥50 is 5,000 fen. The flow returns a payment confirmation entry, and the merchant receives the upgrade result after payment.

The half-period example makes the arithmetic easy to follow; actual proration depends on the applicable timing rules. There is also a business question the formula cannot answer. If the florist has used all 300 images, should she receive half her fee back as upgrade credit? The service may already have incurred most of its generation cost. Time-based credit needs to fit the product’s economics.

To stop renewal at the end of a paid period, the merchant can use modify_type=CANCEL with cancel_at_period_end=true. Canceling the next renewal and refunding the current payment are separate operations to consider. An immediate cancellation with a refund needs the corresponding modification parameters and refund rules.

For the September cancellation at the start of the article, the application keeps access until current_period_end. The florist can download her posters until October 1. Nothing in her request to stop buying another month requires the service to take away the month she has paid for.

Alipay and Stripe: how the subscription models differ

Readers of the Stripe article will recognize Product, Price, and Subscription. Both platforms can handle recurring purchases, upgrades, and cancellation. The comparison becomes more useful when we follow a charge through the APIs.

Stripe places Subscriptions in Billing. A subscription generates an Invoice for a billing period; invoice lines describe the charges before collection proceeds. A monthly fee, prorated upgrade, or additional one-time charge can be represented on a bill. See Stripe’s subscription invoices and invoice items.

The Token Pay integration examined here is organized around subscription operations. Creating or upgrading a subscription produces a payment request and a confirmation entry. A subscription-change notification reports the outcome. The merchant links the subscription, request, and transaction through their identifiers.

Alipay’s order_no should not be treated as the equivalent of Stripe’s Invoice. One identifies a payment request; the other records amounts owed, with line items and invoice states. The diagram summarizes public product and API responsibilities, rather than a platform’s deployment architecture.

Consider the same ¥50 upgrade in Stripe. Credit for the remaining Basic period and the cost of Pro become proration items. Configuration controls when they are invoiced and collected. For an automatically collected subscription, proration_behavior=always_invoice creates an invoice for the adjustment and attempts payment. See prorations and updating subscriptions.

Updating a plan does not always prove that its upgrade payment succeeded. Where supported, payment_behavior=pending_if_incomplete makes the change wait for payment of the new invoice. If authentication is required, the integration must handle that customer action too. Stripe documents the conditions under pending updates.

Token Pay’s documented upgrade flow gives the merchant a different sequence: submit UPGRADE, obtain the calculated or specified payment amount and confirmation entry, then apply the reported result after the customer pays.

For this fixed-price image tool, those operations map to purchase, upgrade, and cancellation controls. A business that needs to collect several kinds of charges on one bill, then manage its payment terms, has a reason to examine Stripe’s Invoice model. That model also brings more invoice states and collection settings to understand. The useful test is whether a design accommodates the business’s charging rules without requiring too much parallel bookkeeping.

Alipay and WeChat Pay: what managed subscriptions take over

WeChat Pay’s general entrusted-debit product supports automatic renewal. “Entrusted debit” refers here to collection under a customer’s payment authorization. Merchants need the relevant product permission and agreement template; ordinary payment acceptance is not enough.

In the general automatic-renewal integration, the merchant submits each period’s collection request with an agreement identifier, order number, and amount. Under the mode that collects 24 hours after notification, WeChat sends the notice, waits, and executes that charge. This describes subsequent renewals; the first payment after authorization has separate rules.

Another mode separates the advance notice from the collection request. The merchant submits the expected amount, waits, then requests payment within the permitted window. Amounts, timing, and retries are constrained. This is not permission to charge any amount at any time.

Alipay’s default managed mode takes over the arrangement of subsequent periodic charges. The following comparison uses WeChat’s notification-then-24-hour-collection mode:

WeChat also has other routes, including scheduled collection and insurance-specific debit, with their own requirements. The comparison here concerns its general entrusted-debit automatic-renewal flow, not every recurring-payment product in its catalog.

With a thousand subscribers, the image tool will have monthly customers, annual customers, recent upgrades, and pending cancellations. A merchant using general entrusted debit must work out who owes what this period and submit the requests. A managed subscription service can maintain the selected plans and periods, arrange renewals, and report the changes. The image tool still owns its credit ledger and its policy for failed image generation.

A merchant with an established billing system may prefer to keep those calculations. Adding a second product catalog creates synchronization work, particularly when several payment channels feed the same application. In that situation, a collection product can be a reasonable fit. Alipay’s MERCHANT_DEDUCT mode also lets the merchant retain collection initiation; the managed-mode benefits above should not be assumed for every integration.

Handling notifications without granting credits twice

Suppose Alipay collects ¥99 and the image tool grants 300 credits. The network fails before Alipay receives the handler’s acknowledgment. The notification is retried. A handler that adds 300 credits again has now delivered 600 credits for one payment.

The public notification protocol includes notify_id, signature verification, and a success acknowledgment. One merchant-side design is to verify the signature and application ownership, persist the notification, and acknowledge receipt. Processing then needs both notification deduplication and a business rule preventing the same purchase from granting its allowance twice. A confirmed transaction identifier can form part of that rule; the exact key depends on how purchases and allowances are recorded.

I would keep a current subscription snapshot separate from the credit ledger. The snapshot records the plan, status, service period, and cancellation arrangement. The ledger records grants and usage. Subscription queries can help reconcile notifications with current platform state. When a customer reports a payment without usable credits, support can trace the transaction, subscription, and grant instead of guessing from a membership flag.

The florist does not need any of these identifiers. She needs her payment to unlock images, her upgrade credit to follow the advertised terms, and her posters to remain available for the month she paid for. Those are the behaviors the integration has to deliver.

This article uses public official documentation, with selected fields and simplified examples. Eligibility was rechecked for this English edition on September 23, 2026; implementation requirements can change. The main Chinese-language references are Alipay’s individual subscription integration guide and WeChat Pay’s entrusted-debit integration guide.

Back to the subscription series