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 с восемью руководителями PayPal, включая Шри Шивананду (технический директор), Эдвина Аоки, Джима Магатса, Джона Кунце и других.

Список отзывов из 27 пунктов

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

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

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

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

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

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

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

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

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

Команды включились, обещания были даны

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

Признайте наличие пробела. Мы отследим и устраним эту проблему. Ещё раз спасибо за ваш отзыв!

Сессия была описана как попытка:

откровенный рассказ о вашем опыте

к:

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

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

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

трек и адрес

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

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

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

Смены в руководстве:

Технические руководители, которые давали обещания, а затем ушли:

PayPal превратился в своего рода вращающуюся дверь, где руководители собирают отзывы разработчиков, дают обещания, а затем уходят в более эффективные компании, такие как JPMorgan, Ripple и другие финтех-компании.

Это объясняет, почему ответ на проблему на GitHub в 2025 году казался совершенно оторванным от наших отзывов в 2020 году — буквально все, кто получил эти отзывы, покинули PayPal.

2025: Новое руководство, те же проблемы

Перенесёмся в 2025 год, и мы увидим ту же самую картину. После многих лет застоя новое руководство PayPal снова обращается к общественности.

Новый генеральный директор вмешивается

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

Привет, Ник! Спасибо, что связались с нами и оставили отзыв. Мишель (копия) и её команда готовы обсудить этот вопрос с вами. Спасибо -А

Ответ Мишель Гилл

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

Большое спасибо, Ник, переводим Алекса в режим скрытой копии. Мы занимаемся этим с момента вашего предыдущего поста. Мы позвоним вам до конца недели. Не могли бы вы прислать мне свои контактные данные, чтобы кто-то из моих коллег мог с вами связаться? Мишель

Наш ответ: больше никаких встреч

Мы отказались от еще одной встречи, объяснив свое разочарование следующим:

Спасибо. Однако мне кажется, что звонок ничего не даст. Вот почему... Я уже звонил, но это ни к чему не привело. Я потратил больше двух часов на разговоры со всей командой и руководством, но ничего не произошло... Куча писем туда-сюда. Абсолютно ничего. Обратная связь ни к чему не привела. Я годами пытался добиться, чтобы меня выслушали, но всё равно ничего не вышло.

Ответ Марти Бродбека на чрезмерную инженерию

Затем ко мне обратился Марти Бродбек, возглавляющий отдел потребительских технологий в PayPal:

Привет, Ник! Это Марти Бродбек. Я возглавляю отдел разработки потребительских продуктов в PayPal и занимаюсь разработкой API для компании. Не могли бы вы обсудить проблему, с которой вы столкнулись, и как мы можем помочь?

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

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

Это совершенно неправильный подход. Нам не нужны месяцы разработки сложной архитектуры. Нам нужна одна простая конечная точка REST, которая выводит список подписок — то, что должно было существовать ещё с 2014 года.

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

Противоречие «простого CRUD»

Когда мы указали, что это базовая функциональность CRUD, которая должна была существовать с 2014 года, ответ Марти был красноречив:

Простые операции Crud являются частью основного API, мой друг, так что это не займет месяцы разработки.

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

Этот ответ показывает, что он не понимает свой API. Если «простые CRUD-операции являются частью основного API», то где находится конечная точка для листинга подписок? Мы ответили:

Если «простые CRUD-операции являются частью основного API», то где находится конечная точка для листинга подписок? Разработчики просили об этой «простой CRUD-операции» с 2014 года. Прошло уже 11 лет. У всех остальных платёжных систем эта базовая функциональность есть с самого начала.

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

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

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

Эта тенденция объясняет, почему команды PayPal в 2025 году, похоже, совершенно не следят за обширной обратной связью, предоставленной в 2020 году: люди, которые получали эту обратную связь, ушли, а новое руководство повторяет те же ошибки.

Годы сообщений об ошибках, которые они игнорировали

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

2016: Ранние жалобы на UI/UX

Ещё в 2016 году мы публично обращались к руководству PayPal, включая Дэна Шульмана, по поводу проблем с интерфейсом и удобством использования. Это было 9 лет назад, и те же проблемы с пользовательским интерфейсом и пользовательским опытом сохраняются и по сей день.

2021: Отчет об ошибках в деловой электронной почте

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

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

Спасибо, Ник! Перехожу к BCC. @Prasy, это ваша команда ответственна за это письмо или вы знаете, кто? Фраза «Niftylettuce, LLC, мы больше не будем выставлять вам счета» наводит меня на мысль, что произошла путаница с адресом и содержанием письма.

Результат: Они действительно исправили это! Марк Стюарт подтвердил:

Только что команда уведомлений сообщила, что шаблон электронного письма был исправлен и запущен. Спасибо, что сообщили об этом. Спасибо!

Это показывает, что они МОГУТ исправить ситуацию, когда захотят — просто в большинстве случаев они предпочитают этого не делать.

2021: Предложения по улучшению пользовательского интерфейса

В феврале 2021 года мы предоставили подробный отзыв об интерфейсе панели управления, в частности о разделе «Недавние действия PayPal»:

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

Марк Стюарт переслал его команде потребительских товаров:

Спасибо! Я не уверен, какая команда отвечает за эту активность, но я переслал её руководителю отдела потребительских товаров, чтобы он помог найти нужную команду. Повторяющийся платёж в размере 0,00 долларов США, похоже, ошибка. Вероятно, стоит отфильтровать.

Результат: Так и не исправлено. В интерфейсе всё ещё отображаются эти бесполезные записи с нулевой стоимостью.

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 — это просто катастрофа. Вот с чем мы сталкиваемся каждый день:

Интерфейс PayPal настолько неудобен, что вы даже не можете закрыть уведомления.
Панель разработчика буквально заставляет вас перетаскивать ползунок, а затем через 60 секунд выдаёт выход из системы.
Ещё больше проблем с интерфейсом разработчика PayPal, демонстрирующих нарушенные рабочие процессы
Интерфейс управления подписками — он настолько плох, что нам пришлось полагаться на код для генерации продуктов и планов подписки.
Вид неисправного интерфейса подписки с отсутствующей функциональностью (невозможно легко создавать продукты/планы/подписки – и, похоже, нет возможности удалить продукты или планы после их создания в интерфейсе)
Типичные сообщения об ошибках PayPal — непонятные и бесполезные

Проблемы с SDK

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

Нарушения политики безопасности контента

Их SDK требует наличия unsafe-inline и unsafe-eval в вашем CSP, заставляя вас поставить под угрозу безопасность вашего сайта.

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

Сам Марк Стюарт признался:

Согласен, что существует абсурдное количество устаревших и новых API. Действительно сложно понять, на что обратить внимание (даже нам, работающим здесь).

Уязвимости безопасности

Реализация двухфакторной аутентификации (2FA) в PayPal отсталая. Даже при включённых приложениях TOTP они принудительно проверяют SMS, что делает аккаунты уязвимыми для атак с подменой SIM-карт. Если у вас включён TOTP, он должен использовать только его. В качестве резервного варианта следует использовать электронную почту, а не SMS.

Авария управления сеансом

Их панель разработчика выдаёт выход из системы через 60 секунд бездействия. Попробуйте заняться чем-нибудь полезным, и вы постоянно будете проходить через этапы: вход → капча → двухфакторная аутентификация → выход → повтор. Используете VPN? Удачи.

Июль 2025: Последняя капля

После 11 лет одних и тех же проблем переломный момент наступил во время планового переноса учётной записи. Нам нужно было перейти на новый счёт PayPal, соответствующий названию нашей компании «Forward Email LLC», для более точной бухгалтерской отчётности.

То, что должно было быть простым, превратилось в полную катастрофу:

  • Первоначальное тестирование показало, что всё работает корректно.
  • Спустя несколько часов PayPal внезапно заблокировал все платежи по подписке без предупреждения.
  • Клиенты не могли платить, что создавало путаницу и создавало дополнительную нагрузку на службу поддержки.
  • Служба поддержки PayPal давала противоречивые ответы, утверждая, что аккаунты были верифицированы.
  • Мы были вынуждены полностью прекратить платежи через PayPal.
Ошибка, которую видели клиенты при попытке оплаты — никаких объяснений, никаких журналов, ничего.
Служба поддержки PayPal утверждает, что всё в порядке, хотя платежи полностью прекратились. В последнем сообщении говорится, что они «восстановили некоторые функции», но по-прежнему просят дополнительную неуточненную информацию — классический пример поддержки PayPal.
Процесс подтверждения личности, который якобы ничего не «исправил»
Расплывчатое сообщение, и решение так и не найдено. Никакой информации, уведомлений или каких-либо дополнительных сведений о том, какая информация требуется. Служба поддержки молчит.

Почему мы не можем просто отказаться от PayPal

Несмотря на все эти проблемы, мы не можем полностью отказаться от PayPal, поскольку для некоторых клиентов PayPal — единственный способ оплаты. Как написал один из клиентов на нашем форуме страница статуса:

PayPal — мой единственный вариант оплаты

Мы вынуждены поддерживать неисправную платформу, поскольку 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: эта сумма будет автоматически списана с вашего счёта. Пожалуйста, немедленно свяжитесь с нами по телефону [ТЕЛЕФОН]»
  • «Счёт от [НАЗВАНИЕ КОМПАНИИ] ([ИДЕНТИФИКАТОР ЗАКАЗА])»
  • Различные варианты с разными номерами телефонов и поддельными идентификаторами заказов

Эти письма часто приходят с хостов 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.

Исследователь отметил:

«Кажется, 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} - Оформить ОДНУ подписку (если известен 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 лет халатности

Самый ранний задокументированный отчет об этой проблеме появился на 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 сентября 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 г. (архивировано) зафиксированы те же самые проблемы:

«Проблема начала проявляться около двух недель назад и затрагивает не все заказы. Наиболее распространённой из них, похоже, является ошибка 404 при захвате.»

Торговец описывает ту же схему, которая наблюдалась при пересылке электронных писем:

«После попытки перехватить заказ PayPal возвращает ошибку 404. При получении сведений о заказе: {'id': 'ID', 'intent': 'CAPTURE', 'status': 'COMPLETED', ..., 'final_capture': true, ...} **Никаких следов успешного перехвата с нашей стороны не обнаружено».

Катастрофа надежности Webhook

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

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