الشراء المعلّق يبدو كعملية بيع، لكن المال لم يصل بعد، ومنحه مبكرًا يعني إهداء المنتج مجانًا

يضغط أحدهم على زر الشراء في تطبيقك. تُظهر سجلاتك طلبًا جديدًا، ويُطلَق مستمع الفوترة لديك، فتسلّم البضاعة. في معظم عمليات الشراء يكون هذا صحيحًا تمامًا. أما في الشراء المعلّق فهو خطأ، لأن الطلب موجود لكن المال غير موجود. اختار العميل طريقة دفع تُسوّى لاحقًا، وما زال المتجر ينتظر أن يُدفع له، وقد سلّمت للتو ميزة مدفوعة مقابل رسم قد لا يكتمل أبدًا. هذا هو القريب الهادئ للاسترداد. لا شيء يُعكس هنا، لأنه لم يُحصَّل شيء قط. لقد أهديت المنتج مجانًا فحسب.

الشراء المعلّق طلب حقيقي في حالة لم-تُدفع-بعد، وهو موجود في كل من App Store و Google Play. كلا المتجرين يخبرانك بوضوح أن تنتظر. الفخّ هو أن الطلب المعلّق يبدو في الكود شبه مطابق للطلب المكتمل، لذا فإن أي تكامل يعامل كل عملية شراء جديدة كعملية بيع سيشحن البضاعة على طلبات ما زال المتجر يحاول تحصيلها. تعامل معها بشكل صحيح فلا تخسر شيئًا. تعامل معها بشكل خاطئ فيصبح كل دفع بطيء يسقط في منتصف الطريق خسارة صافية، مُقدَّمة على حسابك.

ما هو الشراء المعلّق فعليًا

الشراء المعلّق طلب سجّله المتجر لكنه لم يفرض عليه رسومًا بعد. بدأ المشتري العملية، وقبلها المتجر، وتجري التسوية في مكان لا يستطيع تطبيقك رؤيته. يسمّي Google Play هذا حالة PENDING. ويسمّيه Apple معاملة معلّقة أو مؤجّلة. أسماء مختلفة، والحقيقة واحدة: المتجر يبقي طلبًا مفتوحًا بينما ينتظر أن يُدفع له، وقد أخبرك ألّا تعامل ذلك الطلب كمال.

Google Play: الدفع يجري في مكان آخر

بعض طرق الدفع تُسوّى خارج النطاق. الدفع نقدًا في متجر فعلي، والتحويلات المصرفية، وبعض فواتير مشغّل الاتصالات، كلها تتطلب خطوات إضافية بين الضغط والرسم. عندما يختار العميل إحداها، يعيد Google الشراء بحالة PENDING بدلًا من PURCHASED. في حالة الدفع نقدًا يتلقّى العميل رمزًا عبر الإشعار والبريد الإلكتروني، يحمله إلى متجر مشارك، ويدفع لأمين الصندوق. حتى يحدث ذلك، لم يحصّل Google شيئًا، ولا أنت. قاعدة Google في سطر واحد: استخدم getPurchaseState() وامنح الاستحقاق فقط عندما تكون الحالة PURCHASED. كما يخبرك ألّا تُقرّ باستلام الشراء وهو في حالة PENDING، لأن الإقرار يخصّ طلبًا مدفوعًا، لا طلبًا موعودًا.

Apple: الشراء ينتظر ضغطة شخص آخر

تعني حالة Apple المعلّقة أن المعاملة تحتاج إلى إجراء خارجي قبل أن تكتمل. أكثرها شيوعًا هو Ask to Buy، حيث يبدأ طفل عملية شراء ويتعيّن على منظّم العائلة الموافقة عليها. في StoreKit 2 يعيد استدعاء الشراء Product.PurchaseResult.pending. وفي StoreKit الأقدم يُبلَّغ عن المعاملة كمؤجّلة. في كلتا الحالتين، لم يفرض Apple رسومًا على أحد، والمعاملة المكتملة، إن أتت، تصل بشكل غير متزامن عبر Transaction.updates. اعرض للعميل حالة انتظار ولا تفتح أي شيء حتى تصل المعاملة المكتملة.

لماذا يكلّفك منح الشراء المعلّق مالًا حقيقيًا

الخسارة هنا ليست من نوع الاسترداد، حيث يُسحب مال سجّلته. بل هي أسوأ من ناحية محددة واحدة: لا يوجد مال لسحبه، لأنه لم يُحصَّل شيء قط.

أنت تسلّم، والمتجر لا يحصّل أبدًا

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

إشارة الإلغاء، وماذا تعني

المتجر يخبرك فعلًا عندما يموت طلب معلّق. على Google Play، المنتج لمرة واحدة الذي يسقط يرسل إشعار ONE_TIME_PRODUCT_CANCELED، من النوع 2، والاشتراك الذي كان معلّقًا يرسل SUBSCRIPTION_PENDING_PURCHASE_CANCELED، من النوع 20. وعندما تكتمل الطلبات نفسها بدلًا من ذلك، تحصل على ONE_TIME_PRODUCT_PURCHASED، من النوع 1، أو SUBSCRIPTION_PURCHASED، من النوع 4. على Apple لا يوجد حدث إلغاء لالتقاطه، لأن المعاملة المؤجّلة التي تُرفض ببساطة لا تصبح معاملة مكتملة أبدًا. إن كنت قد فتحت مبكرًا، فذلك الصمت هو الفاتورة.

المهلة، ومن ينتظر من

الشراء المعلّق ليس ساعةً تتسابق معها. إنه ساعة لم تبدأ بعد، من جهتك.

Google Play يمنح العميل أيامًا، لا دقائق

الدفع نقدًا أو بتحويل مصرفي يُسوّى وفق جدول العميل، لا جدولك. يبقى الطلب في PENDING حتى يدفع العميل أو تنتهي المهلة فيلغيه Google. أما مهلة الإقرار الخاصة بك ومدتها ثلاثة أيام، تلك التي تسترد تلقائيًا شراءً تعجز عن الإقرار به، فلا تبدأ أساسًا حتى ينتقل الشراء من PENDING إلى PURCHASED. لذا لا داعي للاستعجال في خدمة طلب معلّق. هناك فقط انضباط انتظار تغيّر الحالة.

موافقة Apple على هاتف منظّم العائلة

يصل طلب Ask to Buy إلى جهاز المنظّم كإشعار يوافق عليه أو يرفضه متى تسنّى له ذلك. قد يكون هذا بعد دقائق أو ساعات أو يوم، ولا يستطيع تطبيقك تعجيله. السلوك الصحيح الوحيد هو أن تعكس حالة الانتظار وتدع StoreKit يسلّمك المعاملة المكتملة إن أتت الموافقة ومتى أتت.

كيف تتعامل مع عمليات الشراء المعلّقة دون تسريب

المهمة كلها تتلخّص في أربع عادات. لا شيء منها صعب، وتجاوز أي منها هو المكان الذي يذهب فيه المال.

امنح عند الحالة المدفوعة، لا عند المعلّقة أبدًا

على Google Play، تحقّق من getPurchaseState() وامنح فقط عند PURCHASED، ولا تُقرّ باستلام الشراء وهو في حالة PENDING. على Apple، افتح فقط عند معاملة مكتملة ولا تفتح أبدًا عند النتيجة المعلّقة. هذه القاعدة الوحيدة تُغلق التسريب بالكامل. كل ما تبقّى يتعلّق بالتأكّد من أنك تلاحظ فعلًا وصول الحالة المدفوعة.

أعد التحقق عندما يعود التطبيق

غالبًا ما يحدث الانتقال من معلّق إلى مدفوع بينما تطبيقك غير قيد التشغيل. على Google Play، استدعِ queryPurchasesAsync() في معالج onResume() لالتقاط الطلبات التي أصبحت PURCHASED في الخلفية، وأبقِ مستمع Real-time Developer Notifications كمصدر الحقيقة على جانب الخادم. على Apple، استمع إلى Transaction.updates طوال عمر التطبيق كاملًا، لأن المعاملة المُوافَق عليها قد تصل بعد وقت طويل من عودة استدعاء الشراء الأصلي.

فعّل دعم المعلّق واختبر النهايتين

يتطلّب Google أن تستدعي enablePendingPurchases() عند إنشاء BillingClient، ودعم المعاملات المعلّقة للمنتجات لمرة واحدة إلزامي، وليس اختياريًا. اختبره قبل الإطلاق. يحصل مختبرو الترخيص على أداتَي اختبار إضافيتين لأشكال الدفع المؤجّلة، حيث يكتمل الدفع تلقائيًا أو يُلغى تلقائيًا بعد بضع دقائق، حتى تتمكن من مشاهدة مسار الدفع ومسار السقوط من البداية إلى النهاية.

أخبر العميل أن الطلب لم يكتمل

المشتري المعلّق عميل حقيقي في منتصف عملية شراء، وليس فشلًا. أظهر له أن الطلب ينتظر دفعه أو موافقة، وامنحه طريقًا واضحًا للعودة وإتمامه. الحالة المعلّقة الصامتة تخسر مبيعات تستعيدها حالة موسومة جيدًا، لأن معظم هؤلاء المشترين ما زالوا يريدون الشيء ولم يتبقَّ أمامهم سوى خطوة واحدة.

نفس موجزات Real-time Developer Notifications و App Store Server Notifications التي يقرأها RefundHalt بالفعل للاستردادات وعمليات ردّ المبالغ تحمل هذه الإشارات أيضًا. إشعار الشراء الذي يقول إن طلبًا معلّقًا اكتمل أخيرًا، وإشعار الإلغاء الذي يقول إنه لم يكتمل، يصلان إلى لوحة التحكم بجانب بقية أحداث إيراداتك، بحيث يصبح الطلب المعلّق الذي سقط شيئًا يمكنك رؤيته بدلًا من شيء دفعت مقابله عن طريق الخطأ.

باختصار

الشراء المعلّق طلب بلا دفع، وكلا المتجرين صريحان في أنه ينبغي لك الانتظار. يعيد Google Play الطلبات النقدية والتحويلات المصرفية وبعض طلبات فواتير مشغّل الاتصالات بحالة PENDING ويخبرك بمنح الوصول فقط عند PURCHASED. ويعيد Apple معاملة معلّقة أو مؤجّلة لـ Ask to Buy وغيرها من الإجراءات المطلوبة، ويسلّم المعاملة المكتملة لاحقًا عبر Transaction.updates. افتح عند الحالة المدفوعة، وأعد التحقق عند استئناف تطبيقك، وفعّل دعم المعلّق واختبره، وسِمِ الطلب المنتظر للعميل. افعل ذلك فلن يكلّفك الشراء المعلّق شيئًا. تجاوزه فتسلّم منتجًا مدفوعًا مقابل رسم لم يأتِ قط، وهي الخسارة الوحيدة التي لا إيصال تشير إليه.