הטמעת Google Play Billing (רכישות חד-פעמיות) עבור Android
תארו לעצמכם: האפליקציה שלכם כבר בחנות, אבל הבנייה נדחית בגלל גרסת BillingClient מיושנת. או גרוע מכך — רכישות עוברות, אבל Google מחזירה את הכסף שלושה ימים לאחר מכן כי המפתח שכח לקרוא ל-acknowledgePurchase(). מקרים כאלה אינם נדירים. בפרקטיקה שלנו, היה לנו לקוח שאיבד עד 30% מההכנסות בגלל טיפול לא נכון בעסקאות ממתינות. לאחר מעבר ל-Billing Library 6 והטמעת אימות בצד השרת, ההכנסות שלהם גדלו ב-15%. אנו עוזרים להימנע מטעויות אלו ומבטיחים אישור מודרציה בפעם הראשונה. במאמר זה תלמדו כיצד לשלב כראוי רכישות חד-פעמיות תוך הימנעות ממלכודות טיפוסיות.
התיעוד הרשמי של Google מדגיש: אישור (acknowledgement) הוא חובה עבור כל הרכישות. Billing Library 6 הפך לחובה עבור אפליקציות חדשות. ה-API האסינכרוני שלו דורש שכתוב של קוד קיים. ה-queryPurchases הסינכרוני מוחלף ב-queryPurchasesAsync, נוסף PendingPurchasesParams עבור עסקאות נדחות, ו-acknowledge נדרש כעת. ללא קריאה אליו בתוך 72 שעות, Google מבטל אוטומטית את הרכישה. בואו נצלול להיבטים המרכזיים של האינטגרציה.
מוצרים חד-פעמיים: INAPP לעומת DURABLE
ב-Play Billing 6+, רכישות חד-פעמיות מחולקות לשני תת-סוגים:
- INAPP (סוג legacy) — מוצרים מתכלים ולא-מתכלים בסל אחד.
- DURABLE — במפורש לא-מתכלה, סוג חדש מאז BillingClient 6.
בפועל, עבור "הסרת פרסומות" ו"פתיחת רמות" אנו משתמשים ב-ProductType.INAPP עם סטטוס מאושר כסמן בעלות. DURABLE נוח כאשר צריך להפריד בקפדנות בין סוגי מוצרים באנליטיקה.
| קריטריון | INAPP | DURABLE |
|---|---|---|
| סוג מוצר | כל סוג (מתכלה/לא-מתכלה) | רק לא-מתכלה |
| היסטוריה | לפני Billing 6 | הוצג ב-Billing 6 |
| אישור (Acknowledgement) | חובה | חובה |
| המלצה | אוניברסלי | להפרדה ברורה |
למה אישור (acknowledgement) הוא קריטי?
כל רכישה חייבת להיות מאושרת תוך 3 ימים באמצעות acknowledgePurchase() או consumePurchase() (עבור מוצרים מתכלים). אם לא מאושרת, Google מחזירה אוטומטית את הכסף ומבטלת את הרכישה. זה לא ברור מהתיעוד אבל נבדק בקפדנות במהלך המודרציה. אובדן הכנסות יכול להגיע עד $1,600 בשנה עם 1,000 משתמשים משלמים.
דוגמת קוד לאישור רכישה
val billingClient = BillingClient.newBuilder(context)
.setListener { billingResult, purchases ->
purchases?.forEach { purchase ->
if (purchase.purchaseState == Purchase.PurchaseState.PURCHASED) {
if (!purchase.isAcknowledged) {
val params = AcknowledgePurchaseParams.newBuilder()
.setPurchaseToken(purchase.purchaseToken)
.build()
billingClient.acknowledgePurchase(params) { result ->
if (result.responseCode == BillingClient.BillingResponseCode.OK) {
unlockFeature(purchase.products.first())
}
}
}
}
}
}
.enablePendingPurchases(
PendingPurchasesParams.newBuilder()
.enableOneTimeProducts()
.build()
)
.build()val billingClient = BillingClient.newBuilder(context) .setListener { billingResult, purchases -> purchases?.forEach { purchase -> if (purchase.purchaseState == Purchase.PurchaseState.PURCHASED) { if (!purchase.isAcknowledged) { val params = AcknowledgePurchaseParams.newBuilder() .setPurchaseToken(purchase.purchaseToken) .build() billingClient.acknowledgePurchase(params) { result -> if (result.responseCode == BillingClient.BillingResponseCode.OK) { unlockFeature(purchase.products.first()) } } } } } } .enablePendingPurchases( PendingPurchasesParams.newBuilder() .enableOneTimeProducts() .build() ) .build() הוא כעת חובה. בלעדיו, enablePendingPurchases() זורק חריגה. רכישות ממתינות (תשלומים במזומן דרך שותפי Google Pay באזורים מסוימים) לא עוברות ל-PURCHASED מיד — צריך להאזין לעדכונים דרך BillingClient.startConnection().
איך לשחזר רכישות לאחר התקנה מחדש?
בהתקנה מחדש של האפליקציה, רכישות משוחזרות דרך PurchasesUpdatedListener. קראו בכל הפעלה:
val params = QueryPurchasesParams.newBuilder()
.setProductType(BillingClient.ProductType.INAPP)
.build()
billingClient.queryPurchasesAsync(params) { billingResult, purchaseList ->
purchaseList.filter { it.purchaseState == Purchase.PurchaseState.PURCHASED && it.isAcknowledged }
.forEach { restoreAccess(it) }
}איך לבחור בין אימות בצד הלקוח לאימות בצד השרת?
| קריטריון | רק בצד הלקוח | אימות בצד השרת |
|---|---|---|
| אמינות | נמוכה (ניתן לזייף) | גבוהה (Google Play Developer API) |
| שחזור בין מכשירים | לא | כן |
| הגנה מפני הונאה | לא | כן |
| מורכבות | מינימלית | בינונית (נדרש back-end) |
אימות בצד השרת אמין פי 2 מאשר בצד הלקוח ומונע דליפת הכנסות: עם 1,000 משתמשים משלמים, הוא חוסך עד 15% מההכנסות. אנו תמיד מיישמים את חלק השרת — אנו מקימים אינטגרציה עם Google Play Developer API תוך יום אחד.
תהליך: מבדיקה ועד שחרור
- בדיקת קוד נוכחי — איתור קריאות מיושנות, שגיאות בטיפול במצבים.
- עיצוב — בחירת INAPP או DURABLE, עיצוב תהליך הרכישה.
- אינטגרציה — חיבור Billing Library 6, הטמעת אישור, רכישות ממתינות, שחזור.
- אימות בצד השרת — הקמת endpoint, פריסת אימות טוקנים.
- בדיקות — דרך License Testing ב-Play Console, בדיקת כל המצבים.
- שחרור — פרסום עדכון, הבטחת אישור מודרציה.
מה כלול
- קוד מקור של האינטגרציה (Kotlin/Java עם הערות)
- נקודת קצה API לאימות בצד השרת (Node.js/Python/PHP)
- תיעוד על תהליך הרכישה והבדיקות
- עזרה בהקמת חשבונות בדיקה
- תמיכה במהלך השחרור (שבועיים)
טעויות אינטגרציה טיפוסיות
מפתחים לעתים קרובות מדלגים על acknowledgePurchase — ואז הכסף מוחזר לאחר 3 ימים. חוסר ב-enablePendingPurchases גורם לקריסה בחיבור. אי-שחזור רכישות בהתקנה מחדש גורם למשתמשים לאבד גישה. אימות רק בצד הלקוח ללא שרת מאפשר זיוף. כל אחת מהטעויות הללו יכולה לעלות לעסק עד $2,000 בניפוי באגים ואובדן נאמנות.
אנו מבטיחים שאף אחת מהשגיאות הללו לא תגיע לייצור. לצוות שלנו יש ניסיון של 5+ שנים במונטיזציה של אפליקציות מובייל. פיתחנו מערכת אימות מאובטחת שמקצרת את זמן האינטגרציה ב-30% בהשוואה לפיתוח פנימי. מומחים מוסמכים (Google Play Console Administrator) מאשרים את המומחיות שלנו.
לוחות הזמנים לאינטגרציה הם 2–3 ימי עבודה עבור חלק הלקוח, +יום אחד עבור אימות בצד השרת. העלות מחושבת באופן אישי. אם אתם צריכים ליישם רכישות חד-פעמיות באפליקציה שלכם, בקשו ייעוץ. נעריך את הפרויקט שלכם תוך יום אחד ונציע פתרון אופטימלי. צרו קשר כדי לדון בפרטים.