كارثة واجهة برمجة التطبيقات (API) الخاصة بـ PayPal والتي استمرت لمدة 11 عامًا: كيف قمنا ببناء حلول بديلة بينما تجاهلوا المطورين

متصفحك لا يدعم وسم الفيديو.

مشاكل SDK

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

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

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

فوضى التوثيق

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

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

ثغرات أمنية

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

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

لوحة معلومات المطورين تُسجّل خروجك بعد 60 ثانية من عدم النشاط. حاول القيام بأي شيء مفيد وستجد نفسك تُكرر: تسجيل الدخول ← التحقق من الهوية ← المصادقة الثنائية ← تسجيل الخروج ← التكرار. هل تستخدم VPN؟ بالتوفيق.

يوليو 2025: القشة الأخيرة

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

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

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

لماذا لا يمكننا ببساطة إسقاط PayPal

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

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

لقد أصبحنا عالقين في دعم منصة معطلة لأن PayPal أنشأ احتكار الدفع لمستخدمين معينين.

الحل البديل للمجتمع

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

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

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

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

المشكلة الحقيقية: قوالب PayPal تبدو وكأنها عمليات احتيال

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

الموضوع: [Sandbox] TEST - New invoice from PaypalBilling434567 sandbox #A4D369E8-0001

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

تنفيذنا

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

// 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;
}

لماذا كان علينا حظر PayPal

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

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

مقياس المشكلة

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

• "فاتورة من فريق فوترة باي بال: سيتم خصم هذه الرسوم تلقائيًا من حسابك. يُرجى التواصل معنا فورًا على الرقم [PHONE]"
• "فاتورة من [COMPANY NAME] (رقم الطلب])"
• نسخ متعددة بأرقام هواتف مختلفة ومعرفات طلبات مزيفة

غالبًا ما تأتي هذه الرسائل الإلكترونية من مضيفين 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 (جميعها مُعتمدة من SPF وDKIM وDMARC). كما ارتبط الزر برابط بدا وكأنه رابط PayPal شرعي... استغرق الأمر ثانيةً لأدرك أنه بريد إلكتروني شرعي. لقد تلقيتُ للتو "فاتورة" عشوائية من مُحتال.

وأشار الباحث إلى:

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

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

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

عملية KYC العكسية من PayPal

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

كيف ينبغي أن يعمل

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

١. أكمل عملية التحقق من هوية العميل (KYC) أولاً ٢. وافق على حساب التاجر ٣. وفر وصولاً إلى واجهة برمجة التطبيقات الإنتاجية ٤. اسمح بتحصيل المدفوعات

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

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

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

١. توفير وصول فوري إلى واجهة برمجة التطبيقات الإنتاجية ٢. السماح بتحصيل المدفوعات لساعات أو أيام ٣. حظر المدفوعات فجأةً دون إشعار ٤. اطلب توثيق "اعرف عميلك" بعد تأثر العملاء بالفعل ٥. عدم إخطار التاجر ٦. السماح للعملاء باكتشاف المشكلة والإبلاغ عنها

التأثير الحقيقي في العالم

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

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

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

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

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

لماذا هذا مهم؟

يُظهر نهج باي بال للامتثال سوء فهمٍ جوهريٍّ لكيفية عمل الشركات. ينبغي أن يتمّ تطبيق إجراءات "اعرف عميلك" الصحيحة قبل دمج الإنتاج، وليس بعد بدء العملاء في الدفع. ويُظهر غياب التواصل الاستباقي عند ظهور المشاكل انفصال باي بال عن احتياجات التجار.

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

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

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

شريط

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

مجداف

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

حامل مكان مؤقت 0 كوين بيس كوميرس

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

مربع

تتضمن واجهة برمجة التطبيقات الخاصة بـ Square قائمة الاشتراك باعتبارها ميزة أساسية، وليس مجرد فكرة ثانوية.

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

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

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

ما تقدمه المعالجات الأخرى مقابل 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

شريط - تصفية حسب الحالة:

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

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

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

# You can ONLY get ONE subscription if you already know the ID
# There is NO endpoint to list all subscriptions
# There is NO way to search or filter
# You must track all subscription IDs yourself

نقاط النهاية المتاحة لـ 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-community.com 6,003,558 عضوًا، وتضمن مئات الآلاف من المنشورات وتقارير الأخطاء والشكاوى والمناقشات حول أعطال واجهة برمجة تطبيقات باي بال. ويمثل هذا أكثر من عقد من الأدلة الموثقة على مشاكل باي بال المنهجية.

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

عملية الإنقاذ من جهة خارجية

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

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

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

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

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

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

خسارة 1,899 دولارًا أمريكيًا في رسائل البريد الإلكتروني الموجهة إلى

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

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

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

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

سنكرر ذلك مرة أخرى: الخسائر الجماعية لآلاف التجار على مدى أكثر من 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. يعمل PayPal على حلها."

بعد مرور أكثر من 11 عامًا، ما زالوا "يعملون على ذلك".

اعتراف عام 2016: PayPal يكسر مجموعة أدوات التطوير البرمجية الخاصة به

في عام ٢٠١٦، وثّق مستودع GitHub الخاص بشركة PayPal تأثير فشل كبير في الالتقاط على مجموعة تطوير البرامج PHP الرسمية الخاصة بها. وكان حجم المشكلة مذهلاً:

منذ 20/9/2016، فشلت جميع محاولات التقاط بيانات باي بال مع ظهور الخطأ 'INVALID_RESOURCE_ID - لم يتم العثور على معرف المورد المطلوب'. لم يتغير شيء بين 19/9 و20/9 في تكامل واجهة برمجة التطبيقات. أعادت 100% من محاولات التقاط البيانات منذ 20/9 هذا الخطأ.

وأفاد أحد التجار:

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

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

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

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

١. أجروا تغييرات غير موثقة، مما أدى إلى تعطل حزمة تطوير البرامج الرسمية الخاصة بهم ٢. أعطّلوا حزمة تطوير البرامج الرسمية الخاصة بهم ٣. ألقوا اللوم على التجار أولاً ٤. لم يعترفوا بالخطأ إلا تحت الضغط

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

"تم ترقية SDK إلى الإصدار 1.7.4 ولا تزال المشكلة قائمة."

التصعيد في عام 2024: لا يزال مكسورًا

تُظهر التقارير الأخيرة من مجتمع باي بال المُحافظ عليه أن المشكلة قد تفاقمت. يُوثّق مناقشة سبتمبر 2024 (مؤرشفة) نفس المشاكل تمامًا:

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

يصف التاجر نفس النمط الذي واجهته خدمة إعادة توجيه البريد الإلكتروني:

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

كارثة موثوقية Webhook

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

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

لمدفوعات الاشتراك:

"لم يتم استلام ""PAYMENT.SALE.COMPLETED"" في بعض الأحيان أو حتى بعد بضع ساعات.**"

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

١. "لماذا يحدث هذا؟" - نظام ويب هوك الخاص بباي بال معطل تمامًا. ٢. "إذا كانت حالة الطلب "مكتمل"، فهل أفترض أنني استلمت المبلغ؟" - لا يمكن للتجار الوثوق باستجابات واجهة برمجة تطبيقات باي بال. ٣. "لماذا لا يمكن لـ "سجلات الأحداث -> أحداث ويب هوك" العثور على أي سجلات؟" - حتى نظام تسجيل باي بال نفسه لا يعمل.

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

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

• ٢٠١٣: "باي بال تعمل على حل المشكلة"
• ٢٠١٦: باي بال تعترف بتغيير جذري وتقدم حلاً معطلاً
• ٢٠٢٤: لا تزال الأخطاء نفسها تحدث، مما يؤثر على إعادة توجيه البريد الإلكتروني والعديد من الأخطاء الأخرى

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

١. إلقاء اللوم على التجار بسبب أخطاء باي بال ٢. إجراء تغييرات جذرية غير موثقة ٣. تقديم إصلاحات غير كافية وغير فعالة ٤. تجاهل التأثير المالي على الشركات ٥. إخفاء الأدلة من خلال إغلاق منتديات المجتمع

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

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

وهذا يفرض على كل تاجر أن:

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

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

نمط الخداع الأوسع نطاقًا لدى PayPal

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

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

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

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

دعوى العسل: إعادة كتابة الروابط التابعة

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

النمط واضح:

١. أعطال واجهة برمجة التطبيقات: إخفاء الوظائف المعطلة، وإلقاء اللوم على التجار. ٢. إسكات المجتمع: إزالة أدلة المشاكل. ٣. الانتهاكات التنظيمية: الانخراط في ممارسات خادعة. ٤. سرقة الشركات التابعة: سرقة العمولات من خلال التلاعب الفني.

تكلفة إهمال PayPal

خسارة شركة Forward Email البالغة 1,899 دولارًا أمريكيًا ليست سوى غيض من فيض. تأمل التأثير الأوسع:

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

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

كذبة التوثيق

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

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

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

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

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

النمط واضح:

١. يُبلغ المطورون عن المشكلات ٢. تُنظم باي بال جلسات تقييم مع المديرين التنفيذيين ٣. تُقدم ملاحظات شاملة ٤. تُقر الفرق بوجود ثغرات وتتعهد بـ"متابعتها ومعالجتها" ٥. لا يُنفذ أي شيء ٦. يغادر المديرون التنفيذيون إلى شركات أفضل ٧. تطلب الفرق الجديدة نفس الملاحظات ٨. تتكرر الدورة

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

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

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