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

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

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

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

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

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

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

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

Але PayPal? Вони просто... так і не створили його.

2014-2017: Проблема виникає

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

Відповідь PayPal? Цвіркуни.

Члени громади почали розчаровуватися:

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

"+1. Минуло майже 3 роки." - laudukang (тобто проблема існує з ~2014 року)

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

2020: Ми надаємо їм вичерпний відгук

У жовтні 2020 року PayPal звернувся до нас для офіційної сесії зворотного зв'язку. Це була не просто звичайна розмова – вони організували 45-хвилинну дзвінок у Microsoft Teams з 8 керівниками PayPal, включаючи Шрі Шивананду (технічний директор), Едвіна Аокі, Джима Магатса, Джона Кунце та інших.

Список відгуків із 27 пунктів

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

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

Відгук не був теоретичним – він походив від реальних спроб інтеграції:

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

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

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

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

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

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

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

У міру виявлення нових проблем PayPal продовжував додавати до обговорення нові команди. Даршан Раджу з команди інтерфейсу керування підписками приєднався та сказав:

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

Сеанс було описано як пошук:

відвертий розповідь про ваш досвід

до:

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

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

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

відстеження та адреса

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

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

А ось тут починається справді цікаво. Кожна людина, яка отримала наш відгук за 2020 рік, залишила PayPal:

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

• Ден Шульман (генеральний директор протягом 9 років) → Алекс Крісс (вересень 2023 р.)
• Шрі Шивананда (технічний директор, який організовував зворотний зв'язок) → JPMorgan Chase (січень 2024 р.)

Технічні лідери, які давали обіцянки, а потім пішли:

• Марк Стюарт (обіцяний відгук буде «каталізатором») → Зараз у Ripple
• Джим Магатс (18-річний ветеран PayPal) → Генеральний директор MX (2022)
• Джон Кунце (віце-президент з глобальних споживчих продуктів) → На пенсії (2023)
• Едвін Аокі (один з останніх, що залишилися) → Щойно вирушив на Nasdaq (січень 2025)

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

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

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

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

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

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

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

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

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

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

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

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

Дякую. Однак, я не думаю, що дзвінок щось дасть. Ось чому... У минулому мені телефонували, і це ні до чого не призвело. Я витратив понад 2 години свого часу на розмови з усією командою та керівництвом, і нічого не було зроблено... Купа електронних листів туди-сюди. Абсолютно нічого не було зроблено. Зворотній зв'язок ні до чого не призвів. Я роками намагався, мене вислухали, а потім це ні до чого не призвело.

Відповідь Марті Бродбека на надмірну інженерію

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

Привіт, Ніку, це Марті Бродбек. Я очолюю всі напрямки споживчої інженерії в PayPal і керую розробкою 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: Ранні скарги на інтерфейс користувача/користувацький інтерфейс

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

2021: Звіт про помилку в діловій електронній пошті

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

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

Дякую, Нік! Переходимо до прихованої копії. @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 також абсолютно неточна. Ми думали, що можемо знайти обхідний шлях, завантаживши жорстко закодований список ідентифікаторів підписок. Але це навіть не працює!

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

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

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

Шрі Шивананда (технічний директор) подякував нам:

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

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

Кошмар для розробників

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

Пошкоджений інтерфейс користувача

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

Проблеми з SDK

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

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

Їхній 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 через фішинг

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

• "Рахунок-фактура від команди PayPal Billing: - Цей платіж буде автоматично списано з вашого рахунку. Будь ласка, негайно зв'яжіться з нами за номером [ТЕЛЕФОН]"
• "Рахунок-фактура від [НАЗВА КОМПАНІЇ] ([ІДЕНТИФІКАТОР ЗАМОВЛЕННЯ])"
• Кілька варіантів з різними номерами телефонів та фальшивими ідентифікаторами замовлень

Ці електронні листи часто надходять з хостів outlook.com, але, схоже, походять із легітимних систем PayPal, що робить їх особливо небезпечними. Електронні листи проходять автентифікацію SPF, DKIM та DMARC, оскільки вони надсилаються через фактичну інфраструктуру PayPal.

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

• X-Email-Type-Id: RT000238 (той самий ідентифікатор, який ми блокуємо)
• From: "service@paypal.com" <service@paypal.com>
• Дійсні підписи DKIM від paypal.com
• Належні записи SPF, що показують поштові сервери PayPal

Це створює неможливу ситуацію: легітимні електронні листи PayPal та спам мають однакові технічні характеристики.

Іронія

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

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

Вплив на реальний світ: нові шахрайства PayPal

Проблема виходить за рамки просто поганого дизайну шаблону. Систему рахунків PayPal настільки легко використовувати, що шахраї регулярно зловживають нею для надсилання шахрайських рахунків-фактур, що виглядають справжніми. Дослідник безпеки Гевін Андерегг задокументував випадок Нова афера з PayPal, коли шахраї надсилають справжні рахунки-фактури PayPal, які проходять усі перевірки автентифікації:

«Перевіривши джерело, я зрозумів, що електронний лист справді надійшов від PayPal (SPF, DKIM та DMARC пройшли перевірку). Кнопка також вела на те, що виглядало як легітимна URL-адреса PayPal... Мені знадобилася секунда, щоб усвідомити, що це справжній електронний лист. Мені щойно надіслав випадковий «рахунок-фактуру» від шахрая».

Дослідник зазначив:

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

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

На додачу до всього, це вплинуло на якість доставки з Yahoo, що призвело до скарг клієнтів та годин ретельного тестування та перевірки шаблонів.

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

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

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

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

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 має список підписок з моменту запуску свого API. У їхній документації чітко показано, як отримати всі підписки для облікового запису клієнта або продавця. Це вважається базовою функціональністю CRUD.

Весло

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

Coinbase Commerce

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

Квадрат

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

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

Доступні кінцеві точки PayPal:

• POST /v1/billing/subscriptions - Створити підписку
• GET /v1/billing/subscriptions/{id} - Отримати ОДНУ підписку (якщо ви знаєте її ідентифікатор)
• PATCH /v1/billing/subscriptions/{id} - Оновити підписку
• POST /v1/billing/subscriptions/{id}/cancel - Скасувати підписку
• POST /v1/billing/subscriptions/{id}/suspend - Призупинити підписку

Чого бракує в PayPal:

• ❌ Немає GET /v1/billing/subscriptions (показати всі)
• ❌ Немає функції пошуку
• ❌ Немає фільтрації за статусом, клієнтом, датою
• ❌ Немає підтримки пагінації

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

Систематичне приховування PayPal: заглушення 6 мільйонів голосів

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

Велике стирання

Оригінальна спільнота PayPal за адресою paypal-community.com мала 6 003 558 учасників та містила сотні тисяч публікацій, звітів про помилки, скарг та обговорень щодо збоїв API PayPal. Це являло собою понад десятиліття документальних доказів систематичних проблем PayPal.

30 червня 2025 року PayPal непомітно відключив увесь форум. Усі посилання paypal-community.com тепер повертають помилки 404. Це не була міграція чи оновлення.

Рятувальна служба третьої сторони

На щастя, сторонній сервіс за адресою ppl.lithium.com зберіг частину контенту, що дозволило нам отримати доступ до обговорень, які PayPal намагався приховати. Однак це збереження сторонніми службами є неповним і може зникнути будь-коли.

Така схема приховування доказів не є новою для PayPal. У них є задокументована історія:

• Видалення звітів про критичні помилки з публічного доступу
• Припинення роботи інструментів розробника без попередження
• Зміна API без належної документації
• Замовчування обговорень у спільноті щодо їхніх невдач

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

11-річна катастрофа з помилкою захоплення: $1899 і зростає

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

Збиток від пересилання електронного листа на суму $1899

У наших виробничих системах ми виявили 108 платежів PayPal на загальну суму $1899, які були втрачені через збої обробки даних PayPal. Ці платежі демонструють послідовну закономірність:

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

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

Це стосується лише одного бізнесу. Сукупні збитки тисяч торговців за понад 11 років, ймовірно, сягають мільйонів доларів.

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

Єдина причина, чому ми це виявили, полягає в тому, що ми неймовірно скрупульозні та орієнтовані на дані.

Початковий звіт за 2013 рік: понад 11 років недбалості

Найдавніше задокументоване повідомлення про цю конкретну проблему з'являється Переповнення стека у листопаді 2013 року (архівовано):

"Постійно отримую помилку 404 з Rest API під час захоплення"

Помилка, про яку повідомлялося у 2013 році, ідентична тій, що виникала у функції «Пересилання електронної пошти» у 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 вересня 2016 року всі спроби отримання коштів через PayPal завершуються невдачею з помилкою «INVALID_RESOURCE_ID – Запитаний ідентифікатор ресурсу не знайдено». Між 19 та 20 вересня в інтеграції API нічого не змінювалося. 100% спроб отримання коштів з 20 вересня повертали цю помилку.»

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

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

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

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

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

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

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

"Оновив SDK до версії 1.7.4, але проблема все ще виникає"

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

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

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

Продавець описує ту саму схему пересилання електронних листів:

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

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

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

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

Для оплати передплати:

"'ПЛАТЕЖ.ПРОДАЖ.ЗАВЕРШЕНО' іноді не надходило або отримувалося лише через кілька годин."

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

1. «Чому це відбувається?» - Система вебхуків PayPal принципово не працює
2. «Якщо статус замовлення «ЗАВЕРШЕНО», чи можу я вважати, що отримав гроші?» - Продавці не можуть довіряти відповідям API PayPal
3. «Чому «Журнали подій->Події вебхуків» не можуть знайти жодних журналів?» - Навіть власна система ведення журналу PayPal не працює

Схема систематичної недбалості

Дані охоплюють понад 11 років і демонструють чітку закономірність:

• 2013: «PayPal працює над цим»
• 2016: PayPal визнає критичні зміни та пропонує виправлення
• 2024: Ті самі помилки все ще виникають, впливаючи на функцію пересилання електронної пошти та безліч інших

Це не помилка – це систематична недбалість. PayPal знає про ці критичні збої в обробці платежів вже понад десять років і постійно:

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

Недокументована вимога

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

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

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

Будь-який інший платіжний процесор надає надійні API захоплення даних, які працюють з першого разу.

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

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

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

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

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

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

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

Закономірність зрозуміла:

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

Ціна недбалості PayPal

Збитки Forward Email у розмірі 1899 доларів США – це лише верхівка айсберга. Розглянемо ширший вплив:

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

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

Документальна брехня

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

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

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

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

Систематична нездатність PayPal задовольнити основні потреби розробників під час збору ґрунтовних відгуків свідчить про фундаментальну організаційну проблему. Вони ставляться до збору відгуків як до заміни фактичного виправлення проблем.

Закономірність зрозуміла:

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

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

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

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