واجهة شحن الألعاب البرمجية للموزّعين

الإجابة المختصرة

تتيح واجهة شحن الألعاب البرمجية للموزّعين إرسال العملة داخل اللعبة (UC، Diamonds، Robux، Crystals) مباشرةً إلى حساب اللاعب بإدخال معرّفه ومبلغ الشحن. وخلافًا لواجهة بطاقات الهدايا التي تسلّم رمزًا، ترسل واجهة الشحن رصيدًا إلى الحساب دون توليد رمز قابل للاسترداد. ويغيّر ذلك متطلبات التكامل — فالتحقق من معرّف اللاعب إلزامي، ومطابقة المنطقة حاسمة، ولا يوجد رمز يمكن للعميل إساءة استخدامه أو إعادة بيعه. والمزايا الأساسية في واجهة الشحن للموزّعين هي — التحقق من معرّف اللاعب، وتحديد المنطقة، وإنشاء الطلب، وحالة التسليم، والتسوية.

التعريف — واجهة شحن الألعاب البرمجية هي واجهة B2B تتيح للموزّعين تمويل حساب لاعب داخل اللعبة بعملة افتراضية عبر إدخال معرّف اللاعب واختيار باقة شحن — دون توليد رمز قابل للاسترداد. والتسليم مباشر إلى حساب اللعبة.

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

لمن هذا الدليل

هذا الدليل موجّه لـ —

• الموزّعين الذين يبيعون العملة داخل اللعبة (PUBG UC، Roblox Robux، Mobile Legends Diamonds، Genshin Crystals، إلخ) ويريدون أتمتة التسليم
• أصحاب المتاجر الإلكترونية الذين يضيفون شحن الألعاب إلى كتالوج منتجاتهم
• مطوّري بوتات Telegram الذين يبنون تسليم شحن آليًا
• المطوّرين الذين يدمجون مورّد شحن في الواجهة الخلفية لمتجر أو سوق

ما هو شحن الألعاب

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

أمثلة:

• 600 UC تُضاف إلى حساب PUBG Mobile (يُعرَّف بمعرّف اللاعب)
• 800 Robux تُضاف إلى حساب Roblox (يُعرَّف باسم المستخدم أو معرّف المستخدم)
• 500 Diamonds تُضاف إلى حساب Mobile Legends (يُعرَّف بمعرّف اللاعب + معرّف الخادم)
• 980 Genesis Crystals تُضاف إلى حساب Genshin Impact (يُعرَّف بـ UID + منطقة الخادم)

الشحن مقابل بطاقة الهدايا — ما الذي يتغيّر للموزّعين

كيف تعمل واجهة الشحن البرمجية

سير العمل الأساسي في API

1. يدخل العميل معرّف اللاعب (والخادم إن لزم)
2. يستدعي متجرك نقطة نهاية التحقق من معرّف اللاعب
3. تؤكّد API وجود معرّف اللاعب وتُعيد اسم الحساب
4. يؤكّد العميل ويدفع
5. يستدعي متجرك نقطة نهاية إنشاء الطلب بمعرّف اللاعب المتحقَّق منه
6. ترسل API العملة إلى حساب اللعبة
7. تُعيد API تأكيد التسليم
8. يُظهر متجرك التأكيد للعميل

التحقق من معرّف اللاعب

هذه هي الخطوة التي تتخطّاها معظم عمليات التكامل ثم تندم عليها. يتحقق التحقق من معرّف اللاعب من أن المعرّف الذي أدخله العميل —

• حساب حقيقي موجود
• في اللعبة والخادم الصحيحين
• مؤهّل لتلقّي الشحن (بعض الحسابات عليها قيود)

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

تُعيد نقطة نهاية التحقق عادةً الاسم المعروض للحساب. أظهره للعميل قبل الدفع — "سيُرسَل الشحن إلى — [DisplayName] — هل هذا صحيح؟"

تحديد المنطقة

تقسّم كثير من الألعاب قاعدة لاعبيها إلى خوادم إقليمية. فلاعب PUBG Mobile على خادم آسيا لديه مساحة حساب مختلفة عن لاعب على خادم أمريكا، حتى مع صيغة معرّف اللاعب نفسها.

ألعاب تتطلّب تحديد الخادم/المنطقة:

• Mobile Legends — Bang Bang (يتطلّب معرّف الخادم)
• Genshin Impact (يتطلّب الخادم — Asia، America، Europe، TW/HK/MO)
• Honkai — Star Rail (يتطلّب الخادم)
• Arena of Valor (يعتمد على الخادم)

ألعاب يكون فيها معرّف اللاعب فريدًا عالميًا:

• PUBG Mobile (معرّف اللاعب فريد عالميًا)
• Roblox (اسم المستخدم أو معرّف المستخدم فريد عالميًا)
• Free Fire (معرّف اللاعب فريد عالميًا)

المزايا الأساسية في API لموزّعي الشحن

التكامل — ما يحتاجه متجرك

متطلبات صفحة المنتج

تحتاج كل صفحة منتج شحن إلى —

• حقل إدخال معرّف اللاعب (إلزامي)
• محدِّد للخادم/المنطقة (حيثما تتطلّبه اللعبة)
• زر تحقق أو مُشغِّل تحقق فوري
• عرض اسم الحساب المُستبان قبل الدفع
• خطوة تأكيد واضحة تُظهر اسم الحساب + المبلغ

مسار السداد لعمليات الشحن

الخطوة 1: يختار العميل اللعبة ومبلغ الشحن
الخطوة 2: يدخل العميل معرّف اللاعب (والخادم إن لزم)
الخطوة 3: يستدعي متجرك نقطة نهاية التحقق
         ← أظهر الاسم المعروض للحساب للعميل
         ← إذا فشل التحقق — أظهر خطأً ولا تتابع
الخطوة 4: يؤكّد العميل ويدفع
الخطوة 5: يستدعي متجرك إنشاء الطلب
الخطوة 6: اعرض تأكيد التسليم مع طابع زمني

معالجة الأخطاء

التعامل مع الاستردادات في إعادة بيع الشحن

عمليات الشحن غير قابلة للعكس عمومًا بمجرد تلقّي حساب اللعبة للرصيد. ويغيّر ذلك نموذج الاسترداد مقارنةً ببطاقات الهدايا —

بطاقات الهدايا — إذا لم يُستخدَم الرمز، فقد يقبل المورّد مطالبة استرداد ضمن نافذة محددة.

عمليات الشحن — بمجرد إضافة الرصيد إلى الحساب، تتحكّم منصة اللعبة في العملة. ولا يستطيع المورّد عادةً عكس شحن مُسلَّم. وهذا يعني —

• مخاطر الاسترداد منخفضة جدًا عليك كموزّع — فالرصيد المُسلَّم غير قابل للعكس
• مسؤولية العميل مرتفعة — عليه تقديم معرّف اللاعب الصحيح
• يجب أن تنصّ شروط خدمتك بوضوح على أن عمليات الشحن غير قابلة للاسترداد بعد التسليم
• التحقق من معرّف اللاعب قبل الدفع هو ضابط المخاطر الأساسي

حساب الهامش لموزّعي الشحن

صيغة الهامش هي نفسها كما في بطاقات الهدايا. والفرق العملي هو أنه يمكن ضبط احتياطي الاسترداد أقل لعمليات الشحن لأن —

1. لا يوجد رمز يمكن للعميل إساءة استخدامه
2. الشحن المُسلَّم غير قابل للعكس من جانب المورّد
3. سيناريو النزاع الرئيسي (الحساب الخطأ) يُمنَع بالتحقق من المعرّف

مثال توضيحي (مثال فقط؛ ليس تسعير FoxReload):

انخفاض احتياطي الاسترداد مقارنةً ببطاقات الهدايا هو الفائدة الأساسية للهامش في إعادة بيع الشحن.

أخطاء شائعة في تكامل واجهة الشحن البرمجية

1. تخطّي التحقق من معرّف اللاعب — الخطأ الأكثر شيوعًا. تحقّق دائمًا قبل التحصيل.

2. عدم إظهار اسم الحساب المُستبان — يخطئ العملاء في كتابة المعرّفات. وإظهار الاسم هو خط الدفاع الأخير.

3. عدم معالجة الألعاب التي تتطلّب خادمًا — لـ Mobile Legends وGenshin، يؤدي معرّف خادم مفقود إلى فشل التسليم.

4. معاملة شحن فاشل على أنه مُسلَّم — إذا أعادت API حالة فشل، فلا تضع علامة اكتمال على الطلب ولا تُحصّل العميل.

5. عدم مراقبة الرصيد — يؤدي الرصيد الصفري إلى فشل كل الطلبات؛ اضبط تنبيهات أعلى بكثير من حجم طلبك المتوقع.

6. عدم توضيح عدم قابلية الاسترداد مقدمًا — انصّ بوضوح قبل الدفع على أن عمليات الشحن غير قابلة للاسترداد بمجرد التسليم. وهذا يقلّل النزاعات.

7. دمج منطق الشحن وبطاقات الهدايا — لطلبات الشحن وطلبات بطاقات الهدايا مدخلات عملاء وخطوات تحقق وسياسات استرداد مختلفة. عالجهما بشكل منفصل في شيفرتك البرمجية.

قائمة تحقق التكامل

• حدّد الألعاب التي ستعرضها (لكل منها صيغة معرّف لاعب مختلفة)
• أكّد أي الألعاب تتطلّب اختيار خادم/منطقة
• نفّذ نقطة نهاية التحقق من معرّف اللاعب لكل لعبة
• ابنِ واجهة إدخال معرّف اللاعب مع محدِّد خادم حيثما لزم
• اعرض اسم الحساب المتحقَّق منه قبل الدفع
• نفّذ إنشاء الطلب مع معالجة أخطاء لكل وضع فشل
• نفّذ استطلاع حالة الطلب للتسليم غير الفوري
• أعدّ webhooks لتأكيد التسليم
• أعدّ مراقبة الرصيد مع تنبيهات
• اكتب شروطًا للعملاء — عمليات الشحن غير قابلة للاسترداد بعد التسليم
• اختبر صيغة معرّف كل لعبة في بيئة sandbox (طول وصيغة وبادئة مختلفة)
• أجرِ اختبار حمل عند حجم الطلبات المتوقع في الذروة
• أعدّ تصدير التسوية لفريق المالية