YITH WooCommerce Paypal Adaptive Payments - Плагин WordPress

Руководство по настройке YITH WooCommerce Paypal Adaptive Payments для WooCommerce

YITH WooCommerce Paypal Adaptive Payments - это не обычный платежный шлюз для одного магазина, а инструмент для старой модели распределения платежей между владельцем WooCommerce-сайта и несколькими получателями. В этом руководстве разберём, как оценить пригодность плагина, что проверить перед установкой, как настроить получателей и комиссии, чем отличаются режимы Parallel и Chained, как провести тестовый заказ и где искать причины ошибок.

Главный нюанс продукта - его зависимость от PayPal Adaptive Payments. Официальная страница YITH прямо указывает, что плагин больше не продаётся, потому что PayPal прекратил развитие этого сервиса для новых подключений. Поэтому материал полезнее всего для владельцев сайтов, у которых уже есть рабочий доступ к Adaptive Payments, архивная установка плагина или задача аккуратно проверить старый магазин перед миграцией.

Руководство не заменяет договорённости с платёжным провайдером и не обещает, что новый аккаунт PayPal сможет включить Adaptive Payments. Наоборот, здесь упор на безопасную проверку: сначала подтвердить доступность сервиса, затем настроить тестовую среду, только потом включать разделение платежей на живом магазине.

Что решает плагин и почему его нельзя включать вслепую

Обычный WooCommerce-заказ обычно оплачивается на один торговый аккаунт: покупатель платит магазину, а владелец сайта уже сам рассчитывается с партнёрами, авторами, поставщиками или продавцами. YITH WooCommerce Paypal Adaptive Payments был создан для другой ситуации - когда сумму заказа нужно разложить между несколькими PayPal-получателями по заданным долям.

Классический пример - магазин цифровых товаров, где один курс продаётся совместно двумя авторами, или небольшой маркетплейс, где администратор удерживает комиссию, а остальная часть уходит продавцу. Плагин позволяет задать получателей и проценты, а затем использовать PayPal Adaptive Payments для распределения денег при оплате заказа.

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

Первое решение до установки - понять, есть ли у вашего PayPal-аккаунта уже действующий доступ к Adaptive Payments. Если доступа нет, плагин не станет современной заменой PayPal Payouts, Stripe Connect или PayPal Commerce Platform.

В этой статье мы будем рассматривать продукт как наследуемое решение. Если магазин запускается с нуля, правильнее сразу сравнить современные варианты выплат и маркетплейс-платежей. Если же у вас старый проект с работающим Adaptive Payments, руководство поможет настроить и проверить его аккуратнее.

Кому подходит такой сценарий разделения платежей

Плагин имеет смысл там, где разделение денег связано с самим заказом, а не только с отчётностью. Если владелец магазина хочет раз в месяц вручную выгружать CSV и переводить партнёрам деньги, Adaptive Payments может быть избыточным. Если же нужна автоматизация распределения по правилам, продукт закрывает более узкую задачу.

Подходящие случаи

YITH WooCommerce Paypal Adaptive Payments может быть уместен для сайтов, где уже подтверждён доступ к PayPal Adaptive Payments и где платежи должны раскладываться между несколькими участниками сделки. Особенно важно, чтобы получатели заранее знали, как именно покупатель будет видеть оплату и кто считается продавцом в конкретном режиме.

• Магазин продаёт совместные цифровые продукты, например курс, музыку, шаблон, пакет файлов или консультацию с несколькими авторами.
• Небольшой маркетплейс использует YITH WooCommerce Multi Vendor и хочет автоматизировать выплаты продавцам в старой инфраструктуре.
• Владелец сайта удерживает комиссию, а остаток суммы должен уходить партнёру без отдельного ручного перевода.
• Партнёры работают с PayPal, готовы предоставить корректные аккаунты получателей и понимают ограничения старого API.
• Магазин может тестировать оплату в песочнице и хранить журнал проверок по каждому изменению настроек.

Когда лучше искать другой путь

Если вы только проектируете маркетплейс, этот плагин редко будет лучшей отправной точкой. Новые подключения Adaptive Payments недоступны для обычного сценария, а современные маркетплейсы чаще строятся на PayPal Payouts, PayPal Commerce Platform, Stripe Connect или специализированных multi-vendor решениях.

• У вас нет уже одобренного Adaptive Payments в PayPal.
• Нужны подписки, регулярные платежи или сложная работа с продлениями - официальный источник YITH указывает, что плагин не управляет recurring payments.
• Магазин работает на современных версиях WordPress и WooCommerce без возможности проверить совместимость старой версии плагина на тестовом стенде.
• Нужны правила KYC, онбординг продавцов, удержания, споры и современная платёжная отчётность уровня маркетплейса.
• Вы не готовы разбирать статусы PayPal, IPN-уведомления, журналы WooCommerce и ошибки получателей.

Главный практический вывод простой: продукт полезен не всем магазинам с несколькими продавцами, а только тем, у кого уже есть право и техническая возможность использовать старый Adaptive Payments.

Как работает связка WooCommerce, PayPal Adaptive Payments и получателей

Чтобы настройка не превратилась в угадывание, полезно представить цепочку целиком. WooCommerce создаёт заказ, плагин выбирает платежный метод Adaptive Payments, получает список получателей и комиссий, отправляет покупателя в PayPal, а затем ждёт подтверждение платежа и статусы распределения. Если одна часть цепочки не готова, заказ может зависнуть, комиссия не уйти или покупатель увидит не тот сценарий оплаты.

Роль WooCommerce

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

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

Роль PayPal Adaptive Payments

Adaptive Payments исторически поддерживал несколько схем платежей: простой платёж одному получателю, параллельный платёж нескольким получателям и цепочный платёж через основного получателя. Для YITH важны именно сценарии, где деньги распределяются между владельцем магазина и партнёрами.

PayPal при этом не просто «принимает оплату». Он проверяет доступность сервиса для аккаунта, корректность получателей, статус приложения, параметры запроса, валюту, ограничения аккаунтов и способность отправить уведомление обратно на сайт. Поэтому в диагностике важны не только настройки плагина, но и PayPal-журналы.

Роль получателей и комиссий

Получатель - это PayPal-аккаунт партнёра, продавца или другого участника, которому должна уйти часть суммы. В настройках YITH заявлены общие receiver settings и возможность указать отличающиеся получатели на уровне отдельного товара. Такая логика нужна, когда один набор партнёров действует для большинства товаров, а у отдельных продуктов есть свои авторы или продавцы.

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

Что проверить до установки на рабочий магазин

Подготовка важнее самой установки. Плагин относится к платежной инфраструктуре, поэтому сначала нужно снять риски: совместимость, доступ к PayPal, резервная копия, тестовая среда и понятная схема комиссий. Без этого даже правильные настройки могут дать непредсказуемый результат на современном сайте.

Доступность PayPal Adaptive Payments

Проверьте, что ваш PayPal-аккаунт действительно может использовать Adaptive Payments. Официальные источники YITH и PayPal указывают, что сервис не открыт для новых обычных подключений. Если у вас нет старого доступа, не тратьте время на подбор настроек в WordPress - сначала выясните вопрос у PayPal.

• Уточните, есть ли у аккаунта PayPal Business доступ к нужному сервису.
• Проверьте наличие требуемых API-данных и App ID для старой интеграции.
• Убедитесь, что все получатели имеют PayPal-аккаунты, готовые принимать платежи.
• Заранее решите, что делать, если Adaptive Payments недоступен: ручные выплаты, PayPal Payouts, Stripe Connect или другой маркетплейс-процесс.

Совместимость сайта

Официальная карточка YITH указывает старые границы совместимости по WordPress, WooCommerce и PHP. В статье не имеет смысла превращать это в список версий, потому что пользователь должен смотреть актуальные условия своей установки и архивного пакета. Практически это означает одно: не ставьте плагин сразу на живой магазин с современным стеком.

Сделайте копию сайта на тестовом домене, включите отладку WooCommerce-журналов и проверьте оформление заказа на той же теме и с теми же основными плагинами. Особенно внимательно смотрите на плагины оформления заказа, валют, налогов, multi-vendor, кэширования и безопасности.

Безопасность платежной проверки

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

Если сайт уже принимает реальные заказы, включайте платежный шлюз только после теста в закрытой среде и после проверки возврата покупателя на страницу order received.

Схема комиссий до кликов в админке

Подготовьте простую таблицу вне WordPress: товар, главный получатель, дополнительные получатели, процент каждого получателя, режим платежа, задержка выплаты, ожидаемый статус заказа. Такая таблица помогает избежать типичной ошибки, когда настройки выглядят заполненными, но бизнес-логика непонятна.

Установка и первая проверка после активации

Сам процесс установки похож на установку любого премиального WordPress-плагина: загрузить ZIP в админке, активировать, затем перейти к настройкам WooCommerce. Но здесь важно не торопиться с включением платежного метода для покупателей. Сначала нужно убедиться, что плагин появился в правильном разделе и не ломает оформление заказа.

Базовая установка

1. Откройте админ-панель WordPress и перейдите в Plugins - Add New - Upload Plugin.
2. Загрузите ZIP-архив плагина из вашего легального источника и нажмите Install Now.
3. После установки нажмите Activate.
4. Перейдите в WooCommerce - Settings - Payments и проверьте, появился ли платежный метод PayPal Adaptive Payments.
5. Не включайте живые платежи, пока не заполнены API-данные и не подготовлена песочница.

Если метод не появился, сначала проверьте системные требования, активность WooCommerce, отсутствие фатальных ошибок в журнале PHP и совместимость с текущей версией магазина. Не пытайтесь лечить проблему случайным отключением всех плагинов на рабочем сайте - для этого нужен тестовый стенд.

Проверка после активации

После активации откройте список платежных методов WooCommerce. Метод должен быть виден в настройках, но покупатель не обязан видеть его на публичном сайте, пока вы не включили его осознанно. Проверьте, что страница оформления заказа открывается, стандартные платежные методы остались на месте и в консоли браузера нет ошибок, вызванных сторонними скриптами checkout.

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

Почему первый тест должен быть простым

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

Настройка платежного шлюза, получателей и тестового режима

Раздел настройки должен быть самым аккуратным. Официальная страница YITH показывает несколько групп экранов: gateway settings, receiver settings, product receiver, cron settings, endpoint settings, chained method settings и parallel method settings. Названия могут отличаться в вашей сборке, но логика остаётся похожей: сначала включается шлюз и API, затем задаются получатели, затем выбирается режим распределения, затем проверяются статусы и ручные действия.

Gateway settings: включение и публичное название

В настройках шлюза обычно проверяют флажок включения, название метода оплаты для покупателя, описание на checkout и API-данные. Название должно быть понятным, но не перегруженным техническими словами. Покупателю не обязательно знать, что внутри используется Adaptive Payments, если это не влияет на его выбор и юридическую прозрачность.

API-данные вводите только в защищённой админке и не отправляйте их в сторонние инструменты. Если сайт обслуживает команда, ограничьте доступ к платежным настройкам. Для отладки лучше использовать журналы WooCommerce и PayPal, а не пересылать секреты в переписке.

Что включать сразу

• Включите тестовый режим, если он доступен и вы проверяете песочницу.
• Заполните API-данные и App ID только для соответствующей среды: sandbox к sandbox, live к live.
• Укажите понятное название платежного метода на странице оформления заказа.
• Включите журнал отладки только на время диагностики, если он есть в вашей версии.

Что не трогать без причины

Не меняйте одновременно режим платежа, задержку комиссий, endpoint и набор получателей. Делайте одно изменение, сохраняйте настройки, затем выполняйте тестовый заказ. Такой подход медленнее, но он позволяет понять, какая настройка повлияла на результат.

Receiver settings: общие получатели и проценты

В receiver settings задаются участники, которые получают долю от продаж. Для типового сайта сначала настройте минимальный набор: владелец магазина как основной участник и один тестовый партнёр. Когда этот сценарий подтвердится, добавляйте остальных получателей.

Сумма комиссий не должна быть предметом догадки. До сохранения настроек проверьте бизнес-таблицу: кто получает долю, почему именно такую, что происходит с остатком, кто оплачивает комиссию PayPal и как отражается возврат. Если правила выплат не согласованы вне WordPress, плагин не решит организационную проблему.

Product receiver: когда нужны правила на уровне товара

Официальная карточка YITH указывает возможность задавать специальные получатели и комиссии для конкретных товаров. Это полезно, если общий набор партнёров не подходит ко всем продуктам. Например, один цифровой курс продаётся с участием автора А, другой - с автором Б, а магазин удерживает одинаковую административную комиссию.

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

Cron и задержка выплат

YITH заявляет возможность задержать выплату комиссий в режиме Chained. Такой режим может быть полезен, если магазин хочет сначала дождаться обработки заказа, проверки риска или истечения внутреннего периода. Но задержка добавляет ещё один слой диагностики: нужно понимать, кто уже получил деньги, кто ждёт, какой процесс запускает выплату и есть ли возможность ручного действия.

Если в интерфейсе есть cron settings, проверьте, что WordPress cron действительно выполняется на вашем хостинге. На малопосещаемых сайтах встроенный cron может срабатывать редко. Для живого магазина лучше обсудить с администратором сервера системный cron, но не добавлять команды вслепую без понимания текущей конфигурации.

Parallel и Chained: какой режим выбрать для магазина с партнёрами

Самый продуктовый выбор в YITH WooCommerce Paypal Adaptive Payments - режим распределения платежа. Parallel и Chained решают похожую задачу, но по-разному показывают участников покупателю и по-разному распределяют ответственность между получателями.

Parallel Payments

В Parallel Payments покупатель отправляет один платёж, который распределяется между несколькими получателями. По смыслу это прозрачная модель: участники платежа видны как отдельные получатели. Такой вариант подходит, если покупатель должен понимать, что деньги уходят разным сторонам, например нескольким продавцам в одной корзине.

Плюс режима - прозрачность и немедленное распределение. Минус - покупатель может увидеть больше технической информации о получателях, чем вы ожидали. Для B2B, партнёрских товаров или явного маркетплейса это нормально. Для магазина, где покупатель воспринимает площадку как единого продавца, такой режим может быть менее удобен.

Chained Payments

В Chained Payments есть основной получатель, а остальные получают свою долю через цепочку. Официальная страница YITH описывает этот режим как сценарий, где покупатель видит вас как единого продавца, а комиссии затем распределяются партнёрам. Для бренда магазина это может выглядеть аккуратнее.

Минус - больше ответственности у основного получателя и больше нюансов с задержкой, ручной выплатой, статусами и возвратами. Если вам важна простая диагностика, сначала протестируйте Chained на минимальном заказе и отдельно проверьте задержанные комиссии.

Как принять решение

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

Товарные правила и интеграция с YITH WooCommerce Multi Vendor

Отдельная ценность продукта - работа не только с общими получателями, но и с товарными правилами и связкой с YITH WooCommerce Multi Vendor. Именно здесь плагин отличается от простого шлюза оплаты: он пытается связать заказ WooCommerce с логикой продавцов, партнёров и комиссий.

Когда использовать правила на уровне продукта

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

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

Корзина с несколькими продавцами

Официальная карточка YITH указывает, что если в корзине куплены товары от нескольких продавцов, PayPal Adaptive Payments может становиться единственным доступным платежным методом. Это логично: если заказ должен быть сразу разделён между участниками, обычный шлюз одного получателя не знает, как разложить деньги.

Проверьте этот сценарий отдельно. Добавьте в корзину товары разных продавцов или партнёров и посмотрите, какие платежные методы видит покупатель. Если исчезают альтернативные методы, убедитесь, что это ожидаемая логика, а не конфликт с настройками WooCommerce Payments или условными платежными шлюзами.

Что важно для Multi Vendor

YITH WooCommerce Multi Vendor исторически был связан с выплатами продавцам, но YITH также отдельно сообщает, что опции MassPay и Adaptive Payments были удалены из новых версий Multi Vendor после прекращения поддержки этих методов PayPal. Поэтому связку нужно проверять по фактической версии и документации вашей установки.

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

Практический пример: тестовый заказ с разделением комиссии

Ниже - безопасный сценарий, который помогает понять, как пользоваться YITH WooCommerce Paypal Adaptive Payments на практике. Он не требует сложного маркетплейса и подходит для первичной проверки: один тестовый товар, один партнёр-получатель, песочница и понятная ожидаемая доля.

Цель

Проверить, что заказ WooCommerce может быть оплачен через Adaptive Payments, плагин применяет правильного получателя, покупатель возвращается на страницу успешного заказа, а администратор видит ожидаемый статус платежа и комиссии.

Подготовка

• Есть тестовая копия сайта с активным WooCommerce и плагином YITH.
• Есть PayPal sandbox-аккаунты для покупателя, владельца магазина и партнёра.
• В настройках шлюза включён тестовый режим и заполнены sandbox API-данные.
• Создан простой виртуальный или физический товар с минимальной ценой.
• В таблице заранее записано, какую долю должен получить партнёр.

Шаги

1. Откройте товар в админке и задайте специального получателя, если проверяете product receiver.
2. Сохраните товар и очистите только тот кэш, который влияет на страницу товара и checkout.
3. Откройте сайт как покупатель в отдельном браузере или приватном окне.
4. Добавьте тестовый товар в корзину и перейдите к оформлению заказа.
5. Выберите платежный метод Adaptive Payments, если он не выбран автоматически.
6. Перейдите в PayPal sandbox, завершите оплату и вернитесь на сайт.
7. Откройте заказ в WooCommerce - Orders и проверьте статус, заметки заказа и журнал платежного шлюза.

Ожидаемый результат

Покупатель должен попасть на страницу подтверждения заказа, WooCommerce должен получить подтверждение платежа, а в PayPal sandbox должны быть видны операции, соответствующие выбранному режиму. Если используется Chained с задержкой, вторичная комиссия может не уйти сразу - это нормально только тогда, когда задержка действительно включена и видна в настройках.

Нюанс, который часто мешает

Если заказ оплачен в PayPal, но WooCommerce остаётся в ожидании оплаты, не меняйте статус вручную как окончательное решение. Сначала проверьте уведомления PayPal, доступность сайта снаружи, SSL, журналы WooCommerce и ошибки IPN. Ручная смена статуса может скрыть проблему, но не исправит следующий заказ.

Как проверить результат после настройки

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

Проверка в WooCommerce

Откройте заказ и посмотрите статус, заметки заказа, выбранный платежный метод и транзакционные данные. Если включены журналы, найдите запись по времени тестовой оплаты. Журнал должен помогать понять цепочку, а не быть постоянным включённым режимом на живом сайте.

• Статус заказа соответствует типу товара и настройкам WooCommerce.
• В заметках заказа нет повторяющихся ошибок или нескольких попыток одного платежа.
• Покупатель получил стандартное письмо WooCommerce только после подтверждения оплаты.
• Склад, если он включён, уменьшился после фактического подтверждения, а не раньше.

Проверка в PayPal

В PayPal sandbox или live-аккаунте проверьте операции по всем участникам. Для Parallel обращайте внимание на несколько получателей. Для Chained смотрите основного получателя, вторичных получателей, задержки и возможные статусы ожидания.

Если PayPal показывает ошибку получателя, неподтверждённый аккаунт, ограничение сервиса или отказ в API, это не ошибка дизайна checkout. Это платёжное ограничение, которое нужно решать на стороне PayPal-аккаунтов и доступов.

Проверка в личном кабинете получателя

Официальная страница YITH показывает сценарий, где продавцы могут видеть статусы комиссий в разделе My Account. Если в вашей установке такая вкладка включена, войдите под тестовым пользователем-получателем и проверьте, что сумма и статус понятны. Если используется Multi Vendor, дополнительно проверьте кабинет продавца.

Хороший тест считается завершённым только тогда, когда совпали три уровня: статус WooCommerce, операции PayPal и ожидаемая таблица комиссий.

Ограничения, безопасность и план миграции

Из-за статуса PayPal Adaptive Payments этот раздел не второстепенный. Для многих сайтов главная ценность руководства - не «как включить», а «как понять, стоит ли продолжать использовать». Старый платёжный сервис может работать у существующих пользователей, но это не делает его хорошей основой для нового магазина.

Ограничение по новым подключениям

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

Ограничение по подпискам

YITH прямо указывает, что плагин не управляет recurring payments. Если магазин продаёт подписки, членства, регулярные поставки или услуги с продлением, нужно выбирать решение, которое поддерживает такие сценарии на уровне платежного провайдера и WooCommerce-расширения.

IPN, SSL и сетевые требования

Adaptive Payments связан с уведомлениями PayPal о событиях платежа. Официальная документация PayPal описывает IPN как механизм, который сообщает сайту о платежах, возвратах, спорах и других событиях. YITH также фиксировал проблемы песочницы и live-среды, связанные с TLS 1.2, SHA-256 и HTTP/1.1. Для практики это означает, что старый сервер, устаревшая библиотека SSL или блокировка входящих уведомлений могут ломать статусы заказов.

План миграции

Если магазин зависит от YITH WooCommerce Paypal Adaptive Payments, составьте план выхода. Он не обязан быть срочным, но должен быть документирован. Для PayPal-сценария проверьте PayPal Payouts или PayPal Commerce Platform. Для карточных платежей и моментального разделения комиссий посмотрите Stripe Connect. Для полноценного маркетплейса сравните, где будут храниться продавцы, комиссии, отчёты и выплаты.

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

Диагностика ошибок оплаты, комиссий и статусов

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

Платёж прошёл в PayPal, но заказ остался в ожидании

Симптом: покупатель оплатил, деньги или sandbox-операция видны в PayPal, но заказ WooCommerce не перешёл в ожидаемый статус. Возможная причина - сайт не получил или не обработал уведомление PayPal, SSL/сервер блокирует запрос, IPN пришёл с ошибкой, другой плагин вмешался в статус заказа.

Что проверить: журналы WooCommerce, историю IPN в PayPal, доступность сайта по HTTPS, ошибки firewall, режим обслуживания, плагины безопасности и кэш checkout. Исправление: восстановить доставку уведомлений, временно отключить конфликтующий модуль на тестовом стенде, затем повторить заказ. Не делайте ручную смену статуса постоянной процедурой.

Получатель не получил комиссию

Симптом: заказ завершён, владелец магазина видит оплату, но партнёр не видит свою долю. Возможная причина - неверный PayPal-аккаунт получателя, неподтверждённый аккаунт, превышение долей, ошибка режима Chained, задержка комиссии или ограничение PayPal.

Что проверить: receiver settings, правило на уровне товара, режим Parallel/Chained, включённую задержку, статус получателя в PayPal и журналы. Исправление: исправить аккаунт получателя, провести новый маленький тестовый заказ, а старый спорный случай сверить вручную по PayPal-операциям и внутренним договорённостям.

Платежный метод не показывается на checkout

Симптом: в админке метод есть, но покупатель не видит его при оформлении заказа. Возможная причина - метод выключен, не заполнены обязательные настройки, включены условия показа платежей, в корзине нет товаров с подходящими правилами, другой плагин ограничивает шлюзы или YITH показывает Adaptive Payments только для определённого multi-vendor сценария.

Что проверить: WooCommerce - Settings - Payments, страну и валюту тестового покупателя, содержимое корзины, условные платежные методы, правила multi-vendor и кэш checkout. Исправление: начать с простого товара и одного покупателя, отключить условные ограничения на тестовой копии, затем вернуть правила по одному.

Ошибка песочницы или соединения с PayPal

Симптом: sandbox-тест не проходит, хотя API-данные выглядят верными. Возможная причина - несовпадение sandbox/live данных, устаревший TLS на сервере, блокировка исходящих запросов, неверный App ID или недоступный Adaptive Payments для аккаунта.

Что проверить: режим среды, API-данные, SSL/TLS на сервере, разрешение исходящих HTTPS-запросов, ответ PayPal и сообщения в журнале. Исправление: разделить sandbox и live-настройки, обновить серверную среду, связаться с PayPal по доступности сервиса. Если PayPal не даёт доступ, настройками WordPress это не исправить.

Комиссии рассчитались не так, как ожидалось

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

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

После обновления перестала работать связка с Multi Vendor

Симптом: до обновления комиссии работали, после обновления настройки исчезли или заказы не распределяются. Возможная причина - обновлённый marketplace-плагин больше не поддерживает старые опции Adaptive Payments, изменилась совместимость или отключился связующий модуль.

Что проверить: список изменений плагинов, резервную копию, тестовый стенд, наличие старых настроек, официальные заметки YITH о прекращении поддержки MassPay и Adaptive Payments в новых версиях Multi Vendor. Исправление: откатить на резервной копии, если это критический магазин, затем планировать миграцию на современный вариант выплат.

Полезные настройки для стабильной работы магазина

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

Минимальный регламент перед изменениями

• Перед изменением платежных настроек делайте резервную копию и фиксируйте текущее состояние.
• Меняйте один параметр за раз: режим, получателя, процент или задержку.
• После каждого изменения проводите тестовый заказ с маленькой суммой.
• Храните таблицу ожидаемых комиссий отдельно от WordPress, чтобы быстро сверять результат.
• Отключайте debug log после диагностики, чтобы не копить лишние данные.

Что делать с кэшем и оптимизацией

Страницы корзины, оформления заказа и личного кабинета не должны агрессивно кэшироваться. Если на сайте есть кэш-плагин, CDN или серверный кэш, исключите checkout, cart, order received и my account. Это стандартная практика для WooCommerce, но для платежного распределения она особенно важна: покупатель должен видеть актуальный метод оплаты, а сайт должен корректно обработать возврат после PayPal.

Как откатывать спорную настройку

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

Когда YITH WooCommerce Paypal Adaptive Payments будет удачным выбором

Этот плагин имеет смысл рассматривать как инструмент поддержки старого, уже одобренного PayPal Adaptive Payments-сценария. Он может помочь магазину распределять доход между партнёрами, задавать получателей, использовать Parallel или Chained, задерживать комиссии в подходящем режиме и проверять выплаты вручную. Но он не должен быть основой нового проекта без подтверждённого доступа PayPal.

Если ваш сайт уже работает на такой связке, подходите к изменениям осторожно: тестовая копия, маленький заказ, проверка WooCommerce-статусов, PayPal-операций и комиссий получателей. Если магазин только запускается, сравните YITH PayPal Payouts, YITH Stripe Connect, YITH Multi Vendor, Dokan PayPal Marketplace и WooCommerce Product Vendors с учётом вашей страны, провайдера, модели продавцов и требований к выплатам.

После проверки совместимости, доступов и сценария тестового заказа можно получить файл YITH WooCommerce Paypal Adaptive Payments и развернуть его сначала на безопасной копии сайта. Так вы поймёте, подходит ли старый механизм вашему магазину, не рискуя живыми заказами и деньгами партнёров.