خرید درون‌برنامه‌ای — ماهیت، انواع خرید و نحوه عملکرد درآمدزایی

In-App Purchase چیست؟

In-App Purchase (IAP) — فناوری است که امکان فروش کالاها و خدمات دیجیتال را درون برنامه موبایل فراهم می‌کند. پرداخت‌ها از طریق App Store (در iOS) یا Google Play (در Android) پردازش می‌شوند که برای انجام تراکنش کارمزد دریافت می‌کنند. توسعه‌دهنده پس از کسر کارمزد فروشگاه وجه را دریافت می‌کند.

Apple کارمزد 30% دریافت می‌کند (15% برای کسب‌وکارهای کوچک با درآمد تا 1 میلیون دلار). Google Play نیز 30% دریافت می‌کند (15% برای اولین 1 میلیون دلار درآمد توسعه‌دهنده). از سال 2024، Google برنامه User Choice Billing را آزمایش می‌کند که به توسعه‌دهندگان امکان استفاده از سیستم‌های پرداخت جایگزین را می‌دهد.

IAP برای فروش کالاهای دیجیتال در برنامه‌ها طبق سیاست‌های App Store و Google Play اجباری است. کالاهای فیزیکی، خدمات (سفارش تاکسی، تحویل غذا) و پرداخت‌های peer-to-peer می‌توانند از سیستم‌های پرداخت شخص ثالث استفاده کنند.

انواع 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) درباره تغییر وضعیت اشتراک ارائه می‌دهند: تمدید، انقضا، بازگشت وجه.

تنظیم IAP در App Store Connect و Google Play Console

تنظیم In-App Purchase در پنل‌های توسعه‌دهنده آغاز می‌شود: App Store Connect برای iOS و Google Play Console برای Android. برای هر محصول شناسه (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 استفاده می‌کند. برای خریدهای consumable در Android از پرچم جداگانه consume استفاده می‌شود که محصول را برای خرید مجدد بازنشانی می‌کند.

بررسی محصولات IAP به طور متوسط 24–48 ساعت در App Store و چند ساعت در Google Play طول می‌کشد. تغییرات قیمت بدون بررسی مجدد بلافاصله اعمال می‌شوند. Product ID پس از ایجاد قابل تغییر نیست — فقط می‌توان حذف و دوباره ایجاد کرد.

Server-side receipt validation و محافظت در برابر تقلب

Receipt validation (بررسی رسید) — مرحله اجباری پردازش In-App Purchase. برنامه مشتری رسید (receipt) را به سرور خود می‌فرستد، سرور آن را از طریق API Apple (https://buy.itunes.apple.com) یا Google (https://androidpublisher.googleapis.com) بررسی می‌کند و تنها پس از تأیید معتبر بودن، کالا را به کاربر تحویل می‌دهد.

بدون اعتبارسنجی سروری، مهاجم می‌تواند پاسخ فروشگاه را جعل کرده و کالا را رایگان دریافت کند. Client-side validation ناامن است زیرا در محیطی تحت کنترل کاربر اجرا می‌شود. بررسی سروری تضمین می‌کند که رسید معتبر است و پرداخت با موفقیت انجام شده است. برای Apple بررسی از طریق endpoint verifyReceipt (production یا sandbox) و برای 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 را برای محافظت در برابر حملات replay رد کند.

ادغام IAP در برنامه موبایل در Swift و Kotlin

ادغام In-App Purchase نیاز به اتصال کتابخانه‌های پلتفرمی دارد: StoreKit 2 در iOS و Billing Library 7+ در Android. API امکان دریافت لیست محصولات، شروع خرید، پردازش نتیجه و بازیابی کالاهای خریداری‌شده قبلی را فراهم می‌کند.

Swift — StoreKit 2 در iOS 17+

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 نیاز به استراتژی قیمت‌گذاری و UX اندیشیده‌شده دارد. کاربران بیشتر تمایل به اولین خرید دارند اگر بسته شروع جذاب (starter pack) با قیمت پایین به آنها پیشنهاد شود. Apple و Google توصیه می‌کنند قیمت محصول را قبل از تأیید خرید نشان دهید.

Subscription onboarding — مرحله بحرانی تبدیل است. قبل از درخواست پرداخت، ارزش اشتراک را به کاربر نشان دهید: دوره آزمایشی رایگان، مقایسه تعرفه‌ها، لیست مزایا. طبق تحقیقات، دوره آزمایشی رایگان (free trial) تبدیل کاربران پرداخت‌کننده را 25–40% افزایش می‌دهد.

Restore Purchases برای محصولات non-consumable و اشتراک‌ها اجباری است. دکمه بازیابی باید در تنظیمات برنامه یا صفحه پرداخت در دسترس باشد. Google و Apple ممکن است برنامه را رد کنند اگر بازیابی خریدها برای انواع IAP مربوطه پیاده‌سازی نشده باشد.

Grace Period — دوره مهلت برای اشتراک‌ها که در آن کاربر پس از عدم موفقیت پرداخت دسترسی خود را حفظ می‌کند. iOS و Android از grace period تا 30 روز پشتیبانی می‌کنند. فعال‌سازی grace period نرخ ریزش (churn rate) را 10–15% کاهش می‌دهد.

آزمایش A/B قیمت‌های IAP — روش مهم درآمدزایی. App Store Connect از قیمت‌های محلی (Price Tiers) با امکان تغییر قیمت بدون بررسی مجدد محصول پشتیبانی می‌کند. Google Play Console امکان تنظیم تا 5 طرح پایه با قیمت‌های مختلف برای یک محصول اشتراکی را فراهم می‌کند. توصیه می‌شود حداقل دو نقطه قیمت را آزمایش کنید: فعلی و جدید. آزمایش به مدت 2–4 هفته روی نمونه حداقل 1000 کاربر برای هر نقطه قیمت انجام می‌شود.

بررسی فروشگاه و مدیریت رد — مرحله اجباری انتشار برنامه با IAP. Apple به ویژه برنامه‌های با auto-renewable subscriptions را دقیق بررسی می‌کند: باید حساب آزمایشی با اشتراک فعال ارائه دهید، صفحه لغو اشتراک را نشان دهید و Restore Purchases را پیاده‌سازی کنید. Google Play سخت‌گیری کمتری دارد اما تأیید حقوق محتوای دیجیتال را می‌خواهد. توصیه می‌شود یادداشتی برای بازبین (Review Notes) با توضیح منطق IAP اضافه کنید.