لماذا يتم رفض تطبيقات الدفع المبنية بالحدس من متجر التطبيقات

يتم رفض تطبيقات الدفع المبنية بالحدس (Vibe-coded) من متجر التطبيقات بمعدل أعلى من أي شيء آخر تقريباً في طابور المراجعة، وعادة ما لا تكون للأسباب أي علاقة بجودة الكود. التطبيق المبني بالحدس — وهو التطبيق الذي بنيته من خلال وصف ما تريده لمساعد ذكاء اصطناعي وشحن ما كتبه — يمكن أن يبدو غير قابل للتمييز عن العمل الاحترافي. لا تقوم مراجعة Apple بتقييم الكود. بل تتحقق من الجهة التي قدمت التطبيق، وآلية الدفع التي تتعامل مع أي نوع من السلع، وما إذا كان قد تمت الموافقة على ميزات الأجهزة بشكل منفصل، وما إذا كان بإمكان المراجع إتمام معاملة حقيقية. هذه هي بالضبط الأشياء التي لا يستطيع مساعد الذكاء الاصطناعي إنشاؤها.

هذا هو الجدار الذي يصطدم به الجميع بعد بناء نظام POS مخصص باستخدام نموذج ذكاء اصطناعي: الكود يصبح موجوداً في فترة بعد الظهر، ولكن وضعه على جهاز iPhone كتطبيق دفع حقيقي هو عملية امتثال، وليس مهمة ترميز.

هل قام الذكاء الاصطناعي الخاص بك بتوجيه المدفوعات عبر النظام الخاطئ؟

الرفض الأكثر شيوعاً هو استخدام آلية الدفع الخاطئة للسلع التي يتم بيعها، ومساعدو الذكاء الاصطناعي بارعون بشكل غير عادي في ارتكاب هذا الخطأ. تضع إرشادات مراجعة متجر تطبيقات Apple خطاً فاصلاً صارماً. يجب أن تستخدم المحتويات والخدمات الرقمية التي يتم استهلاكها داخل التطبيق نظام الشراء داخل التطبيق من Apple بموجب الإرشاد 3.1.1. أما السلع المادية والخدمات الواقعية — مثل قهوة، أو قصة شعر، أو طلب مشحون — فيجب أن تفعل العكس بموجب الإرشاد 3.1.5(أ): لا يجوز لها استخدام الشراء داخل التطبيق على الإطلاق، وتتطلب طريقة دفع خارجية.

يعيد نموذج الترميز إنتاج أي نمط دفع هيمن على بيانات تدريبه — سواء كان كوداً جاهزاً للشراء داخل التطبيق من البرامج التعليمية للاشتراكات، أو حزمة تطوير برمجيات (SDK) للدفع عبر الويب من أمثلة التجارة الإلكترونية — دون أن يسأل عما تبيعه. اطلب منه "تطبيقاً يقبل المدفوعات" وستحصل على أحد الخيارين، بناءً على الإحصاءات بدلاً من قواعد Apple. تختلف القواعد أيضاً حسب المتجر: بعد حكم Epic لعام 2025، قد تربط التطبيقات في المتجر الأمريكي بخيارات شراء خارجية للسلع الرقمية، ولكن هذا الاستثناء ينطبق فقط في الولايات المتحدة. ولا يزال يتعين على التطبيق الموزع في جميع أنحاء العالم تلبية القاعدة الأكثر صرامة في أي مكان آخر.

هل يُسمح لك أصلاً بتقديم تطبيق دفع؟

تتوقع Apple أن يتم تقديم التطبيقات التي تتعامل مع إدارة الأموال أو الخدمات المالية من قبل المؤسسة التي تقدم هذه الخدمات بالفعل، مع الترخيص المطلوب في كل منطقة يتوفر فيها التطبيق — وهذا هو الإرشاد 3.2.1. المطور الفردي الذي يشحن تطبيق مدفوعات تم إنشاؤه بواسطة الذكاء الاصطناعي ليس مؤسسة مالية مرخصة، وكذلك الوكالة التي تقدم تطبيقاً لعميل. وتقديم التطبيق في بلد لا يتوفر فيه ترخيص نقل الأموال هو نفس الرفض ولكن بختم بريدي مختلف.

لا يقيم مراجعو Apple ما إذا كان برنامج الامتثال الخاص بك جيداً؛ بل يتحققون مما إذا كانت الجهة الصحيحة هي التي قدمت التطبيق ويرفضونه عندما لا تكون كذلك. لا يوجد أمر يمكنه إصلاح ذلك.

لماذا تعد ميزة tap-to-pay عملية موافقة منفصلة؟

يتطلب قبول البطاقات اللاتلامسية على جهاز iPhone ميزة Tap to Pay on iPhone — وهو طلب منفصل لشركة Apple، مستقل عن مراجعة التطبيق، ويُمنح لكيان قانوني وليس لكود برميجي. عادةً ما تتم الموافقة على ميزة التطوير في غضون يوم أو يومين. أما ميزة النشر فتمر عبر فريق العمليات في Apple، وتستغرق عادةً من أسبوع إلى أسبوعين، وتتطلب العمل مع مزود خدمة دفع مدعوم. سيكتب مساعد الذكاء الاصطناعي بكل سرور كود tap-to-pay دون ذكر أي من هذا؛ وإذا قدمت التطبيق قبل منح الميزة، فسيتم رفضه.

كما أن قبول البطاقات الفعلية يجر متطلبات لا تملكها Apple: أجهزة قراءة معتمدة، وقواعد EMV، ونطاق PCI لأي شيء يلمس بيانات البطاقة. لا شيء من هذا يخرج من نموذج يكتب بلغة Swift.

هل يمكن للمراجع إنهاء المعاملة فعلياً؟

يقضي الإرشاد 2.1، اكتمال التطبيق، بهدوء على تطبيقات دفع أكثر مما تفعل قواعد المدفوعات. يجب أن يكون المراجعون قادرين على تجربة التطبيق بالكامل، بما في ذلك تدفق الدفع. يتطلب تطبيق الدفع عادةً حساب تاجر، والتحقق من الهوية، وأحياناً حساباً مصرفياً — وهي أشياء لا يمكن للمراجع التسجيل فيها أثناء المراجعة. تفشل الطلبات المبنية بالحدس هنا باستمرار، لأن المطور غالباً لم يقم بتهيئة حساب تاجر حقيقي بنفسه؛ بل تم اختبار التطبيق فقط ضد بيانات وهمية أنشأها الذكاء الاصطناعي بجانبه. بدون حساب تجريبي فعال وطريقة لإجراء معاملة اختبارية، يتم رفض التطبيق لعدم اكتماله، وتكلف كل إعادة تقديم دورة مراجعة أخرى.

إذن ما الذي يتم شحنه فعلياً؟

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

بالنسبة للتاجر الذي يبيع سلعاً مادية، فإن الاستنتاج العملي أبسط: لا تدخل هذا الطابور. يحتاج عملك إلى نظام دفع فعال، وليس إلى إدراج تطبيقك الخاص في متجر التطبيقات — فالترخيص واعتماد الأجهزة وأعباء المراجعة لا تكون منطقية إلا للشركات التي تكون برمجيات المدفوعات هي منتجها الأساسي. أدر شباك البيع على منصة POS استوعبت بالفعل تلك التكاليف (تم بناء Final بهذه الطريقة تماماً — المدفوعات من خلال Final Pay مع أجهزة دفع معتمدة، ولا يوجد تطبيق خاص بك لتنشره)، وضع أموال دورة المراجعة في أشياء تزيد من الإيرادات، مثل تدفق دفع أسرع ورسوم بطاقات فعلية أقل.

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