In-App Purchase — ما هو، أنواع المشتريات وكيف يعمل تحقيق الدخل

ما هو In-App Purchase؟

In-App Purchase (IAP) هي تقنية تتيح بيع السلع والخدمات الرقمية داخل التطبيق المحمول. تتم معالجة المدفوعات عبر App Store (على iOS) أو Google Play (على Android)، والتي تفرض عمولة على معالجة المعاملة. يتلقى المطور الأموال مطروحًا منها عمولة المتجر.

تفرض Apple عمولة 30% (15% للشركات الصغيرة التي يقل دخلها عن مليون دولار). يفرض Google Play أيضًا 30% (15% على أول مليون دولار من دخل المطور). منذ عام 2024، تختبر Google برنامج User Choice Billing الذي يسمح للمطورين باستخدام أنظمة دفع بديلة.

IAP إلزامي لبيع السلع الرقمية في التطبيقات وفقًا لسياسات App Store و Google Play. يمكن للسلع المادية والخدمات (طلب السيارات، توصيل الطعام) والمدفوعات من نظير إلى نظير استخدام أنظمة دفع تابعة لجهات خارجية.

أنواع In-App Purchase: consumable و non-consumable والاشتراك

يدعم App Store و Google Play ثلاثة أنواع رئيسية من In-App Purchase. كل نوع مصمم لنماذج تحقيق دخل مختلفة. يؤثر اختيار نوع المنتج على منطق استعادة المشتريات وإدارة الاشتراكات والسلوك عند إعادة تثبيت التطبيق.

Consumable (المشتريات القابلة للاستهلاك)

المشتريات القابلة للاستهلاك هي عناصر يمكن شراؤها عدة مرات وتُستهلك أثناء الاستخدام. أمثلة نموذجية: عملات اللعبة (عملات، جواهر)، أرواح إضافية، معززات، أدوات تعزيز قابلة للاستهلاك. لا تُستعاد المشتريات القابلة للاستهلاك عند إعادة تثبيت التطبيق — يدير المطور رصيد كل مستخدم على خادمه الخاص.

Non-Consumable (المشتريات غير القابلة للاستهلاك)

المشتريات غير القابلة للاستهلاك هي عناصر تُشترى مرة واحدة وتبقى متاحة إلى الأبد. أمثلة: النسخة الكاملة من التطبيق، المستويات المتميزة، فتح الفلاتر، إزالة الإعلانات. يمكن استعادة المنتجات غير القابلة للاستهلاك عبر API Restore Purchases: بعد إعادة التثبيت، يمكن للمستخدم استرداد العناصر المشتراة سابقًا دون دفع مرة أخرى.

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، يتم تكوين المنتجات المدارة في قسم Monetise → Products → In-app products. يستخدم Google مصطلحات Managed Product (ما يعادل non-consumable) و Subscription. للمشتريات القابلة للاستهلاك على Android، يتم استخدام علامة consume منفصلة تعيد ضبط المنتج لإعادة الشراء.

تستغرق مراجعة منتجات IAP عادةً 24–48 ساعة في App Store وبضع ساعات في Google Play. يتم تطبيق تغييرات الأسعار فورًا دون إعادة مراجعة. لا يمكن تغيير معرف المنتج بعد الإنشاء — فقط حذفه وإنشاؤه من جديد.

التحقق من الإيصال من جانب الخادم والحماية من الاحتيال

التحقق من الإيصال هو خطوة إلزامية في معالجة In-App Purchase. يرسل تطبيق العميل إيصالًا إلى الخادم الخاص بك، ويتحقق الخادم منه عبر API Apple (https://buy.itunes.apple.com) أو API Google (https://androidpublisher.googleapis.com)، وفقط بعد التحقق الناجح يتم تسليم المنتج للمستخدم.

بدون التحقق من جانب الخادم، يمكن للمهاجم تزوير استجابة المتجر والحصول على المنتج مجانًا. التحقق من جانب العميل غير آمن لأنه يتم تنفيذه في بيئة يتحكم فيها المستخدم. يضمن التحقق من جانب الخادم أن الإيصال أصلي وأن الدفع تم بنجاح. بالنسبة لـ 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 لكل إيصال ورفض الطلبات المكررة بنفس المعرف للحماية من هجمات إعادة التشغيل.

دمج IAP في التطبيق المحمول باستخدام Swift و Kotlin

دمج In-App Purchase يتطلب توصيل مكتبات المنصة: StoreKit 2 على iOS و Billing Library 7+ على Android. تتيح واجهات برمجة التطبيقات طلب قائمة المنتجات، بدء عملية الشراء، معالجة النتيجة واستعادة المنتجات المشتراة سابقًا.

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)

التحقق من الإيصال من جانب الخادم (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-Appurchase استراتيجية تسعير وتجربة مستخدم مدروسة جيدًا. يميل المستخدمون أكثر إلى إجراء أول عملية شراء إذا عُرضت عليهم حزمة بداية جذابة بسعر منخفض. توصي Apple و Google بعرض سعر المنتج قبل خطوة تأكيد الشراء.

الإعداد للاشتراك هو مرحلة تحويل حاسمة. أظهر للمستخدم قيمة الاشتراك قبل طلب الدفع: فترة تجريبية مجانية، مقارنة الخطط، قائمة المزايا. وفقًا للبحث، تزيد الفترة التجريبية المجانية من التحويل إلى المستخدمين الدافعين بنسبة 25–40%.

استعادة المشتريات إلزامية للمنتجات غير القابلة للاستهلاك والاشتراكات. يجب أن يكون زر الاستعادة متاحًا في إعدادات التطبيق أو على شاشة الدفع. قد ترفض Google و Apple التطبيق إذا لم يتم تنفيذ استعادة المشتريات لأنواع IAP ذات الصلة.

فترة السماح (Grace Period) هي فترة تأجيل للاشتراكات يحتفظ خلالها المستخدم بالوصول بعد فشل الدفع. يدعم iOS و Android فترة سماح تصل إلى 30 يومًا. يؤدي تفعيل فترة السماح إلى تقليل معدل التوقف (churn rate) بنسبة 10–15%.

اختبار A/B لأسعار IAP هو ممارسة مهمة لتحقيق الدخل. يدعم App Store Connect التسعير المحلي (Price Tiers) مع إمكانية تغيير السعر دون إعادة مراجعة. يسمح Google Play Console بتكوين ما يصل إلى 5 خطط أساسية بأسعار مختلفة لمنتج اشتراك واحد. يُوصى باختبار نقطتي سعر على الأقل: الحالية والجديدة. يجب إجراء الاختبار على مدى 2–4 أسابيع على عينة من 1000 مستخدم على الأقل لكل نقطة سعر.

مراجعة المتجر وإدارة الرفض هي مرحلة إلزامية لنشر تطبيق مع IAP. تفحص Apple بدقة التطبيقات ذات الاشتراكات المتجددة تلقائيًا: يجب تقديم حساب اختبار مع اشتراك نشط، وإظهار شاشة إلغاء الاشتراك، وتنفيذ استعادة المشتريات. Google Play أقل صرامة ولكنه يطلب تأكيد حقوق المحتوى الرقمي. يُوصى بإضافة ملاحظة للمراجع (Review Notes) تصف منطق IAP.