אסון ה-API בן 11 השנים של PayPal: איך בנינו פתרונות עקיפים בזמן שהם התעלמו מהמפתחים

ב-Forward Email, אנו מתמודדים עם ה-API השבור של PayPal כבר יותר מעשור. מה שהתחיל כמתחים קטנים הפך לאסון שלם שדרש מאיתנו לבנות פתרונות עקיפים משלנו, לחסום את תבניות הפישינג שלהם, ולבסוף לעצור את כל התשלומים דרך PayPal במהלך מעבר חשבון קריטי.

זו הסיפור של 11 שנים שבהן PayPal התעלמה מצרכים בסיסיים של מפתחים בזמן שניסינו הכל כדי לגרום לפלטפורמה שלהם לעבוד.

החלק החסר: אין דרך לרשום מנויים

הנה הדבר שמדהים אותנו: לפייפאל יש חיוב מנויים מאז 2014, אבל הם מעולם לא סיפקו דרך לסוחרים לרשום את המנויים שלהם.

תחשבו על זה לרגע. אפשר ליצור מנויים, אפשר לבטל אותם אם יש לך את ה-ID, אבל אי אפשר לקבל רשימה של כל המנויים הפעילים בחשבון שלך. זה כמו שיש מסד נתונים בלי משפט SELECT.

אנחנו צריכים את זה לפעולות עסקיות בסיסיות:

• תמיכת לקוחות (כשמישהו שולח מייל ושואל על המנוי שלו)
• דיווחים פיננסיים ופיוס
• ניהול חיובים אוטומטי
• תאימות וביקורת

אבל פייפאל? הם פשוט... מעולם לא בנו את זה.

2014-2017: הבעיה מתגלה

בעיית רישום המנויים הופיעה לראשונה בפורומי הקהילה של פייפאל ב-2017. מפתחים שאלו את השאלה הברורה: "איך אני מקבל רשימה של כל המנויים שלי?"

תגובת פייפאל? שתיקה.

חברי הקהילה התחילו להתבאס:

"השמטה מאוד מוזרה אם סוחר לא יכול לרשום את כל ההסכמים הפעילים. אם מזהה ההסכם אבד, זה אומר שרק המשתמש יכול לבטל או להשעות הסכם." - leafspider

"+1. עברו כמעט 3 שנים." - laudukang (משמעות הדבר שהבעיה קיימת מאז ~2014)

הפוסט המקורי בקהילה מ-2017 מראה מפתחים שמבקשים את הפונקציונליות הבסיסית הזו. תגובת פייפאל הייתה לארכיב את המאגר שבו אנשים דיווחו על הבעיה.

2020: נתנו להם משוב נרחב

באוקטובר 2020, פייפאל פנתה אלינו למפגש משוב פורמלי. זה לא היה שיחה מקרית - הם ארגנו שיחת Microsoft Teams של 45 דקות עם 8 בכירים בפייפאל כולל Sri Shivananda (CTO), Edwin Aoki, Jim Magats, John Kunze ואחרים.

רשימת 27 הפריטים של המשוב

הגענו מוכנים. אחרי 6 שעות של ניסיון אינטגרציה עם ה-APIs שלהם, ערכנו רשימה של 27 בעיות ספציפיות. Mark Stuart מצוות PayPal Checkout אמר:

היי ניק, תודה ששיתפת את כולם היום! אני חושב שזה יהיה הקטליזטור לקבלת תמיכה והשקעה נוספת לצוות שלנו לתקן את הדברים האלה. היה קשה לקבל משוב עשיר כמו מה שהשארת לנו עד כה.

המשוב לא היה תיאורטי - הוא הגיע מניסיונות אינטגרציה אמיתיים:

1. יצירת אסימון גישה לא עובדת:

יצירת אסימון גישה לא עובדת. גם, צריכים להיות יותר מדוגמאות cURL בלבד.

2. אין ממשק ווב ליצירת מנויים:

איך לעזאזל אפשר ליצור מנויים בלי לעשות את זה עם cURL? לא נראה שיש ממשק ווב לעשות את זה (כמו שיש ל-Stripe)

Mark Stuart מצא את בעיית יצירת אסימון הגישה מדאיגה במיוחד:

בדרך כלל אנחנו לא שומעים על בעיות סביב יצירת אסימון גישה.

צוותים נכנסו לתמונה, הובטחו הבטחות

ככל שגילינו עוד בעיות, פייפאל המשיכה להוסיף צוותים לשיחה. Darshan Raju מצוות ניהול המנויים הצטרף ואמר:

מכירים בחוסר. נעקוב ונטפל בזה. תודה שוב על המשוב!

המפגש תואר כ:

סיור כן בחווייתכם

כדי:

להפוך את פייפאל למה שהיא צריכה להיות למפתחים.

התוצאה? כלום.

למרות מפגש המשוב הפורמלי, רשימת 27 הפריטים הנרחבת, מעורבות צוותים מרובה והבטחות ל:

לעקוב ולטפל

בבעיות, לא תוקן כלום.

בריחת הבכירים: איך פייפאל איבדה את כל הזיכרון המוסדי

כאן זה נהיה מעניין באמת. כל אדם שקיבל את המשוב שלנו ב-2020 עזב את פייפאל:

שינויים בהנהלה:

• דן שולמן (מנכ"ל במשך 9 שנים) → אלכס כריס (ספטמבר 2023)

• Sri Shivananda (CTO שאירגן את המשוב) → JPMorgan Chase (ינואר 2024) מנהיגים טכניים שהבטיחו, ואז עזבו:

• מרק סטיוארט (הבטיח שהמשוב יהיה "זרז") → עכשיו ב-Ripple

• ג'ים מגאץ' (ותיק פייפאל בן 18 שנה) → מנכ"ל MX (2022)

• ג'ון קונזה (סגן נשיא מוצרי צרכנים גלובליים) → פרש לגמלאות (2023)

• אדווין אוקי (אחד מהאחרונים שנותרו) → עזב עכשיו ל-Nasdaq (ינואר 2025)

פייפאל הפכה לדלת מסתובבת שבה מנהלים אוספים משוב ממפתחים, מבטיחים, ואז עוזבים לחברות טובות יותר כמו JPMorgan, Ripple וחברות פינטק אחרות.

זה מסביר מדוע התגובה לבעיה ב-GitHub ב-2025 נראתה מנותקת לחלוטין מהמשוב שלנו מ-2020 - כל מי שקיבל את המשוב הזה עזב את פייפאל.

2025: הנהגה חדשה, אותן בעיות

קדימה ל-2025, והדפוס המדויק חוזר על עצמו. אחרי שנים ללא התקדמות, ההנהגה החדשה של פייפאל פונה שוב.

המנכ"ל החדש מתערב

ב-30 ביוני 2025, העלינו ישירות למנכ"ל החדש של פייפאל, אלכס כריס. תגובתו הייתה קצרה:

היי ניק – תודה שפנית והמשוב. מישל (בהעתק) אחראית עם הצוות שלה להתעסק ולעבוד על זה איתך. תודה -א

תגובת מישל גיל

מישל גיל, סמנכ"לית בכירה ומנהלת כללית לעסקים קטנים ושירותים פיננסיים, הגיבה:

תודה רבה ניק, מעבירה את אלכס להעתק נסתר. אנחנו בודקים את זה מאז הפוסט הקודם שלך. נתקשר אליך לפני סוף השבוע. האם תוכל לשלוח לי את פרטי הקשר שלך כדי שאחד מהעמיתים שלי יוכל לפנות אליך. מישל

התגובה שלנו: לא עוד פגישות

סרבנו לפגישה נוספת, והסברנו את התסכול שלנו:

תודה. עם זאת, אני לא מרגיש ששיחה תעשה משהו. הנה למה... נכנסתי לשיחה בעבר וזה לא הוביל לשום מקום. בזבזתי יותר משעתיים מזמני בשיחה עם כל הצוות וההנהלה ולא נעשה כלום... המון מיילים הלוך ושוב. כלום לא נעשה. המשוב לא התקדם. ניסיתי במשך שנים, הקשיבו לי, ואז זה לא הוביל לשום מקום.

תגובת ההנדסה המופרזת של מרטי ברודבק

אז מרטי ברודבק, שמוביל את הנדסת הצרכנים בפייפאל, פנה אלינו:

היי ניק, זה מרטי ברודבק. אני מוביל את כל הנדסת הצרכנים כאן בפייפאל והובלתי את פיתוח ה-API של החברה. האם נוכל להתחבר ולדבר על הבעיה שאתה מתמודד איתה ואיך נוכל לעזור כאן.

כשהסברנו את הצורך הפשוט בנקודת קצה לרשימת מנויים, תגובתו חשפה את הבעיה המדויקת:

תודה ניק, אנחנו בתהליך יצירת API מנוי יחיד עם SDK מלא (תומך בטיפול שגיאות מלא, מעקב מנויים מבוסס אירועים, זמינות גבוהה) כאשר החיוב גם מפוצל כ-API נפרד לסוחרים לגשת אליו במקום לנהל בין מספר נקודות קצה לקבלת תגובה אחת.

זו בדיוק הגישה השגויה. אנחנו לא צריכים חודשים של ארכיטקטורה מורכבת. אנחנו צריכים נקודת קצה REST פשוטה אחת שמציגה מנויים - משהו שהיה צריך להיות קיים מאז 2014.

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

סתירת "CRUD פשוט"

כשהצבענו שזהו פונקציונליות CRUD בסיסית שצריכה הייתה להיות קיימת מאז 2014, תגובת מרטי הייתה משמעותית:

פעולות CRUD פשוטות הן חלק מה-API המרכזי חבר שלי, אז זה לא ייקח חודשים של פיתוח

ה-SDK של PayPal ב-TypeScript, שתומך כיום רק בשלוש נקודות קצה אחרי חודשים של פיתוח, יחד עם ציר הזמן ההיסטורי שלו, מראים בבירור שפרויקטים כאלה דורשים יותר מכמה חודשים להשלמה. תגובה זו מראה שהוא לא מבין את ה-API שלו עצמו. אם "פעולות CRUD פשוטות הן חלק מה-API המרכזי," אז איפה נקודת הקצה לרשימת המנויים? הגענו לתגובה:

אם 'פעולות CRUD פשוטות הן חלק מה-API המרכזי' אז איפה נקודת הקצה לרשימת המנויים? מפתחים מבקשים את 'פעולת CRUD הפשוטה' הזו מאז 2014. עברו 11 שנים. כל מעבד תשלומים אחר היה עם הפונקציונליות הבסיסית הזו מהיום הראשון.

הניתוק מתבהר

החלפות ההודעות מ-2025 עם אלכס כריס, מישל גיל ומארטי ברודבק מראות את אותה דיספונקציה ארגונית:

1. ההנהגה החדשה אינה מודעת למפגשי המשוב הקודמים
2. הם מציעים את אותן פתרונות מופרזים
3. הם לא מבינים את מגבלות ה-API שלהם
4. הם רוצים עוד פגישות במקום פשוט לתקן את הבעיה

תבנית זו מסבירה מדוע צוותי PayPal ב-2025 נראים מנותקים לחלוטין מהמשוב הנרחב שניתן ב-2020 - האנשים שקיבלו את המשוב הזה כבר לא שם, וההנהגה החדשה חוזרת על אותן טעויות.

שנים של דיווחי באגים שהתעלמו מהם

לא רק שהתלוננו על חוסרים בתכונות. דיווחנו באופן פעיל על באגים וניסינו לעזור להם להשתפר. הנה ציר זמן מקיף של הבעיות שתיעדנו:

2016: תלונות מוקדמות על UI/UX

אפילו כבר ב-2016, פנינו בפומבי להנהלת PayPal כולל דן שולמן לגבי בעיות בממשק ובעיות שימושיות. זה היה לפני 9 שנים, והבעיות באותו ממשק ממשיכות גם היום.

2021: דיווח על באג במייל עסקי

במרץ 2021, דיווחנו שמערכת המייל העסקית של PayPal שולחת הודעות ביטול שגויות. תבנית המייל הכילה משתנים שהוצגו בצורה שגויה, והציגה הודעות מבלבלות ללקוחות.

מרק סטיוארט אישר את הבעיה:

תודה ניק! עוברים ל-BCC. @Prasy, האם הצוות שלך אחראי על המייל הזה או יודע מי אחראי? ה-"Niftylettuce, LLC, לא נשלם לך יותר" גורם לי להאמין שיש בלבול למי ההודעה מיועדת ותוכן המייל.

תוצאה: הם באמת תיקנו את זה! מרק סטיוארט אישר:

רק שמעתי מצוות ההודעות שתבנית המייל תוקנה ופורסמה. מעריך שפנית לדווח על זה. תודה!

זה מראה שהם יכולים לתקן דברים כשרוצים - הם פשוט בוחרים לא לעשות זאת ברוב המקרים.

2021: הצעות לשיפור UI

בפברואר 2021, נתנו משוב מפורט על ממשק הלוח בקרה שלהם, במיוחד על החלק "פעילות אחרונה ב-PayPal":

אני חושב שהלוח ב-paypal.com, במיוחד "פעילות אחרונה ב-PayPal" צריך שיפור. אני לא חושב שצריך להראות את שורות הסטטוס "נוצר" של תשלום חוזר בסכום $0 - זה מוסיף המון שורות מיותרות ולא מאפשר לראות בקלות כמה הכנסה נוצרת ליום/לכמה ימים אחרונים.

מרק סטיוארט העביר את זה לצוות מוצרי הצרכנים:

תודה! אני לא בטוח איזה צוות אחראי על הפעילות, אבל העברתי את זה לראש מוצרי הצרכנים כדי למצוא את הצוות הנכון. תשלום חוזר של $0.00 נראה כמו באג. כנראה צריך לסנן אותו החוצה.

תוצאה: לא תוקן מעולם. הממשק עדיין מציג את הערכים חסרי התועלת של $0.

2021: כשלים בסביבת הסנדבוקס

בנובמבר 2021, דיווחנו על בעיות קריטיות בסביבת הסנדבוקס של PayPal:

• מפתחות API סודיים של הסנדבוקס שונו ונכנסו למצב מושבת באופן אקראי
• כל חשבונות הבדיקה בסנדבוקס נמחקו ללא הודעה
• הודעות שגיאה בעת ניסיון לצפות בפרטי חשבון סנדבוקס
• כשלים בטעינה לסירוגין

מסיבה כלשהי מפתח ה-API הסודי שלי בסנדבוקס שונה והוא הושבת. גם כל חשבונות הבדיקה הישנים שלי בסנדבוקס נמחקו.

לפעמים הם נטענים ולפעמים לא. זה מתסכל בצורה בלתי נסבלת.

תוצאה: ללא תגובה, ללא תיקון. מפתחים עדיין מתמודדים עם בעיות אמינות בסנדבוקס.

2021: מערכת הדוחות שבורה לחלוטין

במאי 2021, דיווחנו שמערכת ההורדה של PayPal לדוחות עסקאות הייתה שבורה לחלוטין:

נראה שהורדות הדוחות לא עובדות כרגע ולא עבדו כל היום. גם כנראה שצריך לקבל התראה במייל אם זה נכשל.

גם ציינו את האסון בניהול הסשנים:

גם אם אתה לא פעיל בזמן שאתה מחובר ל-PayPal במשך כ-5 דקות, אתה מתנתק. אז כשאתה מרענן את הכפתור שוב ליד הדוח שברצונך לבדוק את הסטטוס שלו (אחרי שאתה מחכה לנצח), זה מעצבן שצריך להתחבר שוב.

מרק סטיוארט אישר את בעיית תום הזמן של הסשן:

אני זוכר שדיווחת על זה בעבר עם תום הזמן של הסשן שלך לעיתים קרובות והפרעה לזרימת הפיתוח שלך כשאתה עובר בין ה-IDE שלך ל-developer.paypal.com או ללוח הבקרה של הסוחר שלך, ואז אתה חוזר ומנותק שוב.

תוצאה: תום הזמן של הסשנים עדיין 60 שניות. מערכת הדוחות עדיין נכשלת באופן קבוע.

2022: תכונת API מרכזית חסרה (שוב)

בינואר 2022, העלינו שוב את בעיית רשימת המנויים, הפעם עם פרטים נוספים על איך התיעוד שלהם שגוי:

אין GET שמציג את כל המנויים (שנקראו בעבר הסכמי חיוב)

גילינו שהתיעוד הרשמי שלהם לא מדויק בכלל:

תיעוד ה-API גם הוא לא מדויק בכלל. חשבנו שנוכל לעקוף את זה על ידי הורדת רשימה קשיחה של מזהי מנוי. אבל זה אפילו לא עובד!

מהתיעוד הרשמי כאן... כתוב שאתה יכול לעשות את זה... והנה העניין - אין שדה "מזהה מנוי" בכלל שניתן לסמן.

כריסטינה מונטי מ-PayPal הגיבה:

מתנצלים על התסכול שנגרם מהשלבים השגויים האלה, נתקן את זה השבוע.

סרי שיבננדה (CTO) הודתה לנו:

תודה על העזרה המתמשכת שלכם בשיפור שלנו. מאוד מוערך.

תוצאה: התיעוד מעולם לא תוקן. נקודת הקצה לרשימת המנויים מעולם לא נוצרה.

סיוט חוויית המפתח

לעבוד עם ה-APIs של PayPal זה כמו לחזור בזמן 10 שנים. הנה הבעיות הטכניות שתיעדנו:

ממשק משתמש שבור

לוח הבקרה של מפתחי PayPal הוא אסון. הנה מה שאנחנו מתמודדים איתו מדי יום:

בעיות SDK

• לא יכול להתמודד עם תשלומים חד-פעמיים ומנויים בו זמנית בלי פתרונות מסובכים הכוללים החלפה וטעינה מחדש של כפתורים תוך טעינת ה-SDK עם תגי סקריפט
• ה-SDK של JavaScript מפר את הקונבנציות הבסיסיות (שמות מחלקות באותיות קטנות, ללא בדיקת מופעים)
• הודעות השגיאה לא מציינות אילו שדות חסרים
• סוגי נתונים לא עקביים (דורש סכומים כמחרוזות במקום כמספרים)

הפרות מדיניות אבטחת תוכן

ה-SDK שלהם דורש unsafe-inline ו-unsafe-eval ב-CSP שלך, מה שמכריח אותך לפגוע באבטחת האתר שלך.

כאוס בתיעוד

מרק סטיוארט עצמו הודה:

מסכים שיש כמות אבסורדית של API ישנים וחדשים. ממש קשה למצוא מה לחפש (אפילו לנו שעובדים כאן).

פרצות אבטחה

היישום של 2FA ב-PayPal הפוך. אפילו עם אפליקציות TOTP מופעלות, הם מכריחים אימות SMS - מה שהופך חשבונות לפגיעים להתקפות החלפת SIM. אם יש לך TOTP מופעל, זה צריך לשמש באופן בלעדי. הגיבוי צריך להיות אימייל, לא SMS.

אסון בניהול סשנים

לוח הבקרה למפתחים שלהם מתנתק אחרי 60 שניות של חוסר פעילות. תנסה לעשות משהו פרודוקטיבי ואתה כל הזמן עובר דרך: התחברות → קפצ'ה → 2FA → התנתקות → חזרה. משתמש ב-VPN? בהצלחה.

יולי 2025: הקש האחרון

אחרי 11 שנים של אותן בעיות, נקודת השבר הגיעה במהלך העברת חשבון שגרתית. היינו צריכים לעבור לחשבון PayPal חדש שיתאים לשם החברה שלנו "Forward Email LLC" לצורך הנהלת חשבונות נקייה יותר.

מה שהיה אמור להיות פשוט הפך לאסון שלם:

• בדיקות ראשוניות הראו שהכל עובד כראוי
• שעות לאחר מכן, PayPal חסם פתאום את כל תשלומי המנויים ללא הודעה מוקדמת
• לקוחות לא יכלו לשלם, מה שיצר בלבול ועומס על התמיכה
• תמיכת PayPal נתנה תגובות סותרות שטענו שהחשבונות אומתו
• היינו חייבים להפסיק לחלוטין את תשלומי PayPal

למה אנחנו לא יכולים פשוט לוותר על PayPal

למרות כל הבעיות האלה, אנחנו לא יכולים לוותר לחלוטין על PayPal כי יש לקוחות שלפניהם PayPal היא האפשרות היחידה לתשלום. כפי שאמר לקוח אחד בדף הסטטוס שלנו:

PayPal היא האפשרות היחידה שלי לתשלום

אנחנו תקועים לתמוך בפלטפורמה שבורה כי PayPal יצרה מונופול תשלומים עבור משתמשים מסוימים.

הפתרון הקהילתי

מכיוון ש-PayPal לא מספקת פונקציונליות בסיסית להצגת מנויים, קהילת המפתחים בנתה פתרונות עקיפים. יצרנו סקריפט שעוזר לנהל מנויים ב-PayPal: set-active-pypl-subscription-ids.js

הסקריפט מתייחס לגיסט קהילתי שבו מפתחים משתפים פתרונות. משתמשים למעשה מודים לנו על מתן מה ש-PayPal הייתה צריכה לבנות לפני שנים.

חסימת תבניות PayPal בגלל פישינג

הבעיות חורגות מעבר ל-APIs. תבניות האימייל של PayPal מעוצבות כל כך גרוע שנאלצנו ליישם סינון ספציפי בשירות האימייל שלנו כי הן בלתי ניתנות להבחנה מניסיונות פישינג.

הבעיה האמיתית: תבניות PayPal נראות כמו הונאות

אנו מקבלים דיווחים באופן קבוע על אימיילים מ-PayPal שנראים בדיוק כמו ניסיונות פישינג. הנה דוגמה אמיתית מדיווחי ההתעללות שלנו:

נושא: [Sandbox] TEST - חשבונית חדשה מ-PaypalBilling434567 sandbox #A4D369E8-0001

אימייל זה הועבר ל-abuse@microsoft.com כי נראה כניסיון פישינג. הבעיה? זה היה למעשה מסביבת הסנדבוקס של PayPal, אבל עיצוב התבנית שלהם כל כך גרוע שהוא מפעיל מערכות זיהוי פישינג.

היישום שלנו

ניתן לראות את הסינון הספציפי ל-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

הטמענו זאת כי PayPal סירבה לתקן בעיות עצומות של ספאם/פישינג/הונאה למרות דיווחים חוזרים שלנו לצוותי ההתעללות שלהם. סוגי האימייל הספציפיים שאנו חוסמים כוללים:

• RT000238 - התראות חשבונית חשודות
• PPC001017 - אישורי תשלום בעייתיים
• RT000542 - ניסיונות פריצה להודעות מתנה

היקף הבעיה

יומני סינון הספאם שלנו מראים את נפח הספאם העצום של חשבוניות PayPal שאנו מעבדים מדי יום. דוגמאות לנושאים שחוסמו כוללות:

• "חשבונית מצוות החיוב של PayPal:- חיוב זה ינוכה אוטומטית מחשבונך. אנא צור קשר מיידי בטלפון [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 כל כך פגיעה שנוכלים מנצלים אותה באופן קבוע כדי לשלוח חשבוניות מזויפות שנראות לגיטימיות. חוקר אבטחה Gavin Anderegg תיעד הונאה חדשה של PayPal שבה נוכלים שולחים חשבוניות אמיתיות של PayPal שעוברות את כל בדיקות האימות:

"כשבדקתי את המקור, האימייל נראה כאילו באמת הגיע מ-PayPal (SPF, DKIM ו-DMARC כולם עברו). הכפתור גם קישר לכתובת שנראתה כמו URL לגיטימי של PayPal... לקח לי רגע להבין שזה אימייל לגיטימי. פשוט קיבלתי 'חשבונית' אקראית מנוכל."

החוקר ציין:

"נראה שזה גם תכונה נוחה ש-PayPal צריכה לשקול לחסום. מיד הנחתי שמדובר בסוג של הונאה והתעניינתי רק בפרטים הטכניים. זה נראה קל מדי לביצוע, ואני חושש שאחרים עלולים ליפול בפח."

זה ממחיש בצורה מושלמת את הבעיה: המערכות הלגיטימיות של PayPal כל כך גרועות בעיצובן שהן מאפשרות הונאה ובו בזמן גורמות לתקשורת לגיטימית להיראות חשודה.

להחמיר את המצב, זה השפיע על יכולת המסירה שלנו עם Yahoo וגרם לתלונות לקוחות ושעות של בדיקות מדוקדקות ובדיקת דפוסים.

תהליך ה-KYC ההפוך של PayPal

אחד ההיבטים המתסכלים ביותר בפלטפורמת PayPal הוא הגישה ההפוכה שלהם לציות ולנהלי Know Your Customer (KYC). בניגוד לכל מעבד תשלומים אחר, PayPal מאפשרת למפתחים לשלב את ה-APIs שלהם ולהתחיל לאסוף תשלומים בסביבת ייצור לפני השלמת אימות תקין.

איך זה אמור לעבוד

כל מעבד תשלומים לגיטימי פועל לפי הרצף הלוגי הבא:

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 יש רישום מנויים מאז שה-API שלהם הושק. התיעוד שלהם מראה בבירור כיצד לשלוף את כל המנויים עבור לקוח או חשבון סוחר. זה נחשב לפונקציונליות CRUD בסיסית.

Paddle

Paddle מספקת APIs מקיפים לניהול מנויים הכוללים רישום, סינון ודפדוף. הם מבינים שסוחרים צריכים לראות את זרמי ההכנסות החוזרות שלהם.

Coinbase Commerce

אפילו מעבדי תשלומים במטבעות קריפטוגרפיים כמו Coinbase Commerce מספקים ניהול מנויים טוב יותר מ-PayPal.

Square

ה-API של 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

# אתה יכול לקבל רק מנוי אחד אם אתה כבר יודע את ה-ID
# אין נקודת קצה לרשום את כל המנויים
# אין דרך לחפש או לסנן
# אתה חייב לעקוב אחר כל מזהי המנויים בעצמך

נקודות הקצה הזמינות של PayPal:

• POST /v1/billing/subscriptions - יצירת מנוי

• GET /v1/billing/subscriptions/{id} - קבלת מנוי אחד (אם אתה יודע את ה-ID)

• PATCH /v1/billing/subscriptions/{id} - עדכון מנוי

• POST /v1/billing/subscriptions/{id}/cancel - ביטול מנוי

• POST /v1/billing/subscriptions/{id}/suspend - השעיית מנוי מה חסר ב-PayPal:

• ❌ אין GET /v1/billing/subscriptions (רשימת כל המנויים)

• ❌ אין פונקציית חיפוש

• ❌ אין סינון לפי סטטוס, לקוח, תאריך

• ❌ אין תמיכה בעמודים (pagination)

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. יש להם היסטוריה מתועדת של:

• הסרת דיווחי באגים קריטיים מהציבור
• הפסקת כלים למפתחים ללא הודעה מוקדמת
• שינויי API ללא תיעוד נאות
• השתקת דיוני קהילה על הכשלים שלהם

הסגירה של הפורום מייצגת את הניסיון החצוף ביותר עד כה להסתיר את הכשלים השיטתיים שלהם מביקורת ציבורית.

אסון הבאג של לכידת התשלום בן 11 השנים: 1,899$ ומספרים

בעוד ש-PayPal היו עסוקים בארגון מפגשי משוב והבטחות, מערכת עיבוד התשלומים המרכזית שלהם שבורה באופן יסודי כבר למעלה מ-11 שנים. הראיות הרסניות.

ההפסד של Forward Email בסך 1,899$

במערכות הייצור שלנו גילינו 108 תשלומים ב-PayPal בסך כולל של 1,899$ שאבדו עקב כשלים בלכידת התשלום של PayPal. תשלומים אלו מציגים דפוס עקבי:

• התקבלו webhook של CHECKOUT.ORDER.APPROVED
• ה-API של לכידת התשלום של 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: PayPal שוברת את ה-SDK שלה

ב-2016, מאגר ה-GitHub של PayPal תיעד כשלונות עצומים בתפיסות שהשפיעו על ה-SDK הרשמי שלהם ל-PHP. ההיקף היה מדהים:

"מאז 20/9/2016, כל ניסיונות התפיסה של PayPal נכשלו עם 'INVALID_RESOURCE_ID - Requested resource ID was not found.'. לא שונה דבר בין 19/9 ל-20/9 באינטגרציית ה-API. 100% מניסיונות התפיסה מאז 20/9 החזירו את השגיאה הזו."

סוחר אחד דיווח:

"היו לי מעל 1,400 ניסיונות תפיסה שנכשלו ב-24 השעות האחרונות, כולם עם תגובת שגיאה INVALID_RESOURCE_ID."

תגובת PayPal הראשונית הייתה להאשים את הסוחר ולהפנות אותו לתמיכה טכנית. רק לאחר לחץ כבד הם הודו בטעות:

"יש לי עדכון ממפתחי המוצר שלנו. הם מבחינים בכותרות שנשלחות שה-PayPal-Request-ID נשלח עם 42 תווים, אבל נראה ששינוי אחרון הגביל את ה-ID הזה ל-38 תווים בלבד."

ההודאה הזו חושפת רשלנות שיטתית של PayPal:

1. הם עשו שינויים שבורים ללא תיעוד
2. הם שברו את ה-SDK הרשמי שלהם
3. הם האשימו את הסוחרים תחילה
4. הם הודו בטעות רק תחת לחץ

אפילו לאחר "תיקון" הבעיה, סוחרים דיווחו:

"שדרגתי את ה-SDK לגרסה v1.7.4 ו-הבעיה עדיין מתרחשת."

ההסלמה ב-2024: עדיין שבור

דיווחים אחרונים מהקהילה השמורה של PayPal מראים שהבעיה למעשה החמירה. דיון מספטמבר 2024 (ארכיון) מתעד את אותן בעיות בדיוק:

"הבעיה התחילה להופיע רק לפני כשבועיים ואינה משפיעה על כל ההזמנות. הנפוצה הרבה יותר נראית להיות שגיאות 404 בתפיסה."

הסוחר מתאר את אותו דפוס ש-Forward Email חווה:

"לאחר ניסיון לתפוס את ההזמנה, 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:

1. "למה זה קורה?" - מערכת ה-webhook של PayPal שבורה ביסודה
2. "אם סטטוס ההזמנה הוא 'COMPLETED', האם ניתן להניח שקיבלתי את הכסף?" - סוחרים לא יכולים לסמוך על תגובות ה-API של PayPal
3. "למה 'Event Logs->Webhook Events' לא מוצא שום לוגים?" - אפילו מערכת הלוגים של PayPal עצמה לא עובדת

דפוס הרשלנות השיטתית

הראיות מתפרשות על פני 11+ שנים ומראות דפוס ברור:

• 2013: "PayPal עובדים על זה"
• 2016: PayPal מודה בשינוי שבור, מספק תיקון שבור
• 2024: אותן שגיאות בדיוק עדיין מתרחשות, משפיעות על Forward Email ועל רבים אחרים

זו לא תקלה - זו רשלנות שיטתית. PayPal יודעת על כשלונות קריטיים בעיבוד תשלומים כבר יותר מעשור וממשיכה בעקביות:

1. האשימו סוחרים בבאגים של PayPal
2. ביצעו שינויים שבורים ללא תיעוד
3. סיפקו תיקונים לא מספקים שלא עובדים
4. התעלמו מההשפעה הכלכלית על עסקים
5. הסתרת ראיות על ידי הסרת פורומי קהילה

הדרישה הבלתי מתועדת

בשום מקום בתיעוד הרשמי של PayPal לא מציינים שסוחרים חייבים ליישם לוגיקת ניסיון חוזר עבור פעולות תפיסה. התיעוד שלהם מציין שסוחרים צריכים "לתפוס מיד לאחר אישור," אך אינו מזכיר שה-API שלהם מחזיר שגיאות 404 אקראיות שדורשות מנגנוני ניסיון חוזר מורכבים.

זה מאלץ כל סוחר:

• ליישם לוגיקת ניסיון חוזר עם התעצמות אקספוננציאלית
• להתמודד עם אספקת webhook לא עקבית
• לבנות מערכות ניהול מצב מורכבות
• לנטר תפיסות שנכשלו באופן ידני

כל מעבד תשלומים אחר מספק APIs לתפיסה אמינים שעובדים בפעם הראשונה.

דפוס ההונאה הרחב של PayPal

אסון הבאג בתפיסה הוא רק דוגמה אחת לגישה השיטתית של PayPal להטעות לקוחות ולהסתיר את הכשלים שלהם.

הפעולה של מחלקת השירותים הפיננסיים של ניו יורק

בינואר 2025, מחלקת השירותים הפיננסיים של ניו יורק הוציאה פעולת אכיפה נגד PayPal בגין פרקטיקות מטעות, המדגימה שדפוס ההונאה של PayPal מתפרש הרבה מעבר ל-APIs שלהם.

פעולה רגולטורית זו מראה את נכונות PayPal לעסוק בפרקטיקות מטעות בכל העסק שלהם, לא רק בכלי המפתחים.

תביעת Honey: שינוי קישורי שותפים

רכישת Honey על ידי PayPal הובילה לתביעות המאשימות את Honey בשינוי קישורי שותפים, גניבת עמלות מיוצרי תוכן ומשפיענים. זה מייצג צורה נוספת של הונאה שיטתית שבה PayPal מרוויחה על ידי הפניית הכנסות שצריכות להגיע לאחרים.

הדפוס ברור:

1. כשלי API: הסתרת פונקציונליות שבורה, האשמת סוחרים
2. שתיקת הקהילה: הסרת ראיות לבעיות
3. הפרות רגולטוריות: עיסוק בפרקטיקות מטעות
4. גניבת שותפים: גניבת עמלות באמצעות מניפולציה טכנית

עלות הרשלנות של PayPal

הפסד של Forward Email בסך 1,899$ מייצג רק את קצה הקרחון. שקלו את ההשפעה הרחבה:

• סוחרים בודדים: אלפים מאבדים מאות עד אלפי דולרים כל אחד
• לקוחות ארגוניים: פוטנציאל לאובדן הכנסות במיליונים
• זמן מפתחים: שעות רבות של בניית פתרונות עקיפים ל-APIs השבורים של PayPal
• אמון לקוחות: עסקים מאבדים לקוחות בגלל כשלי התשלום של PayPal

אם שירות דוא"ל קטן אחד איבד כמעט 2,000$, והבעיה קיימת כבר מעל 11 שנים ומשפיעה על אלפי סוחרים, הנזק הכלכלי הכולל ככל הנראה מסתכם במאות מיליוני דולרים.

שקר התיעוד

התיעוד הרשמי של PayPal נכשל בעקביות לציין את המגבלות הקריטיות והבאגים שהסוחרים ייתקלו בהם. לדוגמה:

• API תפיסה: אין אזכור ששגיאות 404 נפוצות ודורשות לוגיקת ניסיון חוזר
• אמינות webhook: אין אזכור ש-webhooks לעיתים מתעכבים בשעות
• רישום מנויים: התיעוד מרמז שרישום אפשרי כאשר אין נקודת קצה קיימת
• פסק זמן של סשנים: אין אזכור לפסקי זמן אגרסיביים של 60 שניות

ההסתרה השיטתית של מידע קריטי מאלצת סוחרים לגלות את מגבלות PayPal דרך ניסוי וטעייה במערכות ייצור, שלעיתים מוביל להפסדים כלכליים.

מה זה אומר למפתחים

הכישלון השיטתי של PayPal לטפל בצרכים בסיסיים של מפתחים תוך איסוף משוב נרחב מראה על בעיה ארגונית יסודית. הם מתייחסים לאיסוף משוב כתחליף לתיקון בעיות בפועל. התבנית ברורה:

1. מפתחים מדווחים על בעיות
2. PayPal מארגנת מפגשי משוב עם מנהלים בכירים
3. ניתנת משוב נרחב
4. הצוותים מכירים בפערים ומבטיחים "לעקוב ולטפל"
5. שום דבר לא מיושם
6. מנהלים בכירים עוזבים לחברות טובות יותר
7. צוותים חדשים מבקשים את אותו המשוב
8. המחזור חוזר על עצמו

בינתיים, מפתחים נאלצים לבנות פתרונות עקיפים, להתפשר על אבטחה, ולהתמודד עם ממשקי משתמש שבורים רק כדי לקבל תשלומים.

אם אתם בונים מערכת תשלום, למדו מהניסיון שלנו: בנו את הגישה המשולשת שלכם עם מספר מעבדים, אבל אל תצפו ש-PayPal תספק את הפונקציונליות הבסיסית שאתם צריכים. תכננו לבנות פתרונות עקיפים מהיום הראשון.

פוסט זה מתעד את הניסיון שלנו במשך 11 שנים עם ה-APIs של PayPal ב-Forward Email. כל דוגמאות הקוד והקישורים הם מהמערכות הייצוריות שלנו בפועל. אנו ממשיכים לתמוך בתשלומי PayPal למרות הבעיות האלה כי לחלק מהלקוחות אין אפשרות אחרת