Reminder: By Aug 31, 2025, all new apps and updates to existing apps must use Billing Library version 7 or newer. If you need more time to update your app, you can request an extension until Nov 1, 2025. Learn about Play Billing Library version deprecation.
تنظيم صفحاتك في مجموعات
يمكنك حفظ المحتوى وتصنيفه حسب إعداداتك المفضّلة.
مع ازدياد شعبية تطبيقك، قد يجذب أيضًا انتباه المستخدمين الضارين الذين قد يرغبون في إساءة استخدامه. يقدّم هذا الموضوع اقتراحات يمكنك اتّباعها للمساعدة في منع هذه الهجمات على عملية تكامل الفوترة وتقليل تأثير إساءة الاستخدام في تطبيقك.
نقل المنطق الحسّاس إلى الخلفية
بقدر ما يسمح به تصميم تطبيقك، يمكنك نقل البيانات الحساسة والمنطق إلى خادم خلفي تتحكّم فيه. كلما زادت البيانات والمنطق في جهاز الواجهة الأمامية، زادت احتمالية تعديله أو التلاعب به.
على سبيل المثال، يجب أن تتحقّق لعبة الشطرنج على الإنترنت من صحة جميع الحركات في الخلفية بدلاً من الوثوق بأنّ الواجهة الأمامية ترسل دائمًا حركات قانونية.
بالإضافة إلى ذلك، إذا رصدت ثغرات أو مشاكل أمنية، قد يكون من الأسهل تصحيح الأخطاء وإصلاحها وطرح التحديثات في الخلفية بدلاً من الواجهة الأمامية، وذلك حسب تصميم نظامك.
إثبات ملكية عمليات الشراء قبل منح الأذونات
من الحالات الخاصة للبيانات الحسّاسة والمنطق الذي يجب التعامل معه في الخلفية
هي عملية إثبات ملكية عمليات الشراء وتأكيدها. بعد أن يجري المستخدم عملية شراء، عليك اتّباع الخطوات التالية:
أرسِل purchaseToken المقابل إلى الخلفية. وهذا يعني أنّه عليك الاحتفاظ بسجلّ لجميع قيم purchaseToken لجميع عمليات الشراء.
تأكَّد من أنّ قيمة purchaseToken لعملية الشراء الحالية لا تتطابق مع أي قيم purchaseToken سابقة. purchaseToken فريد على مستوى العالم، لذا يمكنك استخدام هذه القيمة بأمان كمفتاح أساسي في قاعدة البيانات.
إذا كانت عملية الشراء قانونية ولم يتم استخدامها في الماضي، يمكنك بعد ذلك منح إذن الوصول إلى المنتج أو الاشتراك داخل التطبيق بأمان.
بالنسبة إلى الاشتراكات، عند ضبط
linkedPurchaseToken
في Purchases.subscriptionsv2:get، عليك أيضًا إزالة
linkedPurchaseToken من قاعدة البيانات وإلغاء الإذن الممنوح
لـ linkedPurchaseToken لضمان عدم حصول عدة مستخدمين على الإذن
نفسه مقابل عملية الشراء نفسها.
يجب منح إذن الوصول فقط عندما تكون حالة الشراء PURCHASED،
ويجب التأكّد من التعامل مع عمليات الشراء التي تحمل الحالة PENDING بشكل صحيح. في حال حدوث ارتفاع كبير في عدد عمليات شراء CANCELED، قد تمنح المستخدمين أذونات الوصول عندما تكون عملية الشراء لا تزال في الحالة PENDING. يمكنك الاطّلاع على مزيد من المعلومات في مقالة التعامل مع المعاملات المعلّقة.
بعد منح إذن الوصول، إذا أردت استهلاك منتج قابل للاستهلاك والإقرار بذلك، استخدِم واجهة Purchases.products:consume
Play Developer API على خادم الخلفية الآمن.
للإقرار باستلام منتج غير قابل للاستهلاك أو اشتراك، اتّصِل بنقطة النهاية ذات الصلة في Play Developer API، إما Purchases.products:acknowledge أو Purchases.subscriptions:acknowledge، على خادم الخلفية الآمن.
ويجب تقديم إقرار لأنّه يُعلم Google Play بأنّه تم منح المستخدم إذن الوصول إلى المنتج الذي اشتراه. يجب الإقرار بإتمام عملية الشراء فور منح الإذن.
يُرجى العِلم أنّه على الرغم من إمكانية إقرار عملية الشراء أو استهلاكها من جهة العميل من خلال تطبيقك، فإنّ واجهات برمجة التطبيقات من جهة الخادم توفّر حماية إضافية من المشاكل، مثل ضعف الاتصال بالشبكة والنشاط الضار. على سبيل المثال، لنفترض أنّ أحد المستخدمين اشترى منتجًا من تطبيقك، ولكن انقطع اتصاله بالشبكة أثناء التحقّق من صحة عملية الشراء. بدون إقرار من الخادم، قد يحتاجون إلى تسجيل الدخول مرة أخرى من خلال التطبيق لإكمال عملية الإقرار. في حال عدم تسجيل الدخول مجددًا خلال ثلاثة أيام، سيتم ردّ الأموال تلقائيًا بسبب عدم الإقرار بإتمام عملية الشراء. يمنع الإقرار من الخادم حدوث هذا السيناريو من خلال إرسال إقرار فور إرسال Google Play إشعارًا إلى الخادم بأنّ عملية الشراء صالحة.
لمزيد من المعلومات حول الإقرار بعمليات الشراء والاستهلاك، اطّلِع على مقالة معالجة عمليات الشراء.
حماية المحتوى غير المحظور
لمنع المستخدمين الضارين من إعادة توزيع المحتوى غير المحظور، لا تضمّنه في ملف APK. بدلاً من ذلك، اتّخِذ أحد الإجراءات التالية:
استخدِم خدمة في الوقت الفعلي لتقديم المحتوى، مثل خلاصة المحتوى.
يتيح لك تقديم المحتوى من خلال خدمة في الوقت الفعلي أيضًا الحفاظ على حداثة المحتوى.
استخدِم خادمًا بعيدًا لتقديم المحتوى.
عند عرض المحتوى من خادم بعيد أو خدمة في الوقت الفعلي، يمكنك تخزين المحتوى غير المحمي في ذاكرة الجهاز أو على بطاقة SD الخاصة بالجهاز.
إذا كنت تخزّن المحتوى على بطاقة SD، احرص على تشفيره واستخدام مفتاح تشفير خاص بالجهاز.
رصد عمليات الشراء الملغاة والتعامل معها
المشتريات الملغاة هي المشتريات التي تم إلغاؤها أو إبطالها أو ردّ أموالها. إذا كانت عملية الشراء الملغاة قد منحت المستخدم سلعًا داخل التطبيق أو محتوى آخر، يمكنك استخدام Voided Purchases API لمعرفة سبب إلغاء عملية الشراء بالإضافة إلى أي محتوى مرتبط يمكنك استرداده.
يمكن إلغاء عمليات شراء السلع داخل التطبيق والاشتراكات لعدة أسباب، بما في ذلك ما يلي:
يتم إلغاء عملية شراء من قِبل المستخدم أو المطوّر أو Google
(بما في ذلك عمليات الشراء التي تم إلغاؤها تلقائيًا ولم يتم الإقرار بها).
بالنسبة إلى الاشتراكات، يُرجى العِلم أنّ هذا يشير إلى إلغاء شراء اشتراك، وليس إلى إلغاء الاشتراك نفسه.
تم استرداد الأموال المدفوعة مقابل عملية شراء.
يلغي مطوّر التطبيق طلب المستخدم أو يردّ أمواله ويضع علامة في مربّع الاختيار "إلغاء" في وحدة التحكّم.
استنادًا إلى سبب إبطال عملية الشراء، مع أخذ بيانات السلوك السابقة للمستخدم في الاعتبار، يمكنك اتّخاذ قرار بشأن الإجراء المناسب. ننصحك بتنفيذ إجراء واحد أو أكثر مما يلي:
إجراء عمليات استرداد: عند إلغاء عملية شراء، يمكنك استرداد العناصر غير المستخدَمة كما لو لم يتم شراؤها مطلقًا. على سبيل المثال، إذا تم إلغاء عملية شراء عملة داخل اللعبة، يمكنك استرداد العملة التي تم منحها للمستخدم. في حال أنفق المستخدم العملة الافتراضية، ننصحك بضبط رصيد العملة على قيمة سالبة وتقييد نشاط التطبيق وعمليات الشراء المستقبلية إلى أن يصبح رصيد العملة موجبًا.
تنفيذ نظام الإنذارات المتعدّدة: ننصح باتّخاذ إجراءات أقل صرامة مع المخالفين للمرة الأولى، مثل عرض تحذيرات داخل التطبيق. بالنسبة إلى المخالفين المتكررين، ننصح باتّخاذ تدابير أكثر صرامة.
إيقاف عمليات الشراء مؤقتًا: على غرار تنفيذ نظام الإنذارات المتعددة، ننصحك بإيقاف عمليات الشراء مؤقتًا للمستخدمين الذين أجروا عمليات شراء تم إبطالها إلى أن تتمكّن من التحقيق بشكل أكثر شمولاً في سبب إبطال عمليات الشراء.
منع الوصول إلى تطبيقك مؤقتًا أو نهائيًا: في الحالات القصوى التي يتكرّر فيها النشاط الضار، ننصحك بمنع الوصول إلى تطبيقك، سواء بشكل مؤقت أو نهائي.
إجراء طلبات متكررة إلى واجهة برمجة التطبيقات Voided Purchases API: عند رصد عملية شراء تم إبطالها أو أكثر، ننصحك بإجراء طلبات متكررة إلى واجهة برمجة التطبيقات Voided Purchases API لاسترداد عمليات الشراء قبل أن يتمكّن المستخدم من استهلاكها. يمكنك الاطّلاع على مزيد من المعلومات حول حصص Voided Purchases API في مستندات Voided Purchases API.
مساعدة Google في رصد عمليات الاحتيال قبل حدوثها
ترتبط بعض أنواع الاحتيال بالمستخدمين الضارين الذين ينشئون حسابات متعدّدة على Google وداخل التطبيقات لإخفاء نشاطهم.
تستخدم Google هذه البيانات لرصد السلوك المريب وحظر بعض أنواع المعاملات الاحتيالية قبل إكمالها.
اتّخاذ إجراءات ضدّ انتهاك حقوق العلامات التجارية وحقوق الطبع والنشر
إذا كنت تستخدم خادمًا بعيدًا لعرض المحتوى أو إدارته، اطلب من تطبيقك التحقّق من حالة شراء المحتوى الذي تم إلغاء قفله كلما أراد المستخدم الوصول إلى المحتوى. يتيح لك ذلك إبطال الاستخدام عند الضرورة والحدّ من القرصنة.
إذا لاحظت إعادة توزيع المحتوى الخاص بك على Google Play، احرص على اتّخاذ إجراءات سريعة وحاسمة. لمزيد من التفاصيل، يُرجى الاطّلاع على صفحة الأسئلة الشائعة عن حقوق الطبع والنشر في "مركز مساعدة حقوق الطبع والنشر".
يخضع كل من المحتوى وعيّنات التعليمات البرمجية في هذه الصفحة للتراخيص الموضحّة في ترخيص استخدام المحتوى. إنّ Java وOpenJDK هما علامتان تجاريتان مسجَّلتان لشركة Oracle و/أو الشركات التابعة لها.
تاريخ التعديل الأخير: 2025-07-27 (حسب التوقيت العالمي المتفَّق عليه)
[null,null,["تاريخ التعديل الأخير: 2025-07-27 (حسب التوقيت العالمي المتفَّق عليه)"],[],[],null,["# Fight fraud and abuse\n\nAs your app grows in popularity, it can also attract the unwanted\nattention of malicious users that might want to abuse your app. This topic\ndescribes recommendations that you should use to help prevent these attacks on\nyour billing integration and decrease the impact of abuse in your app.\n\nMove sensitive logic to your backend\n------------------------------------\n\nAs much as your app design permits, move sensitive data and logic to a backend\nserver that you control. The more data and logic you have in a frontend device,\nthe more vulnerable it is to being modified or tampered with.\n\nFor example, an online chess game should validate all moves in the backend\ninstead of trusting that the frontend always sends legal moves.\n\nFurthermore, if you find vulnerabilities or security issues, depending on your system design, it might be easier to debug, fix, and roll out updates on the\nbackend rather than the frontend.\n\nVerify purchases before granting entitlements\n---------------------------------------------\n\nA special case of sensitive data and logic that should be handled in the backend\nis purchase verification and acknowledgement. After a user has made a purchase,\nyou should do the following:\n\n1. Send the corresponding `purchaseToken` to your backend. This means that you should maintain a record of all `purchaseToken` values for all purchases.\n2. Verify that the `purchaseToken` value for the current purchase does not match any previous `purchaseToken` values. `purchaseToken` is globally unique, so you can safely use this value as a primary key in your database.\n3. Use the [`Purchases.products:get`](https://developers.google.com/android-publisher/api-ref/rest/v3/purchases.products/get) or [`Purchases.subscriptionsv2:get`](https://developers.google.com/android-publisher/api-ref/rest/v3/purchases.subscriptionsv2/get) endpoints in the Google Play Developer API to verify with Google that the purchase is legitimate.\n4. If the purchase is legitimate and has not been used in the past, you can then safely grant entitlement to the in-app item or subscription.\n5. For subscriptions, when [`linkedPurchaseToken`](https://developers.google.com/android-publisher/api-ref/rest/v3/purchases.subscriptionsv2) is set in `Purchases.subscriptionsv2:get`, you should also remove the `linkedPurchaseToken` from your database and revoke the entitlement that is granted to the `linkedPurchaseToken` to ensure that multiple users are not entitled for the same purchase.\n6. You should grant entitlement only when the purchase state is `PURCHASED` and make sure to handle the `PENDING` purchases correctly. If there is a spike of `CANCELED` purchases, you may be granting entitlements when the purchase is still in `PENDING` state. You can find more information at [Handling pending transactions](/google/play/billing/integrate#pending).\n7. After granting entitlement, if you want to consume and acknowledge a\n consumable product, use the\n [`Purchases.products:consume`](https://developers.google.com/android-publisher/api-ref/rest/v3/purchases.products/consume)\n Play Developer API on your secure backend server.\n To acknowledge a non-consumable product or a subscription,\n call the relevant Play Developer API endpoint, either\n [`Purchases.products:acknowledge`](https://developers.google.com/android-publisher/api-ref/rest/v3/purchases.products/acknowledge)\n or\n [`Purchases.subscriptions:acknowledge`](https://developers.google.com/android-publisher/api-ref/rest/v3/purchases.subscriptions/acknowledge)\n on your secure backend server.\n Acknowledgment is required, as it notifies Google Play that the user has\n been granted entitlement to the purchase. You should acknowledge the\n purchase immediately after granting entitlement.\n\n Note that while you can acknowledge or consume the purchase on the client\n side through your app, server side APIs provide additional protection\n against issues like poor network connectivity and malicious activity. For\n example, consider if a user has purchased an item from your app but they\n lost network connectivity while the purchase was being validated. Without\n server acknowledgment, they might need to log back in through the app to\n complete the acknowledgement process. Otherwise, if the user does not log\n back in within three days, the purchase is automatically refunded due to\n lack of purchase acknowledgement. Server acknowledgment prevents this\n scenario by sending acknowledgment as soon as Google Play notifies the\n server that the purchase is valid.\n\n For more information about purchase acknowledgment and consumption, see\n [Processing purchases](https://developer.android.com/google/play/billing/integrate#process).\n\n| **Note:** Do not grant entitlement when the purchase state is `PENDING`.\n| **Note:** Do not use `orderId` to check for duplicate purchases or as a primary key in your database, as not all purchases are guaranteed to generate an `orderId`. In particular, purchases made with promo codes do not generate an `orderId`.\n\nProtecting your unlocked content\n--------------------------------\n\nTo prevent malicious users from redistributing your unlocked content, do not\nbundle it in your APK file. Instead, do one of the following:\n\n- Use a real-time service to deliver your content, such as a content feed. Delivering content through a real-time service also enables you to keep your content fresh.\n- Use a remote server to deliver your content.\n\nWhen you deliver content from a remote server or a real-time service, you can\nstore the unlocked content in device memory or store it on the device's SD card.\nIf you store content on an SD card, be sure to encrypt the content and use a\ndevice-specific encryption key.\n\nDetect and handle voided purchases\n----------------------------------\n\n*Voided purchases* are purchases that have been canceled, revoked, or\ncharged back. If a voided purchase had previously granted in-app items or other\ncontent to a user, you can use the\n[Voided Purchases API](https://developers.google.com/android-publisher/voided-purchases)\nto obtain the reason the purchase was voided along with any associated\ncontent that you can claw back.\n| **Note:** Voided purchases without any associated clawback content are not exposed by the Voided Purchases API.\n\nPurchases for in-app items and subscriptions can be voided for a variety of\nreasons, including the following:\n\n- A purchase is canceled, either by the user, by the developer, or by Google (including unacknowledged auto-canceled purchases). For subscriptions, note that this refers to canceling the *purchase* of a subscription, rather than [canceling the subscription itself](https://support.google.com/googleplay/answer/7018481?co=GENIE.Platform%3DAndroid).\n- A purchase is charged back.\n- The app developer cancels or refunds a user order and checks the \"revoke\" option in the console.\n\nBased on the reason for the voided purchase, and taking previous user\nbehavioral data into account, you can decide on a course of action. We recommend\nimplementing one or more of the following:\n\n- **Perform clawbacks:** When a purchase is voided, you can claw back unused items as if they were never purchased. For example, if an in-game currency purchase was voided, you could claw back currency that was already granted to the user. In the case where the user has already spent the currency, consider setting the currency balance to negative and limiting app activity and future purchases until the currency balance is positive.\n- **Multiple strikes implementation:** Consider taking less drastic actions for first-time offenders, such as displaying in-app warnings. For repeat offenders, consider more severe measures.\n- **Temporarily disable purchases:** Similar to the multiple strikes implementation, consider disabling purchases for users with voided purchases until you can more thoroughly investigate why the purchases were voided.\n- **Temporarily or permanently disallow access to your app:** For extreme cases with repeated malicious activity, consider disallowing access to your app, either temporarily or permanently.\n- **Make frequent calls to the Voided Purchases API:** When you detect one or more voided purchases, consider making more frequent calls to the Voided Purchases API to claw back purchases before the user can consume them. You can find more information on Voided Purchases API quotas in the [Voided Purchases API documentation](https://developers.google.com/android-publisher/voided-purchases#quotas).\n\nHelp Google detect fraud before it happens\n------------------------------------------\n\nSome types of fraud are related to malicious users who create multiple Google\nand in-app accounts to hide their activity.\n\nUse the\n[`setObfuscatedAccountId`](/reference/com/android/billingclient/api/BillingFlowParams.Builder#setObfuscatedAccountId(java.lang.String))\nand\n[`setObfuscatedProfileId`](/reference/com/android/billingclient/api/BillingFlowParams.Builder#setobfuscatedprofileid)\nmethods in the builder for\n[`BillingFlowParams`](/reference/com/android/billingclient/api/BillingFlowParams.Builder)\nto help Google map Google Accounts to in-app accounts.\n\nGoogle uses this data to detect suspicious behavior and block some types of fraudulent transactions before they are completed.\n\nTaking action against trademark and copyright infringement\n----------------------------------------------------------\n\nIf you are using a remote server to deliver or manage content, have your\napp verify the purchase state of the unlocked content whenever a user accesses\nthe content. This allows you to revoke use when necessary and minimize piracy.\nIf you see your content being redistributed on Google Play, be sure to act\nquickly and decisively. For more details, see the\n[Frequently Asked Copyright Questions](https://support.google.com/legal/answer/4558836)\npage in the Copyright Help Center."]]
