GetPaid Sage Pay Payment - Плагин WordPress

Руководство по настройке GetPaid Sage Pay Payment для приема платежей в WordPress

GetPaid Sage Pay Payment нужен тем сайтам на WordPress, где уже используется GetPaid для счетов, платежных форм или кнопок покупки, а принимать оплату нужно через Sage Pay, который в документации платежного провайдера сейчас часто называется Opayo. В этом руководстве разберем не карточку продукта, а рабочий путь внедрения: что проверить до установки, как включить шлюз в GetPaid, как подготовить страницы оплаты, как провести тестовый платеж и где искать причину, если статус в WordPress и MyOpayo расходится.

У платежных расширений есть особенность: они редко ломаются сами по себе в одном месте. Проблема может быть в валюте, в тестовом аккаунте провайдера, в неверной странице возврата, в кэше, в старом endpoint или в том, что сайт не получает ответ после оплаты. Поэтому настройка GetPaid Sage Pay Payment должна идти как цепочка проверок, а не как один пункт «активировать плагин».

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

Как шлюз встраивается в GetPaid и зачем он нужен

GetPaid работает как платежная и счетная система внутри WordPress. В базовом сценарии вы создаете item, платежную форму, кнопку покупки или invoice, а пользователь проходит checkout и получает receipt. Платежный шлюз отвечает за момент, когда деньги должны быть авторизованы внешним провайдером. Для Sage Pay это означает, что сайт передает данные платежа в систему Sage Pay/Opayo, а затем ожидает результат, чтобы отметить счет как оплаченный, отклоненный или требующий дальнейшей проверки.

Официальная страница add-on описывает GetPaid Sage Pay Payment Gateway как расширение для приема платежей через Sage Pay Payment Gateway, а страница ядра GetPaid на WordPress.org показывает, что сама система поддерживает items, invoices, buy now buttons, inline checkout forms и платежные шлюзы. Из этого следует практический вывод: add-on не заменяет GetPaid и не создает отдельный магазин. Он добавляет один способ оплаты в уже существующую схему GetPaid.

Что происходит во время платежа

С точки зрения администратора цепочка выглядит просто: покупатель выбирает item или открывает invoice, на checkout выбирает Sage Pay, проходит оплату у провайдера, после чего возвращается на страницу результата. Но технически важно, чтобы каждая часть цепочки уже была настроена:

• В GetPaid должна существовать checkout page с нужным shortcode или виджетом.
• Success page и failed transaction page должны быть заданы в общих настройках GetPaid.
• Валюта сайта должна быть допустимой для используемого платежного аккаунта.
• Шлюз должен быть включен в разделе payment gateways и, если нужно, выбран как default gateway.
• В MyOpayo должны совпадать режим, учетные данные, разрешенные настройки и ожидания по возврату покупателя.

Главная проверка перед запуском - не наличие кнопки на странице, а успешный полный круг: checkout, переход к провайдеру, возврат, корректный статус invoice в GetPaid. Если хотя бы один участок не работает, пользователь может увидеть ошибку, а администратор - непонятный статус заказа или счета.

Когда Sage Pay/Opayo уместен именно в GetPaid

Этот шлюз логичен, когда сайт продает услуги, цифровые материалы, доступы, бронирования, консультации, взносы или счета без полноценного WooCommerce-магазина. GetPaid хорош там, где нужна легкая платежная форма или счет, а не каталог товаров, корзина, доставка, вариации, склад и сложная кассовая логика. Если платежный провайдер уже выбран как Sage Pay/Opayo, расширение позволяет не перестраивать сайт на другую систему только ради приема карт.

Отдельный плюс такого подхода - понятная административная граница. GetPaid хранит items, invoices, forms и статусы внутри WordPress, а провайдер отвечает за обработку платежа. Это не отменяет обязанность проверять безопасность сайта, но помогает не смешивать учет заказов, форму оплаты и данные карты в одну самодельную конструкцию.

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

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

Подходящие задачи

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

• Сайт уже использует GetPaid для счетов, форм или кнопок покупки.
• Платежный аккаунт Sage Pay/Opayo уже существует или выбран бизнесом заранее.
• Нужны простые одноразовые платежи, счета или формы без сложной товарной корзины.
• Администратор готов проверять статусы и журнал платежей не только в WordPress, но и в MyOpayo.
• Нужно оставить оплату в рамках GetPaid, чтобы не добавлять тяжелую торговую платформу.

Когда плагин может быть лишним

Если сайт уже построен на WooCommerce и весь процесс продаж завязан на корзину, доставку, налоги, email-шаблоны магазина и статусы заказов WooCommerce, отдельный GetPaid gateway может оказаться параллельной системой учета. В этом случае чаще логичнее смотреть на Opayo gateway именно для WooCommerce. То же касается проектов, где платежи строятся вокруг Gravity Forms: если форма уже сложная, с условной логикой и оплатой прямо в форме, специализированный Opayo add-on для Gravity Forms может потребовать меньше перестройки.

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

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

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

Подготовка экономит больше времени, чем сама установка. В платежных интеграциях типовая ошибка выглядит так: администратор загружает add-on, включает gateway, видит вариант оплаты на checkout и считает задачу завершенной. Потом покупатель получает ошибку, платеж виден в MyOpayo, а invoice в WordPress остается неоплаченным. Чтобы этого избежать, сначала проверьте окружение.

Версии и зависимости

Официальная карточка add-on указывает требования к WordPress, GetPaid Core Plugin и PHP. При этом ядро GetPaid на WordPress.org может иметь свои текущие требования. Поэтому безопасный подход такой: сверяйте не только минимальные требования add-on, но и требования установленного ядра GetPaid, версии WordPress, PHP на хостинге и дополнительных расширений, которые участвуют в checkout.

• Проверьте, что GetPaid установлен, активирован и открывает свои страницы настроек без ошибок.
• Сделайте резервную копию сайта и базы данных перед установкой платежного add-on.
• Убедитесь, что на сайте есть SSL-сертификат и checkout открывается по HTTPS.
• Отключите агрессивную оптимизацию JavaScript на странице оплаты до завершения тестов.
• Подготовьте отдельный тестовый item или invoice с небольшой суммой.

Страницы GetPaid, без которых gateway не проверяется

В общих настройках GetPaid есть page settings: checkout page, terms and conditions, success page, failed transaction page, invoice history page и invoice subscriptions page. Для проверки Sage Pay особенно важны checkout, success и failed transaction. Если они не назначены или содержат неправильный shortcode, пользователь может оплатить у провайдера, но вернуться на пустую страницу или получить ошибку.

Перед установкой откройте каждую страницу в режиме инкогнито. Проверьте, что checkout не закрыт случайным редиректом, не требует авторизации, если вы хотите принимать оплату от гостей, и не кэшируется как статический HTML. Если включена настройка Require Login to Checkout, осознанно решите, подходит ли она вашему сценарию. Для счетов постоянным клиентам авторизация может быть нормальной, для разовой оплаты услуги через публичную форму - часто лишней.

Валюта и регион платежей

Документация GetPaid прямо предупреждает, что у платежных шлюзов могут быть валютные ограничения. Это важный пункт для Sage Pay/Opayo, потому что платежный аккаунт и merchant settings провайдера определяют, какие валюты и типы операций доступны. В GetPaid проверьте Currency, формат разделителей и число десятичных знаков. В MyOpayo проверьте, что выбранная валюта действительно разрешена для вашего аккаунта.

Не меняйте валюту на рабочем сайте «для теста», если уже есть реальные invoices и отчеты. Лучше создать тестовый сайт или staging-копию, где можно проверить gateway без риска испортить бухгалтерскую историю.

Установка add-on и первичная проверка в админ-панели

Установка GetPaid Sage Pay Payment проходит как установка обычного WordPress-плагина из ZIP-архива. Главное - не путать три уровня: ядро GetPaid, add-on платежного шлюза и настройки провайдера. Если активировать только add-on, но не настроить GetPaid pages и MyOpayo, рабочей оплаты не получится.

Безопасный порядок установки

1. Проверьте, что ядро GetPaid активно и в админ-панели есть разделы GetPaid, Settings, Items и Payment Forms.
2. Откройте Plugins - Add New - Upload Plugin, выберите ZIP-архив add-on и установите его.
3. Нажмите Activate и убедитесь, что WordPress не показывает fatal error, warning или конфликт зависимостей.
4. Перейдите в настройки GetPaid и найдите раздел платежных шлюзов.
5. Проверьте, появился ли Sage Pay gateway в списке доступных gateways.

Если gateway не появился, не начинайте сразу переустановку. Сначала проверьте, что активен Core Plugin, версия PHP соответствует требованиям, ZIP-архив относится именно к GetPaid, а не к WooCommerce или Gravity Forms, и что в WordPress нет кеша object cache, который показывает старые данные админки. Иногда помогает обычный выход из админ-панели и повторный вход, но это не должно заменять проверку ошибок в журнале сервера.

Первый тест без реальной оплаты

До ввода учетных данных провайдера полезно проверить, как GetPaid ведет себя без gateway. Создайте item с небольшой ценой, вставьте payment form shortcode на тестовую страницу и убедитесь, что форма открывается. Если даже базовая форма не отображается, проблема не в Sage Pay add-on, а в общем слое GetPaid, теме, блоках, shortcodes или JavaScript на странице.

Мини-итог после установки: gateway должен появиться в списке, базовая форма GetPaid должна открываться, страницы результата должны быть назначены. Только после этого есть смысл переходить к MyOpayo и тестовым платежам.

Карта настроек GetPaid после установки шлюза

Настройка после установки должна быть последовательной. Сначала включается gateway и базовая видимость на checkout, затем проверяются страницы, валюта, подписи для пользователя и поведение формы. Не все конкретные поля Sage Pay add-on доступны в публичной документации, поэтому точные названия credential-полей нужно сверять с вашей установленной версией. Но общая логика GetPaid подтверждена документацией: gateways включаются в payment gateway settings, default gateway выбирается отдельно, а страницы checkout/success/failed задаются в general settings.

Gateway settings: включение, название и приоритет

Откройте GetPaid - Settings - Payment Gateways. В общих настройках gateways обычно проверяют два пункта: список доступных gateways и default gateway. Если Sage Pay должен быть основным способом оплаты, выберите его по умолчанию. Если вы оставляете несколько вариантов, например Sage Pay и bank transfer, проверьте порядок отображения и текст, который увидит пользователь.

Название на checkout должно быть понятным. Для русскоязычного сайта можно написать в описании, что оплата пройдет через защищенную страницу платежного провайдера Sage Pay/Opayo. Но не обещайте того, что не контролируете: абсолютную безопасность, мгновенное зачисление во всех случаях или отсутствие любых отказов. Правильнее объяснить, что пользователь будет перенаправлен к платежному провайдеру и вернется на сайт после результата операции, если именно так работает ваша версия интеграции.

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

• Активируйте gateway только после проверки страниц checkout и результата.
• Выберите default gateway, если на сайте нет других платежных методов.
• Сохраните настройки и откройте checkout в новом окне как обычный пользователь.
• Проверьте, что вариант Sage Pay отображается без PHP warning и без пустого описания.

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

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

Checkout, success и failed transaction pages

В general settings GetPaid убедитесь, что checkout page содержит [wpinv_checkout], success page содержит receipt-логику, а failed transaction page реально открывается. Если вы используете блоки или виджеты GetPaid вместо shortcode, смысл тот же: страница должна выводить соответствующий элемент GetPaid, а не быть пустой заготовкой.

Для платежного gateway страница failed transaction так же важна, как success page. Пользователь может отказаться от 3-D Secure, карта может быть отклонена, провайдер может вернуть ошибку, а сайт должен показать понятный следующий шаг. Не оставляйте пользователя на пустом «спасибо» или на главной странице без объяснения.

Проверка формы и item

Создайте отдельный item для теста. В GetPaid item может быть стандартным продуктом или услугой, fee, пакетом при интеграции с GeoDirectory или другим типом, если активны add-ons. Для проверки gateway обычно достаточно стандартного item с небольшой суммой. Затем создайте payment form или используйте shortcode item/button, который предоставляет GetPaid.

[getpaid item=123 button='Pay now']

Замените 123 на ID вашего тестового item. Этот пример не является обязательной схемой для всех сайтов, но он полезен для изолированной проверки: вы убираете лишние формы, скидки, bundles и сложные условия, чтобы увидеть, проходит ли платежный путь в минимальном виде.

MyOpayo, тестовый режим и возврат покупателя после оплаты

Sage Pay в современных материалах провайдера часто описывается через бренд Opayo и интерфейс MyOpayo. Для администратора GetPaid это означает, что часть настройки находится не в WordPress. Нужно понимать, какой аккаунт используется, тестовый или рабочий, какие credentials вводятся в плагин, какие URL провайдера актуальны и видит ли MyOpayo ваши тестовые транзакции.

Test и live не должны смешиваться

В документации Opayo отдельно указаны test и live окружения MyOpayo. Учетные данные и пользователи могут не переноситься между ними автоматически, а отдельные настройки нужно выполнять в нужной среде. Если вы вводите test credentials в live gateway или наоборот, платеж может не зарегистрироваться, вернуться с ошибкой или вообще не появиться там, где вы его ищете.

Практический порядок проверки:

1. Откройте именно test MyOpayo, если проверяете тестовые платежи.
2. Убедитесь, что у пользователя есть права видеть transactions и invalid transactions.
3. Получите нужные gateway данные из того же окружения, которое выбрано в GetPaid.
4. Сохраните настройки gateway в WordPress.
5. Проведите тест и ищите транзакцию в том же окружении MyOpayo.

Если один человек настраивает WordPress, а другой управляет MyOpayo, заранее договоритесь о тестовом сценарии и времени проверки. Иначе один участник будет видеть ошибку в WordPress, а другой искать транзакцию не в том окружении.

Vendor Name, encryption password и учетные данные

В сторонних и официальных материалах по Opayo Form часто встречаются Vendor Name и Form Integration Encryption Password. Это не означает, что публичная документация GetPaid Sage Pay Payment раскрывает все поля конкретного add-on. Поэтому действуйте так: поля в админке GetPaid заполняйте по названиям вашей установленной версии, а их смысл сверяйте с MyOpayo и документацией провайдера.

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

Почему возврат после оплаты так важен

Opayo Form и Server сценарии предполагают передачу данных от сайта к провайдеру и возврат результата. У GetPaid есть success page и failed transaction page. Если return URL, success/failure logic или callback не отрабатывают, пользователь может оплатить, но счет в WordPress останется в неправильном статусе. В таких ситуациях нельзя делать вывод только по экрану покупателя. Нужно сверить три места: GetPaid invoice, MyOpayo transaction и серверные логи.

Для сайта с кэшем добавьте страницы checkout, receipt, success и failed transaction в исключения. Платежные страницы не должны отдаваться как устаревший статический HTML. Если у вас есть firewall, защита от ботов или ограничения по странам, проверьте, не блокируют ли они обращение платежного провайдера к сайту или возврат покупателя.

Практический пример: принять оплату за услугу через счет GetPaid

Разберем конкретную задачу. Допустим, сайт веб-специалиста или агентства выставляет клиенту счет за консультацию. Нужно дать клиенту ссылку на оплату, принять платеж через Sage Pay/Opayo и убедиться, что invoice в GetPaid стал оплаченным. Такой сценарий хорошо показывает, зачем нужны настройки страниц, gateway и MyOpayo.

Цель сценария

Получить минимальный, но полный платежный путь: item или invoice создан, checkout открывается, Sage Pay выбран как способ оплаты, покупатель проходит тестовую оплату, затем видит страницу результата, а администратор подтверждает статус в WordPress и MyOpayo.

Подготовка

• На сайте установлен GetPaid и add-on Sage Pay gateway.
• Назначены checkout, success и failed transaction pages.
• В GetPaid выбрана корректная валюта.
• В MyOpayo есть доступ к test account и пользователю с правом смотреть transactions.
• Кэш и оптимизация скриптов временно отключены для платежных страниц.

Шаги

1. Создайте тестовый item с понятным названием, например консультация или тестовая услуга. Не используйте реальный дорогой продукт для первого платежа.
2. Создайте payment form через GetPaid - Payment Forms - Add New или используйте shortcode для item.
3. Разместите форму на закрытой тестовой странице, доступной только вам и команде.
4. Откройте страницу как обычный пользователь и проверьте, что форма показывает сумму, email, total payable и вариант Sage Pay.
5. Выберите Sage Pay, запустите оплату и пройдите тестовый путь у провайдера.
6. После возврата на сайт откройте invoice или историю платежей в GetPaid и проверьте статус.
7. В MyOpayo найдите тестовую транзакцию и сверяйте сумму, currency, reference и результат.

Что должно получиться

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

Нюанс тестирования с несколькими платежными методами

Если на checkout одновременно включены PayPal, bank transfer, manual payment и Sage Pay, первый тест лучше выполнить с Sage Pay как default gateway. Так вы исключите ситуацию, когда пользователь или тестировщик случайно выбрал другой метод. После успешного теста можно вернуть нужный порядок вариантов оплаты и снова проверить форму.

Хороший тестовый платеж должен оставить следы в двух системах: в GetPaid и в MyOpayo. Если след есть только в одной системе, это не финальная готовность, а сигнал к диагностике.

Особенности Sage Pay/Opayo, которые влияют на работу сайта

Платежный провайдер задает правила, которые WordPress-плагин не может отменить. Важно не воспринимать GetPaid Sage Pay Payment как «черный ящик», который сам решит все вопросы. Он является связующим слоем, а ограничения аккаунта, протокола, страниц провайдера, 3-D Secure, currency и fraud screening остаются на стороне платежной системы.

Hosted page и PCI-границы

Официальные материалы Opayo объясняют разные типы интеграций: Form, Server, Direct и другие подходы. Hosted-страницы обычно уменьшают объем карточных данных, которые проходят через сайт, потому что покупатель вводит карту у провайдера. Но это не делает WordPress-сайт «безопасным автоматически». Ваш checkout, редиректы, email, аккаунты администраторов и база данных все равно должны быть защищены.

Не добавляйте собственные поля для ввода номера карты в GetPaid forms. Если интеграция работает через hosted page, данные карты должны вводиться там, где это предусмотрено платежным провайдером. Самодельные поля в WordPress только увеличат риск и не дадут корректной авторизации.

3-D Secure и отказы банка

Ошибки 3-D Secure не всегда означают поломку плагина. В документации Opayo есть примеры, где transaction может быть отклонена из-за правил аутентификации, карты покупателя, настроек аккаунта или поведения пользователя на странице провайдера. В статье нельзя обещать, что включение GetPaid Sage Pay Payment устранит все отказы. Правильная задача плагина - передать платеж, получить результат и корректно отразить его в GetPaid.

Endpoints и старый бренд Sage Pay

В источниках встречаются названия Sage Pay, Opayo и Elavon. Также у провайдера есть материалы о миграции URL. Для администратора это означает практическое правило: если платежная регистрация не проходит, проверяйте не только пароль и vendor name, но и то, какие endpoints использует ваша версия add-on. Если публичная документация add-on не раскрывает этот момент, безопаснее обратиться в официальную поддержку GetPaid или проверить changelog установленной версии.

Page customiser и внешний вид платежной страницы

Opayo описывает page customiser для определенных методов интеграции и условий. Если вы хотите, чтобы страница провайдера визуально была ближе к бренду сайта, сначала проверьте, поддерживает ли ваш метод integration такую настройку. Не пытайтесь имитировать hosted payment page внутри WordPress через CSS или iframe, если это не предусмотрено gateway. Внешний вид оплаты важен, но корректный статус и безопасность важнее.

Совместимость с темой, кэшем и другими расширениями WordPress

Платежная форма находится на пересечении темы, shortcodes, блоков, JavaScript, cookies, сессий, кэша и внешнего gateway. Даже если GetPaid и Sage Pay gateway настроены правильно, тема или оптимизатор могут нарушить checkout. Поэтому после настройки нужно провести отдельный compatibility pass.

Кэш и оптимизация

Страницы checkout, receipt, success и failed transaction лучше исключить из page cache. Если на сайте используется оптимизация JavaScript, отложенная загрузка, объединение файлов или перенос скриптов в footer, проверяйте платежную форму после каждого включения. Симптомы конфликта: кнопка не нажимается, total не пересчитывается, gateway не выбирается, редирект не начинается, форма отправляется дважды.

Тема и блоки

Если checkout вставлен в сложный макет конструктора страниц, сначала протестируйте его на простой странице с обычным контентом. Некоторые конструкторы добавляют модальные окна, lazy loading, AJAX-навигацию или CSS, который влияет на форму. Это не всегда ошибка GetPaid. Хорошая проверка - создать временную страницу без сложных секций и вставить туда только shortcode или блок GetPaid.

Права пользователей и гостевая оплата

Настройка Require Login to Checkout в GetPaid может быть полезной для закрытых кабинетов, но мешать публичной оплате. Если клиент получает ссылку на invoice и видит требование войти, убедитесь, что это ожидаемое поведение. Для разовых платежей гостевой checkout часто удобнее, но тогда нужно внимательнее относиться к email, receipt и защите от спама.

Письма и уведомления

После успешного теста проверьте email-уведомления. Письмо о счете, receipt или payment confirmation может уходить через WordPress mail, SMTP-плагин или внешний сервис. Если платеж прошел, но письмо не пришло, это отдельная проблема доставки почты, а не обязательно ошибка Sage Pay gateway. В таком случае проверьте SMTP-логи, spam folder и отправителя сайта.

Возвращайте кэш и оптимизацию постепенно. Если включить все обратно одним кликом и checkout сломается, диагностика станет намного дольше.

Ошибки оплаты и диагностика без догадок

Диагностику платежей нужно вести как расследование по следам. Сначала фиксируется симптом, затем проверяются GetPaid settings, MyOpayo transactions, invalid transactions, журнал ошибок WordPress, серверные логи и кэш. Не стоит удалять и заново ставить плагин при первом отказе: так можно потерять контекст и усложнить поддержку.

Gateway не виден на checkout

Симптом: форма GetPaid открывается, сумма видна, но Sage Pay не отображается среди способов оплаты. Возможные причины: add-on не активен, gateway выключен, выбран неподходящий item/form, валюта не подходит, форма использует другой default payment form, на странице показан старый кэш.

Что проверить

• Активен ли add-on в Plugins.
• Включен ли gateway в GetPaid - Settings - Payment Gateways.
• Сохранены ли настройки после включения.
• Открыта ли страница checkout без кэша и как гость.
• Не используется ли другая payment form, где gateway скрыт условием или не выбран item.

Исправление начинайте с базового тестового item и простой страницы. Если gateway появляется там, но не появляется в рабочей форме, проблема в форме, макете или условиях, а не в установке add-on.

Error 5080 или ошибка регистрации form transaction

В официальной документации Opayo ошибка 5080 связана с проблемой формата post или encryption. Частые практические причины: неверный encryption password, перепутанные test/live credentials, устаревший endpoint, поврежденная строка передачи данных, лишние символы или неправильная обработка ответа. В WordPress-сценарии администратор не всегда видит всю внутреннюю строку, поэтому важно открыть invalid transactions в MyOpayo и смотреть подробность там.

Как действовать

1. Убедитесь, что тестируете в правильном окружении MyOpayo.
2. Проверьте credentials без публикации секретов в тикетах и чатах.
3. Посмотрите invalid transactions в MyOpayo.
4. Проверьте, не менял ли провайдер gateway URLs и поддерживает ли ваша версия add-on актуальные endpoints.
5. Если ошибка повторяется, соберите диагностический пакет для поддержки: время теста, invoice ID, сумма, режим, код ошибки, фрагмент лога без секретов.

Не исправляйте 5080 случайной заменой символов в коде плагина. Правка ядра add-on усложнит обновления и может сломать обработку платежей. Если проблема в версии интеграции или endpoint, ее нужно решать через обновление, настройку или поддержку разработчика.

Платеж успешен в MyOpayo, но invoice в GetPaid не оплачен

Это один из самых неприятных симптомов, потому что деньги могли быть авторизованы, а сайт не обновил статус. Возможные причины: покупатель не вернулся на сайт, callback заблокирован, success page настроена неверно, кэш отдал старую страницу, firewall заблокировал запрос, обработчик статуса завершился ошибкой PHP.

Проверяйте по порядку. Сначала найдите transaction в MyOpayo и зафиксируйте результат. Затем откройте invoice в GetPaid и посмотрите notes/status. После этого проверьте серверные логи вокруг времени платежа. Если есть security-плагин, посмотрите его журнал блокировок. Если используется CDN или Web Application Firewall, проверьте правила на платежные URL.

Ошибка IP restriction или проблема с хостингом

Opayo документация описывает valid IPs для server/direct scenarios. Даже если ваша конкретная интеграция работает через hosted flow, IP и сетевые ограничения могут всплывать в отдельных конфигурациях. На хостингах с меняющимися исходящими IP такие ошибки особенно неприятны. Не пытайтесь угадать IP по панели WordPress. Уточните у хостинга, какие исходящие адреса использует сервер для внешних запросов, и сверяйте требования с MyOpayo.

Покупатель видит failed page после отказа или 3-D Secure

Failed page сама по себе не означает поломку. Карта может быть отклонена, 3-D Secure может не пройти, покупатель может закрыть страницу провайдера, банк может вернуть отказ. Задача сайта - показать понятное сообщение и дать безопасный следующий шаг: попробовать другую карту, связаться с поддержкой, вернуться к invoice или выбрать другой метод оплаты, если он разрешен.

Быстрая карта симптомов и проверок

Симптом	Где смотреть сначала	Безопасное действие
Sage Pay не отображается	GetPaid gateway settings и кэш checkout	Проверить активность add-on, включение gateway, default gateway и простую тестовую форму.
Ошибка 5080	MyOpayo invalid transactions	Сверить test/live, encryption password, endpoint и журналы без правки ядра плагина.
Оплата есть у провайдера, но не в GetPaid	Invoice notes, server logs, security logs	Проверить возврат, callback, кэш, firewall и failed/success pages.
Покупатель не завершает 3-D Secure	MyOpayo transaction details	Проверить причину отказа и дать пользователю понятный повторный путь оплаты.

Полезные улучшения без правки ядра плагина

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

Отдельная тестовая страница checkout

Создайте закрытую страницу, на которой будет только тестовая payment form. Не добавляйте туда конструкторные эффекты, всплывающие окна, сторонние формы, рекламные скрипты и тяжелую аналитику. Такая страница нужна не покупателям, а администратору: при ошибке вы сможете быстро понять, проблема в gateway или в рабочем макете.

Чек-лист перед публикацией

• Выполнен тестовый платеж в test MyOpayo.
• Invoice в GetPaid получил ожидаемый статус.
• Success page и failed transaction page открываются без кэша.
• Письма GetPaid и SMTP-доставка проверены.
• Покупатель видит понятный текст gateway на checkout.
• Администратор знает, где искать invalid transactions и server logs.

Откат спорных изменений

Если после включения кэша, firewall-правила или оптимизации checkout сломался, откатывайте именно последнее изменение. Не отключайте сразу все плагины на рабочем сайте. Лучше иметь список изменений с временем: включили minify, провели тест, включили delay JS, провели тест, добавили CDN rule, провели тест. Такой журнал проще передать разработчику или поддержке.

Кодовые snippets для payment emails или invoice links используйте только из официальной документации и через безопасный способ вроде Code Snippets или дочерней темы, если вы понимаете, что делает фрагмент. Для первого запуска GetPaid Sage Pay Payment код обычно не нужен: сначала добейтесь стабильного gateway flow стандартными настройками.

Вопросы, которые стоит закрыть перед реальными платежами

Можно ли использовать GetPaid Sage Pay Payment без установленного GetPaid?

Нет, смысл add-on в том, чтобы добавить Sage Pay gateway к GetPaid. Сначала должен работать Core Plugin GetPaid, его settings, items, forms или invoices. Без ядра шлюз не даст самостоятельную платежную систему.

Почему в источниках встречаются Sage Pay, Opayo и Elavon?

Sage Pay в современных материалах провайдера часто фигурирует как Opayo в составе Elavon. Для администратора это важно при поиске документации, входе в MyOpayo, проверке endpoints и чтении ошибок. В интерфейсе add-on название может оставаться Sage Pay, но справка провайдера может использовать Opayo.

Нужно ли включать login requirement для оплаты счета?

Зависит от сценария. Для закрытого кабинета постоянных клиентов авторизация может быть уместной. Для публичной разовой оплаты она может мешать пользователю. Проверьте настройку Require Login to Checkout и протестируйте ссылку на invoice как гость.

Что делать, если тестовый платеж не появляется в MyOpayo?

Сначала проверьте, в том ли окружении вы ищете transaction. Test и live разделены. Затем проверьте gateway credentials, ошибку на checkout, invalid transactions, endpoint и серверные логи. Если платеж вообще не дошел до провайдера, причина может быть в отправке запроса, шифровании, блокировке или неверной настройке gateway.

Можно ли включать кэш на странице checkout?

Для платежных страниц лучше делать исключения. Checkout, receipt, success и failed transaction pages зависят от текущего пользователя, invoice, статуса и возврата после платежа. Статический кэш может показать устаревшую форму или сломать сценарий возврата.

Почему invoice не стал paid, хотя деньги видны у провайдера?

Чаще всего это связано с возвратом результата на сайт, обработчиком callback, блокировкой запроса, ошибкой PHP, кэшем или неправильными success/failed pages. Сверьте GetPaid invoice notes, transaction в MyOpayo и серверный журнал вокруг времени оплаты.

Подходит ли расширение для подписок?

GetPaid поддерживает recurring items и subscriptions на уровне ядра, но конкретная поддержка повторных платежей зависит от gateway, аккаунта провайдера и версии add-on. Если вам нужны регулярные списания через Sage Pay/Opayo, не включайте их на рабочем сайте без отдельного подтверждения в документации или поддержке разработчика.

Где лучше искать помощь при ошибках?

По ошибкам WordPress и GetPaid - в официальной поддержке GetPaid и журналах сайта. По статусам платежа, invalid transactions, 3-D Secure и настройкам MyOpayo - в справке Opayo/Elavon и аккаунте провайдера. В обращении не передавайте secret keys, encryption password и полные доступы без необходимости.

Когда GetPaid Sage Pay Payment будет удачным выбором

GetPaid Sage Pay Payment стоит использовать, если вы хотите принимать Sage Pay/Opayo платежи именно в экосистеме GetPaid: через invoices, items, payment forms или buy now buttons. Он особенно уместен для сайтов услуг, счетов, консультаций, платных размещений и небольших продаж без тяжелой корзины WooCommerce. Перед рабочим запуском обязательно проверьте страницы GetPaid, currency, test/live MyOpayo, возврат после оплаты и статус invoice.

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

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