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 конкретных проблем. Марк Стюарт из команды PayPal Checkout сказал:

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

Обратная связь была не теоретической — она исходила из реальных попыток интеграции:

1. Генерация токена доступа не работает:

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

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

Как, черт возьми, можно создавать подписки, не используя cURL? Похоже, нет веб-интерфейса для этого (как у Stripe).

Марк Стюарт особенно обеспокоился проблемой с токеном доступа:

Обычно мы не слышим о проблемах с генерацией токена доступа.

Вовлечение команд, даны обещания

По мере обнаружения новых проблем PayPal подключал к обсуждению всё больше команд. Даршан Раджу из команды управления подписками присоединился и сказал:

Признаем пробел. Мы будем отслеживать и решать это. Спасибо еще раз за ваш отзыв!

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

откровенный разбор вашего опыта

чтобы:

сделать PayPal таким, каким он должен быть для разработчиков.

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

Несмотря на формальную сессию обратной связи, обширный список из 27 пунктов, участие нескольких команд и обещания:

отслеживать и решать

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

Исход руководства: как PayPal потерял всю институциональную память

Вот где становится действительно интересно. Все, кто получил наш отзыв в 2020 году, покинули PayPal:

Изменения в руководстве:

• Дэн Шульман (генеральный директор 9 лет) → Алекс Крисс (сентябрь 2023)

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

• Марк Стюарт (обещал, что обратная связь станет "катализатором") → Сейчас в Ripple

• Джим Магатс (ветеран PayPal с 18-летним стажем) → Генеральный директор MX (2022)

• Джон Кунце (вице-президент по глобальным потребительским продуктам) → Вышел на пенсию (2023)

• Эдвин Аоки (один из последних оставшихся) → Только что ушёл в 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 кажется ошибкой. Его, вероятно, нужно фильтровать.

Результат: Не исправлено. Интерфейс по-прежнему показывает эти бесполезные записи с $0.

2021: Сбой среды песочницы

В ноябре 2021 года мы сообщили о критических проблемах с песочницей PayPal:

• Секретные API-ключи песочницы случайно менялись и отключались
• Все тестовые аккаунты песочницы были удалены без предупреждения
• Ошибки при попытке просмотра деталей аккаунта песочницы
• Перемежающиеся сбои загрузки

По какой-то причине мой секретный API-ключ песочницы был изменён и отключён. Также все мои старые тестовые аккаунты песочницы были удалены.

Иногда они загружаются, а иногда нет. Это невероятно раздражает.

Результат: Нет ответа, нет исправления. Разработчики по-прежнему сталкиваются с проблемами надежности песочницы.

2021: Система отчетов полностью сломана

В мае 2021 года мы сообщили, что система загрузки отчетов о транзакциях PayPal полностью сломана:

Похоже, что загрузка отчетов сейчас не работает и не работала весь день. Также, вероятно, стоит получать уведомление по электронной почте, если загрузка не удалась.

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

Кроме того, если вы неактивны, будучи залогинены в PayPal около 5 минут, вас выкидывает из системы. Поэтому, когда вы обновляете кнопку рядом с отчетом, чтобы проверить статус (после того, как ждете вечность), приходится заново входить в систему — это очень неудобно.

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

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

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

2022: Отсутствие ключевой функции API (снова)

В январе 2022 года мы снова подняли вопрос с отображением подписок, на этот раз с еще большим количеством деталей о том, как их документация неверна:

Нет GET-запроса, который бы выводил все подписки (ранее называвшиеся соглашениями о выставлении счетов)

Мы обнаружили, что их официальная документация полностью неточна:

Документация 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 секунд бездействия. Пытаетесь сделать что-то продуктивное — и постоянно проходите через: вход → капча → 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, который мы обрабатываем ежедневно. Примеры заблокированных тем включают:

• "Счет от команды выставления счетов PayPal: — Эта сумма будет автоматически списана с вашего счета. Пожалуйста, свяжитесь с нами немедленно по телефону [PHONE]"
• "Счет от [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. Позволить клиентам обнаружить проблему и сообщить о ней

Реальное влияние на бизнес

Этот обратный процесс создаёт катастрофы для бизнеса:

• Клиенты не могут завершить покупки в периоды пиковых продаж
• Нет предварительного предупреждения о необходимости верификации
• Нет уведомлений по электронной почте, когда платежи блокируются
• Торговцы узнают о проблемах от растерянных клиентов
• Потеря дохода в критические для бизнеса периоды
• Потеря доверия клиентов, когда платежи таинственно не проходят

Катастрофа с миграцией аккаунтов в июле 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": "Запрошенный ID ресурса не найден",
  "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 - Запрошенный идентификатор ресурса не найден.'. Между 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: переписывание партнерских ссылок

Поглощение Honey компанией PayPal привело к искам, утверждающим, что 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 несмотря на эти проблемы, потому что у некоторых клиентов нет другого выбора