应用内购买 — 本质、购买类型及变现如何运作

什么是 In-App Purchase？

In-App Purchase（IAP） —— 是一种允许在移动应用内销售数字商品和服务的技术。支付通过 App Store（iOS 上）或 Google Play（Android 上）处理，它们会收取交易手续费。开发者在扣除商店佣金后收到款项。

Apple 收取 30% 的佣金（收入不超过 100 万美元的小型企业为 15%）。Google Play 也收取 30%（开发者收入的首个 100 万美元为 15%）。自 2024 年起，Google 正在测试 User Choice Billing 计划，允许开发者使用替代支付系统。

根据 App Store 和 Google Play 的政策，在应用中销售数字商品必须使用 IAP。实物商品、服务（叫出租车、送餐）和点对点支付可以使用第三方支付系统。

In-App Purchase 类型：consumable、non-consumable 和 subscription

App Store 和 Google Play 支持三种主要的 In-App Purchase 类型。每种类型适用于不同的变现模式。产品类型的选择会影响购买恢复逻辑、订阅管理以及重新安装应用时的行为。

Consumable（消耗品）

Consumable —— 是可以多次购买并在使用过程中消耗的商品。典型例子：游戏货币（金币、钻石）、额外生命值、加速器、消耗型增益道具。Consumable 在重新安装应用时不会恢复 —— 开发者在自己的服务器上自行管理每个用户的余额。

Non-Consumable（非消耗品）

Non-Consumable —— 是一次性购买并永久保留的商品。例子：应用的完整版本、高级关卡、解锁滤镜、去除广告。Non-consumable 产品通过 Restore Purchases API 恢复：重新安装后，用户可以找回之前购买的商品，无需再次付款。

Auto-Renewable Subscription（自动续订订阅）

Auto-Renewable Subscription —— 是为在特定期间（周、月、年）内访问内容或服务而进行的定期付款。订阅会自动续订，直到用户在账户设置中取消。商店会提供关于订阅状态变更的服务器通知（App Store Server Notifications、Google Play Developer Notifications）：续订、到期、退款。

在 App Store Connect 和 Google Play Console 中配置 IAP

配置 In-App Purchase 从开发者面板开始：iOS 使用 App Store Connect，Android 使用 Google Play Console。每个产品需要指定标识符（Product ID）、名称、描述、类型和以美元计的价格，并可自动转换为区域货币。创建后，产品需要通过商店审核。

在 App Store Connect 中，IAP 产品在 Features → In-App Purchases 部分创建。每个产品需要选择类型（consumable、non-consumable、auto-renewable subscription、non-renewing subscription）并填写本地化名称。对于订阅，还需要配置订阅组（Subscription Groups）—— 可互换的订阅组。

在 Google Play Console 中，受管产品（managed products）在 Monetise → Products → In-app products 部分配置。Google 使用术语 Managed Product（相当于 non-consumable）和 Subscription。在 Android 上，消耗品购买使用单独的 consume 标志，该标志会重置产品以便再次购买。

IAP 产品的审核平均需要 24–48 小时（App Store）和几小时（Google Play）。价格更改会立即生效，无需重新审核。Product ID 在创建后无法更改 —— 只能删除后重新创建。

Server-side receipt validation 和防欺诈保护

Receipt validation（收据验证）—— In-App Purchase 处理的强制步骤。客户端应用将收据（receipt）发送到自有服务器，服务器通过 Apple（https://buy.itunes.apple.com）或 Google（https://androidpublisher.googleapis.com）API 进行验证，只有在成功验证后才向用户发放商品。

如果没有服务器端验证，攻击者可以伪造商店的响应并免费获取商品。Client-side validation 不安全，因为它是在用户控制的环境中执行的。服务器端验证确保证收据是真实的且支付已成功完成。对于 Apple，验证通过 verifyReceipt 端点（生产或沙箱）进行；对于 Google，通过 Android Publisher API 进行。两个商店都以 JSON 格式返回确认信息。

Apple 在收据中返回购买数据：product_id、transaction_id、purchase_date、expiration_date（用于订阅）。Google 通过 API Purchases.products.get 或 Purchases.subscriptions.get 返回类似字段。服务器应存储每个收据的 transaction_id，并拒绝使用相同 ID 的重复请求，以防止重放攻击。

在 Swift 和 Kotlin 中向移动应用集成 IAP

集成 In-App Purchase 需要连接平台库：iOS 上的 StoreKit 2 和 Android 上的 Billing Library 7+。API 允许请求产品列表、发起购买、处理结果和恢复之前购买的商品。

Swift —— iOS 17+ 上的 StoreKit 2

import StoreKit

func purchaseProduct(productID: String) async throws {
    guard let product = try await Product.products(for: [productID]).first else { return }
    let result = try await product.purchase()
    switch result {
    case .success(let verification):
        let transaction = try verification.payloadValue
        await validateReceipt(transaction)
        await transaction.finish()
    default:
        break
    }
}

Kotlin —— Billing Library 7

import com.android.billingclient.api.BillingClient
import com.android.billingclient.api.BillingFlowParams

val billingClient = BillingClient.newBuilder(context)
    .setListener { billingResult, purchases ->
        if (billingResult.responseCode == BillingClient.BillingResponseCode.OK) {
            purchases?.forEach { purchase ->
                validateReceipt(purchase)
            }
        }
    }
    .build()

val params = BillingFlowParams.newBuilder()
    .setProductDetails(productDetails)
    .build()
billingClient.launchBillingFlow(activity, params)

Server-side receipt validation（Node.js）

const response = await fetch('https://buy.itunes.apple.com/verifyReceipt', {
    method: 'POST',
    body: JSON.stringify({
        'receipt-data': receiptBase64,
        'password': 'SHARED_SECRET'
    })
})

const data = await response.json()
if (data.status === 0) {
    // 收据已确认 — 发放商品
    await grantProduct(data.receipt.product_id)
}

通过 In-App Purchase 实现变现的最佳实践

变现 通过 In-App Purchase 需要深思熟虑的定价策略和用户体验。如果向用户提供低价有吸引力的新手包（starter pack），他们更倾向于进行首次购买。Apple 和 Google 建议在确认购买前显示产品价格。

订阅引导（Subscription onboarding） —— 转化的关键阶段。在请求付款之前向用户展示订阅的价值：免费试用期、套餐比较、优势列表。根据研究，免费试用期（free trial）可将付费用户的转化率提高 25–40%。

恢复购买（Restore Purchases） 对于 non-consumable 产品和订阅是必需的。恢复按钮应在应用设置或付款屏幕上可用。如果未针对相应的 IAP 类型实现购买恢复功能，Google 和 Apple 可能会拒绝该应用。

宽限期（Grace Period） —— 订阅的宽限期，在此期间用户在付款失败后仍保留访问权限。iOS 和 Android 支持最长 30 天的宽限期。启用宽限期可将流失率降低 10–15%。

IAP 价格的 A/B 测试 —— 重要的变现实践。App Store Connect 支持本地价格（Price Tiers），可在无需重新审核产品的情况下更改价格。Google Play Console 允许为单个订阅产品配置最多 5 个不同价格的基础方案。建议测试至少两个价格点：当前价格和新价格。测试应在每个价格点至少 1000 名用户的样本上进行 2–4 周。

商店审核与拒绝管理 —— 发布包含 IAP 的应用的强制步骤。Apple 特别仔细地检查具有自动续订订阅的应用：需要提供具有有效订阅的测试账户、显示取消订阅屏幕并实现恢复购买。Google Play 不那么严格，但要求确认数字内容的权利。建议添加包含 IAP 逻辑描述的审阅说明（Review Notes）。