تتم عملية الشراء بنجاح، ويحصل العميل على منتجه، وبعد ثلاثة أيام يختفي كل ذلك. يقوم Google Play بعكس عملية الدفع وسحب الاستحقاق، دون أن يطلب العميل ذلك ودون أن يلمس أحد في فريق الدعم لديك أي زر. فشلت عملية الشراء بصمت لأن خادمك لم يُخبر Google مطلقًا بأنها تمّت معالجتها.
هذه هي القاعدة بأكملها: أقرّ عملية شراء في Google Play خلال ثلاثة أيام، أو سيقوم Google باسترداد مبلغها وإلغائها تلقائيًا. في كل مرة، دون استثناءات. ومن بين كل الطرق التي يمكن أن تنعكس بها عملية بيع في أي من المتجرين، تُعد هذه واحدة من الطرق القليلة جدًا التي تقع بالكامل ضمن نطاق تكاملك الخاص، وهذا ما يجعلها أيضًا من أكثر الطرق هدوءًا لاستنزاف الإيرادات.
الأمر لا يتعلق بفحص احتيال ولا بقرار سياسي. إنه استدعاء رد (callback) لم يُفعَّل أبدًا. الإصلاح بسيط، لكن الأموال التي تفقدها بتجاهله ليست بسيطة، لذا يستحق الأمر معرفة ما تنص عليه القاعدة بالضبط، وسبب تفلّت عمليات الشراء منها، وما تجرّه معها كل عملية بيع تختفي.
ما تتطلبه وثائق Google بالفعل
يتطلب Play Billing أن يُخطر تطبيقك Google بعد أن يمنح الاستحقاق ويُخبر المستخدم بأن عملية الشراء تمت بنجاح. تضع وثائق Google رقمًا صريحًا لذلك: يجب إجراء هذا الإخطار "خلال ثلاثة أيام حتى لا يتم استرداد مبلغ عملية الشراء تلقائيًا وسحب الاستحقاق". تُكرر وثائق المنتجات ذات الشراء الواحد العبارة نفسها دون أي تحفظ. وإذا تجاهلت الإقرار، فإن "المستخدم يحصل تلقائيًا على استرداد للمبلغ، ويقوم Google Play بإلغاء عملية الشراء". وتخضع عملية الشراء الأولية للاشتراك لنفس القاعدة تمامًا.
الإقرار ليس مجرد إجراء ورقي. إنه الإشارة الوحيدة التي يملكها Google لمعرفة أن التسليم قد تم بالفعل. وعدم وجود أي إشارة يعني أن Google يفترض أنه لم يتم تسليم أي شيء، فيقوم بعكس المعاملة بأكملها لصالح المشتري دون الرجوع إليك. يرى المشتري استردادًا غير متوقع للمبلغ، وترى أنت عملية بيع اختفت من سجلاتك.
أهم النقاط
اترك عملية بيع دون تأكيد لمدة 72 ساعة، وسيحدث العكس من تلقاء نفسه: يُعاد سداد المبلغ للمشتري، ويُسحب الاستحقاق، دون الرجوع إلى أحد. لم يتسبب أي متسوق في ذلك؛ بل تسبب فيه خادمك الخلفي (backend) بصمته، وهو نفسه قادر بنفس القدر على منع حدوثه.
الوصول إلى حالة PURCHASED هو ما يُشغّل العد التنازلي، وهذا ما يجعل لحظة الدفع نفسها غير ذات صلة بموعدك النهائي. أي عملية لا تزال في حالة PENDING لا يُطبَّق عليها أي مؤقت، ولا تستحق استدعاء تأكيد حتى الآن.
يُمكن الوفاء بهذا الالتزام من خلال أحد استدعائين. نفّذ purchases.products.consume على منتج استهلاكي، أو استخدم purchases.products.acknowledge وpurchases.subscriptions.acknowledge على أي منتج آخر. يعتبر Google كلًا منهما دليلًا على وصول السلعة.
تطلب منك الاشتراكات ذلك مرة واحدة فقط، عند التسجيل. وتتم تسوية كل دورة فوترة لاحقة من قِبل Google نفسه، ويتم تمييزها كمؤكدة دون أن يتحرك كودك على الإطلاق.
هل تبيع خطة مدفوعة مسبقًا تمتد لأقل من سبعة أيام؟ تنخفض المهلة الممنوحة لك إلى خمسين بالمائة من مدة الخطة، أيًا كانت. منتج أقصر، فترة سماح أقصر.
لا يعود إلى المتسوق سوى سعر المنتج فقط. أما وقت الحوسبة، ونفقات واجهات برمجة التطبيقات (API) الخاصة بالنماذج، وفواتير التخزين، ومستحقات المبدعين (creators)، فتلك أموال خرجت من حسابك أثناء التنفيذ ولن يعود منها شيء. الضرر الحقيقي يتجاوز ما يُسجَّله بند الاسترداد.
لا شيء على iOS يعمل بهذه الطريقة. يُعيد StoreKit تقديم المعاملة غير المكتملة في كل مرة يُفتح فيها التطبيق، وينتظر بصبر، دون أن يعكس عملية الدفع أبدًا. هذا الخطر بالتحديد موجود في Google Play فقط ولا مكان آخر.
الموعد النهائي لا يبدأ عند الدفع
النقر على زر "شراء" لا يُشغّل المؤقت. يجب أن تتحول حالة عملية الشراء إلى PURCHASED أولًا، وبعض عمليات الشراء تبقى في حالة PENDING قبل ذلك. طرق الدفع النقدي تفعل ذلك، وكذلك التحويلات المصرفية البطيئة وطلبات موافقة ولي الأمر. يذكر Google ذلك بشكل مباشر: "تبدأ نافذة الإقرار البالغة ثلاثة أيام فقط عندما تتحول حالة عملية الشراء من PENDING إلى PURCHASED."
هذا يعني أمرين بالنسبة لكيفية بناء التدفق (flow) الخاص بك. امنح الاستحقاق فقط بعد أن تصبح الحالة PURCHASED، وليس في حالة PENDING أبدًا، وإلا فستُسلّم منتجًا مقابل أموال قد لا تصل فعليًا. ولا تُقرّ أيضًا عملية شراء في حالة PENDING، لأنه لا يوجد شيء لإقراره بعد. استدعِ enablePendingPurchases() عند إعداد BillingClient، وانتظر انتقال الحالة، ولا تبدأ العد إلا بعد أن تصل إلى PURCHASED.
اعتبر حالة PENDING بمعنى "لم يُبع بعد". لا شيء واجب: لا استحقاق، ولا إقرار، ولا شيء يُسجَّل كإيراد. وفي اللحظة التي تتحول فيها إلى PURCHASED، يصبح الاستحقاق والعد التنازلي لثلاثة أيام كلاهما مسؤوليتك.
اختيار استدعاء API المناسب لما بعته
هناك مساران من واجهة برمجة التطبيقات (API) يُنهيان الموعد النهائي، ويعتمد المسار المناسب على ما بعته. كلاهما يُلبّي المتطلب بنفس القدر. ما يُميّز بينهما هو ما يفعله كل منهما بالمنتج بعد ذلك.
المنتجات الاستهلاكية تُستهلك. وهذا يعني استخدام purchases.products.consume على خادم خلفي آمن، أو consumeAsync() من مكتبة Play Billing Library على جهاز العميل. يقوم الاستهلاك بوظيفة مضاعفة، لأنه يُلبّي متطلب الإقرار ويُعيد المنتج للبيع من جديد. وهذا ما تحتاجه بالنسبة للعملات، أو الأرصدة، أو أي عملية إنشاء لمرة واحدة قد يشتريها العميل بشكل متكرر.
أما المنتجات غير الاستهلاكية والاشتراكات، فيتم إقرارها بدلًا من ذلك، من خلال purchases.products.acknowledge أو purchases.subscriptions.acknowledge أو acknowledgePurchase() على جهاز العميل. هذا يُنهي الموعد النهائي لكن لا يُعيد فتح المنتج للشراء.
وفيما يلي كيفية ربط كل نوع من المنتجات باستدعاء ومهلة زمنية محددة:
بالنسبة إلى منتج استهلاكي، استدعِ purchases.products.consume أو consumeAsync(). وهذا يُعيد أيضًا المنتج للبيع من جديد، ومهلتك هي ثلاثة أيام من لحظة PURCHASED.
بالنسبة إلى منتج غير استهلاكي، استدعِ purchases.products.acknowledge أو acknowledgePurchase(). يتم تأكيد الاستحقاق دون إمكانية إعادة الشراء، ومهلتك هي ثلاثة أيام من لحظة PURCHASED.
بالنسبة إلى عملية الشراء الأولية للاشتراك، استدعِ purchases.subscriptions.acknowledge أو acknowledgePurchase(). وهذا يُؤكّد الاشتراك الجديد، ومهلتك هي ثلاثة أيام من لحظة PURCHASED.
بالنسبة إلى تجديد الاشتراك، لا تحتاج إلى أي استدعاء على الإطلاق. يُميّزه Google على أنه مُقرّ تلقائيًا، لذا لا توجد مهلة زمنية.
بالنسبة إلى خطة مدفوعة مسبقًا تقل مدتها عن أسبوع، استخدم استدعاءات الإقرار نفسها، لكن مهلتك تنكمش إلى نصف مدة الخطة.
الالتزام يتوقف عند الدفعة الأولى
لا تحتاج تجديدات الاشتراك إلى إقرار على الإطلاق. يذكر Google ذلك بشكل مباشر: "لست مضطرًا لإقرار تجديدات الاشتراك"، ويُميّز Google كل تجديد على أنه مُقرّ تلقائيًا. إن عملية الشراء الأولى للاشتراك فقط هي التي تصل في حالة إقرار معلّق، وتبقى على عاتقك إلى أن تُزيلها. تحقق من حالة الإقرار من جانب الخادم، أو استخدم isAcknowledged() على جهاز العميل، قبل اتخاذ أي إجراء. بهذه الطريقة لن ترسل استدعاء إقرار مكررًا أبدًا.
مهلة أضيق للخطط المدفوعة مسبقًا قصيرة المدى
تتبع الخطط المدفوعة مسبقًا التي تبلغ مدتها أسبوعًا أو أكثر قاعدة الثلاثة أيام القياسية. أما الخطط الأقصر فلا تفعل ذلك. تنص وثائق Google على أن الخطط "التي تقل مدتها عن أسبوع واحد يجب إقرارها خلال نصف مدة الخطة". خطة مدفوعة مسبقًا لمدة ثلاثة أيام تمنحك يومًا ونصفًا فقط، لا النافذة الكاملة. وإذا كانت عمليات الشحن المدفوعة مسبقًا القصيرة جزءًا من كتالوجك، فيجب أن يكون مسار الإقرار سريعًا ومُدارًا من جانب الخادم، دون الاعتماد أبدًا على إعادة فتح العميل للتطبيق.
أين يضيع استدعاء الإقرار عادةً
لا أحد يتجاهل هذه الخطوة عن قصد. إنها تضيع لأن منطق الإقرار يُربط بمحفّز خاطئ. النمط الخاطئ الشائع هو أن يقوم جهاز العميل بالإقرار فقط عندما يعود تدفق الشراء إلى المقدمة (foreground). وهذا يغطي العميل الذي يُنهي الشراء ويستمر في استخدام التطبيق مباشرة بعد ذلك، ولا يغطي أي شخص آخر.
يقع المطورون في هذا الفخ باستمرار. تتبع المواضيع في مجتمع مطوري Google نفسه السيناريو نفسه كل مرة، سواء كانت نسخة من مستخدم يُسترد له المبلغ تلقائيًا بعد ثلاثة أيام من الشراء، أو طلب لفهم سبب استمرار انعكاس عمليات الدفع من تلقاء نفسها في اليوم الثالث. والتشخيص نادرًا ما يتغير: كان استدعاء الإقرار مرتبطًا بإجراء من المستخدم لم يحدث أبدًا، فلم يُفعَّل على الإطلاق.
التجارب المجانية والعميل الذي لا يفتح التطبيق مرة أخرى أبدًا
أسوأ نسخة من هذا هي تجربة مجانية، أو عملية شراء تمت في اللحظات الأخيرة قبل أن يُغلق أحدهم تطبيقك للمرة الأخيرة. فعندما ينتظر الإقرار فتح التطبيق مرة أخرى، ولا يأتي هذا الفتح أبدًا، تنتهي صلاحية عملية الشراء ببساطة. يقوم Google باستردادها وإلغائها في اليوم الثالث. وبالنسبة لتجربة كانت في طريقها إلى التحول إلى اشتراك مدفوع، تفقد أول فاتورة لم تتمكن من تحصيلها أبدًا، ويتبخر معها استحقاق العميل بصمت. لا يظهر أي منهما في قائمة طلبات الدعم لديك. يظهر كلاهما كعملية شراء ملغاة، إن بحثت عن ذلك.
الإقرار الذي يعتمد على فتح التطبيق مرة أخرى هو عملية بيع تخسرها في كل مرة يغيب فيها العميل لمدة ثلاثة أيام. والتجارب وعمليات الشراء بنقرة واحدة هي بالضبط اللحظات التي يغيب فيها العملاء.
الفاتورة الحقيقية وراء استرداد غير مُقرّ
بند الاسترداد يُقلّل من تقدير ما خسرته بالفعل. يعكس Google عملية البيع، وتُعيد السعر، وهذا هو الرقم الذي يراه الجميع. لكنه ليس الفاتورة بأكملها.
تخيل منتجًا استهلاكيًا يُشغّل عملًا حقيقيًا في اللحظة التي يشتريه فيها أحدهم. دفعة من عمليات إنشاء الصور، أو مجموعة من الاستدعاءات لواجهة برمجة تطبيقات (API) لمزود نموذج، أو تصدير فيديو، أو مستحقات واجبة لمبدع (creator). أنت دفعت ثمن تلك الحوسبة، وتلك استدعاءات API، وذلك التخزين، وتلك المستحقات وقت الاستخدام. يُعيد الاسترداد سعر البيع إلى العميل، لكنه لا يُعيد لك فاتورة المزوّد. تكلفة حقيقية خرجت من الباب ولم يعد منها شيء.
بالنسبة للاشتراكات والتجارب، الخسارة هي أول فاتورة لم تُحصّلها أبدًا، بالإضافة إلى علاقة عميل انتهت قبل أن تبدأ. والمخاطر على وشك أن تزداد. فبدءًا من 3 أغسطس 2026، سينقل Google Play سعر شراء الاستردادات القسرية (chargeback) ورسوم البنوك إلى عاتق المطورين بالنسبة للطلبات التي تتم بعد ذلك التاريخ، وهذا ما يجعل من الجدير إغلاق أي تسرب يمكن تجنبه الآن بدلًا من الانتظار. الاسترداد غير المُقرّ ليس استردادًا قسريًا (chargeback)، لكنه يُعلّمك الدرس نفسه: الأموال التي أنفقتها بالفعل ليست بالضرورة أموالًا تحتفظ بها.
بناء خطوة الإقرار بحيث لا يمكن تفويتها
النمط الموثوق يُخرج تطبيقك تمامًا من المسار الحرج. نفّذه على خادمك الخلفي، مدفوعًا بالإشعارات، لا باعتماد ما إذا كان أحدهم سيعيد فتح الشاشة.
اشترك في إشعارات المطورين الفورية (real-time developer notifications). يصل حدث شراء منتج لمرة واحدة، أو حدث شراء اشتراك، إلى خادمك في اللحظة التي يُسجّل فيها Google عملية البيع، سواء كان التطبيق قيد التشغيل أم لا.
تحقق من صحة رمز الشراء (purchase token) عبر Play Developer API، وتأكد من أن الحالة هي PURCHASED وليست PENDING.
سجّل الاستحقاق في نظامك الخاص، مرتبطًا بحساب ذلك العميل.
استهلك أو أقِرّ دون تأخير. تُستهلك المنتجات الاستهلاكية، وتُقرّ المنتجات غير الاستهلاكية والاشتراكات الأولية. اقرأ حالة الإقرار أولًا حتى لا يُرسل الاستدعاء مرتين أبدًا.
احتفظ بآلية تعبئة احتياطية (backfill) من جانب العميل. استدعاء queryPurchasesAsync() في onResume() يلتقط أي شيء تمت تسويته أثناء إغلاق التطبيق. اعتبرها تأمينًا، لا المسار الرئيسي.
النقطة الأساسية هي أن الإقرار يُفعَّل بواسطة حدث يُسلّمه Google إليك، بدلًا من إجراء من المستخدم لا يمكنك ضمان حدوثه. فالشخص الذي يشتري مرة واحدة ولا يعود أبدًا يظل مغطى بالكامل، لأن خادمك قام بالعمل بالفعل في اللحظة التي وصلت فيها عملية الشراء.
شبكة أمان لما يتسرّب على أي حال
مهما كان خط الأنابيب (pipeline) مُصمّمًا بشكل جيد، فإنه يستحق شبكة أمان إضافية. تُعدّد واجهة Voided Purchases API الخاصة بـ Google الطلبات التي انتهت باسترداد، أو إلغاء، أو استرداد قسري (chargeback)، وتُسلّط الضوء بشكل خاص على السيناريو الذي يكون فيه السبب عملية شراء "لم يُقرّها المطوّر أبدًا، وقد لا تكون موجودة بالتالي في سجلات المطور". استعلم عنها بشكل منتظم ويمكنك سحب الوصول من أي شخص قام Google بإلغاء طلبه بصمت من ورائك. لكن احذر هذا الحد: فقط آخر 30 يومًا قابلة للاسترجاع، وهذا ما يجعل من هذا مهمة مُجدولة بدلًا من شيء تتعامل معه بمرور كل فصل.
iOS لم يُصمَّم أبدًا ليفعل بك هذا
انتقل إلى App Store، ولن ينطبق أي شيء من هذا. فقد بنت Apple خطوة إغلاق خاصة بها، وهي إنهاء المعاملة (finishing a transaction)، إلا أن العقوبة على تجاهلها تسير في الاتجاه المعاكس. تبقى المعاملة غير المكتملة معلّقة في قائمة انتظار Apple. وتظهر من جديد في كل مرة يُفتح فيها التطبيق، ومرة أخرى في كل مرة يرتبط فيها المراقب (observer)، مما يُعطيك فرصًا متكررة لتسليم ما دفع العميل ثمنه. لا تُصدر Apple أي عملية عكسية بشأن ذلك. لا يوجد شيء يشبه محفّز استرداد الأموال بعد 72 ساعة على تلك المنصة.
وهذا بالضبط ما يجعل نموذجًا ذهنيًا واحدًا غير قابل للتمدد عبر المتجرين معًا. يُعطيك Android عدًا تنازليًا وعملية بيع تتبخر إن خسرتها، أما iOS فيُعطيك تذكيرًا مستمرًا ووقتًا غير محدود للرد عليه. أدخل عادات iOS إلى قاعدة كود Android، وعاجلًا أم آجلًا ستجد نفسك أمام كومة من الطلبات المُعاد عكسها التي لا يستطيع أحد في الفريق تفسيرها.
إغلاق هذه الثغرة هو بالضبط ما تقوم به Refund Sensor. يُفعَّل التأكيد مباشرة من إشعار المتجر، في غضون لحظات من وصوله، بينما يقوم مرور تسوية دائم مقابل Voided Purchases API بسحب الوصول في أي مكان قام فيه Google بإلغاء طلب من ورائك بالفعل. العد التنازلي الذي كان يمكن أن تخسره يتحول إلى مربّع تم تحديده قبل أن تُفكّر حتى في التحقق منه.
أين يتم توثيق هذه القواعد
الأسئلة الشائعة
لم يرسل خادمك استدعاء الإقرار في الوقت المحدد. فعندما تبقى عملية شراء دون إقرار لمدة تتجاوز ثلاثة أيام من وصولها إلى حالة PURCHASED، يقوم Google بإلغاء عملية البيع وسحب الاستحقاق تلقائيًا. الأمر لا يتعلق بشيء فعله العميل، ولا يُعد عقوبة يفرضها Google. إنه ببساطة استدعاء إقرار مفقود، وإجراء الإقرار من جانب الخادم بناءً على إشعار المتجر يُزيل هذه المشكلة تمامًا.
كلاهما يوقف عداد الثلاثة أيام، لكنهما يتركان المنتج في حالتين مختلفتين. الاستهلاك، عبر purchases.products.consume أو consumeAsync()، مخصص للمنتجات الاستهلاكية. فهو يُلغي الموعد النهائي ويُعيد المنتج للبيع من جديد. أما الإقرار، عبر purchases.products.acknowledge أو purchases.subscriptions.acknowledge أو acknowledgePurchase()، فهو مخصص للمنتجات غير الاستهلاكية والاشتراكات. فهو يؤكد الاستحقاق دون إعادة فتح المنتج للشراء مرة أخرى.
لا، فقط عملية الشراء الأولى. لا يتطلب Google إقرار التجديدات، ويقوم بتمييزها على أنها مُقرَّة تلقائيًا. عملية شراء الاشتراك الأولية فقط، التي تصل في حالة إقرار معلّق، هي التي تبقى مسؤوليتك إلى أن تُزيلها.
لا، يجب الانتظار حتى تصل إلى حالة PURCHASED. عملية الشراء التي تكون في حالة PENDING، مثل الدفع النقدي أو طلب موافقة ولي الأمر، لم يبدأ عداد الثلاثة أيام بشأنها على الإطلاق. امنح الاستحقاق وأرسل الإقرار فقط بعد أن تتحول الحالة فعليًا من PENDING إلى PURCHASED.
لا، ومن المهم معرفة ذلك قبل افتراض أن أنظمة Android وiOS تتصرف بالطريقة نفسها. فمعاملة StoreKit غير المكتملة تُعاد إعادة تسليمها في كل مرة يُفتح فيها التطبيق إلى أن تُنهيها، ولا تقوم Apple أبدًا برد أموالها تلقائيًا. الرد التلقائي بعد ثلاثة أيام هو أمر خاص بـ Google Play فقط، لذا يحتاج كل نظام إلى طريقة تعامل مختلفة.
لا يمكن التراجع عن عملية الاسترداد نفسها، لكن ما يمكنك فعله هو التسوية. فواجهة Voided Purchases API تعرض عمليات الشراء المستردة والملغاة خلال آخر 30 يومًا، وتُشير إلى العمليات التي أُلغيت لأنها لم تُقرّ على الإطلاق، بحيث يمكنك سحب الاستحقاق الذي منحته. ومن الآن فصاعدًا، فإن الإقرار بناءً على إشعار المتجر هو ما يمنع تفلّت العملية التالية.
