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

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

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

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

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

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

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

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

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

2014-2017: הבעיה צצה

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

התגובה של פייפאל? צרצרים.

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

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

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

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

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

באוקטובר 2020, פייפאל פנתה אלינו לפגישת משוב רשמית. זו לא הייתה שיחה אגבית - הם ארגנו שיחת Microsoft Teams בת 45 דקות עם 8 מנהלים בפייפאל, ביניהם סרי שיבננדה (מנהל טכנולוגיות ראשי), אדווין אאוקי, ג'ים מגאטס, ג'ון קונזה ואחרים.

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

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

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

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

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

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

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

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

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

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

צוותים התערבו, הבטחות ניתנו

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

הכר בפער. נעקוב ונטפל בזה. תודה שוב על המשוב שלך!

הפגישה תוארה כמבקשת:

סיור גלוי של החוויה שלך

אֶל:

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

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

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

מעקב וכתובת

בעיות, שום דבר לא תוקן.

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

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

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

• דן שולמן (מנכ"ל במשך 9 שנים) → אלכס כריס (ספטמבר 2023)
• סרי שיבננדה (מנהל טכנולוגי ראשי שארגן את המשוב) → ג'יי.פי מורגן צ'ייס (ינואר 2024)

מנהיגים טכנולוגיים שהבטיחו הבטחות, ואז עזבו:

• מארק סטיוארט (המשוב שהובטח יהיה "זרז") → עכשיו בריפל
• ג'ים מגאטס (18 שנות ניסיון בפייפאל) → מנכ"ל MX (2022)
• ג'ון קונזה (סמנכ"ל מוצר צריכה גלובלי) → בְּדִימוּס (2023)
• אדווין אאוקי (אחד האחרונים שנותרו) → בדיוק יצאתי לנאסד"ק (ינואר 2025)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

הניתוק מתבהר

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

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

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

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

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

2016: תלונות מוקדמות על ממשק משתמש/חוויית משתמש

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

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

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

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

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

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

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

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

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

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

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

כריסטינה מונטי מפייפאל הגיבה:

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

שרי שיווננדה (מנהל טכנולוגי ראשי) הודה לנו:

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

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

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

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

ממשק משתמש פגום

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

בעיות ב-SDK של

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

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

ערכת הפיתוח (SDK) שלהם דורשת גישה לא בטוחה (unsafe-inline) וגישה לא בטוחה (unsafe-eval) בספק שירותי התקשורת (CSP) שלכם, מה שמאלץ אתכם לסכן את אבטחת האתר שלכם.

כאוס תיעוד

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

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

פגיעויות אבטחה

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

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

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

יולי 2025: הקש ששבר את גב הגמל

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

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

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

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

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

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

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

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

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

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

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

הבעיות חורגות מעבר ל-API. תבניות הדוא"ל של 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

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

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

היקף הבעיה

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

• "חשבונית מצוות החיוב של PayPal:- חיוב זה יחויב אוטומטית מחשבונך. אנא צור איתנו קשר מיד בטלפון [טלפון]"
• "חשבונית מ- [שם החברה] ([מזהה הזמנה])"
• וריאציות מרובות עם מספרי טלפון שונים ומזהי הזמנה מזויפים

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

החוקר ציין:

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

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

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

תהליך KYC לאחור של PayPal

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

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

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

1. יש להשלים תחילה אימות KYC
2. לאשר את חשבון הסוחר
3. לספק גישה ל-API הייצור
4. לאפשר גביית תשלומים

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

איך PayPal עובד בפועל

התהליך של פייפאל הפוך לחלוטין:

1. מתן גישה מיידית ל-API של הייצור
2. אפשר גביית תשלומים במשך שעות או ימים
3. חסימת תשלומים פתאומית ללא הודעה מוקדמת
4. דרוש תיעוד KYC לאחר שהלקוחות כבר מושפעים
5. לא לספק הודעה לסוחר
6. אפשר ללקוחות לגלות את הבעיה ולדווח עליה

ההשפעה על העולם האמיתי

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

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

אסון העברת החשבונות ביולי 2025

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

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

למה זה חשוב

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

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

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

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

פס

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

משוט

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

מסחר קוינבייס

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

ריבוע

ממשק ה-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
}

פס - סינון לפי לקוח:

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

פס - סינון לפי סטטוס:

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

פייפאל - מה שאתם מקבלים בפועל:

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 - השעיית מנוי

מה חסר בפייפאל:

• ❌ אין GET /v1/billing/subscriptions (הצגת הכל)
• ❌ אין פונקציונליות חיפוש
• ❌ אין סינון לפי סטטוס, לקוח, תאריך
• ❌ אין תמיכה בעמודים

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

הטיוח השיטתי של פייפאל: השתקת 6 מיליון קולות

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

המחיקה הגדולה

קהילת PayPal המקורית ב-paypal-community.com אירחה 6,003,558 חברים והכילה מאות אלפי פוסטים, דיווחי באגים, תלונות ודיונים על כשלים ב-API של PayPal. מידע זה ייצג למעלה מעשור של עדויות מתועדות לבעיות השיטתיות של PayPal.

ב-30 ביוני 2025, PayPal הסירה בשקט את כל הפורום מהאינטרנט. כל הקישורים paypal-community.com מחזירים כעת שגיאות 404. זו לא הייתה העברה או שדרוג.

הצלת צד שלישי

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

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

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

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

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

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

הפסד של 1,899 דולר להעברת דוא"ל

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

• התקבלו CHECKOUT.ORDER.APPROVED webhooks
• ממשק ה-API ללכידה של PayPal החזיר שגיאות 404
• הזמנות הפכו בלתי נגישות דרך ממשק ה-API של PayPal

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

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

אנחנו הולכים להצהיר זאת שוב: ההפסדים המצטברים של אלפי סוחרים במשך 11+ שנים מסתכמים ככל הנראה במיליוני דולרים.

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

הדו"ח המקורי משנת 2013: 11+ שנים של רשלנות

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

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

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

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

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

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

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

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

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

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

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

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

דיווחים אחרונים מקהילת PayPal המשומרת מראים שהבעיה החמירה. קובץ דיון ספטמבר 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:

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

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

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

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

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

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

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

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

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

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

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

דפוס הטעיה רחב יותר של PayPal

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

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

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

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

תביעת הדבש: כתיבה מחדש של קישורי שותפים

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

התבנית ברורה:

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

מחיר הרשלנות של PayPal

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

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

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

שקר התיעוד

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

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

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

מה המשמעות עבור מפתחים

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

התבנית ברורה:

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

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

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

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