كارثة واجهة برمجة تطبيقات PayPal التي استمرت 11 عامًا: كيف بنينا حلولًا بديلة بينما تجاهلوا المطورين

في Forward Email، كنا نتعامل مع واجهات برمجة تطبيقات PayPal المعطلة لأكثر من عقد من الزمن. ما بدأ كإحباطات بسيطة تحول إلى كارثة كاملة أجبرتنا على بناء حلول بديلة خاصة بنا، وحظر قوالب التصيد الخاصة بهم، وفي النهاية إيقاف جميع مدفوعات PayPal أثناء ترحيل حساب حرج.

هذه هي قصة 11 عامًا من تجاهل PayPal للاحتياجات الأساسية للمطورين بينما حاولنا كل شيء لجعل منصتهم تعمل.

القطعة المفقودة: لا توجد طريقة لسرد الاشتراكات

إليك الأمر الذي يذهلنا: لدى PayPal نظام فوترة الاشتراكات منذ عام 2014، لكنهم لم يوفروا أبدًا طريقة للتجار لسرد اشتراكاتهم الخاصة.

فكر في ذلك للحظة. يمكنك إنشاء الاشتراكات، يمكنك إلغاؤها إذا كان لديك المعرف، لكن لا يمكنك الحصول على قائمة بجميع الاشتراكات النشطة لحسابك. إنه مثل وجود قاعدة بيانات بدون عبارة SELECT.

نحن بحاجة إلى هذا للعمليات التجارية الأساسية:

• دعم العملاء (عندما يرسل شخص ما بريدًا إلكترونيًا يسأل عن اشتراكه)
• التقارير المالية والمصالحة
• إدارة الفوترة الآلية
• الامتثال والتدقيق

لكن PayPal؟ هم فقط... لم يبنوا ذلك أبدًا.

2014-2017: ظهور المشكلة

ظهرت مشكلة سرد الاشتراكات لأول مرة في منتديات مجتمع PayPal في عام 2017. كان المطورون يطرحون السؤال الواضح: "كيف أحصل على قائمة بجميع اشتراكاتي؟"

رد PayPal؟ لا شيء.

بدأ أعضاء المجتمع يشعرون بالإحباط:

"إغفال غريب جدًا إذا لم يتمكن التاجر من سرد جميع الاتفاقيات النشطة. إذا فقد معرف الاتفاقية فهذا يعني أن المستخدم فقط يمكنه إلغاء أو تعليق الاتفاقية." - leafspider

"+1. لقد مضى ما يقرب من 3 سنوات." - laudukang (بمعنى أن المشكلة موجودة منذ حوالي 2014)

يُظهر المنشور الأصلي في المجتمع من عام 2017 المطورين يتوسلون للحصول على هذه الوظيفة الأساسية. كان رد PayPal هو أرشفة المستودع حيث كان الناس يبلغون عن المشكلة.

2020: قدمنا لهم ملاحظات موسعة

في أكتوبر 2020، تواصل معنا PayPal لجلسة ملاحظات رسمية. لم تكن محادثة عادية - نظموا مكالمة Microsoft Teams مدتها 45 دقيقة مع 8 من التنفيذيين في PayPal بما في ذلك Sri Shivananda (المدير التقني)، Edwin Aoki، Jim Magats، John Kunze، وآخرين.

قائمة الملاحظات المكونة من 27 بندًا

كنا مستعدين. بعد 6 ساعات من محاولة التكامل مع واجهات برمجة التطبيقات الخاصة بهم، جمعنا 27 مشكلة محددة. قال مارك ستيوارت من فريق PayPal Checkout:

مرحبًا نيك، شكرًا لمشاركتك مع الجميع اليوم! أعتقد أن هذا سيكون الحافز للحصول على المزيد من الدعم والاستثمار لفريقنا للذهاب وإصلاح هذه الأمور. كان من الصعب الحصول على ملاحظات غنية مثل التي تركتها لنا حتى الآن.

لم تكن الملاحظات نظرية - بل جاءت من محاولات تكامل حقيقية:

1. توليد رمز الوصول لا يعمل:

توليد رمز الوصول لا يعمل. أيضًا، يجب أن يكون هناك أكثر من مجرد أمثلة cURL.

2. لا توجد واجهة ويب لإنشاء الاشتراكات:

كيف يمكن إنشاء الاشتراكات بدون الحاجة لاستخدام cURL؟ لا يبدو أن هناك واجهة ويب للقيام بذلك (كما هو الحال مع Stripe)

وجد مارك ستيوارت مشكلة توليد رمز الوصول مثيرة للقلق بشكل خاص:

عادة لا نسمع عن مشاكل في توليد رمز الوصول.

شاركت الفرق، وتم تقديم وعود

مع اكتشافنا المزيد من المشاكل، استمر PayPal في إضافة فرق أخرى إلى المحادثة. انضم دارشان راجو من فريق إدارة واجهة الاشتراكات وقال:

نعترف بالفجوة. سنتابع ونعالج هذا. شكرًا مرة أخرى على ملاحظاتك!

وُصفت الجلسة بأنها تسعى إلى:

جولة صريحة عبر تجربتك

لـ:

جعل PayPal كما يجب أن يكون للمطورين.

النتيجة؟ لا شيء.

على الرغم من جلسة الملاحظات الرسمية، وقائمة الـ 27 بندًا الموسعة، ومشاركة فرق متعددة، والوعود بـ:

المتابعة والمعالجة

لم يتم إصلاح أي شيء على الإطلاق.

هجرة التنفيذيين: كيف فقدت PayPal كل الذاكرة المؤسسية

هنا يصبح الأمر أكثر إثارة للاهتمام. كل شخص تلقى ملاحظاتنا في 2020 قد غادر PayPal:

تغييرات القيادة:

• دان شولمان (المدير التنفيذي لمدة 9 سنوات) → أليكس كريس (سبتمبر 2023)

• سري شيفاناندا (المدير التقني الذي نظم جلسة الملاحظات) → JPMorgan Chase (يناير 2024) القادة التقنيون الذين قطعوا وعودًا، ثم رحلوا:

• مارك ستيوارت (وعد بأن يكون التعليق "محفزًا") → الآن في Ripple

• جيم ماجاتس (محترف في بايبال لمدة 18 عامًا) → الرئيس التنفيذي لشركة MX (2022)

• جون كونزي (نائب رئيس المنتجات الاستهلاكية العالمية) → متقاعد (2023)

• إدوين آوكي (أحد القلائل المتبقين) → غادر للتو إلى ناسداك (يناير 2025)

أصبحت بايبال بابًا دوارًا حيث يجمع التنفيذيون تعليقات المطورين، يقطعون وعودًا، ثم يغادرون إلى شركات أفضل مثل JPMorgan وRipple وشركات التكنولوجيا المالية الأخرى.

هذا يفسر لماذا بدا رد قضية GitHub لعام 2025 منفصلًا تمامًا عن تعليقاتنا في 2020 - فكل من تلقى تلك التعليقات قد غادر بايبال حرفيًا.

2025: قيادة جديدة، نفس المشاكل

تقدم سريع إلى عام 2025، ونفس النمط بالضبط يظهر. بعد سنوات من عدم التقدم، تتواصل قيادة بايبال الجديدة مرة أخرى.

تدخل الرئيس التنفيذي الجديد

في 30 يونيو 2025، تصاعدنا مباشرة إلى الرئيس التنفيذي الجديد لبايبال أليكس كريس. كان رده موجزًا:

مرحبًا نيك – شكرًا لتواصلك وللتعليقات. ميشيل (مُدرجة في النسخة) مسؤولة مع فريقها عن التواصل والعمل معك في هذا الأمر. شكرًا -أ

رد ميشيل جيل

ردت ميشيل جيل، نائب الرئيس التنفيذي والمدير العام للأعمال الصغيرة والخدمات المالية:

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

ردنا: لا مزيد من الاجتماعات

رفضنا اجتماعًا آخر، موضحين إحباطنا:

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

رد مارتي برودبيك المفرط في الهندسة

ثم تواصل مارتي برودبيك، الذي يرأس هندسة المستهلك في بايبال:

مرحبًا نيك، أنا مارتي برودبيك. أنا مسؤول عن جميع هندسة المستهلك هنا في بايبال وقد كنت أقود تطوير واجهة برمجة التطبيقات للشركة. هل يمكننا التواصل لمناقشة المشكلة التي تواجهها وكيف يمكننا المساعدة هنا.

عندما شرحنا الحاجة البسيطة لنقطة نهاية لقائمة الاشتراكات، كشف رده عن المشكلة بالضبط:

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

هذا هو النهج الخاطئ تمامًا. نحن لا نحتاج إلى شهور من الهندسة المعمارية المعقدة. نحتاج إلى نقطة نهاية REST بسيطة واحدة تسرد الاشتراكات - شيء كان يجب أن يكون موجودًا منذ 2014.

GET /v1/billing/subscriptions
Authorization: Bearer {access_token}

تناقض "CRUD البسيط"

عندما أشرنا إلى أن هذه وظيفة CRUD أساسية كان يجب أن تكون موجودة منذ 2014، كان رد مارتي دالًا:

عمليات CRUD البسيطة هي جزء من واجهة برمجة التطبيقات الأساسية يا صديقي، لذا لن تستغرق شهورًا من التطوير

يوضح SDK الخاص ببايبال لـ TypeScript، الذي يدعم حاليًا ثلاث نقاط نهاية فقط بعد شهور من التطوير، إلى جانب الجدول الزمني التاريخي، بوضوح أن مثل هذه المشاريع تتطلب أكثر من بضعة أشهر لإكمالها. يُظهر هذا الرد أنه لا يفهم واجهة برمجة التطبيقات الخاصة به. إذا كانت "عمليات CRUD البسيطة جزءًا من واجهة برمجة التطبيقات الأساسية"، فأين نقطة نهاية قائمة الاشتراكات؟ لقد ردينا:

إذا كانت 'عمليات CRUD البسيطة جزءًا من واجهة برمجة التطبيقات الأساسية' فأين نقطة نهاية قائمة الاشتراكات؟ كان المطورون يطلبون هذه 'العملية البسيطة لـ CRUD' منذ عام 2014. لقد مضى 11 عامًا. كل معالج دفع آخر لديه هذه الوظيفة الأساسية منذ اليوم الأول.

يتضح الانفصال

تُظهر تبادلات عام 2025 مع أليكس كريس، وميشيل جيل، ومارتي برودبيك نفس الخلل التنظيمي:

1. القيادة الجديدة لا تعرف جلسات التغذية الراجعة السابقة
2. يقترحون نفس الحلول المعقدة المفرطة
3. لا يفهمون قيود واجهة برمجة التطبيقات الخاصة بهم
4. يريدون المزيد من الاجتماعات بدلاً من مجرد إصلاح المشكلة

هذا النمط يفسر لماذا تبدو فرق بايبال في 2025 منفصلة تمامًا عن التغذية الراجعة الواسعة المقدمة في 2020 - الأشخاص الذين تلقوا تلك التغذية الراجعة قد رحلوا، والقيادة الجديدة تكرر نفس الأخطاء.

سنوات من تقارير الأخطاء التي تجاهلوها

لم نكن نشتكي فقط من الميزات المفقودة. لقد أبلغنا بنشاط عن الأخطاء وحاولنا مساعدتهم على التحسين. إليك جدول زمني شامل للمشاكل التي وثقناها:

2016: شكاوى مبكرة حول واجهة المستخدم وتجربة المستخدم

حتى في عام 2016، كنا نتواصل علنًا مع قيادة بايبال بما في ذلك دان شولمان حول مشاكل الواجهة وقابلية الاستخدام. كان ذلك منذ 9 سنوات، ولا تزال نفس مشاكل واجهة المستخدم وتجربة المستخدم قائمة حتى اليوم.

2021: تقرير خطأ في البريد الإلكتروني للأعمال

في مارس 2021، أبلغنا أن نظام البريد الإلكتروني للأعمال في بايبال كان يرسل إشعارات إلغاء غير صحيحة. قالب البريد الإلكتروني كان يعرض المتغيرات بشكل خاطئ، مما أظهر رسائل مربكة للعملاء.

أقر مارك ستيوارت بالمشكلة:

شكرًا نيك! الانتقال إلى نسخة مخفية الوجهة (BCC). @Prasy، هل فريقك مسؤول عن هذا البريد الإلكتروني أو يعرف من المسؤول؟ "Niftylettuce, LLC، لن نقوم بالفوترة بعد الآن" يجعلني أعتقد أن هناك خلطًا في من يُوجه إليه البريد ومحتويات البريد الإلكتروني.

النتيجة: لقد أصلحوا هذا فعلاً! أكد مارك ستيوارت:

تلقيت للتو من فريق الإشعارات أن قالب البريد الإلكتروني قد تم إصلاحه ونشره. نقدر تواصلك للإبلاغ عنه. شكرًا لك!

هذا يوضح أنهم يستطيعون إصلاح الأمور عندما يريدون - لكنهم يختارون عدم القيام بذلك لمعظم المشاكل.

2021: اقتراحات تحسين واجهة المستخدم

في فبراير 2021، قدمنا ملاحظات مفصلة حول واجهة لوحة التحكم الخاصة بهم، وبالتحديد قسم "نشاط بايبال الأخير":

أعتقد أن لوحة التحكم في paypal.com، وبالتحديد "نشاط بايبال الأخير" تحتاج إلى تحسين. لا أعتقد أنه يجب عرض خطوط حالة "تم الإنشاء" للدفع المتكرر بقيمة 0 دولار - فهي تضيف الكثير من الخطوط الإضافية ولا يمكنك بسهولة رؤية مقدار الدخل المتولد لليوم/الأيام القليلة الماضية بنظرة سريعة.

حوّل مارك ستيوارت الملاحظة إلى فريق المنتجات الاستهلاكية:

شكرًا! لست متأكدًا من الفريق المسؤول عن النشاط، لكني حولتها إلى رئيس المنتجات الاستهلاكية لإيجاد الفريق الصحيح. يبدو أن الدفع المتكرر بقيمة 0.00 دولار هو خطأ. يجب تصفيته على الأرجح.

النتيجة: لم يتم إصلاحها أبدًا. لا تزال واجهة المستخدم تعرض هذه الإدخالات عديمة الفائدة بقيمة 0 دولار.

2021: فشل بيئة الصندوق الرملي

في نوفمبر 2021، أبلغنا عن مشاكل حرجة في بيئة الصندوق الرملي لبايبال:

• تم تغيير وتعطيل مفاتيح API السرية للصندوق الرملي عشوائيًا
• تم حذف جميع حسابات الاختبار في الصندوق الرملي دون إشعار
• رسائل خطأ عند محاولة عرض تفاصيل حساب الصندوق الرملي
• فشل تحميل متقطع

لسبب ما تم تغيير مفتاح API السري للصندوق الرملي وتم تعطيله. كما تم حذف جميع حسابات الاختبار القديمة في الصندوق الرملي.

أحيانًا يتم تحميلها وأحيانًا لا. هذا محبط للغاية.

النتيجة: لا رد، لا إصلاح. لا يزال المطورون يواجهون مشاكل في موثوقية الصندوق الرملي.

2021: نظام التقارير معطل تمامًا

في مايو 2021، أبلغنا أن نظام تنزيل تقارير المعاملات في PayPal كان معطلاً تمامًا:

يبدو أن تنزيلات التقارير لا تعمل الآن ولم تعمل طوال اليوم. كما يجب على الأرجح تلقي إشعار عبر البريد الإلكتروني إذا فشل الأمر.

كما أشرنا إلى كارثة إدارة الجلسة:

أيضًا إذا كنت غير نشط أثناء تسجيل الدخول إلى PayPal لمدة 5 دقائق تقريبًا، يتم تسجيل خروجك. لذا عندما تقوم بتحديث الزر بجانب التقرير الذي تريد التحقق من حالته (بعد انتظار طويل)، يكون من المزعج الاضطرار إلى تسجيل الدخول مرة أخرى.

أقر مارك ستيوارت بمشكلة انتهاء صلاحية الجلسة:

أتذكر أنك أبلغت عن ذلك في الماضي مع انتهاء صلاحية جلستك كثيرًا وتعطيل تدفق تطويرك أثناء التنقل بين IDE الخاص بك و developer.paypal.com أو لوحة تحكم التاجر، ثم تعود وتجد نفسك قد تم تسجيل خروجك مرة أخرى.

النتيجة: لا تزال مهلات انتهاء الجلسة 60 ثانية. نظام التقارير لا يزال يفشل بانتظام.

2022: ميزة أساسية في API مفقودة (مرة أخرى)

في يناير 2022، قمنا بتصعيد مشكلة قائمة الاشتراكات مرة أخرى، هذه المرة مع مزيد من التفاصيل حول كيف أن توثيقهم كان خاطئًا:

لا يوجد GET يعرض جميع الاشتراكات (المعروفة سابقًا باتفاقيات الفوترة)

اكتشفنا أن توثيقهم الرسمي كان غير دقيق تمامًا:

وثائق API أيضًا غير دقيقة تمامًا. ظننا أننا يمكننا إيجاد حل بديل عن طريق تنزيل قائمة ثابتة من معرفات الاشتراك. لكن هذا لا يعمل حتى!

من الوثائق الرسمية هنا... تقول أنه يمكنك فعل هذا... وهنا المفاجأة - لا يوجد حقل "معرف الاشتراك" على الإطلاق في أي مكان يمكن العثور عليه للتحقق منه.

ردت كريستينا مونتي من PayPal:

نعتذر عن الإحباطات التي سببتها هذه الخطوات الخاطئة، سنصلح ذلك هذا الأسبوع.

شكرنا سري شيفاناندا (المدير التقني):

شكرًا لمساعدتك المستمرة في جعلنا أفضل. نقدر ذلك كثيرًا.

النتيجة: لم يتم إصلاح التوثيق أبدًا. لم يتم إنشاء نقطة نهاية قائمة الاشتراكات أبدًا.

كابوس تجربة المطور

العمل مع واجهات برمجة تطبيقات PayPal يشبه العودة بالزمن 10 سنوات. إليك المشكلات التقنية التي وثقناها:

واجهة المستخدم المعطلة

لوحة تحكم مطوري PayPal كارثة. إليك ما نتعامل معه يوميًا:

مشاكل SDK

• لا يمكن التعامل مع المدفوعات لمرة واحدة والاشتراكات معًا بدون حلول معقدة تتضمن تبديل وإعادة عرض الأزرار أثناء إعادة تحميل SDK باستخدام وسوم السكريبت
• SDK جافا سكريبت ينتهك القواعد الأساسية (أسماء الفئات بحروف صغيرة، لا فحص للحالات)
• رسائل الخطأ لا تشير إلى الحقول المفقودة
• أنواع بيانات غير متسقة (تتطلب مبالغ كنصوص بدلاً من أرقام)

انتهاكات سياسة أمان المحتوى

يتطلب SDK الخاص بهم استخدام unsafe-inline و unsafe-eval في سياسة أمان المحتوى الخاصة بك، مما يجبرك على التضحية بأمان موقعك.

فوضى التوثيق

اعترف مارك ستيوارت بنفسه:

أتفق على أن هناك كمية هائلة من واجهات برمجة التطبيقات القديمة والجديدة. من الصعب جدًا العثور على ما تبحث عنه (حتى بالنسبة لنا الذين نعمل هنا).

ثغرات أمنية

تنفيذ بايبال للمصادقة الثنائية (2FA) معكوس. حتى مع تمكين تطبيقات TOTP، يجبرون على التحقق عبر الرسائل النصية - مما يجعل الحسابات عرضة لهجمات تبديل بطاقة SIM. إذا كان لديك TOTP مفعّل، يجب استخدامه حصريًا. يجب أن يكون البريد الإلكتروني هو الخيار الاحتياطي، وليس الرسائل النصية.

كارثة إدارة الجلسات

لوحة تحكم المطورين الخاصة بهم تقوم بتسجيل خروجك بعد 60 ثانية من عدم النشاط. حاول القيام بأي شيء منتج وستمر باستمرار عبر: تسجيل الدخول → اختبار CAPTCHA → المصادقة الثنائية → تسجيل الخروج → تكرار. تستخدم VPN؟ حظًا سعيدًا.

يوليو 2025: القشة التي قصمت ظهر البعير

بعد 11 عامًا من نفس المشاكل، وصلنا إلى نقطة الانهيار خلال ترحيل حساب روتيني. كنا بحاجة للانتقال إلى حساب بايبال جديد يتطابق مع اسم شركتنا "Forward Email LLC" لمحاسبة أنظف.

ما كان يجب أن يكون بسيطًا تحول إلى كارثة كاملة:

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

لماذا لا يمكننا التخلي عن بايبال فقط

على الرغم من كل هذه المشاكل، لا يمكننا التخلي تمامًا عن بايبال لأن بعض العملاء لا يملكون سوى بايبال كخيار للدفع. كما قال أحد العملاء على صفحة الحالة:

بايبال هو خياري الوحيد للدفع

نحن مجبرون على دعم منصة معطلة لأن بايبال أنشأت احتكارًا للدفع لبعض المستخدمين.

الحلول المجتمعية

نظرًا لأن بايبال لا يوفر وظيفة أساسية لعرض الاشتراكات، قام مجتمع المطورين ببناء حلول بديلة. أنشأنا سكربت يساعد في إدارة اشتراكات بايبال: set-active-pypl-subscription-ids.js

هذا السكربت يشير إلى مقتطف مجتمعي حيث يشارك المطورون الحلول. المستخدمون في الواقع يشكروننا على توفير ما كان يجب أن تبنيه بايبال منذ سنوات.

حظر قوالب بايبال بسبب التصيد الاحتيالي

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

المشكلة الحقيقية: قوالب بايبال تبدو كعمليات احتيال

نتلقى بانتظام تقارير عن رسائل بريد إلكتروني من بايبال تبدو تمامًا مثل محاولات التصيد الاحتيالي. إليكم مثالًا فعليًا من تقارير الإساءة لدينا:

الموضوع: [Sandbox] TEST - فاتورة جديدة من PaypalBilling434567 sandbox #A4D369E8-0001

تم إعادة توجيه هذا البريد الإلكتروني إلى abuse@microsoft.com لأنه بدا كمحاولة تصيد احتيالي. المشكلة؟ كان في الواقع من بيئة اختبار بايبال، لكن تصميم قالبهم سيء جدًا لدرجة أنه يفعّل أنظمة كشف التصيد الاحتيالي.

تنفيذنا

يمكنك رؤية التصفية الخاصة ببايبال التي نفذناها في كود تصفية البريد الإلكتروني:

// check for paypal scam (very strict until PayPal resolves phishing on their end)
// (seems to only come from "outlook.com" and "paypal.com" hosts)
//
// X-Email-Type-Id = RT000238
// PPC001017
// RT000542 = gift message hack
// RT002947 = paypal invoice spam
// <https://www.bleepingcomputer.com/news/security/beware-paypal-new-address-fraud/>
//
if (
  session.originalFromAddressRootDomain === 'paypal.com' &&
  headers.hasHeader('x-email-type-id') &&
  ['PPC001017', 'RT000238', 'RT000542', 'RT002947'].includes(
    headers.getFirst('x-email-type-id')
  )
) {
  const err = new SMTPError(
    'Due to ongoing PayPal invoice spam, you must manually send an invoice link'
  );
  err.isCodeBug = true; // alert admins for inspection
  throw err;
}

لماذا اضطررنا لحظر بايبال

نفذنا هذا لأن بايبال رفضت إصلاح مشاكل ضخمة في الرسائل المزعجة/التصيد الاحتيالي/الاحتيال رغم تقاريرنا المتكررة إلى فرق الإساءة لديهم. أنواع الرسائل التي نحظرها تشمل:

• RT000238 - إشعارات فواتير مشبوهة
• PPC001017 - تأكيدات دفع إشكالية
• RT000542 - محاولات اختراق رسائل الهدايا

حجم المشكلة

تُظهر سجلات تصفية الرسائل المزعجة لدينا الحجم الهائل لرسائل فواتير بايبال المزعجة التي نعالجها يوميًا. أمثلة على المواضيع المحظورة تشمل:

• "فاتورة من فريق فواتير بايبال:- سيتم خصم هذه الرسوم تلقائيًا من حسابك. يرجى الاتصال بنا فورًا على [PHONE]"
• "فاتورة من [COMPANY NAME] ([ORDER-ID])"
• عدة تنويعات بأرقام هواتف مختلفة وأرقام طلبات مزيفة غالبًا ما تأتي هذه الرسائل الإلكترونية من مضيفي outlook.com لكنها تبدو وكأنها صادرة من أنظمة PayPal الشرعية، مما يجعلها خطيرة بشكل خاص. تمر الرسائل الإلكترونية باختبارات التوثيق SPF وDKIM وDMARC لأنها تُرسل عبر بنية PayPal التحتية الفعلية.

تُظهر سجلاتنا التقنية أن هذه الرسائل المزعجة تحتوي على رؤوس شرعية من PayPal:

• X-Email-Type-Id: RT000238 (نفس المعرف الذي نقوم بحظره)
• From: "service@paypal.com" <service@paypal.com>
• توقيعات DKIM صالحة من paypal.com
• سجلات SPF صحيحة تُظهر خوادم بريد PayPal

هذا يخلق وضعًا مستحيلاً: رسائل PayPal الشرعية والرسائل المزعجة لها نفس الخصائص التقنية.

السخرية

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

هذا موثق في أبحاث أمنية: احذر من احتيال العنوان الجديد في PayPal - يوضح كيف يتم استغلال أنظمة PayPal نفسها في الاحتيال.

التأثير الواقعي: احتيالات PayPal الجديدة

تتجاوز المشكلة مجرد تصميم القوالب السيء. نظام فواتير PayPal سهل الاستغلال لدرجة أن المحتالين يستغلونه بانتظام لإرسال فواتير احتيالية تبدو شرعية. وثق الباحث الأمني غافين أندريغ احتيال PayPal جديد حيث يرسل المحتالون فواتير PayPal حقيقية تمر بجميع اختبارات التوثيق:

"عند فحص المصدر، بدا البريد الإلكتروني وكأنه صادر فعلاً من PayPal (تم اجتياز SPF وDKIM وDMARC جميعها). كما أن الزر كان مرتبطًا بما بدا عنوان URL شرعي لـ PayPal... استغرق الأمر ثانية لأدرك أنه بريد شرعي. لقد تم إرسال 'فاتورة' عشوائية لي من محتال."

لاحظ الباحث:

"يبدو أيضًا أنها ميزة راحة يجب على PayPal التفكير في تأمينها. افترضت فورًا أن هذا نوع من الاحتيال وكنت مهتمًا فقط بالتفاصيل التقنية. يبدو الأمر سهلاً جدًا للتنفيذ، وأخشى أن يقع الآخرون ضحية له."

هذا يوضح المشكلة تمامًا: أنظمة PayPal الشرعية مصممة بشكل سيء لدرجة أنها تمكّن الاحتيال وفي الوقت نفسه تجعل الاتصالات الشرعية تبدو مشبوهة.

ولزيادة الطين بلة، أثر هذا على قابلية التسليم لدينا مع Yahoo مما أدى إلى شكاوى العملاء وساعات من الاختبارات الدقيقة وفحص الأنماط.

عملية التحقق من هوية العملاء العكسية في PayPal

واحدة من أكثر الجوانب إحباطًا في منصة PayPal هي نهجها العكسي في الامتثال وإجراءات "اعرف عميلك" (KYC). على عكس جميع معالجات الدفع الأخرى، يسمح PayPal للمطورين بدمج واجهات برمجة التطبيقات الخاصة بهم وبدء جمع المدفوعات في بيئة الإنتاج قبل إكمال التحقق الصحيح.

كيف يجب أن تعمل

يتبع كل معالج دفع شرعي التسلسل المنطقي التالي:

1. إكمال التحقق من KYC أولاً
2. الموافقة على حساب التاجر
3. توفير وصول API للإنتاج
4. السماح بجمع المدفوعات

هذا يحمي كل من معالج الدفع والتاجر من خلال ضمان الامتثال قبل تبادل أي أموال.

كيف يعمل PayPal فعليًا

عملية PayPal عكس ذلك تمامًا:

1. توفير وصول API للإنتاج فورًا
2. السماح بجمع المدفوعات لساعات أو أيام
3. حظر المدفوعات فجأة دون إشعار
4. المطالبة بوثائق KYC بعد تأثر العملاء
5. عدم تقديم أي إشعار للتاجر
6. ترك العملاء لاكتشاف المشكلة والإبلاغ عنها

التأثير الواقعي

تؤدي هذه العملية العكسية إلى كوارث للشركات:

• لا يمكن للعملاء إتمام عمليات الشراء خلال فترات الذروة في المبيعات
• لا يوجد تحذير مسبق بأن التحقق مطلوب
• لا توجد إشعارات بريد إلكتروني عند حظر المدفوعات
• يتعرف التجار على المشاكل من العملاء المرتبكين
• خسارة في الإيرادات خلال فترات الأعمال الحرجة
• تضرر ثقة العملاء عندما تفشل المدفوعات بشكل غامض

كارثة ترحيل الحسابات في يوليو 2025

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

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

لماذا هذا مهم

تُظهر طريقة PayPal في الامتثال سوء فهم أساسي لكيفية عمل الشركات. يجب أن يتم التحقق من هوية العميل (KYC) بشكل صحيح قبل دمج الإنتاج، وليس بعد أن يبدأ العملاء بمحاولة الدفع. يوضح نقص التواصل الاستباقي عند ظهور المشاكل انفصال PayPal عن احتياجات التجار.

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

كيف يفعلها كل معالج دفع آخر بشكل صحيح

وظيفة عرض الاشتراكات التي يرفض PayPal تنفيذها كانت معيارًا في الصناعة لأكثر من عقد. إليك كيف يتعامل معالجو الدفع الآخرون مع هذا المتطلب الأساسي:

Stripe

كان لدى Stripe عرض الاشتراكات منذ إطلاق واجهة برمجة التطبيقات الخاصة بهم. توضح وثائقهم بوضوح كيفية استرجاع جميع الاشتراكات لعميل أو حساب تاجر. يُعتبر هذا وظيفة CRUD أساسية.

Paddle

يوفر Paddle واجهات برمجة تطبيقات شاملة لإدارة الاشتراكات تشمل العرض، التصفية، والتقسيم إلى صفحات. هم يفهمون أن التجار بحاجة لرؤية تدفقات إيراداتهم المتكررة.

Coinbase Commerce

حتى معالجو الدفع بالعملات المشفرة مثل Coinbase Commerce يقدمون إدارة اشتراكات أفضل من PayPal.

Square

تتضمن واجهة برمجة تطبيقات Square عرض الاشتراكات كميزة أساسية، وليست فكرة لاحقة.

المعيار الصناعي

يوفر كل معالج دفع حديث:

• عرض جميع الاشتراكات
• التصفية حسب الحالة، التاريخ، العميل
• التقسيم إلى صفحات لمجموعات البيانات الكبيرة
• إشعارات webhook لتغييرات الاشتراك
• وثائق شاملة مع أمثلة عملية

ما يقدمه المعالجون الآخرون مقابل PayPal

Stripe - عرض جميع الاشتراكات:

GET https://api.stripe.com/v1/subscriptions
Authorization: Bearer sk_test_...

Response:
{
  "object": "list",
  "data": [
    {
      "id": "sub_1MowQVLkdIwHu7ixeRlqHVzs",
      "object": "subscription",
      "status": "active",
      "customer": "cus_Na6dX7aXxi11N4",
      "current_period_start": 1679609767,
      "current_period_end": 1682288167
    }
  ],
  "has_more": false
}

Stripe - التصفية حسب العميل:

GET https://api.stripe.com/v1/subscriptions?customer=cus_Na6dX7aXxi11N4

Stripe - التصفية حسب الحالة:

GET https://api.stripe.com/v1/subscriptions?status=active

PayPal - ما تحصل عليه فعليًا:

GET https://api.paypal.com/v1/billing/subscriptions/{id}
Authorization: Bearer access_token

# يمكنك الحصول على اشتراك واحد فقط إذا كنت تعرف المعرف مسبقًا
# لا يوجد نقطة نهاية لعرض جميع الاشتراكات
# لا توجد طريقة للبحث أو التصفية
# يجب عليك تتبع جميع معرفات الاشتراك بنفسك

نقاط النهاية المتاحة في PayPal:

• POST /v1/billing/subscriptions - إنشاء اشتراك

• GET /v1/billing/subscriptions/{id} - الحصول على اشتراك واحد (إذا كنت تعرف المعرف)

• PATCH /v1/billing/subscriptions/{id} - تحديث اشتراك

• POST /v1/billing/subscriptions/{id}/cancel - إلغاء الاشتراك

• POST /v1/billing/subscriptions/{id}/suspend - تعليق الاشتراك ما ينقص PayPal:

• ❌ لا يوجد GET /v1/billing/subscriptions (قائمة الكل)

• ❌ لا توجد وظيفة بحث

• ❌ لا يوجد تصفية حسب الحالة، العميل، التاريخ

• ❌ لا يوجد دعم للتقسيم إلى صفحات

PayPal هو المعالج الوحيد الرئيسي للمدفوعات الذي يجبر المطورين على تتبع معرفات الاشتراك يدويًا في قواعد بياناتهم الخاصة.

التغطية المنهجية لـ PayPal: إسكات 6 ملايين صوت

في خطوة تجسد تمامًا نهج PayPal في التعامل مع النقد، قاموا مؤخرًا بإيقاف منتدى مجتمعهم بالكامل، مما أدى إلى إسكات أكثر من 6 ملايين عضو ومحو مئات الآلاف من المشاركات التي توثق إخفاقاتهم.

المحو الكبير

كان مجتمع PayPal الأصلي على paypal-community.com يضم 6,003,558 عضوًا ويحتوي على مئات الآلاف من المشاركات، تقارير الأخطاء، الشكاوى، والنقاشات حول إخفاقات API الخاصة بـ PayPal. وكان هذا يمثل أكثر من عقد من الأدلة الموثقة على مشاكل PayPal المنهجية.

في 30 يونيو 2025، أوقف PayPal المنتدى بالكامل بهدوء. جميع روابط paypal-community.com الآن تعيد أخطاء 404. لم يكن هذا ترحيلًا أو ترقية.

الإنقاذ من طرف ثالث

لحسن الحظ، خدمة طرف ثالث على ppl.lithium.com حفظت بعض المحتوى، مما يتيح لنا الوصول إلى النقاشات التي حاول PayPal إخفاءها. ومع ذلك، فإن هذا الحفظ من الطرف الثالث غير مكتمل وقد يختفي في أي وقت.

هذا النمط من إخفاء الأدلة ليس جديدًا على PayPal. لديهم تاريخ موثق من:

• إزالة تقارير الأخطاء الحرجة من العرض العام
• إيقاف أدوات المطورين دون إشعار
• تغيير واجهات برمجة التطبيقات بدون توثيق مناسب
• إسكات نقاشات المجتمع حول إخفاقاتهم

تمثل إزالة المنتدى المحاولة الأكثر وقاحة حتى الآن لإخفاء إخفاقاتهم المنهجية عن التدقيق العام.

كارثة خطأ الالتقاط التي استمرت 11 عامًا: 1,899 دولار وما زالت تتزايد

بينما كان PayPal مشغولًا بتنظيم جلسات التغذية الراجعة وتقديم الوعود، كان نظام معالجة المدفوعات الأساسي لديهم معطلاً بشكل جذري لأكثر من 11 عامًا. الأدلة مدمرة.

خسارة Forward Email بقيمة 1,899 دولار

في أنظمتنا الإنتاجية، اكتشفنا 108 مدفوعات PayPal بإجمالي 1,899 دولار فقدت بسبب إخفاقات الالتقاط في PayPal. تظهر هذه المدفوعات نمطًا ثابتًا:

• تم استلام webhooks لـ CHECKOUT.ORDER.APPROVED
• أعادت واجهة التقاط PayPal أخطاء 404
• أصبحت الطلبات غير قابلة للوصول عبر API الخاص بـ PayPal

من المستحيل تحديد ما إذا تم تحصيل الرسوم من العملاء لأن PayPal يخفي تمامًا سجلات التصحيح بعد 14 يومًا ويمحو جميع البيانات من لوحة التحكم للطلبات التي لم يتم التقاطها.

هذا يمثل عملًا واحدًا فقط. الخسائر الجماعية عبر آلاف التجار على مدى أكثر من 11 عامًا من المحتمل أن تصل إلى ملايين الدولارات.

سنكررها مرة أخرى: الخسائر الجماعية عبر آلاف التجار على مدى أكثر من 11 عامًا من المحتمل أن تصل إلى ملايين الدولارات.

السبب الوحيد لاكتشافنا هذا هو أننا دقيقون للغاية ونعتمد على البيانات.

التقرير الأصلي لعام 2013: أكثر من 11 عامًا من الإهمال

أقدم تقرير موثق لهذه المشكلة بالذات يظهر على Stack Overflow في نوفمبر 2013 (الأرشيف):

"استمرار تلقي خطأ 404 مع REST API عند إجراء الالتقاط"

الخطأ المبلغ عنه في 2013 هو مطابق لما واجهته Forward Email في 2024:

{
  "name": "INVALID_RESOURCE_ID",
  "message": "The requested resource ID was not found",
  "information_link": "https://developer.paypal.com/webapps/developer/docs/api/#INVALID_RESOURCE_ID",
  "debug_id": "e56bae98dcc26"
}

كان رد المجتمع في 2013 دالًا:

"هناك مشكلة معلنة في الوقت الحالي مع REST API. PayPal يعملون على حلها." بعد أكثر من 11 عامًا، ما زالوا "يعملون على ذلك."

اعتراف 2016: بايبال تكسر SDK الخاص بها

في عام 2016، وثّق مستودع بايبال الرسمي على GitHub فشلًا هائلًا في عمليات الالتقاط يؤثر على SDK الرسمي الخاص بـ PHP. كان الحجم مذهلاً:

"منذ 20/9/2016، جميع محاولات الالتقاط في بايبال تفشل مع الخطأ 'INVALID_RESOURCE_ID - Requested resource ID was not found.'. لم يتم تغيير أي شيء بين 19/9 و20/9 في تكامل API. 100% من محاولات الالتقاط منذ 20/9 أعادت هذا الخطأ."

أبلغ أحد التجار:

"لقد كان لدي أكثر من 1400 محاولة التقاط فاشلة خلال الـ 24 ساعة الماضية، جميعها مع استجابة خطأ INVALID_RESOURCE_ID."

كان رد بايبال الأولي هو لوم التاجر وتحويله إلى الدعم الفني. فقط بعد ضغط هائل اعترفوا بالخطأ:

"لدي تحديث من مطوري المنتج لدينا. يلاحظون في الرؤوس المرسلة أن PayPal-Request-ID يُرسل بـ 42 حرفًا، لكن يبدو أن تغييرًا حديثًا حدث يحد هذا المعرف إلى 38 حرفًا فقط."

يكشف هذا الاعتراف عن إهمال منهجي من بايبال:

1. أجروا تغييرات مدمرة غير موثقة
2. كسروا SDK الرسمي الخاص بهم
3. لَوَّموا التجار أولاً
4. اعترفوا بالخطأ فقط تحت الضغط

حتى بعد "إصلاح" المشكلة، أبلغ التجار:

"تم ترقية SDK إلى الإصدار v1.7.4 والمشكلة لا تزال تحدث."

التصعيد في 2024: ما زالت المشكلة قائمة

تقارير حديثة من مجتمع بايبال المحفوظ تظهر أن المشكلة قد ازدادت سوءًا. توثق مناقشة سبتمبر 2024 (محفوظة) نفس المشكلات بالضبط:

"بدأت المشكلة بالظهور منذ حوالي أسبوعين ولا تؤثر على جميع الطلبات. الأكثر شيوعًا هو ظهور خطأ 404 عند الالتقاط."

يصف التاجر نفس النمط الذي واجهته Forward Email:

"بعد محاولة التقاط الطلب، يعيد بايبال خطأ 404. عند استرجاع تفاصيل الطلب: {'id': 'ID', 'intent': 'CAPTURE', 'status': 'COMPLETED', ..., 'final_capture': true, ...} وهذا بدون أي أثر لالتقاط ناجح من جانبنا."

كارثة موثوقية الويب هوك

تكشف مناقشة أخرى محفوظة في المجتمع أن نظام الويب هوك في بايبال غير موثوق بشكل أساسي:

"نظريًا، يجب أن يكون هناك حدثان (CHECKOUT.ORDER.APPROVED و PAYMENT.CAPTURE.COMPLETED) من أحداث الويب هوك. في الواقع، نادراً ما يتم استقبال هذين الحدثين فورًا، وغالبًا لا يتم استقبال PAYMENT.CAPTURE.COMPLETED أو يتم استقباله بعد عدة ساعات."

بالنسبة لمدفوعات الاشتراك:

"'PAYMENT.SALE.COMPLETED' لم يتم استقباله أحيانًا أو حتى بعد عدة ساعات."

تكشف أسئلة التاجر عمق مشاكل الموثوقية في بايبال:

1. "لماذا يحدث هذا؟" - نظام الويب هوك في بايبال معطل بشكل جوهري
2. "إذا كانت حالة الطلب 'COMPLETED'، هل يمكنني اعتبار أنني استلمت المال؟" - لا يمكن للتجار الوثوق في ردود API الخاصة ببايبال
3. "لماذا لا يمكن العثور على أي سجلات في 'Event Logs->Webhook Events'؟" - حتى نظام تسجيل الأحداث الخاص ببايبال لا يعمل

نمط الإهمال المنهجي

تمتد الأدلة لأكثر من 11 عامًا وتظهر نمطًا واضحًا:

• 2013: "بايبال يعملون على ذلك"
• 2016: بايبال تعترف بتغيير مدمّر، وتوفر إصلاحًا معطوبًا
• 2024: نفس الأخطاء بالضبط لا تزال تحدث، تؤثر على Forward Email والعديد غيرها

هذه ليست مجرد أخطاء - هذا إهمال منهجي. بايبال تعرف عن هذه الإخفاقات الحرجة في معالجة المدفوعات لأكثر من عقد من الزمن وكانت باستمرار:

1. لوموا التجار على أخطاء PayPal
2. أجروا تغييرات كسر غير موثقة
3. قدموا إصلاحات غير كافية لا تعمل
4. تجاهلوا التأثير المالي على الأعمال
5. أخفوا الأدلة عن طريق إغلاق منتديات المجتمع

المتطلب غير الموثق

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

هذا يجبر كل تاجر على:

• تنفيذ منطق إعادة المحاولة بتراجع أُسّي
• التعامل مع تسليم ويب هوك غير المتسق
• بناء أنظمة إدارة حالة معقدة
• مراقبة الالتقاطات الفاشلة يدويًا

كل معالجات الدفع الأخرى توفر واجهات برمجة تطبيقات الالتقاط الموثوقة التي تعمل من المحاولة الأولى.

نمط الخداع الأوسع لـ PayPal

كارثة خطأ الالتقاط هي مجرد مثال واحد على النهج المنهجي لـ PayPal في خداع العملاء وإخفاء إخفاقاتهم.

إجراء دائرة الخدمات المالية في نيويورك

في يناير 2025، أصدرت دائرة الخدمات المالية في نيويورك إجراء إنفاذ ضد PayPal بسبب ممارسات خادعة، مما يوضح أن نمط الخداع لدى PayPal يمتد إلى ما هو أبعد من واجهات برمجة التطبيقات الخاصة بهم.

يُظهر هذا الإجراء التنظيمي استعداد PayPal للانخراط في ممارسات خادعة عبر كامل أعمالهم، وليس فقط أدوات المطورين الخاصة بهم.

دعوى Honey: إعادة كتابة روابط الأفلييت

أدى استحواذ PayPal على Honey إلى دعاوى قضائية تزعم أن Honey تعيد كتابة روابط الأفلييت، مما يسرق العمولات من منشئي المحتوى والمؤثرين. وهذا يمثل شكلًا آخر من أشكال الخداع المنهجي حيث يربح PayPal من خلال إعادة توجيه الإيرادات التي يجب أن تذهب للآخرين.

النمط واضح:

1. فشل واجهة برمجة التطبيقات: إخفاء الوظائف المعطلة، لوم التجار
2. إسكات المجتمع: إزالة الأدلة على المشاكل
3. انتهاكات تنظيمية: الانخراط في ممارسات خادعة
4. سرقة الأفلييت: سرقة العمولات عبر التلاعب التقني

تكلفة إهمال PayPal

خسارة Forward Email البالغة 1,899 دولار تمثل مجرد قمة الجليد. فكر في التأثير الأوسع:

• التجار الأفراد: آلاف يخسرون مئات إلى آلاف الدولارات لكل منهم
• عملاء المؤسسات: ملايين محتملة من الإيرادات المفقودة
• وقت المطورين: ساعات لا تحصى في بناء حلول بديلة لواجهات برمجة التطبيقات المعطلة لـ PayPal
• ثقة العملاء: خسارة الأعمال لعملائهم بسبب فشل مدفوعات PayPal

إذا فقدت خدمة بريد إلكتروني صغيرة ما يقرب من 2,000 دولار، وهذه المشكلة موجودة لأكثر من 11 عامًا وتؤثر على آلاف التجار، فمن المحتمل أن يبلغ الضرر المالي الجماعي مئات الملايين من الدولارات.

كذبة الوثائق

تفشل وثائق PayPal الرسمية باستمرار في ذكر القيود والأخطاء الحرجة التي سيواجهها التجار. على سبيل المثال:

• واجهة برمجة تطبيقات الالتقاط: لا ذكر لأن أخطاء 404 شائعة وتتطلب منطق إعادة المحاولة
• موثوقية الويب هوك: لا ذكر لأن الويب هوك غالبًا ما يتأخر لساعات
• قائمة الاشتراكات: الوثائق توحي بإمكانية القائمة بينما لا يوجد نقطة نهاية
• انتهاء صلاحية الجلسة: لا ذكر لانتهاء صلاحية صارم خلال 60 ثانية

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

ماذا يعني هذا للمطورين

فشل PayPal المنهجي في تلبية احتياجات المطورين الأساسية أثناء جمع ملاحظات واسعة يظهر مشكلة تنظيمية جوهرية. فهم يعاملون جمع الملاحظات كبديل عن إصلاح المشكلات فعليًا. النمط واضح:

1. يقوم المطورون بالإبلاغ عن المشاكل
2. تنظم PayPal جلسات تغذية راجعة مع التنفيذيين
3. يتم تقديم تغذية راجعة واسعة النطاق
4. تعترف الفرق بالفجوات وتعد بـ "المتابعة والمعالجة"
5. لا يتم تنفيذ أي شيء
6. يغادر التنفيذيون إلى شركات أفضل
7. تطلب الفرق الجديدة نفس التغذية الراجعة
8. تتكرر الدورة

في هذه الأثناء، يُجبر المطورون على بناء حلول بديلة، والتنازل عن الأمان، والتعامل مع واجهات مستخدم معطلة فقط لقبول المدفوعات.

إذا كنت تبني نظام دفع، تعلم من تجربتنا: ابنِ نهج الثلاثية الخاص بك مع عدة معالجات، لكن لا تتوقع من PayPal توفير الوظائف الأساسية التي تحتاجها. خطط لبناء حلول بديلة من اليوم الأول.

توثق هذه التدوينة تجربتنا التي استمرت 11 عامًا مع واجهات برمجة تطبيقات PayPal في Forward Email. جميع أمثلة الشيفرة والروابط مأخوذة من أنظمتنا الإنتاجية الفعلية. نواصل دعم مدفوعات PayPal رغم هذه المشاكل لأن بعض العملاء لا يملكون خيارًا آخر