LifterLMS Stripe Payments - Плагин WordPress

Какую задачу решает этот платежный шлюз

В LifterLMS продажа курса строится вокруг access plan. Это не отдельный товар WooCommerce, а тариф доступа к курсу или membership внутри LMS. Access plan может быть бесплатным, разовым, регулярным, с пробным периодом, видимым, скрытым или доступным только участникам определенного membership. LifterLMS Stripe Payments добавляет к этой схеме платежный gateway, который умеет обрабатывать разовые и recurring-платежи через Stripe.

Когда студент выбирает платный access plan, LifterLMS отправляет его на checkout page. Там пользователь создает или использует учетную запись, вводит платежные данные, применяет coupon, если он есть, и подтверждает оплату. После успешной транзакции заказ получает подходящий статус, а студент автоматически получает доступ к курсу или membership.

Ключевая польза расширения - связать оплату и обучение без ручной выдачи доступа. Если платеж не проходит, заказ и доступ не должны притворяться успешными. Если recurring-платеж отменен или не смог списаться, LifterLMS должен отразить это в заказе и доступе. Именно поэтому при настройке важны webhooks, logs и тестовый сценарий, а не только галочка включения gateway.

Где продукт особенно полезен

Расширение хорошо подходит для сайтов, где LifterLMS остается основной системой обучения, а Stripe нужен как прямой обработчик банковских карт и поддерживаемых платежных методов. Типичные случаи:

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

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

LifterLMS Stripe Payments может быть лишним, если курсы продаются как часть большого магазина с физическими товарами, доставкой, сложными налоговыми правилами, подарочными картами и десятками способов оплаты через WooCommerce. В таком случае логичнее сравнить native gateway с LifterLMS WooCommerce Integration. Если аудитория активно предпочитает PayPal, стоит держать рядом LifterLMS PayPal Payments или хотя бы оценить его как второй вариант оплаты.

Еще один случай - нестандартная корпоративная оплата по счету, банковский перевод или ручное подтверждение. Для этого может хватить Manual Payment Gateway в LifterLMS, особенно если платежи обрабатываются вне сайта и администратор готов вручную подтверждать заказы.

Что проверить перед установкой на WordPress

Платежный gateway затрагивает деньги, учетные записи и доступ к обучению, поэтому подготовка важнее скорости установки. Нельзя просто активировать плагин на рабочем сайте и сразу просить студентов платить. Сначала нужно убедиться, что базовый LifterLMS настроен правильно, checkout page существует, access plans опубликованы, а сервер способен безопасно общаться со Stripe.

Минимальная техническая база

Официальная страница продукта указывает требования к LifterLMS, WordPress и PHP. В статье не фиксируем номера как вечную истину, потому что они могут измениться, но перед установкой нужно сверить их на странице продукта и в вашем окружении. Если сайт сильно отстал по WordPress, PHP или core-плагину LifterLMS, сначала обновляйте тестовую копию, а не платежный модуль на live-сайте.

• В WordPress должен быть активен core-плагин LifterLMS.
• Должны существовать системные страницы LifterLMS, особенно checkout page и student dashboard.
• Сайт должен открываться по HTTPS, а адрес WordPress в настройках не должен вести на старый HTTP-вариант.
• Сервер должен поддерживать актуальные требования Stripe к защищенному соединению, включая TLS 1.2 или более новый стек.
• На staging-копии нужно понимать, включены ли automatic recurring payments, чтобы тестовый клон не начал вести себя как production.

Проверка checkout page и access plans

Если у курса нет active access plan, посетитель не увидит нормальный путь покупки. Если access plan скрыт, он не появится в pricing table, хотя может быть доступен по прямой ссылке. Если recurring access plan не поддерживается активным gateway, LifterLMS может не показать его на публичной части сайта, чтобы пользователь не дошел до тупикового checkout.

Перед подключением Stripe откройте один тестовый курс и проверьте, что у него есть хотя бы один опубликованный платный access plan. Затем убедитесь, что на странице курса есть pricing table или корректная кнопка перехода к checkout.

Права администратора и безопасность ключей

Настройку должен выполнять пользователь с правами администратора WordPress и доступом к Stripe Dashboard. Если на сайте работает агентство, не передавайте секретные ключи в переписку, тикеты или промпты генераторов. Современный способ подключения через Stripe Connect снижает необходимость вручную копировать ключи. Legacy-вариант с publishable и secret keys все еще описан в документации, но его нужно использовать только осознанно.

Если у вас есть staging-сайт, сначала настройте test mode именно там. Для платежного продукта это не формальность, а нормальный рабочий процесс: вы проверяете checkout, webhooks, статусы заказов и доступ до того, как деньги пойдут через live mode.

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

Установка выполняется как обычная загрузка ZIP-плагина в WordPress. Официальная документация описывает путь через Plugins > Add New Plugin > Upload Plugin, выбор ZIP-файла, Install Now и активацию. После активации сам факт установки еще не означает, что сайт принимает платежи: gateway нужно включить и связать со Stripe.

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

1. Откройте админ-панель WordPress и перейдите в LifterLMS > Settings.
2. Откройте вкладку Checkout и найдите раздел Stripe.
3. Включите Enable Stripe Payment Gateway, но не переводите сайт в live-прием платежей до тестов.
4. Нажмите Connect Stripe, если используете современное подключение через Stripe Connect.
5. После возврата из Stripe проверьте сообщение подключения и состояние Webhook Status.
6. Сохраните настройки через Save Changes.

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

Как понять, что первичная связка работает

Первый ориентир - статус подключения Stripe и webhook status в настройках gateway. Второй - возможность открыть checkout для тестового access plan. Третий - появление тестовой транзакции в Stripe Dashboard при включенном test mode. До успешного прохождения всех трех пунктов не стоит считать настройку завершенной.

Не переключайтесь в live mode, пока не прошел тестовый заказ от выбора access plan до появления доступа у студента. Платежный модуль проверяется не по экрану настроек, а по полному сценарию покупки.

Настройка LifterLMS Stripe Payments после установки

Самый полезный раздел настроек находится в LifterLMS > Settings > Checkout > Stripe. Названия отдельных полей могут отличаться в зависимости от версии, но логика остается одной: gateway включается, сайт связывается со Stripe, test mode помогает безопасно прогнать покупку, webhooks возвращают события из Stripe в WordPress, а debug logging нужен только для диагностики.

Первые настройки, которые нужно проверить

Test mode как обязательный этап, а не черновик

Test mode нужен не только для проверки номера карты. Он показывает, что ваш access plan, checkout page, order status, enrollment и webhook-события работают вместе. В документации LifterLMS указано, что после включения test mode все транзакции отправляются в Stripe как тестовые. Значит, при проверке нужно смотреть test data в Stripe Dashboard, иначе вы можете решить, что платеж не создался.

Мини-проверка test mode

1. Включите Enable Stripe Test Mode и сохраните настройки.
2. Откройте курс в режиме обычного пользователя, лучше в приватном окне браузера.
3. Выберите платный access plan и пройдите checkout с тестовыми платежными данными Stripe.
4. Проверьте заказ в LifterLMS: статус, транзакцию, связь с курсом и enrollment.
5. Проверьте Stripe Dashboard в test data: платеж, customer и webhook delivery.

Webhooks: почему зеленый статус важнее красивого checkout

Stripe может показать успешный checkout, но сайт должен получить событие обратно. Webhooks сообщают LifterLMS о событиях вроде completed checkout, failed payment, refund и expired session. Официальная документация перечисляет события, которые расширение использует при настройке webhook endpoint. Если webhook не установлен или не принимает события, заказ, повторный платеж или возврат могут не отразиться в WordPress так, как ожидает администратор.

Если Webhook Status не подтверждается, сначала сохраните настройки gateway еще раз. В release notes у LifterLMS Stripe есть улучшение, связанное с обновлением webhook при сохранении настроек, включая случай изменения URL сайта. Если статус все равно не меняется, откройте Stripe Dashboard, перейдите в Developers > Webhooks, выберите endpoint сайта и изучите Logs.

Debug logging: включать только на время расследования

Debug logging полезен, когда оплата или создание customer ломается, но он не восстанавливает прошлые ошибки. Официальная инструкция подчеркивает: log появится только после включения режима и повторного воспроизведения проблемы. Поэтому порядок такой: включили logging, повторили неудачный checkout, открыли LifterLMS > Status > Logs, выбрали файл, начинающийся с stripe-, сохранили вывод для анализа, затем отключили logging.

Не держите debug logging включенным постоянно на рабочем сайте. Он нужен для короткого расследования, а не как фоновый режим эксплуатации.

Access plans, checkout и автоматическая запись студента

В LifterLMS оплата не живет отдельно от учебного доступа. Покупатель выбирает access plan, проходит checkout, LifterLMS создает order, Stripe обрабатывает платеж, а затем система меняет доступ студента. Поэтому ошибки часто начинаются не в Stripe, а на уровне курса: нет подходящего плана, план скрыт, pricing table не добавлен, checkout page создан неверно или нужный gateway не поддерживает выбранную модель платежа.

Как access plan связан с платежным gateway

Access plan задает условия доступа: разовый платеж, регулярное списание, срок действия, пробный период, видимость, участники membership. Payment gateway отвечает за то, может ли сайт реально обработать этот тип плана. Официальная документация LifterLMS указывает, что система показывает только те access plans, которые можно полностью обработать установленным и активным gateway. Это защищает пользователя от ситуации, когда тариф виден, но оплатить его невозможно.

Из этого следует практический вывод: если pricing table пустая, не начинайте с CSS или темы. Сначала проверьте, есть ли опубликованный access plan, не стоит ли у него скрытая видимость, поддерживает ли включенный gateway этот тип платежа и создана ли checkout page.

Разовый платеж и recurring-подписка

Разовый access plan проще: успешный платеж обычно приводит к completed order и выдаче доступа по правилам плана. Recurring-подписка сложнее, потому что у нее появляются последующие списания, failed-попытки, статусы Active, On Hold, Failed, cancellation и возможная повторная попытка оплаты. Для таких сценариев особенно важны webhooks и корректная поддержка payment method в Stripe.

Stripe поддерживает много способов оплаты, но не каждый метод подходит для subscription mode. В официальной документации LifterLMS отдельно отмечено: если использовать one-time payment method для recurring access plan, платеж может не пройти. Поэтому при включении дополнительных способов оплаты в Stripe Dashboard проверяйте, поддерживает ли выбранный метод регулярные списания.

Checkout page и учетная запись студента

LifterLMS checkout page отвечает не только за оплату. Там пользователь входит, регистрируется, вводит billing information и применяет coupon. В документации LifterLMS указано, что guest checkout не поддерживается: для записи в курс нужна учетная запись. Это логично для LMS, потому что доступ к урокам, прогресс, сертификаты и dashboard должны принадлежать конкретному пользователю.

Что проверить на странице checkout

• Страница содержит корректный checkout-блок или shortcode LifterLMS.
• Форма регистрации не конфликтует с темой, кешем или сторонними оптимизаторами скриптов.
• Пользователь после успешной оплаты видит понятный следующий шаг, а не пустую страницу.
• Student dashboard доступен после покупки и показывает нужный курс или membership.

Stripe Checkout, дополнительные способы оплаты и осторожное включение beta-режима

Обычный сценарий LifterLMS Stripe показывает оплату в checkout LifterLMS. В документации также описан Stripe Checkout, где пользователь переходит на страницу, размещенную у Stripe. Этот режим отмечен как beta, поэтому его нельзя включать как быструю замену без проверки. Его главная практическая причина - дополнительные payment methods, включая кошельки вроде Apple Pay и Google Pay, если они доступны и настроены в Stripe.

Когда Stripe Checkout может быть уместен

Этот режим имеет смысл рассматривать, если аудитория ожидает не только банковские карты, а более широкий набор способов оплаты, доступный в Stripe Dashboard. Но список методов зависит от страны аккаунта, валюты, режима checkout и типа платежа. Для recurring-планов ограничения строже, чем для разовых оплат. Поэтому лучший подход - не включить все подряд, а составить короткий список реально нужных методов и проверить каждый на совместимость с разовой оплатой или subscription.

Если вы продаете подписки, проверяйте поддержку recurring payments до публикации тарифа. Ошибка часто проявляется только на checkout, когда пользователь уже выбрал план и ожидает оплату.

Как включается beta-режим Stripe Checkout

Официальная инструкция требует добавить константу в wp-config.php, после чего в настройках Stripe появляется выбор payment flow. Это изменение должен выполнять человек, который понимает, как редактировать конфигурацию WordPress и как откатить правку. Перед изменением сделайте резервную копию файла и проверьте сайт на staging.

define( 'LLMS_STRIPE_ENABLE_STRIPE_CHECKOUT', true );

После добавления константы откройте LifterLMS > Settings > Checkout > Stripe, выберите поток Accept Payments in Stripe (Stripe Checkout), сохраните настройки и проверьте webhook status. Если статус показывает, что webhook не установлен, сохраните настройки повторно или создайте endpoint вручную по официальной инструкции.

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

Если beta-режим ведет себя нестабильно на вашем сайте, не пытайтесь чинить платежи хаотичными правками. Верните прежний payment flow в настройках, удалите или закомментируйте константу в wp-config.php, очистите кеш и снова прогоните тестовый access plan. Для live-сайта важно не оставлять пользователя между двумя платежными потоками.

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

Возьмем конкретную задачу: у школы есть курс, который нужно продавать через Stripe с автоматической записью после оплаты. Нам нужно не просто увидеть поле карты, а убедиться, что LifterLMS создал заказ, Stripe принял платеж, webhook вернулся на сайт, а студент получил доступ к урокам.

Цель и подготовка

Цель - разовый платный access plan для курса, работающий в test mode. До начала должны быть выполнены условия: LifterLMS установлен, checkout page создана, LifterLMS Stripe Payments активирован, Stripe подключен, test mode включен, webhook status проверен или хотя бы понятен для диагностики.

Шаги сценария

1. Откройте нужный курс в админ-панели и перейдите к блоку access plan.
2. Создайте новый платный план с разовой оплатой, понятным названием и видимостью Visible.
3. Убедитесь, что pricing table или блок выбора плана выведен на странице курса.
4. Откройте публичную страницу курса в приватном окне браузера.
5. Выберите access plan и перейдите на checkout.
6. Создайте тестового студента или войдите под тестовой учетной записью.
7. Заполните checkout тестовыми платежными данными Stripe и подтвердите оплату.
8. Вернитесь в админ-панель и откройте LifterLMS orders.

Проверка результата

В LifterLMS должен появиться order с корректным студентом, курсом, payment gateway и transaction. Для разовой оплаты успешный заказ обычно должен отражать завершенную покупку, а студент должен получить доступ к курсу. В Stripe Dashboard в test data должен появиться соответствующий платеж. Если в LifterLMS заказ завис, а в Stripe платеж есть, смотрите webhook delivery и logs.

Мини-итог сценария: успешной считается не страница «спасибо», а полная цепочка access plan -> checkout -> Stripe payment -> LifterLMS order -> student enrollment.

Нюанс для recurring-планов

Если вместо разовой оплаты вы тестируете подписку, добавьте проверку повторного платежа и статусов order. В LifterLMS recurring order может становиться Active, On Hold, Failed или Pending Cancellation в зависимости от ситуации. Для такого плана важно заранее понять, какие уведомления получает студент при failed payment и включены ли automatic retry rules для поддерживаемого gateway.

Регулярные платежи, возвраты и заказы в LifterLMS

Платежный gateway нужно оценивать не только по первому checkout. На рабочем сайте часто важнее дальнейшая жизнь заказа: что происходит при повторном списании, как студент отменяет подписку, что видит администратор в order notes, как оформить refund и влияет ли возврат на доступ к курсу.

Как читать статусы заказов

Официальная документация LifterLMS описывает orders как основу платежей, enrollment и access control. Для администратора это центр поддержки: здесь видны платежные попытки, subscriptions, renewals, refunds, cancellations и история активности. Если студент пишет, что оплатил курс, но доступа нет, первым делом проверяйте order, transaction и enrollment, а не только Stripe Dashboard.

• Completed обычно относится к успешной разовой покупке.
• Active важен для recurring order, где будущие платежи еще должны списываться.
• On Hold часто связан с проблемами регулярного платежа.
• Failed означает, что платежная попытка не прошла.
• Refunded отражает полный или частичный возврат, который может влиять на доступ.

Failed payments и автоматические повторы

LifterLMS поддерживает automatic retry of failed payments для ряда gateway, включая Stripe. Это помогает не отключать студента сразу из-за временного отказа карты. По умолчанию система применяет последовательность retry rules: переводит order в On Hold, ждет заданный интервал, может отправлять уведомления, а после финальной неудачной попытки переводит order в Failed.

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

Возвраты через Stripe и доступ к курсу

LifterLMS различает manual refunds и automatic refunds через gateway. Manual refund только записывает факт возврата в LifterLMS и требует отдельно вернуть деньги через платежный сервис. Automatic refund через Stripe отправляет возврат через API. Документация LifterLMS также предупреждает, что при refund студент может быть автоматически отписан от курса или membership, а если доступ нужно сохранить, его придется вернуть вручную.

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

Видео по настройке LifterLMS Stripe Payments

Это видео дополняет руководство: видео по продукту. Откройте его после базовой настройки, чтобы сверить интерфейс и последовательность действий.