ضع معرّف حساب مُبهَم على كل عملية شراء في Google Play، وإلا سيصلك ردّ مبلغ دون أي طريقة لتتبّعه

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

ما هو معرّف الحساب المُبهَم فعلياً

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

إنها سلسلة تضبطها عند إتمام الشراء، لا اسم

بكلمات Google، يحدّد setObfuscatedAccountId سلسلة مُبهَمة اختيارية ترتبط بشكل فريد بحساب المستخدم للمشتري في تطبيقك. كلمة مُبهَم تؤدي عملاً حقيقياً. لا يريد Google معرّف المستخدم الخام لديك ولا أي شيء يعرّف الشخص. يريد رمزاً ثابتاً يرتبط واحداً بواحد بمستخدم من جهتك، لا أكثر. الحقل محدود بـ 64 حرفاً، ما يتّسع لتجزئة براحة ولا شيء يذكر غير ذلك.

يقرأه Google أولاً لفحصه الخاص للاحتيال

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

لماذا يهم عندما تصل مراجعة ردّ مبلغ

الاسترداد الذي تراه قادماً سهل. الحالة الصعبة هي ردّ المبلغ من البنك، لأنه لا يبدأ بحديث عميلك معك. يبدأ من البنك، ويحوّله Google Play إليك مراجعةً مرفقة بمؤقّت.

النزاع يسمّي order، لا شخصاً

عندما يعترض عميل على خصم لدى بنكه ويحتاج Google إلى مدخلاتك، يرسل Google Play إشعار PendingRefundReviewNotification. تلك الرسالة تحدّد الـ order. لا تحمل معرّف المستخدم لديك، لأن Google لم يكن لديه معرّف المستخدم لديك قط. لم يكن لديه سوى ما وسمت به عملية الشراء. إن كان ذلك لا شيء، فأنت الآن تبحث عكسياً عن order id ورمز شراء مجردين مقابل سجلاتك الخاصة، آملاً أنك سجّلت الرمز وقت الشراء وآملاً أن التطابق لا لبس فيه. إن ضبطت معرّف حساب مُبهَماً، فإن عملية الشراء تحمل تجزئتك الخاصة، فتبحث عن المستخدم باستعلام واحد، وتنتقل إلى بناء الأدلة بدل مطاردة الهوية.

ما الذي يطلبه منك orders.reviewrefund فعلياً

الإجابة عن النزاع تعني استدعاء طريقة orders.reviewrefund خلال 24 ساعة. يسجّل Google استدعاءك الأول ويتجاهل الباقي، فالإجابة الأولى هي الإجابة الوحيدة. هذه هي الحقول التي يريدها، وكل حقل من حقول الأدلة يفترض أنك تعرف مسبقاً لأي مستخدم يعود الـ order.

ما تكلفة تجاهله فعلياً

على مدى معظم تاريخ Google Play، كان ردّ المبلغ الذي لا تستطيع الدفاع عنه بيعاً ضائعاً وهزّة كتفين. تغيّر ذلك. بالنسبة إلى العمليات التي تتم في 3 August, 2026 أو بعده، فإن ردّ مبلغ خاسراً يحمّل المطوّر سعر الشراء ناقص رسوم خدمة Google، إضافة إلى رسوم ردّ المبلغ من البنك. النزاع الذي لا تستطيع الإجابة عنه صار الآن بنداً في الفاتورة.

لنتتبّع order واحداً. يعترض عميل على عملية شراء بقيمة $9.99 لدى بنكه. يرسل Google Play المراجعة، ولديك 24 ساعة. إن وسمت عملية الشراء، فإنك تجد المستخدم، وترى أنه استهلك معظم ما اشتراه، وتجيب عن reviewrefund بتفضيل DECLINE وأدلة الاستهلاك، فتعطي Google قضية حقيقية للطعن في نزاع غير مشروع. إن لم تسمها، فإما أنك لا تستطيع تحديد الـ order في الوقت المناسب أو تجيب بلا شيء، فيُبتّ في النزاع دون جانبك، وعلى order بعد 3 August تدفع $9.99 ناقص رسوم Google مرتدّة، إضافة إلى رسوم ردّ مبلغ ثابتة من البنك كثيراً ما تقارب $20. على بيع صغير، قد تكون تلك الرسوم الثابتة وحدها أكبر مما صافيته.

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

كيف تضبطه دون حظر عمليات الشراء

قاعدتان تغطيان تقريباً كل خطأ ترتكبه الفرق مع هذا الحقل. جزّئ المعرّف، واضبطه في كل مكان.

جزّئ معرّف المستخدم لديك، ولا ترسل PII أبداً

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

اضبطه على كل عملية شراء، واقرأه مجدداً على خادمك

اربط المعرّف بكل تدفق فوترة، المنتجات لمرة واحدة والاشتراكات على حد سواء، بحيث لا تكون أي عملية شراء دون وسم أبداً. بعد الشراء، اقرأه مجدداً في مكانين. على العميل، يعيد Purchase.getAccountIdentifiers كائناً يمنحك getObfuscatedAccountId فيه السلسلة التي ضبطتها. على واجهتك الخلفية، يحمل سجلّ الشراء من جهة الخادم المعرّف بوصفه حقل obfuscatedExternalAccountId، ونسخة الخادم هي التي يُوثَق بها، لأن النزاع يصل إلى خادمك، لا إلى الجهاز.

استخدم setObfuscatedProfileId عندما يملك حساب واحد عدة ملفات تعريف

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

المكافئ في iOS، في سطر واحد

لدى App Store الفكرة نفسها باسم مختلف. على iOS تربط appAccountToken، وهو UUID، بعملية شراء، ويعود على المعاملة وعلى CONSUMPTION_REQUEST الذي يرسله Apple عندما يطلب عميل استرداداً. شكل المشكلة متطابق على المتجرين. يشير تدفق النزاع أو الاسترداد إلى معاملة، ومعرّفك الخاص هو ما يعيد ربطها بمستخدم يمكنك الإبلاغ عن استخدامه.

لا شيء من هذا صعب البناء. من السهل تجاهله، لأن اليوم الذي تكتب فيه كود إتمام الشراء ليس اليوم الذي يصل فيه ردّ مبلغ، وتكلفة تجاهله غير مرئية حتى ذلك الحين. يضبط RefundHalt معرّف الحساب ويتتبّعه على المتجرين، ويحفظ رابط الشراء إلى المستخدم بحيث يُحلّ أي نزاع دائماً إلى عميل حقيقي، ويجيب عن orders.reviewrefund لدى Google Play و CONSUMPTION_REQUEST لدى Apple ضمن نافذتيهما بأدلة الاستهلاك المسجّلة وقت البيع. مؤقّت الـ 24 ساعة ليس لحظة اكتشاف أنك لا تستطيع معرفة من اشترى الشيء.