---
title: Value-Added Service Solution - Overview
summary: Tuya provides value-added service monetization capabilities for apps. In the revenue-sharing model, Tuya collects user payments and shares revenue with developers. In the write-off model, developers purchase service quotas from Tuya, collect user payments through their own channels, and write off quotas during fulfillment. Open APIs require ticket-based integration, and a Ray-based consumer purchase and fulfillment template is available.
---

<h2 id="value-added-service-solution" class="nx-font-semibold nx-tracking-tight nx-text-slate-900 dark:nx-text-slate-100 nx-mt-10 nx-border-b nx-pb-1 nx-text-3xl nx-border-neutral-200/70 contrast-more:nx-border-neutral-400 dark:nx-border-primary-100/10 contrast-more:dark:nx-border-neutral-400">Value-Added Service Solution<span className="tag_h2">Monetization</span></h2>

This topic explains how to implement **sales and fulfillment** for **value-added services** in an app: who it is suitable for, what the platform provides, how the two common settlement models differ, and how to integrate templates and APIs.

### Applicable Scenarios

In miniapp scenarios, consider this solution if you need to:

- Offer **paid capabilities or content** such as subscriptions or unlocks, with a relatively complete purchase and fulfillment process.
- Complete **revenue sharing** or **write-off settlement** according to the model agreed with Tuya, without building the entire payment and reconciliation chain from scratch.

You can use the platform-provided value-added service solution to reduce self-development costs.

### What the Platform Provides

The platform covers the full loop of **service creation -> user purchase -> fulfillment (activation / usage)**. You mainly focus on product configuration, payment and settlement models, and open API integration.

### Two Settlement Models: Revenue Sharing and Write-Off

| Model | In short | Typical flow |
| --- | --- | --- |
| **Revenue sharing** | Users pay **Tuya as the payment collector**, and Tuya shares revenue with the service seller (you) according to the agreement. | Payment collection and revenue split rules follow Tuya-side processes and agreements. You focus on product configuration and fulfillment. |
| **Write-off** | The service seller (you) **purchases service quotas from Tuya**. Users pay through **your own payment channel**, and fulfillment is **written off against the quotas** with Tuya. | User-side payment goes through your channel. Settlement with Tuya is based on quotas, which must be purchased and written off according to commercial agreements. |

For both models, **product configuration, contract signing, and billing details** are subject to Tuya value-added service, commercial, and delivery documents. Align with your integration contact before launch.

### Developer Integration: Open APIs

The **open APIs** related to value-added services do not provide public self-service documentation. You must submit a **ticket** for evaluation and formal integration. Do not integrate production APIs based on assumptions before authorization.

- **Ticket entry**: [Tuya Service Desk](https://service.console.tuya.com/8/3/list?source=support_center)

### Consumer Miniapp Template

The template helps you quickly build **paywall / in-app purchase** pages. Capabilities include:

- Product and SKU display
- Apple / Google in-app purchase (IAP)
- Third-party payments such as PayPal, Stripe, Alipay, and WeChat Pay, depending on the capabilities actually enabled
- Built-in **mock** mode: When no backend is available or copy has not been delivered, you can simulate the purchase flow locally for development and demos

**Template entry**: [Service Purchase Template (ServicePurchase)](https://developer.tuya.com/material/library_hKiOVClc/component?code=ServicePurchase)

**UI examples**:

<Image style={{ margin: '20px 0', width: '300px' }} src="/images/solution/purchase/purchase-en-1.jpg" />
<Image style={{ margin: '20px 0', width: '300px' }} src="/images/solution/purchase/purchase-en-2.jpg" />

#### Before You Start

- You have registered a Tuya developer account, created a miniapp application, and obtained the **miniAppId**.
- You have enabled related capabilities such as **in-app purchase** on the platform.
- To debug real-device payments, you need to understand Apple IAP and Google Play listing and payment configurations. Store rules are subject to official requirements.

#### Required Changes Before Connecting to the Real Environment

In `src/constants/index.ts`:

| Constant | Description |
| --- | --- |
| `CATEGORY_CODE` | Product category code. The default value `"MOCK_CATEGORY_CODE"` means **mock** mode, which uses local fake data instead of real products. |
| `miniAppId` | Your miniapp ID |

Replace the `<HIGHWAY-PLACEHOLDER-*>` placeholders in `src/utils/fetch/api.ts` with the **real open API names** provided through the ticket or by your integration contact.

If you do not yet have a **CATEGORY_CODE** or **API authorization**, apply through **[Technical Support / Ticket](https://service.console.tuya.com/8/3/list?source=support_center)**.

#### Main Pages in the Template

| Path | Purpose |
| --- | --- |
| `/pages/home/index` | Entitlement or landing page that can navigate to the product page |
| `/pages/product-v1/index` | Product page style 1, focused on service information display |
| `/pages/product-v2/index` | Product page style 2, focused on SKU and purchase |
| `/pages/payment/index` | Payment WebView or mock payment page |

### Case

See the case page for details: [Top-Up Subscription](../case#4-top-up-subscription)