Sales models in China (and recommended architecture)

This page answers a common question:

“Can AppInChina provide payments and user/product management?”

AppInChina Payments is a payments layer (WeChat Pay + Alipay wrapper + transaction records). It does not replace your user system, product catalog, or entitlement/subscription management.

If you are unsure what is in scope, start with: Capabilities and Limitations (Scope).

Common sales models (alternatives to auto-renew subscriptions)

In Mainland China, many teams avoid “silent” auto-renew and instead ship models that are easier to explain and support.

Typical approaches include:

• One-time purchase (permanent unlock): user buys once, entitlement is permanent.
• Fixed-term access (manual renewal): sell “1 month / 3 months / 1 year access” as non-auto-renewing products.
  • The user buys again when the term expires.
  • Your backend extends the entitlement window on confirmed payment.
• Prepaid top-up / wallet: user buys credits, then consumes credits for features/content.
  • Your backend tracks credit balance and consumption.
• Bundles / feature packs: user purchases a pack that unlocks a group of features.
• Activation code / voucher: user redeems a code (sold via a partner channel) that grants entitlement.
  • Your backend validates and redeems the code, then grants entitlement.

Auto-renewing subscriptions can work, but they require extra care: explicit consent, clear renewal rules, cancellation/refund policy, and support handling. AppInChina Payments can record transactions, but subscription lifecycle policy and user support workflows remain on your side.

Responsibility split (who owns what)

Area	Your system (client app + backend)	AppInChina Payments
User accounts	Login, account recovery, identity linking, admin tools	Not provided
Product catalog	SKUs, pricing, eligibility, promotions	Not provided
Orders & entitlements	Internal order model; grant/revoke/extend access; term logic	Records transaction status and history
Payment initiation	Trigger payment flow from your app/backend	SDK/API to start WeChat Pay / Alipay
Payment confirmation	Verify final status server-side before fulfillment	Query authoritative transaction status
Refunds	Your business policy + customer support. Must provide a Purchase History UI so users can find their bizNo for refund requests.	Refund operations via Dashboard (filtered by bizNo).

For identity mapping, see: Login → Payments integration (customer identity).

Recommended implementation pattern

This pattern works for one-time purchases and fixed-term access.

1. User logs in (your login system, e.g. Authing / WeChat Login / custom) → your backend returns a stable internal userId.
2. App loads product catalog from your backend (often hosted in China for latency/compliance, depending on your architecture).
3. Create internal order in your backend:
   • Compute the final price (and any discount logic you own).
   • Create an internal order ID (bizNo) for idempotency and reconciliation.
4. Create payment via AppInChina Payments using the final amount and metadata:
   • Include customerIdentity = userId.
   • Optionally include attachData (your product ID, plan ID, etc.) for your own reconciliation.
5. User completes payment in WeChat Pay / Alipay.
6. Verify payment server-side by querying order status.
7. Fulfill in your backend:
   • One-time purchase: grant entitlement permanently.
   • Fixed-term access: extend expiresAt based on the product term (e.g. +30 days).
8. App refreshes entitlements from your backend and unlocks features.

Checking access when the app opens

When a user opens the app again, the app should ask your backend whether the logged-in user currently has access. The app should not query AppInChina Payments directly to decide whether a subscription or fixed-term entitlement is still valid.

Your backend should check its own entitlement state first, such as the user's active plan, expiresAt, fulfillment status, and any refund reconciliation you have already recorded. If the backend needs to verify a specific transaction, it can query AppInChina Payments by bizNo and customerIdentity.

If an order has been refunded, AppInChina will report the order with paymentStatus == REFUND. Your backend should then update or revoke the related entitlement according to your refund policy, and return the current access state to the app.

“Server in China” note (where to store what)

Many clients keep these in their China-region backend:

• User identity mapping (userId + external identities)
• Product catalog and pricing rules
• Entitlements (what the user has access to, and until when)
• Internal orders (bizNo, product/plan, fulfillment status)

AppInChina Payments stores transaction records and provides query endpoints for status/history, keyed by identifiers you provide (for example bizNo and customerIdentity).