На прошлой неделе я разбирал сайт одного клиента — оптовая компания, промышленные фильтры, около трёх тысяч позиций в каталоге, WooCommerce на WordPress. Сайту три года, работает нормально, но вот что меня убило: двадцать четыре активных плагина. Двадцать четыре. И это не считая mu-plugins и тех, что деактивированы «на всякий случай». Среди этих двадцати четырёх — два отдельных плагина для приёма платежей. Один для ЮKassa, второй для Тинькофф. Каждый со своими настройками, своими обновлениями, своими конфликтами. ЮKassa-плагин обновился полгода назад и сломал оформление заказа на мобильных — чекаут просто не загружался. Два дня простоя, пока разобрались. Плагин Тинькофф вообще не обновлялся больше года — и при переходе на PHP 8.2 начал сыпать deprecated-ошибками в лог на сто мегабайт в сутки.

Знакомая ситуация? Я бы удивился, если нет. Потому что это типичная боль любого, кто строит интернет-магазин на WooCommerce в России. Нам нужны российские платёжные системы — ЮKassa, Тинькофф, СБП. И для каждой — отдельный плагин с отдельным жизненным циклом, отдельными разработчиками и отдельной историей совместимости. А если у вас ещё и B2B-клиенты, которым нужно выставлять счета на юрлицо, — добро пожаловать в мир костылей, WooCommerce-хуков, переделанного чекаута и бессонных ночей.

Я долго думал, почему так получается. Почему в 2026 году приём платежей на российском WooCommerce-сайте — это квест. И ответ оказался на поверхности: никто не думает о платежах как о части единой системы. Каждый платёжный плагин — это отдельный микромир. У него свои таблицы в базе данных, свои хуки, свои JavaScript-файлы, которые грузятся на чекауте. И когда эти микромиры начинают сталкиваться друг с другом внутри одного WordPress, летят искры. Конфликты стилей, дублирование скриптов, race conditions при обработке колбэков. Я видел сайт, где одновременно два плагина пытались обработать один и тот же webhook — и заказ помечался как оплаченный дважды, что ломало складской учёт.

Когда мы проектировали модуль оплаты в COS WP Woo, идея была простая и, как мне кажется, правильная: платёжные шлюзы должны быть встроены в тот инструмент, который уже управляет магазином. Не как отдельные плагины, а как часть единой архитектуры. Один плагин — одна точка настройки — одно обновление. Звучит очевидно, но в экосистеме WordPress это почему-то революция.

И знаете, что самое удивительное? Когда я обсуждаю эту идею с владельцами магазинов, первая реакция почти всегда одинаковая: «А зачем? У меня же и так работает». Работает — пока не сломается. Пока WooCommerce не обновится до следующей мажорной версии. Пока PHP не перейдёт на новую версию. Пока ЮKassa не поменяет API. И тогда начинается паника: плагин не совместим, чекаут не работает, клиенты не могут оплатить, деньги не приходят. И в этот момент выясняется, что автор плагина — один разработчик из Новосибирска, который обновляет код в свободное от основной работы время. И ему сейчас некогда, потому что у него дедлайн на основном проекте. А у вас магазин стоит. Я не осуждаю этого разработчика — он делает большое дело, часто бесплатно. Но зависеть от одного человека в вопросе, который напрямую влияет на выручку, — это риск, который можно и нужно снимать.

Почему каждый лишний плагин — это не просто «ещё один плагин»

Давайте поговорим о том, что реально происходит, когда вы ставите отдельный плагин для приёма платежей. Это не просто файлы в папке wp-content/plugins. Это дополнительные запросы к базе данных при каждой загрузке страницы — потому что WordPress подгружает метаданные плагина, проверяет его состояние, загружает его текстовый домен для переводов. Это дополнительные HTTP-запросы на чекауте, потому что плагин тянет за собой свои CSS и JS-файлы. Это дополнительная точка отказа при обновлениях — и кто работал с WooCommerce больше года, знает, что обновления WooCommerce любят ломать плагины с завидной регулярностью.

Но дело даже не в производительности. Дело в управляемости. Когда у вас два-три отдельных платёжных плагина, вы получаете два-три отдельных интерфейса настройки. ЮKassa настраивается в одном месте, Тинькофф — в другом, ручная оплата по счёту — в третьем. И каждый раз, когда менеджер или владелец сайта хочет что-то поменять — например, включить оплату в рассрочку через Тинькофф или добавить метод оплаты для B2B-клиентов — ему нужно помнить, где что лежит. А если настраивал не он, а подрядчик полгода назад — удачи в поисках.

Я сталкивался с этим десятки раз. Звонит клиент: «У нас на сайте пропала оплата картой». Начинаешь разбираться — оказывается, обновился WooCommerce, плагин ЮKassa не совместим с новой версией, и шлюз автоматически деактивировался. Но уведомление об этом ушло на email, который никто не читает. А клиенты на чекауте видят единственный доступный способ оплаты — банковский перевод, который настроен через стандартный WooCommerce-шлюз BACS. И уходят. Потому что кто в здравом уме будет делать банковский перевод, когда хочешь купить фильтр за две тысячи рублей.

Ещё веселее становится, когда плагин платёжной системы конфликтует с чем-то другим. Я помню проект, где плагин ЮKassa конфликтовал с плагином многоязычности — при переключении языка на чекауте терялся callback URL, и оплата вечно падала с ошибкой. Или другой случай: плагин Тинькофф использовал свою версию библиотеки для работы с HTTP-запросами, которая конфликтовала с WooCommerce Subscriptions. Такие вещи невозможно предугадать, и они стреляют в самый неподходящий момент — обычно в пятницу вечером, когда идёт реклама и трафик на пике.

Вот почему мне кажется принципиально важным убирать из WordPress всё, что можно убрать, и консолидировать функциональность в одном месте. Не из жадности — мол, давайте всё запихнём в один плагин и будет монолит. Нет. Из инженерного здравого смысла. Платёжные шлюзы — это не rocket science. Это API-интеграции с чётко документированными протоколами. ЮKassa и Тинькофф имеют отличную документацию и стабильные API. Нет никакой причины, по которой это должно быть отдельным плагином с отдельной жизнью.

Что умеют встроенные шлюзы: ЮKassa, Тинькофф и B2B-методы

Когда я говорю «встроенные платёжные шлюзы», я имею в виду вот что: внутри COS WP Woo есть полноценная реализация ЮKassa, Тинькофф и трёх B2B-методов оплаты, которые регистрируются как стандартные WooCommerce Payment Gateways. Для WooCommerce они выглядят точно так же, как его встроенные шлюзы — банковский перевод или наложенный платёж. Они видны в настройках WooCommerce, на чекауте, в заказах. Но управляются из единого интерфейса, тестируются вместе, обновляются вместе.

Давайте разберёмся, что конкретно доступно и зачем это нужно.

ЮKassa — это, по сути, стандарт для онлайн-оплаты в российском e-commerce. Если у вас интернет-магазин на WooCommerce и вы принимаете платежи от физических лиц — вам нужна ЮKassa. Наш встроенный шлюз поддерживает три основных метода: оплату банковскими картами, Систему быстрых платежей и ЮMoney — электронный кошелёк. Почему именно эти три? Потому что они покрывают девяносто пять процентов сценариев. Карты — для тех, кто привык платить Visa или MasterCard (ну, или Mir, если точнее — 2026 год на дворе). СБП — для тех, кто оплачивает через мобильный банк по QR-коду, и этот способ стремительно набирает популярность, особенно для платежей до пятнадцати тысяч рублей. ЮMoney — для тех, кто пользуется кошельком ЮMoney, и таких людей тоже хватает, особенно среди аудитории 25-40 лет.

Настройка занимает буквально пару минут. Вводите Shop ID и секретный ключ из личного кабинета ЮKassa, выбираете, какие методы активировать, и всё — шлюз работает. Никаких отдельных плагинов, никаких дополнительных таблиц в базе, никаких лишних JS-файлов на чекауте. Webhook для уведомлений о платежах обрабатывается через стандартный WooCommerce callback, и заказ автоматически переводится в статус «Обработка» при успешной оплате.

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

Зачем это нужно? Представьте: вы продаёте промышленное оборудование. Клиент заказывает насос за четыреста тысяч рублей. Вы проверяете наличие на складе — а его нет, нужно заказывать у поставщика, срок три недели. Без холдирования вы бы списали деньги сразу, а потом три недели нервничали — вдруг клиент передумает и потребует возврат, а деньги уже в обороте. С холдированием деньги заблокированы на карте клиента, вы спокойно заказываете у поставщика, и списываете только когда товар реально приехал на склад и готов к отправке. Клиент тоже спокоен — он видит, что деньги не ушли, а только захолдированы. Это принципиально другой уровень доверия между покупателем и продавцом.

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

Теперь про Тинькофф. Тинькофф Эквайринг — это второй по популярности платёжный шлюз в России после ЮKassa, и для определённых типов бизнеса он даже предпочтительнее. Во-первых, условия эквайринга у Тинькофф зачастую лучше — ниже комиссия за транзакцию, особенно для среднего бизнеса с оборотом от миллиона рублей в месяц. Во-вторых, у Тинькофф есть встроенная рассрочка — и это убийственная фича для магазинов, которые продают дорогие товары.

Встроенный шлюз Тинькофф в COS WP Woo работает по тому же принципу: вводите Terminal Key и пароль из личного кабинета Тинькофф, и шлюз готов. Поддерживается стандартный эквайринг — оплата картой, и рассрочка — когда клиент может разбить платёж на несколько месяцев без процентов. Рассрочку оплачивает магазин в виде комиссии Тинькофф, но для товаров стоимостью от десяти-пятнадцати тысяч рублей это абсолютно окупается — конверсия вырастает на двадцать-тридцать процентов, потому что клиенту психологически проще заплатить три тысячи в месяц, чем отдать пятнадцать тысяч сразу.

Тинькофф тоже поддерживает двухстадийную оплату, и наш шлюз это реализует. Логика такая же: холдирование, подтверждение списания из карточки заказа, автоматическая отмена холда при отмене заказа. Единообразие — это важно. Менеджеру не нужно запоминать, что для ЮKassa подтверждение работает так, а для Тинькофф — по-другому. Интерфейс одинаковый, кнопки одинаковые, логика одинаковая.

А вот дальше мы переходим к тому, что отличает COS WP Woo от всех остальных решений, — B2B-методы оплаты. И это, честно говоря, та область, ради которой я вообще начал писать эту статью.

B2B-оплата: когда «оплата картой» не работает

Если вы работаете только с розничными клиентами — физическими лицами, которые заходят на сайт, кладут товар в корзину и оплачивают картой, — вам, возможно, хватит ЮKassa и Тинькофф. Но стоит вам начать работать с юридическими лицами, как вы попадаете в совершенно другой мир. Мир, где никто не платит картой. Где оплата происходит по счёту, через расчётный счёт компании. Где от оформления заказа до реального поступления денег может пройти неделя, а то и две. И где стандартные WooCommerce-шлюзы не просто неудобны — они принципиально не подходят.

Я видел, как компании пытаются решить эту проблему. Самый распространённый вариант — менеджер формирует счёт вручную в 1С или в Excel, отправляет его клиенту на email, и ждёт. Когда деньги приходят — вручную меняет статус заказа в WooCommerce. Если заказов пять в день — терпимо. Если пятьдесят — это ад. И ошибки неизбежны: забыли поменять статус, перепутали заказ, счёт ушёл не с теми реквизитами.

Другой вариант — стандартный WooCommerce BACS (Bank Account/Check Payments). Технически это банковский перевод. Вы указываете реквизиты компании в настройках, клиент видит их на странице «Спасибо за заказ» и в email. Но это текстовая информация — никакого нормального счёта. Никаких реквизитов покупателя. Никакого автоматического формирования документа. Для B2B это просто несерьёзно. Когда бухгалтер компании-покупателя получает email с текстом «Переведите 47 800 рублей на расчётный счёт такой-то», он как минимум удивится. Ему нужен нормальный счёт — с ИНН, КПП, юридическим адресом, реквизитами банка, печатью и подписью. Такой документ, который можно распечатать, подшить в папку и предъявить на проверке.

В COS WP Woo мы реализовали три метода оплаты для B2B, и каждый решает свою задачу.

Первый — оплата по счёту, Invoice Gateway. Это именно то, что нужно большинству B2B-компаний. Клиент на чекауте выбирает «Оплата по счёту», указывает реквизиты своей компании — или они подтягиваются автоматически из его профиля, если он уже зарегистрирован как B2B-пользователь. После оформления заказа система автоматически формирует счёт на оплату — полноценный документ с реквизитами продавца и покупателя, номером счёта, датой, перечнем товаров, суммой и банковскими реквизитами. Этот счёт можно скачать в формате PDF прямо из личного кабинета или из email-уведомления. Менеджер может отправить счёт повторно, если клиент потерял письмо. Когда оплата приходит — статус заказа меняется, и клиент получает уведомление.

Вот в чём штука: это не просто текстовый шаблон. Это реальный документ, который формируется на основании данных заказа. Реквизиты продавца берутся из настроек — ИНН, КПП, ОГРН, юридический адрес, банковские реквизиты. Реквизиты покупателя — из профиля пользователя или из полей чекаута. Номер счёта генерируется автоматически с учётом нумерации, которую вы настроили. Я знаю, что для бухгалтерии это звучит как мелочь, но когда таких счетов формируется сто в месяц — автоматизация экономит десятки часов.

Второй метод — Purchase Order, или заказ на оплату. Это более свободная форма B2B-оплаты, которая распространена в международной практике и всё чаще встречается в крупных российских компаниях. Суть: покупатель указывает номер своего внутреннего заказа на закупку — Purchase Order number, или PO. Это документ, который прошёл согласование внутри компании-покупателя, и по которому будет произведена оплата. Для продавца это означает, что заказ подтверждён, оплата будет — но не сейчас, а после того, как покупатель обработает документы у себя. Обычно срок оплаты — от четырнадцати до тридцати дней.

Этот метод особенно востребован в промышленных компаниях, где закупки проходят через несколько этапов согласования. Менеджер по закупкам создаёт заявку, начальник отдела утверждает, финансовый директор подписывает, бухгалтерия формирует платёжку. На весь этот процесс может уйти две-три недели. И всё это время заказ висит в WooCommerce в статусе «Ожидает оплаты» с привязанным PO-номером. Менеджер продавца видит этот номер и знает, что оплата в процессе. А когда деньги приходят — подтверждает заказ.

Третий метод — внутренний кошелёк, Wallet Gateway. Это вообще отдельная история, и она, на мой взгляд, недооценена. Суть: для каждого B2B-клиента в системе создаётся внутренний баланс — кошелёк. Клиент может пополнить его банковским переводом на любую сумму — например, на миллион рублей. И после этого оплачивать заказы моментально — деньги списываются с баланса кошелька, без ожидания банковского перевода, без формирования счёта на каждый заказ.

Зачем это нужно? Представьте крупного оптового клиента, который делает двадцать-тридцать заказов в месяц. Каждый заказ — это формирование счёта, ожидание оплаты, проверка поступления. При двадцати заказах в месяц это двадцать счетов, двадцать платёжек, двадцать банковских дней ожидания. А с кошельком: один перевод на общую сумму, и потом клиент оплачивает заказы мгновенно, в один клик. Баланс видит и клиент в личном кабинете, и менеджер в admin-панели. Все транзакции логируются — пополнения, списания, возвраты. Прозрачно и для продавца, и для покупателя.

Я разговаривал с владельцем компании, которая продаёт запчасти для спецтехники. У них двести постоянных B2B-клиентов, и каждый делает от пяти до пятнадцати заказов в месяц. Когда они внедрили систему внутренних кошельков, бухгалтер буквально прослезилась — вместо тысячи двухсот счетов в месяц стало двести пополнений. Рабочая нагрузка упала в шесть раз. И при этом клиенты стали заказывать чаще — потому что оплата мгновенная, не нужно каждый раз ждать согласования.

Все три B2B-метода интегрированы в единый модуль B2B-продаж COS WP Woo. Они работают совместно с группами клиентов, индивидуальными ценами, минимальными объёмами заказа и прочими B2B-функциями. Это не надстройка сбоку — это часть единой системы, где всё связано и всё работает вместе.

Безопасность платежей: о чём обычно не думают до первого инцидента

Раз уж мы заговорили про платёжные шлюзы, нельзя обойти тему безопасности. И я сейчас не про PCI DSS и сертификацию — это ответственность самих ЮKassa и Тинькофф, данные карт обрабатываются на их стороне, и WooCommerce-магазин никогда не видит номер карты клиента. Я про другое — про безопасность самой интеграции.

Каждый платёжный плагин для WordPress — это потенциальная точка входа. У него есть callback URL, на который платёжная система отправляет уведомления. Этот URL доступен из интернета — иначе как ЮKassa сообщит вашему сайту, что платёж прошёл? И этот URL нужно защищать. Нужно проверять подпись запроса, нужно валидировать IP-адрес отправителя, нужно проверять, что сумма и номер заказа совпадают с тем, что хранится в базе. Если этого не делать — злоумышленник может отправить поддельный запрос на ваш callback URL и «подтвердить» оплату заказа, который никто не оплачивал. Товар уедет к мошеннику, а деньги — нет.

Звучит параноидально? В теории — да. На практике — я знаю минимум три случая, когда именно это и произошло. В одном случае плагин платёжной системы проверял подпись запроса, но не проверял сумму. Злоумышленник сформировал заказ на сто тысяч рублей, а потом отправил поддельный callback с суммой один рубль — и подпись была валидной, потому что он использовал свой тестовый аккаунт платёжной системы. Заказ перешёл в статус «оплачен». Менеджер отгрузил товар. Убыток — сто тысяч рублей минус один рубль.

Когда шлюзы встроены в единую систему, безопасность — это не ответственность автора отдельного плагина, а часть общей архитектуры. В COS WP Woo все callback-обработчики проходят через единый слой валидации: проверка подписи, проверка суммы, проверка соответствия заказа, проверка IP-адреса (для ЮKassa — диапазон IP Yoomoney, для Тинькофф — их серверный диапазон). Все подозрительные запросы логируются в системе активности. Если кто-то пытается подделать webhook — вы об этом узнаете из лога, а не из звонка разгневанного клиента.

Есть ещё один аспект безопасности, о котором мало кто задумывается, — это хранение ключей API. Shop ID и секретный ключ ЮKassa, Terminal Key Тинькофф — это, по сути, ключи от вашего расчётного счёта. Если кто-то получит к ним доступ, он может перенаправить платежи на другой аккаунт. И вот здесь важно, как плагин хранит эти данные. Большинство плагинов хранят ключи в открытом виде в wp_options — стандартной таблице настроек WordPress. Это означает, что любой другой плагин с доступом к базе данных (а в WordPress это, фактически, любой плагин) может прочитать ваши ключи. В COS WP Woo секретные ключи хранятся в зашифрованном виде и маскируются в интерфейсе — вы видите только последние четыре символа. При GET-запросе к API настроек ключи никогда не возвращаются в открытом виде. Это не паранойя — это базовая гигиена.

Единая точка настройки — и почему это важнее, чем кажется

Я потратил немало времени, объясняя клиентам, почему консолидация платёжных шлюзов в одном месте — это не маркетинговый трюк, а инженерная необходимость. И каждый раз аргументы одни и те же, но людям нужно время, чтобы это прочувствовать.

Вот типичная ситуация. У компании на сайте три способа оплаты: ЮKassa для физлиц, Тинькофф для рассрочки и ручной банковский перевод для B2B. Три разных плагина, три разных места настройки. Менеджер хочет временно отключить рассрочку — потому что акция закончилась и условия поменялись. Он заходит в WooCommerce → Настройки → Платежи. Видит список шлюзов. Находит Тинькофф. Нажимает «Управлять». Попадает на страницу настроек плагина Тинькофф. Отключает рассрочку. Сохраняет. Готово? Почти — но он забыл, что у плагина Тинькофф есть отдельная страница настроек в главном меню WordPress, и там тоже есть переключатель рассрочки. И они не синхронизированы. Через два часа он проверяет — рассрочка снова доступна на чекауте. Потому что настройка из основного меню плагина перезаписала настройку из WooCommerce Payments.

Звучит как анекдот? Это реальная история. И подобных историй у меня десятки.

В COS WP Woo все платёжные шлюзы настраиваются в одном месте — на одной вкладке, в одном интерфейсе. ЮKassa, Тинькофф, оплата по счёту, Purchase Order, кошелёк — всё рядом, на одном экране. Хотите отключить рассрочку? Один переключатель. Хотите поменять реквизиты в счёте? Здесь же, тут же. Хотите включить двухстадийную оплату для ЮKassa? Один клик. И нет никаких «альтернативных» мест настройки, которые могут перезаписать ваши изменения.

Но дело не только в удобстве для менеджера. Единая архитектура даёт технические преимущества, которые неочевидны на первый взгляд. Когда все шлюзы живут внутри одного плагина, они используют общую инфраструктуру: общий логгер, общую систему обработки ошибок, общие хуки WooCommerce. Это значит, что при обновлении WooCommerce нужно проверить совместимость одного плагина, а не трёх. И если что-то пойдёт не так — дебажить одну точку интеграции, а не три.

Есть ещё один аспект, о котором редко говорят: конфликты на чекауте. Страница оформления заказа в WooCommerce — это самое уязвимое место. Каждый плагин, который добавляет свою логику на чекаут, увеличивает вероятность конфликта. Я видел ситуации, когда два платёжных плагина подключали одну и ту же jQuery-библиотеку разных версий, и чекаут ломался — кнопка «Оплатить» не реагировала на клик. Или когда AJAX-обработчики одного плагина перехватывали события другого. Или когда CSS одного шлюза ломал отображение формы другого. Когда всё внутри одного плагина — таких проблем просто не существует. Один набор скриптов, один набор стилей, один AJAX-обработчик.

И последнее, но не менее важное: обновления. Каждый отдельный плагин — это отдельный цикл обновлений. ЮKassa обновляется раз в месяц. Тинькофф — раз в полгода (если повезёт). Какой-нибудь WooCommerce Invoice — когда автор вспомнит. И каждое обновление — это потенциальный источник проблем. Нужно проверить совместимость с текущей версией WordPress, с текущей версией WooCommerce, с текущей версией PHP, со всеми остальными плагинами. Когда у вас один плагин с встроенными шлюзами — одно обновление, одна проверка, одна кнопка «Обновить». Мы тестируем совместимость всех шлюзов перед каждым релизом. И если обновление WooCommerce что-то ломает — мы чиним все шлюзы разом, а не ждём, когда автор каждого отдельного плагина соизволит выпустить патч.

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

А что если посмотреть на это иначе? Что если воспринимать платёжные шлюзы не как «ещё одну фичу», а как базовый фундамент e-commerce? Без оплаты нет продаж. Без продаж нет бизнеса. И этот фундамент должен быть максимально надёжным, максимально предсказуемым, максимально контролируемым. Когда ваш фундамент — это три отдельных плагина от трёх разных разработчиков с тремя разными графиками обновлений и тремя разными подходами к безопасности — фундамент шатается. Когда фундамент — это часть единой системы, которую вы контролируете целиком — он крепкий.

Я не говорю, что отдельные плагины для ЮKassa или Тинькофф — это плохо. Они решают свою задачу, и многим магазинам их достаточно. Но если вы строите серьёзный e-commerce, особенно с B2B-компонентой, — количество плагинов начинает играть против вас. И каждый плагин, который можно убрать без потери функциональности, — это шаг к более стабильному, более быстрому, более управляемому сайту.

Как это работает на практике: от настройки до первого платежа

Давайте я расскажу, как выглядит процесс на практике — от установки до реального приёма платежей. Без абстракций, конкретно.

Вы устанавливаете COS WP Woo на свой WooCommerce-сайт. Переходите в раздел настроек модуля «Доставка и оплата» — это одна из вкладок в интерфейсе плагина. Видите все доступные платёжные шлюзы. Каждый — с переключателем «Включено/Выключено» и кнопкой настройки.

Начнём с ЮKassa. Нажимаете «Настроить». Вводите два параметра: Shop ID и секретный ключ. Оба берёте из личного кабинета ЮKassa — раздел «Интеграция». Выбираете методы оплаты: банковские карты, СБП, ЮMoney — по отдельности или все вместе. Если хотите двухстадийную оплату — включаете переключатель «Холдирование». Указываете, через сколько дней неподтверждённый холд автоматически отменяется — обычно это семь дней, но можно настроить под себя. Сохраняете. Всё, ЮKassa работает.

Важный момент: webhook URL для ЮKassa генерируется автоматически. Вам нужно скопировать его из настроек шлюза и вставить в личный кабинет ЮKassa, в раздел «HTTP-уведомления». Один раз, при первоначальной настройке. После этого ЮKassa будет автоматически уведомлять ваш сайт о статусе платежей — успешная оплата, отказ, возврат. Заказ в WooCommerce будет автоматически менять статус. Менеджеру не нужно мониторить платежи вручную.

Тинькофф настраивается аналогично. Terminal Key и пароль — из личного кабинета Тинькофф Эквайринга. Включаете стандартный эквайринг, рассрочку — или и то, и другое. Если рассрочка — указываете минимальную сумму заказа, при которой она доступна. Нет смысла предлагать рассрочку на товар за пятьсот рублей — это выглядит странно и не окупается из-за комиссии. Обычно минимальный порог — три-пять тысяч рублей, но это зависит от вашего бизнеса и маржинальности. Webhook URL тоже генерируется автоматически. Сохраняете — готово.

Теперь B2B-методы. Оплата по счёту — здесь нужно заполнить реквизиты вашей компании: наименование организации, ИНН, КПП, ОГРН, юридический адрес, расчётный счёт, БИК, название банка, корреспондентский счёт. Если у вас есть печать и подпись директора в виде изображений — загрузите их, они будут добавлены в PDF-счёт автоматически. Настраиваете шаблон нумерации счетов — например, «СЧ-{год}-{номер}», и каждый счёт будет получать уникальный номер в формате «СЧ-2026-00001». Включаете — и на чекауте появляется метод «Оплата по счёту», доступный для зарегистрированных B2B-пользователей.

Когда B2B-клиент оформляет заказ с оплатой по счёту, система автоматически генерирует PDF-файл счёта. В нём всё: реквизиты продавца и покупателя, список товаров с ценами и количеством, итоговая сумма, НДС, банковские реквизиты для перевода, печать и подпись. Этот документ отправляется клиенту на email и доступен для скачивания в личном кабинете. Менеджер также видит его в карточке заказа — и может переформировать или отправить повторно, если нужно. Никакой ручной работы, никакого Excel, никакой 1С на этом этапе.

Purchase Order ещё проще: на чекауте появляется поле «Номер заказа на закупку», клиент вводит свой PO-номер, оформляет заказ. Заказ создаётся в статусе «Ожидает оплаты» с привязанным PO. Менеджер видит этот номер в заказе и может его верифицировать. Когда оплата приходит — вручную или автоматически через банковскую интеграцию — статус меняется на «Обработка».

Кошелёк — здесь клиент видит свой баланс прямо на чекауте. Если средств достаточно — может оплатить в один клик. Если недостаточно — видит сообщение о нехватке средств и предложение пополнить кошелёк. Пополнение происходит через банковский перевод на указанные реквизиты (с указанием номера кошелька в назначении платежа) или через тот же шлюз ЮKassa/Тинькофф — если вы настроите такую возможность. Баланс, история транзакций, операции пополнения и списания — всё видно и клиенту в личном кабинете, и менеджеру в admin-панели.

Отдельно хочу сказать про возвраты — это тема, которая болит у каждого владельца интернет-магазина. Клиент оплатил, потом передумал, нужно вернуть деньги. При работе с отдельными плагинами возврат — это отдельный квест. Нужно зайти в карточку заказа, найти транзакцию, понять, через какой шлюз прошла оплата, зайти в настройки этого шлюза, проверить, поддерживает ли он автоматический возврат или нужно делать вручную через личный кабинет платёжной системы. В COS WP Woo возврат работает единообразно для всех шлюзов — нажимаете кнопку «Возврат» в карточке заказа, указываете сумму (полный или частичный возврат), подтверждаете. Система сама определяет, через какой шлюз прошла оплата, и отправляет запрос на возврат через API ЮKassa или Тинькофф. Для B2B-кошелька деньги возвращаются на баланс автоматически. Для оплаты по счёту — формируется уведомление менеджеру о необходимости ручного возврата через банк. Всё прозрачно, всё логируется, ничего не теряется.

И вот что мне кажется важным подчеркнуть: все эти методы работают параллельно. На чекауте клиент видит ровно те способы оплаты, которые ему доступны. Физическое лицо видит ЮKassa и Тинькофф. B2B-клиент видит оплату по счёту, Purchase Order, кошелёк — и, если хочет, тоже может оплатить картой через ЮKassa или Тинькофф. Видимость методов настраивается через B2B-группы — вы можете показывать разные способы оплаты разным группам клиентов. Крупным оптовикам — только счёт и кошелёк. Мелким дилерам — счёт и карта. Розничным покупателям — карта, СБП и рассрочку. Гибкость полная.

Честно говоря, когда я впервые увидел, как это работает в реальном магазине — на чекауте одного из наших клиентов, дистрибьютора моторных масел, — я почувствовал что-то вроде профессионального удовлетворения. Потому что это именно та штука, которой мне всегда не хватало на проектах. Когда всё — и онлайн-оплата для физлиц, и автоматические счета для юрлиц, и внутренние кошельки для постоянных оптовиков — живёт в одном месте, управляется из одного интерфейса и работает предсказуемо. Не нужно объяснять менеджеру, что «вот эта кнопка в том плагине, а вот эта — в другом». Не нужно помнить, в каком из трёх мест нужно менять реквизиты, когда компания переехала на новый юридический адрес. Не нужно паниковать после обновления WooCommerce — «а что, если опять что-нибудь сломалось в платежах?»

Я часто слышу вопрос: а не проще ли использовать готовые плагины? Они же бесплатные, поддерживаются разработчиками платёжных систем, постоянно обновляются. И да, на первый взгляд это логично. Но давайте посмотрим честно: «бесплатный» плагин ЮKassa в реальности стоит вам времени — время на настройку, время на дебаг конфликтов, время на ожидание обновлений, когда что-то сломалось. «Поддерживается разработчиками» — формально да, но попробуйте получить ответ в техподдержке плагина ЮKassa, когда у вас конфликт с WooCommerce на чекауте. Я пробовал. Стандартный ответ: «Отключите все остальные плагины и проверьте». Спасибо, очень помогло. «Постоянно обновляется» — проверьте changelog последних обновлений. Чаще всего это «исправлены мелкие ошибки» раз в два-три месяца. А если ваша проблема не в их «мелких ошибках», а в конфликте с другим плагином — вы в очереди на вечность.

Ладно, я, наверное, звучу слишком категорично. Давайте я скажу так: для простого магазина на десять товаров с оплатой только картой — отдельный плагин ЮKassa абсолютно нормальный выбор. Ставите, настраиваете, работает, забываете. Но как только ваш магазин вырастает — появляются B2B-клиенты, нужна рассрочка, нужны счета, нужна двухстадийная оплата — вы начинаете обвешивать WordPress плагинами, как новогоднюю ёлку игрушками. И в какой-то момент ёлка падает.

Мне кажется, правильный подход — думать о платёжной инфраструктуре с самого начала. Не как о чём-то, что «прикручивается» к магазину отдельными плагинами, а как о фундаментальной части e-commerce-системы. Вместе с каталогом, вместе с доставкой, вместе с CRM и аналитикой. Единая система — единая ответственность — единая точка контроля.

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

Напоследок расскажу одну историю. Один из наших клиентов — компания, которая продаёт промышленные смазки и масла, около пятисот B2B-клиентов и несколько тысяч розничных покупателей через сайт. До перехода на COS WP Woo у них стояло четыре плагина, связанных с оплатой: ЮKassa, Тинькофф, какой-то плагин для генерации счетов (платный, кстати, с годовой подпиской) и ещё один — для учёта оплат от юрлиц. Суммарно эти четыре плагина грузили восемь дополнительных JS-файлов и три CSS на чекауте. Время загрузки страницы оформления заказа — четыре с половиной секунды на мобильных. После перехода — две с небольшим. Количество брошенных корзин снизилось на восемнадцать процентов за первый месяц. Не потому что чекаут стал красивее — потому что стал быстрее. Два с половиной секунды разницы — и почти каждый пятый клиент, который раньше уходил, теперь дожидается загрузки страницы и оплачивает.

Я не буду делать вид, что COS WP Woo — это волшебная таблетка от всех проблем e-commerce. Проблем хватит на всех, и новые будут появляться каждый день. Но конкретно в вопросе приёма платежей — особенно если вам нужны российские платёжные системы плюс B2B — единое решение объективно лучше, чем зоопарк отдельных плагинов. Это не моё мнение — это опыт десятков проектов и сотен часов дебага, которые превратились в конкретные инженерные решения.

Попробуйте COS WP Woo — 14 дней бесплатно. Установите, настройте платёжные шлюзы за десять минут, примите первый платёж. И потом сравните с тем, как это работало раньше. Мне кажется, разница будет очевидна.