11-річна катастрофа API PayPal: як ми створювали обхідні шляхи, поки вони ігнорували розробників

У Forward Email ми маємо справу з поламаними API PayPal понад десять років. Те, що починалося як незначні розчарування, перетворилося на повну катастрофу, яка змусила нас створювати власні обхідні шляхи, блокувати їхні фішингові шаблони та врешті-решт припинити всі платежі через PayPal під час критичної міграції облікового запису.

Це історія 11 років ігнорування PayPal базових потреб розробників, поки ми робили все можливе, щоб змусити їхню платформу працювати.

Відсутній елемент: неможливо отримати список підписок

Ось що нас вражає: PayPal має підписковий білінг з 2014 року, але вони ніколи не надали продавцям спосіб отримати список власних підписок.

Подумайте про це на секунду. Ви можете створювати підписки, скасовувати їх, якщо маєте ID, але не можете отримати список усіх активних підписок для свого облікового запису. Це як база даних без оператора SELECT.

Нам це потрібно для базових бізнес-операцій:

• Підтримка клієнтів (коли хтось пише з питанням про свою підписку)
• Фінансова звітність та звірка
• Автоматизоване управління білінгом
• Відповідність вимогам та аудит

А PayPal? Вони просто... ніколи цього не зробили.

2014-2017: Проблема з’являється

Проблема зі списком підписок вперше з’явилася на форумах спільноти PayPal у 2017 році. Розробники ставили очевидне питання: «Як отримати список усіх моїх підписок?»

Відповідь PayPal? Тиша.

Члени спільноти почали розчаровуватися:

«Дуже дивне упущення, якщо продавець не може отримати список усіх активних угод. Якщо ID угоди втрачено, це означає, що лише користувач може скасувати або призупинити угоду.» - leafspider

«+1. Минуло майже 3 роки.» - laudukang (мається на увазі, що проблема існує з ~2014 року)

Оригінальний допис у спільноті 2017 року показує, як розробники благають про цю базову функціональність. Відповіддю PayPal було архівування репозиторію, де люди повідомляли про проблему.

2020: Ми надали їм детальний зворотний зв’язок

У жовтні 2020 року PayPal звернувся до нас для формальної сесії зворотного зв’язку. Це була не проста розмова — вони організували 45-хвилинний дзвінок у Microsoft Teams з 8 керівниками PayPal, включно зі Sri Shivananda (CTO), Edwin Aoki, Jim Magats, John Kunze та іншими.

Список з 27 пунктів зворотного зв’язку

Ми були готові. Після 6 годин спроб інтеграції з їхніми API ми склали 27 конкретних проблем. Mark Stuart з команди PayPal Checkout сказав:

Привіт, Nick, дякую, що поділився з усіма сьогодні! Думаю, це стане каталізатором для отримання більшої підтримки та інвестицій для нашої команди, щоб виправити ці речі. Було важко отримати такий ґрунтовний зворотний зв’язок, як той, що ти нам залишив.

Зворотний зв’язок був не теоретичним — він походив із реальних спроб інтеграції:

1. Генерація токена доступу не працює:

Генерація токена доступу не працює. Також має бути більше прикладів, ніж лише cURL.

2. Немає веб-інтерфейсу для створення підписок:

Як, чорт забирай, можна створювати підписки без використання cURL? Здається, немає веб-інтерфейсу для цього (як у Stripe).

Mark Stuart вважав проблему з токеном доступу особливо тривожною:

Зазвичай ми не чуємо про проблеми з генерацією токена доступу.

Залучили команди, дали обіцянки

Коли ми виявляли більше проблем, PayPal додавали до розмови все більше команд. Darshan Raju з команди управління UI підписок приєднався і сказав:

Визнаємо прогалину. Ми відстежимо і вирішимо це. Ще раз дякуємо за ваш зворотний зв’язок!

Сесію описали як:

відвертий огляд вашого досвіду

щоб:

зробити PayPal таким, яким він має бути для розробників.

Результат? Нічого.

Незважаючи на формальну сесію зворотного зв’язку, детальний список з 27 пунктів, участь кількох команд і обіцянки:

відстежувати і вирішувати

проблеми, абсолютно нічого не було виправлено.

Відхід керівництва: як PayPal втратив усю інституційну пам’ять

Ось де стає по-справжньому цікаво. Кожна людина, яка отримала наш зворотний зв’язок 2020 року, покинула PayPal:

Зміни в керівництві:

• Dan Schulman (CEO протягом 9 років) → Alex Chriss (вересень 2023)

• Sri Shivananda (CTO, який організував зворотний зв’язок) → JPMorgan Chase (січень 2024) Технічні лідери, які давали обіцянки, а потім пішли:

• Mark Stuart (обіцяв, що зворотній зв’язок буде "каталізатором") → Зараз у Ripple

• Jim Magats (ветеран PayPal з 18-річним стажем) → Генеральний директор MX (2022)

• John Kunze (віце-президент з глобальних споживчих продуктів) → Вийшов на пенсію (2023)

• Edwin Aoki (один із останніх, хто залишився) → Щойно пішов у Nasdaq (січень 2025)

PayPal став дверима, що обертаються, де керівники збирають відгуки розробників, дають обіцянки, а потім йдуть у кращі компанії, такі як JPMorgan, Ripple та інші фінтех-фірми.

Це пояснює, чому відповідь на проблему на GitHub у 2025 році здавалася повністю відривною від наших відгуків 2020 року — буквально всі, хто отримував ті відгуки, вже покинули PayPal.

2025: Нове керівництво, ті ж проблеми

Перенесімося у 2025 рік, і з’являється точно така сама картина. Після років відсутності прогресу нове керівництво PayPal знову виходить на зв’язок.

Новий генеральний директор втручається

30 червня 2025 року ми звернулися безпосередньо до нового генерального директора PayPal Алекса Крісса. Його відповідь була короткою:

Привіт, Нік – Дякую, що звернулися, і за відгук. Мішель (в копії) відповідає разом зі своєю командою за залучення і роботу з вами. Дякую -А

Відповідь Мішель Гілл

Мішель Гілл, виконавчий віце-президент і генеральний менеджер малого бізнесу та фінансових послуг, відповіла:

Дуже дякую, Нік, додаю Алекса в приховану копію. Ми розглядаємо це з моменту вашого попереднього допису. Зателефонуємо вам до кінця тижня. Будь ласка, надішліть мені ваші контактні дані, щоб один із моїх колег міг зв’язатися. Мішель

Наша відповідь: більше жодних зустрічей

Ми відмовилися від ще однієї зустрічі, пояснивши наше розчарування:

Дякую. Проте я не вірю, що дзвінок щось змінить. Ось чому... Раніше я вже брав участь у дзвінку, і це ні до чого не призвело. Я витратив понад 2 години свого часу, спілкуючись з усією командою та керівництвом, і нічого не було зроблено... Безліч листів туди-сюди. Абсолютно нічого не зроблено. Відгуки ні до чого не призвели. Я намагався роками, мене слухали, а потім все зупинялося.

Надмірно складна відповідь Марті Бродбека

Потім звернувся Марті Бродбек, який очолює споживчу інженерію в PayPal:

Привіт, Нік, це Марті Бродбек. Я керую всією споживчою інженерією тут, у PayPal, і відповідаю за розробку API для компанії. Чи можемо ми зв’язатися, щоб обговорити проблему, з якою ви зіткнулися, і як ми можемо допомогти.

Коли ми пояснили просту потребу в кінцевій точці для списку підписок, його відповідь виявила суть проблеми:

Дякую, Нік, ми зараз створюємо єдиний API для підписок із повним SDK (підтримує повну обробку помилок, відстеження підписок на основі подій, надійний час роботи), де білінг також виділений як окремий API для продавців, щоб вони могли звертатися до нього, а не координуватися через кілька кінцевих точок для отримання однієї відповіді.

Це саме неправильний підхід. Нам не потрібні місяці складної архітектури. Нам потрібна одна проста REST-ендпоінт, яка перераховує підписки — те, що мало існувати з 2014 року.

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

Протиріччя "простого CRUD"

Коли ми вказали, що це базова функціональність CRUD, яка мала існувати з 2014 року, відповідь Марті була промовистою:

Прості операції CRUD є частиною основного API, друже, тому це не займе місяців розробки

TypeScript SDK PayPal, який наразі підтримує лише три кінцеві точки після місяців розробки, разом із його історичною хронологією, чітко демонструє, що такі проєкти потребують більше ніж кілька місяців для завершення. Ця відповідь показує, що він не розуміє власний API. Якщо «прості операції CRUD є частиною основного API», то де ж кінцева точка для переліку підписок? Ми відповіли:

Якщо «прості операції CRUD є частиною основного API», то де ж кінцева точка для переліку підписок? Розробники просять цю «просту операцію CRUD» з 2014 року. Минуло 11 років. У кожного іншого платіжного процесора ця базова функціональність була з першого дня.

Розрив стає очевидним

Обміни 2025 року з Алексом Кріссом, Мішель Гілл та Марті Бродбеком демонструють ту ж організаційну дисфункцію:

1. Нове керівництво не знає про попередні сесії зворотного зв’язку
2. Вони пропонують ті ж надмірно складні рішення
3. Вони не розуміють обмежень власного API
4. Вони хочуть більше зустрічей замість того, щоб просто виправити проблему

Цей шаблон пояснює, чому команди PayPal у 2025 році здаються повністю відключеними від обширного зворотного зв’язку, наданого у 2020 році — люди, які отримали той зворотний зв’язок, пішли, а нове керівництво повторює ті ж помилки.

Роки ігнорування звітів про помилки

Ми не просто скаржилися на відсутність функцій. Ми активно повідомляли про помилки і намагалися допомогти їм покращитись. Ось докладна хронологія задокументованих нами проблем:

2016: Ранні скарги на UI/UX

Ще у 2016 році ми публічно зверталися до керівництва PayPal, включно з Даном Шульманом, щодо проблем інтерфейсу та зручності використання. Це було 9 років тому, і ті ж проблеми UI/UX залишаються й досі.

2021: Звіт про помилку бізнес-емейлу

У березні 2021 року ми повідомили, що система бізнес-емейлів PayPal надсилає неправильні повідомлення про скасування. Шаблон листа містив змінні, які відображалися некоректно, показуючи клієнтам заплутані повідомлення.

Марк Стюарт визнав проблему:

Дякую, Ніку! Перемикаємо на BCC. @Prasy, ваша команда відповідає за цей емейл або знає, хто? Фраза «Niftylettuce, LLC, ми більше не будемо вам виставляти рахунки» дає підстави вважати, що є плутанина щодо того, кому адресовано лист і його змісту.

Результат: Цю проблему вони справді виправили! Марк Стюарт підтвердив:

Щойно почув від команди сповіщень, що шаблон листа виправлено і впроваджено. Дякую, що звернулися і повідомили про це. Дякую!

Це показує, що вони МОЖУТЬ виправляти проблеми, коли хочуть — просто вибирають не робити цього у більшості випадків.

2021: Пропозиції щодо покращення UI

У лютому 2021 року ми надали детальний зворотний зв’язок щодо їхньої панелі керування, зокрема розділу «Остання активність PayPal»:

Думаю, панель керування на paypal.com, зокрема «Остання активність PayPal», потребує покращення. Не думаю, що варто показувати рядки статусу «Створено» для регулярних платежів на $0 — це просто додає багато зайвих рядків, і неможливо швидко побачити, скільки доходу генерується за день/останні кілька днів.

Марк Стюарт переслав це команді споживчих продуктів:

Дякую! Не впевнений, яка команда відповідає за Активність, але я переслав це керівнику споживчих продуктів, щоб знайти правильну команду. Регулярний платіж на $0.00 виглядає як помилка. Його, мабуть, слід відфільтрувати.

Результат: Ніколи не виправлено. UI досі показує ці марні записи з $0.

2021: Збої в середовищі Sandbox

У листопаді 2021 року ми повідомили про критичні проблеми з середовищем Sandbox PayPal:

• Секретні API-ключі Sandbox випадково змінювалися і відключалися
• Всі тестові акаунти Sandbox були видалені без попередження
• Повідомлення про помилки при спробі переглянути деталі акаунту Sandbox
• Періодичні збої завантаження

З якоїсь причини мій секретний API-ключ Sandbox було змінено і він був відключений. Також всі мої старі тестові акаунти Sandbox були видалені.

Іноді вони завантажуються, а іноді ні. Це надзвичайно дратує.

Результат: Немає відповіді, немає виправлення. Розробники досі стикаються з проблемами надійності Sandbox.

2021: Система звітів повністю зламана

У травні 2021 року ми повідомили, що система завантаження звітів про транзакції PayPal була повністю зламана:

Здається, що завантаження звітів зараз не працює і не працювало весь день. Також, ймовірно, слід отримувати повідомлення електронною поштою, якщо завантаження не вдається.

Ми також вказали на катастрофу з управлінням сесіями:

Також, якщо ви неактивні, перебуваючи в системі PayPal близько 5 хвилин, вас викидає з сесії. Тож коли ви оновлюєте кнопку поруч зі звітом, щоб перевірити його статус (після того, як довго чекаєте), це дуже незручно — доводиться знову входити в систему.

Марк Стюарт визнав проблему з тайм-аутом сесії:

Пам’ятаю, ви раніше повідомляли, що ваша сесія часто закінчується і порушує ваш робочий процес під час перемикання між IDE і developer.paypal.com або панеллю керування продавця, а потім ви повертаєтесь і знову викидає вас з сесії.

Результат: Тайм-аут сесії досі 60 секунд. Система звітів регулярно виходить з ладу.

2022: Відсутня ключова функція API (знову)

У січні 2022 року ми знову підняли питання про список підписок, цього разу з ще більшою деталізацією про те, як їхня документація була неправильною:

Немає GET-запиту, який би виводив усі підписки (раніше називалися billing agreements)

Ми виявили, що їхня офіційна документація була повністю неточною:

Документація API також повністю неточна. Ми думали, що можемо обійти це, завантаживши жорстко закодований список ID підписок. Але це навіть не працює!

З офіційної документації тут... Там написано, що це можна зробити... Але ось у чому суть — немає жодного поля "Subscription ID", яке можна було б знайти і позначити.

Крістіна Монті з PayPal відповіла:

Вибачаємося за розчарування, спричинене цими неправильними кроками, ми виправимо це цього тижня.

Шрі Шівананда (CTO) подякував нам:

Дякуємо за вашу постійну допомогу у покращенні нас. Дуже цінуємо.

Результат: Документацію так і не виправили. Ендпоінт для списку підписок так і не створили.

Кошмар досвіду розробника

Працювати з API PayPal — це як повернутися в минуле на 10 років. Ось технічні проблеми, які ми задокументували:

Зламаний інтерфейс користувача

Панель розробника PayPal — це катастрофа. Ось з чим ми стикаємося щодня:

Проблеми SDK

• Не може одночасно обробляти одноразові платежі та підписки без складних обхідних шляхів, що включають заміну та повторне відображення кнопок під час повторного завантаження SDK через script-теги
• JavaScript SDK порушує базові конвенції (імена класів з маленької літери, відсутність перевірки екземплярів)
• Повідомлення про помилки не вказують, яких полів бракує
• Непослідовні типи даних (вимагають рядкові значення сум замість чисел)

Порушення політики безпеки контенту

Їх SDK вимагає unsafe-inline та unsafe-eval у вашій CSP, змушуючи вас йти на компроміс із безпекою вашого сайту.

Хаос у документації

Сам Марк Стюарт визнав:

Згоден, що існує абсурдна кількість застарілих і нових API. Дуже важко знайти те, що шукаєш (навіть для нас, хто тут працює).

Уразливості безпеки

Реалізація 2FA у PayPal зроблена неправильно. Навіть із увімкненими додатками TOTP вони змушують використовувати SMS-підтвердження – що робить акаунти вразливими до атак із заміною SIM-карти. Якщо у вас увімкнено TOTP, слід використовувати його виключно. Запасним варіантом має бути електронна пошта, а не SMS.

Катастрофа управління сесіями

Їхня панель розробника виходить із системи після 60 секунд бездіяльності. Спробуйте зробити щось продуктивне, і ви постійно проходите через: вхід → captcha → 2FA → вихід із системи → повтор. Використовуєте VPN? Удачі.

Липень 2025: Остання крапля

Після 11 років однакових проблем переломним моментом стала рутинна міграція акаунта. Нам потрібно було перейти на новий акаунт PayPal, щоб відповідати назві нашої компанії "Forward Email LLC" для більш чистого обліку.

Те, що мало бути простим, перетворилося на повну катастрофу:

• Початкове тестування показало, що все працює правильно
• Через кілька годин PayPal раптово заблокував усі платежі за підписками без попередження
• Клієнти не могли платити, що спричинило плутанину та навантаження на службу підтримки
• Підтримка PayPal давала суперечливі відповіді, стверджуючи, що акаунти верифіковані
• Нас змусили повністю припинити прийом платежів через PayPal

Чому ми не можемо просто відмовитись від PayPal

Незважаючи на всі ці проблеми, ми не можемо повністю відмовитись від PayPal, бо деякі клієнти мають лише PayPal як варіант оплати. Як сказав один клієнт на нашій сторінці статусу:

PayPal — це мій єдиний варіант оплати

Ми змушені підтримувати зламану платформу, бо PayPal створив монополію на оплату для певних користувачів.

Обхідне рішення спільноти

Оскільки PayPal не надає базову функціональність для перегляду підписок, спільнота розробників створила обхідні шляхи. Ми створили скрипт, який допомагає керувати підписками PayPal: set-active-pypl-subscription-ids.js

Цей скрипт посилається на спільнотний gist, де розробники діляться рішеннями. Користувачі фактично дякують нам за те, що ми надали те, що PayPal мав би зробити роки тому.

Блокування шаблонів PayPal через фішинг

Проблеми виходять за межі API. Шаблони електронної пошти PayPal настільки погано розроблені, що нам довелося впровадити спеціальне фільтрування в нашому поштовому сервісі, бо їх неможливо відрізнити від фішингових спроб.

Справжня проблема: шаблони PayPal виглядають як шахрайство

Ми регулярно отримуємо повідомлення про листи PayPal, які виглядають точно як фішингові спроби. Ось реальний приклад із наших звітів про зловживання:

Тема: [Sandbox] TEST - New invoice from 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, який ми обробляємо щодня. Приклади заблокованих тем включають:

• "Invoice from PayPal Billing Team:- This charge will be auto-debited from your account. Please contact us immediately at [PHONE]"
• "Invoice from [COMPANY NAME] ([ORDER-ID])"
• Кілька варіацій з різними номерами телефонів і фальшивими номерами замовлень Ці електронні листи часто надходять від хостів outlook.com, але виглядають так, ніби вони походять із легітимних систем PayPal, що робить їх особливо небезпечними. Листи проходять аутентифікацію SPF, DKIM і DMARC, оскільки вони надсилаються через справжню інфраструктуру PayPal.

Наші технічні журнали показують, що ці спам-листи містять легітимні заголовки PayPal:

• X-Email-Type-Id: RT000238 (той самий ID, який ми блокуємо)
• 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, що призвело до скарг клієнтів і годин ретельного тестування та перевірки шаблонів.

Зворотній процес KYC у PayPal

Один із найфруструючих аспектів платформи PayPal — їхній зворотній підхід до процедур відповідності та "Знай свого клієнта" (KYC). На відміну від усіх інших платіжних процесорів, PayPal дозволяє розробникам інтегрувати свої API і починати збирати платежі в продакшені до завершення належної верифікації.

Як це має працювати

Кожен легітимний платіжний процесор дотримується такої логічної послідовності:

1. Спочатку завершити верифікацію KYC
2. Схвалити обліковий запис продавця
3. Надати доступ до API в продакшені
4. Дозволити збір платежів

Це захищає як платіжного процесора, так і продавця, забезпечуючи відповідність перед будь-якими фінансовими операціями.

Як PayPal працює насправді

Процес PayPal повністю зворотній:

1. Негайно надати доступ до API в продакшені
2. Дозволити збір платежів протягом годин або днів
3. Раптово заблокувати платежі без попередження
4. Вимагати документи KYC після того, як клієнти вже постраждали
5. Не повідомляти продавця
6. Дозволити клієнтам виявляти проблему і повідомляти про неї

Реальний вплив

Цей зворотний процес створює катастрофи для бізнесу:

• Клієнти не можуть завершити покупки під час пікових періодів продажів
• Відсутність попередження про необхідність верифікації
• Відсутність email-повідомлень при блокуванні платежів
• Продавці дізнаються про проблеми від розгублених клієнтів
• Втрати доходу у критичні для бізнесу періоди
• Пошкодження довіри клієнтів, коли платежі загадково не проходять

Катастрофа міграції акаунтів у липні 2025 року

Цей саме сценарій стався під час нашої рутинної міграції акаунтів у липні 2025 року. PayPal спочатку дозволяв платежі, а потім раптово їх блокував без будь-яких повідомлень. Ми виявили проблему лише тоді, коли клієнти почали скаржитися, що не можуть оплатити.

Коли ми звернулися до служби підтримки, отримали суперечливі відповіді щодо необхідних документів, без чіткого терміну вирішення. Це змусило нас повністю припинити прийом платежів через PayPal, що збентежило клієнтів, які не мали інших способів оплати.

Чому це важливо

Підхід PayPal до відповідності вимогам демонструє фундаментальне нерозуміння того, як працює бізнес. Правильна KYC має відбуватися до інтеграції в продуктивне середовище, а не після того, як клієнти вже намагаються оплатити. Відсутність проактивної комунікації при виникненні проблем свідчить про відрив PayPal від потреб продавців.

Цей зворотний процес є симптомом ширших організаційних проблем PayPal: вони ставлять свої внутрішні процеси вище за досвід продавців і клієнтів, що призводить до операційних катастроф, які відштовхують бізнес від їхньої платформи.

Як це роблять усі інші платіжні процесори

Функціонал переліку підписок, який PayPal відмовляється впроваджувати, є стандартом у галузі вже понад десять років. Ось як інші платіжні процесори реалізують цю базову вимогу:

Stripe

Stripe має перелік підписок з моменту запуску свого API. Їхня документація чітко показує, як отримати всі підписки для клієнта або акаунта продавця. Це вважається базовою CRUD-функціональністю.

Paddle

Paddle надає комплексні API для керування підписками, включно з переліком, фільтрацією та пагінацією. Вони розуміють, що продавцям потрібно бачити свої потоки повторюваного доходу.

Coinbase Commerce

Навіть криптовалютні платіжні процесори, як Coinbase Commerce, забезпечують кращий менеджмент підписок, ніж PayPal.

Square

API 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

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
# Немає кінцевої точки для переліку всіх підписок
# Немає способу шукати або фільтрувати
# Ви повинні самостійно відслідковувати всі 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 (список усіх)

• ❌ Немає функції пошуку

• ❌ Немає фільтрації за статусом, клієнтом, датою

• ❌ Немає підтримки пагінації

PayPal — єдиний великий платіжний процесор, який змушує розробників вручну відстежувати ID підписок у власних базах даних.

Систематичне приховування 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. Ці платежі демонструють послідовний патерн:

• Отримувалися вебхуки CHECKOUT.ORDER.APPROVED
• API захоплення PayPal повертав помилки 404
• Замовлення ставали недоступними через API PayPal

Неможливо визначити, чи були списані кошти з клієнтів, оскільки PayPal повністю приховує логи налагодження після 14 днів і стирає всі дані з панелі для ID замовлень, які не були захоплені.

Це лише один бізнес. Колективні втрати тисяч торговців за понад 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 році офіційний репозиторій PayPal на GitHub задокументував масштабні збої захоплення, що вплинули на їхній офіційний PHP SDK. Масштаб був вражаючим:

"З 20.09.2016 усі спроби захоплення PayPal завершуються помилкою 'INVALID_RESOURCE_ID - Requested resource ID was not found.'. Між 19.09 та 20.09 у інтеграції API нічого не змінювалося. 100% спроб захоплення з 20.09 повертають цю помилку."

Один продавець повідомив:

"У мене було понад 1400 невдалих спроб захоплення за останні 24 години, усі з помилкою INVALID_RESOURCE_ID."

Початкова відповідь PayPal полягала у звинуваченні продавця та перенаправленні до техпідтримки. Лише під великим тиском вони визнали помилку:

"У мене є оновлення від наших розробників продукту. Вони помітили у заголовках, що надсилається PayPal-Request-ID довжиною 42 символи, але здається, нещодавно було внесено зміну, яка обмежує цей ID лише 38 символами."

Це визнання виявляє систематичну недбалість PayPal:

1. Вони внесли непублічні критичні зміни
2. Вони зламали власний офіційний SDK
3. Спочатку звинувачували продавців
4. Визнали помилку лише під тиском

Навіть після "виправлення" проблеми продавці повідомляли:

"Оновив SDK до v1.7.4 і проблема все ще виникає."

Ескалація 2024 року: все ще зламано

Останні повідомлення з архівованої спільноти PayPal показують, що проблема насправді погіршилася. Обговорення вересня 2024 (архів) документує ті ж самі проблеми:

"Проблема почала з’являтися приблизно 2 тижні тому і не стосується всіх замовлень. Набагато частіше виникають 404 при захопленні."

Продавець описує ту ж схему, що й Forward Email:

"Після спроби захопити замовлення PayPal повертає 404. При отриманні деталей замовлення: {'id': 'ID', 'intent': 'CAPTURE', 'status': 'COMPLETED', ..., 'final_capture': true, ...} При цьому немає жодних слідів успішного захоплення з нашого боку."

Катастрофа надійності вебхуків

Інше архівоване обговорення спільноти виявляє, що система вебхуків PayPal є фундаментально ненадійною:

"Теоретично, має бути два події (CHECKOUT.ORDER.APPROVED та PAYMENT.CAPTURE.COMPLETED) від події вебхука. Насправді, ці дві події рідко надходять одразу, PAYMENT.CAPTURE.COMPLETED більшість часу не надходить або надходить через кілька годин."

Для платежів за підпискою:

"'PAYMENT.SALE.COMPLETED' іноді не надходить або надходить лише через кілька годин."

Питання продавця виявляють глибину проблем з надійністю PayPal:

1. "Чому це відбувається?" - система вебхуків 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, що вимагає складних механізмів повторних спроб.

Це змушує кожного продавця:

• Реалізовувати логіку повторних спроб із експоненційним збільшенням інтервалів
• Обробляти непослідовну доставку вебхуків
• Створювати складні системи управління станом
• Вручну контролювати невдалі захоплення коштів

Усі інші платіжні процесори надають надійні API захоплення, які працюють з першої спроби.

Ширша схема обману PayPal

Катастрофа з помилкою захоплення — це лише один приклад системного підходу PayPal до обману клієнтів і приховування своїх невдач.

Дія Департаменту фінансових послуг Нью-Йорка

У січні 2025 року Департамент фінансових послуг Нью-Йорка видав регуляторний припис проти PayPal за обманні практики, що демонструє, що схема обману PayPal виходить далеко за межі їхніх API.

Ця регуляторна дія показує готовність PayPal застосовувати обманні практики у всьому бізнесі, а не лише у своїх інструментах для розробників.

Позов Honey: Переписування партнерських посилань

Придбання PayPal компанії Honey призвело до позовів, у яких стверджується, що Honey переписує партнерські посилання, крадучи комісії у творців контенту та інфлюенсерів. Це ще одна форма системного обману, де PayPal отримує прибуток, перенаправляючи доходи, які мають належати іншим.

Схема очевидна:

1. Збої API: Приховують непрацюючий функціонал, звинувачують продавців
2. Заглушення спільноти: Видаляють докази проблем
3. Порушення регуляторних норм: Застосовують обманні практики
4. Крадіжка партнерських комісій: Крадуть комісії через технічні маніпуляції

Вартість недбалості PayPal

Втрати Forward Email у розмірі $1,899 — це лише верхівка айсберга. Розглянемо ширший вплив:

• Окремі продавці: Тисячі втрачають від сотень до тисяч доларів кожен
• Корпоративні клієнти: Потенційно мільйони втрачених доходів
• Час розробників: Безліч годин на створення обхідних рішень для зламаних API PayPal
• Довіра клієнтів: Бізнес втрачає клієнтів через збої платежів PayPal

Якщо одна невелика пошта втратила майже $2,000, а ця проблема існує понад 11 років і впливає на тисячі продавців, загальні фінансові збитки, ймовірно, становлять сотні мільйонів доларів.

Брехня в документації

Офіційна документація PayPal систематично не згадує про критичні обмеження та помилки, з якими зіткнуться продавці. Наприклад:

• API захоплення: Немає згадки, що помилки 404 поширені і вимагають логіки повторних спроб
• Надійність вебхуків: Немає згадки, що вебхуки часто затримуються на години
• Перелік підписок: Документація натякає, що перелік можливий, хоча кінцева точка відсутня
• Таймаути сесій: Немає згадки про агресивні таймаути у 60 секунд

Це систематичне приховування критичної інформації змушує продавців виявляти обмеження PayPal методом спроб і помилок у продуктивних системах, що часто призводить до фінансових втрат.

Що це означає для розробників

Систематична неспроможність PayPal вирішувати базові потреби розробників, збираючи при цьому велику кількість відгуків, свідчить про фундаментальну організаційну проблему. Вони розглядають збір відгуків як заміну реальному виправленню проблем. Патерн очевидний:

1. Розробники повідомляють про проблеми
2. PayPal організовує сесії зворотного зв’язку з керівниками
3. Надається обширний зворотний зв’язок
4. Команди визнають недоліки і обіцяють «відстежувати та вирішувати»
5. Нічого не впроваджується
6. Керівники йдуть у кращі компанії
7. Нові команди просять той самий зворотний зв’язок
8. Цикл повторюється

Тим часом розробники змушені створювати обхідні шляхи, йти на компроміси з безпекою та мати справу з поламаними інтерфейсами, лише щоб приймати платежі.

Якщо ви створюєте платіжну систему, вчіться на нашому досвіді: побудуйте свій підхід тріади з кількома процесорами, але не очікуйте, що PayPal надасть базову функціональність, яка вам потрібна. Плануйте створювати обхідні шляхи з першого дня.

Цей допис документує наш 11-річний досвід роботи з API PayPal у Forward Email. Всі приклади коду та посилання взяті з наших реальних виробничих систем. Ми продовжуємо підтримувати платежі через PayPal, незважаючи на ці проблеми, тому що деякі клієнти не мають іншого вибору