תשלומים, מנויים וחיובים באפליקציות מובייל

תשלומים באפליקציות מובייל: רכישה בתוך האפליקציה, StoreKit 2, Google Billing, Stripe, RevenueCat

בכל פרויקט מונטיזציה, אנו מאזנים בין המדיניות של App Store ו-Google Play, דרישות PCI DSS, והלוגיקה של אימות רכישות בצד השרת. מערכת תשלומים מיושמת בצורה גרועה היא לא רק באג—היא מובילה להפסד כספי ולחסימה פוטנציאלית של האפליקציה. במשך יותר מ-7 שנים, ניתחנו יותר מ-50 אינטגרציות של SDK לתשלומים, החל מטפסי Stripe פשוטים ועד לחיוב מבוזר עם webhooks מותאמים אישית בצד השרת.

רכישה בתוך האפליקציה: שתי פלטפורמות, שני APIs שונים

אם האפליקציה שלך מוכרת תוכן דיגיטלי או מנויים, Apple ו-Google דורשות שתשתמש במערכות התשלום שלהן. זה לא נתון למשא ומתן: הפרה של חוק 3.1.1 של App Store או מדיניות המפתחים של Google Play גורמת להסרת האפליקציה. מוצרים פיזיים ושירותים לא מקוונים הם סיפור אחר.

StoreKit 2 (iOS 15+)

StoreKit 2 הוא שיפוץ מלא של ה-StoreKit המקורי עם API מבוסס async/await. Product.products(for:), product.purchase(), Transaction.currentEntitlements—קריא וצפוי יותר בהשוואה לתור העסקאות דרך SKPaymentTransactionObserver.

השינוי החשוב ביותר: עסקאות ב-StoreKit 2 חתומות עם JWS (JSON Web Signature) ומאומתות מקומית ללא צורך בתקשורת עם השרת. Transaction.verificationResult מחזיר .verified(Transaction) או .unverified(Transaction, VerificationError). זה לא אומר שאין צורך בשרת—עדיין יש צורך בו לאחסון סטטוס המנוי—אבל אימות מקומי מסיר את עיכוב ההפעלה.

StoreKit.AppTransaction מאמת את ההורדה בפועל של האפליקציה מ-App Store. נדרש להורדות בתשלום או רכישות שאינן מתחדשות.

חלק מסובך ב-StoreKit 2 הוא הטיפול ב-renewalState עבור מנויים: .subscribed, .expired, .inBillingRetryPeriod, .inGracePeriod, .revoked. מצב inGracePeriod אומר ש-Apple מנסה שוב את החיוב (עד 16 ימים)—עליך להמשיך לספק גישה במהלך תקופה זו. אי טיפול בכך עלול לאבד משתמשים נאמנים שהכרטיס שלהם נכשל זמנית. מניסיוננו, כ-5% מהמנויים נכנסים לניסיון חיוב חוזר, ושחזור גישה אוטומטי משחזר עד 80% מהם.

Google Play Billing Library (v6+)

Google Billing מורכב יותר מ-StoreKit מבחינת טיפול בתרחישים. BillingClient עם PurchasesUpdatedListener, queryProductDetailsAsync, launchBillingFlow, queryPurchasesAsync—יש לקרוא בכל הפעלת אפליקציה; אל תסתמך רק על PurchasesUpdatedListener כמקור האמת היחיד.

אישור רכישה: acknowledgePurchase() עבור מוצרים שאינם מתכלים ומנויים, consumePurchase() עבור מוצרים מתכלים. אם לא תקרא ל-acknowledge תוך שלושה ימים, Google מחזירה את התשלום אוטומטית. זהו אובדן הכנסה מובטח אם תשכח לאשר בצד השרת לאחר האימות.

ProductDetails עם SubscriptionOfferDetails—ב-Billing v5+, מבנה ההצעות הפך למורכב יותר: מוצר אחד יכול לכלול מספר basePlanId ו-offerId (תקופת ניסיון, הנחה למשתמשים חדשים, הצעות שימור). BillingFlowParams.SubscriptionUpdateParams עבור שדרוג/הורדה עם prorationMode.

למה אימות בצד השרת הוא חובה?

לעולם אל תסמוך רק על קוד בצד הלקוח בעת פתיחת תוכן בתשלום. אימות בצד הלקוח ניתן לעקיפה על ידי שינוי האפליקציה.

עבור IAP, הסכימה המינימלית היא: האפליקציה מקבלת receiptData (iOS) או purchaseToken (Android), שולחת אותו לשרת, השרת מאמת דרך Apple App Store Server API / Google Play Developer API, שומר את הסטטוס במסד הנתונים, ומשיב ללקוח. RevenueCat עושה זאת עבורך—אבל אם יש לך שרת מותאם אישית, עליך ליישם זאת בעצמך.

Webhooks חשובים יותר ממה שהם נראים. משתמשים עשויים לבטל מנויים דרך הגדרות הטלפון, לא דרך האפליקציה—האפליקציה לא תקבל את האירוע בזמן אמת. רק webhooks מ-Apple/Google (או RevenueCat) מאפשרים עדכוני סטטוס בזמן. אנו מאמתים בקשות נכנסות באמצעות signedPayload של Apple ו-DeveloperNotification של Google.

איך RevenueCat מפשטת את האינטגרציה?

תחזוקה של StoreKit 2 ו-Google Billing במקביל, עם קודי קידום, הצעות, שחזור רכישות ואימות בצד השרת, לוקחת חודשים של פיתוח. RevenueCat מטפלת ברוב השכבה הזו.

RevenueCat היא לא רק SDK לתשלומים. היא מציעה:

• API אחיד ל-iOS ו-Android (ו-Stripe לאינטרנט)
• אימות בצד השרת ואחסון סטטוס מנויים
• Webhooks לאירועים (רכישה, חידוש, ביטול, בעיית חיוב)
• אנליטיקה עבור קבוצות, MRR, נטישה
• בדיקות A/B של הצעות דרך Experiments

Purchases.configure(withAPIKey:) בעת ההפעלה, Purchases.shared.getCustomerInfo() לקבלת הרשאות נוכחיות—שכבת אינטגרציה מינימלית. Purchases.shared.purchase(package:) במקום קריאה ישירה ל-StoreKit/Billing.

התיעוד של RevenueCat מציין: «RevenueCat מטפלת באימות קבלות בצד השרת, מפחיתה את המורכבות בצד הלקוח ומונעת רכישות הונאה.»

מגבלות של RevenueCat: היא בתשלום (חינם עד $2.5k MRR, ולאחר מכן אחוז מההכנסות), לא מתאימה לזרימות מורכבות מאוד עם מספר חנויות או חבילות מותאמות אישית. עם זאת, עבור אפליקציית SaaS טיפוסית, החיסכון בפיתוח מותאם אישית מסתכם בעשרות אלפי דולרים—האינטגרציה מחזירה את עצמה תוך חודשיים.

Stripe באפליקציות מובייל

Stripe משמשת למוצרים פיזיים, שירותים ותשלומי B2B שבהם IAP אינו נדרש לפי מדיניות הפלטפורמה.

Stripe iOS SDK ו-Android SDK—PaymentSheet עבור ממשק תשלום מוכן, PaymentSheetFlowController עבור ממשק מותאם אישית עם כרטיסים שמורים. Payment Intents נוצרים בשרת; ה-client secret מועבר לאפליקציה—נתוני הכרטיס לעולם לא עוברים דרך השרת שלך, רק דרך Stripe.

Apple Pay ו-Google Pay דרך Stripe: PKPaymentRequest (iOS) ו-GooglePayLauncher (Android) כבר משולבים ב-SDK של Stripe. שיעורי ההמרה של Apple Pay גבוהים פי 1.3–2 מטפסי הזנת כרטיס ידניים—אלה נתונים שאישרנו בעשרות פרויקטים.

כרטיסים שמורים דרך SetupIntent + Customer API—משתמשים משלמים בנגיעה אחת בביקורים חוזרים. עמידה ב-PCI DSS SAQ A—הרמה הקלה ביותר, מכיוון ש-Stripe Tokenization מבטלת את הצורך באחסון נתוני כרטיס בצד שלך. לפי PCI DSS, העברת טוקנים פוטרת אותך מהסמכה ברמה 1.

3DS2 (Strong Customer Authentication) הוא חובה לתשלומים באיחוד האירופי לפי PSD2. Stripe מטפלת בזה אוטומטית דרך PaymentIntent.confirmPayment, אבל עליך לטפל נכון בסטטוס .requiresAction ולהחזיר את המשתמש למסך המתאים לאחר האימות.

מה כלול בעבודה (תוצרים)

תהליך ולוח זמנים

אנו מתחילים בבירור המודל העסקי: מנויים, רכישות חד-פעמיות, מוצרים מתכלים, freemium. הארכיטקטורה תלויה בכך. בדיקת IAP דורשת חשבונות Sandbox (Apple) ו-License Testers (Google)—זו הגדרה של סביבה נפרדת.

ה-Sandbox של Apple מתנהג אחרת מסביבת הייצור: מנויים מתחדשים כל 5 דקות במקום חודשי, inGracePeriod עובד אחרת. חיוני לבדוק תרחישים: פקיעת ניסיון, ביטול, ניסיון חיוב חוזר, החזר כספי.