CodeCanyon Network Merchants Payment Gateway - Плагин WordPress

Руководство по настройке CodeCanyon Network Merchants Payment Gateway для WooCommerce

CodeCanyon Network Merchants Payment Gateway нужен магазину WooCommerce тогда, когда владелец уже работает с NMI или с провайдером, который выдаёт NMI-учётные данные, и хочет принимать оплату картами, электронными кошельками и, при поддержке аккаунта, eCheck прямо в процессе оформления заказа. В этом руководстве мы не повторяем краткую карточку продукта, а разбираем практическую сторону: что проверить перед установкой, какие ключи нужны, как включить тестовый режим, как связать настройки с результатом на странице оплаты и как понять, почему заказ не проходит.

Плагин относится к классу WooCommerce payment gateway: он добавляет способ оплаты в WooCommerce, передаёт платёжные данные в NMI через механизм токенизации Collect.js и возвращает результат в заказ. Это значит, что основная работа администратора не сводится к одному переключателю Enable. Нужно связать WooCommerce, ключи NMI, режим транзакции, 3D Secure, сохранённые карты, webhooks, checkout-шаблон и тестовый заказ в одну цепочку.

Ниже есть подробная инструкция по CodeCanyon Network Merchants Payment Gateway, практический пример первого тестового платежа, карта настроек после установки, блок диагностики и сравнение с близкими решениями. Для спорных моментов я использую осторожные формулировки: точные возможности зависят от вашей версии плагина, NMI merchant account, процессора, страны, настроек WooCommerce и подключённых расширений.

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

Главная задача плагина - подключить WooCommerce к NMI так, чтобы магазин мог принимать платежи через уже выбранного платёжного провайдера. В карточке CodeCanyon и на странице PatSaTECH указаны ключевые возможности: настройка названия и описания способа оплаты, режимы Authorize Only и Sale, поддержка карт, Apple Pay и Google Pay, WooCommerce Subscriptions, Block Checkout, CheckoutWC, возвраты из заказа, выбор разрешённых типов карт, sandbox/live режимы, обязательный CVV, настройка окна 3D Secure и выбор inline или popup-полей карты.

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

Самая важная идея для первого запуска: сначала проверяйте не “появилась ли кнопка оплаты”, а всю цепочку “ключи NMI - токен Collect.js - заказ WooCommerce - статус транзакции - запись в логах”. Если цепочка рвётся в одном месте, покупатель может видеть серую линию, пустые поля, сообщение о недоступном способе оплаты или заказ в неправильном статусе.

Где плагин особенно полезен

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

Отдельный плюс для магазинов с обновлённым WooCommerce - заявленная поддержка Block Checkout и HPOS. Но эти пункты нельзя воспринимать как абсолютную гарантию для любой сборки сайта. Если checkout собран блоками, если используется CheckoutWC, если включён HPOS или подписки, после установки нужен отдельный тест каждого потока: обычный заказ, повторный заказ сохранённой картой, продление подписки, возврат и ошибка оплаты.

Когда лучше выбрать другой путь

CodeCanyon Network Merchants Payment Gateway может не подойти, если у вас нет NMI-аккаунта или процессор не выдаёт нужные ключи. Он также будет лишним, если магазин работает только с WooPayments, Stripe или PayPal и не планирует переходить на NMI. Ещё один ограничитель - сложная схема с несколькими merchant accounts на одном сайте: публичные источники не подтверждают, что этот конкретный плагин штатно поддерживает несколько независимых NMI-аккаунтов в одном способе оплаты.

Для магазинов с нестандартным checkout, агрессивной оптимизацией JavaScript, нестандартной темой или большим набором платежных расширений важна подготовка. Collect.js использует iframe-поля и JavaScript, поэтому конфликт скриптов, блокировка внешнего домена, неверная публикация ключей или ошибка в шаблоне checkout способны выглядеть как “плагин не работает”, хотя причина находится рядом.

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

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

Подготовка особенно важна для этого продукта, потому что в changelog есть изменения, которые затрагивали Collect.js, 3DS, wallets, сохранение карт, webhooks, HPOS, Block Checkout и CheckoutWC. Это не повод избегать плагина. Это нормальная история для платёжного расширения, но она показывает, что после обновления нельзя проверять только главную страницу сайта. Нужно пройти checkout.

Технические условия

Проверьте базу до установки:

• На сайте установлен и активен WooCommerce, а оформление заказа работает хотя бы с одним штатным способом оплаты.
• Сайт использует HTTPS. PatSaTECH указывает SSL-сертификат как требование, а для платёжных полей это практический минимум.
• Версии WordPress и WooCommerce попадают в диапазон совместимости, указанный на актуальной карточке товара CodeCanyon.
• Если включён HPOS, заказные таблицы синхронизированы, а критичные расширения магазина активны во время проверки.
• Если checkout построен блоками, проверьте, что версия плагина содержит поддержку Block Checkout и что на странице нет старого shortcode-дубля.
• Если магазин использует WooCommerce Subscriptions, проверьте настройки сохранённых способов оплаты и продлений отдельно от разовой покупки.

Данные NMI, которые понадобятся

Для первого подключения обычно нужны security key, tokenization public key, webhook signing key и настройки live или sandbox окружения. В документации PatSaTECH отдельно упомянут webhook URL вида https://www.yoursite.com/wc-api/woocommerce_nmipay. Его нужно указывать в настройках NMI так, чтобы gateway мог сообщать WooCommerce о событиях, важных для платежа и подписок.

Отдельный нюанс касается поля Public Checkout Key. В support-блоке CodeCanyon и в описании товара отмечено: если магазин в США застревает на checkout после ввода платёжных данных, это поле рекомендуется оставить пустым, потому что оно требуется только для пользователей из Великобритании. Это редкий пример настройки, где “заполнить все поля” может быть ошибкой. Если ваш процессор или аккаунт требует другой логики, сверяйтесь с NMI и поддержкой PatSaTECH.

Перед рабочим запуском не смешивайте sandbox и live данные. Если security key, public key, webhook signing key и режим окружения взяты из разных сред, ошибка часто проявляется не сразу, а на этапе получения токена, 3DS или завершения заказа.

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

Установка проходит как у большинства коммерческих WordPress-плагинов: загрузить ZIP-файл плагина, активировать его в админ-панели и открыть настройки способа оплаты в WooCommerce. Но у CodeCanyon-архивов есть типичная ловушка: если ZIP называется как общий архив marketplace, внутри может лежать отдельный ZIP плагина и документация. Support-раздел CodeCanyon прямо указывает, что при ошибке “No valid plugins were found” нужно распаковать внешний архив и устанавливать именно plugin ZIP.

Базовый порядок

1. Сделайте резервную копию сайта или работайте на staging.
2. Откройте Plugins и загрузите установочный ZIP плагина, а не общий архив с документацией.
3. Активируйте плагин и перейдите в настройки платежей WooCommerce.
4. Найдите NMI/Network Merchants gateway и включите его только в тестовом окружении.
5. Введите тестовые ключи, выберите sandbox mode, сохраните настройки.
6. Откройте страницу оформления заказа с простым товаром и убедитесь, что способ оплаты появляется.
7. Проверьте заказ в админ-панели и журнал WooCommerce после тестовой попытки.

После активации не спешите включать все возможности. Сначала добейтесь стабильной разовой оплаты картой в тестовом режиме. Затем добавляйте wallets, 3DS, сохранённые карты, подписки и webhooks. Такой порядок проще диагностировать: если всё включить за один проход, непонятно, что именно вызвало ошибку.

Что должно появиться после включения

В настройках WooCommerce должен появиться новый payment method, а на checkout - способ оплаты с названием и описанием, которые вы зададите в админ-панели. Если выбран inline-режим, покупатель видит поля карты внутри формы оформления заказа. Если выбран popup/lightbox-подход, чувствительные поля открываются в отдельном окне или оверлее. В обоих вариантах Collect.js должен вернуть токен, а не передавать карточные данные как обычные поля формы.

Мини-итог этапа: плагин установлен правильно только тогда, когда он виден в платежах WooCommerce, способ оплаты появляется на checkout, Collect.js загружает поля, тестовый заказ создаётся, а в заказе или логах есть понятный результат попытки оплаты.

Карта настроек после установки: от ключей до внешнего вида оплаты

Настройка CodeCanyon Network Merchants Payment Gateway должна идти от критичных параметров к косметическим. Сначала включение, режим, ключи, transaction type и webhooks. Затем card types, 3DS, CVV, wallets, сохранённые карты, подписки и текст на checkout. Внешний вид важен, но он не спасёт интеграцию, если gateway не получает токен или webhook не возвращается на сайт.

Основные поля и безопасная последовательность

Для типового магазина безопасный старт - включить sandbox, настроить ключи, оставить короткое название оплаты, выбрать простой режим карты, выполнить тестовый заказ и только после этого менять вид полей или включать дополнительные методы. Любое изменение, которое влияет на payment token, 3DS или сохранённые карты, проверяйте новым заказом, а не только сохранением страницы настроек.

Authorize Only или Sale

Режим Sale обычно означает попытку сразу провести оплату. Это удобно для цифровых товаров, стандартных заказов и магазинов, где заказ должен уйти в обработку сразу после успешной оплаты. Режим Authorize Only полезен, когда магазин сначала хочет подтвердить наличие товара, проверить адрес, согласовать заказ или удержать сумму перед ручным списанием. В этом случае важно настроить внутренний процесс: кто видит авторизованные заказы, когда выполняется capture, что происходит при отмене и как это отражается в NMI.

Не выбирайте Authorize Only только потому, что он звучит безопаснее. Если команда магазина не привыкла вручную завершать платежи, заказы могут зависать. И наоборот, не включайте Sale, если бизнес-процесс требует проверки перед списанием. Лучшие настройки зависят от того, когда вы готовы принять финансовое обязательство, а не от абстрактного “быстрее” или “строже”.

Карты, CVV, 3D Secure и окно проверки

Плагин заявляет обязательный CVV, выбор типов карт и настраиваемое окно 3D Secure: inline или popup. CVV лучше оставлять обязательным, потому что changelog отдельно фиксировал исправление ситуации, где CVV был необязательным. 3D Secure стоит включать тогда, когда этого требует ваш процессор, регион, риск-профиль или политика магазина. Если 3DS включён, проверьте не только успешную оплату, но и сценарий отказа, потому что в changelog есть отдельные исправления логирования 3DS failures.

Для inline-полей карта выглядит более естественно внутри checkout, но такой режим чаще зависит от CSS, ширины контейнера и конфликтов темы. Popup-режим может быть проще для сложной темы, но он меняет ощущение checkout. В обоих случаях проверьте desktop и mobile, хотя основной интерфейс настройки остаётся админским.

Apple Pay, Google Pay и где они появляются

Карточка товара и changelog указывают поддержку Apple Pay и Google Pay, а также перенос этих методов на cart и checkout. Документация NMI по Collect.js уточняет, что Google Pay обычно доступен через Collect.js, а Apple Pay требует совместимости процессора и доменной проверки. Поэтому wallets нельзя проверять только как “переключатель включён”. Нужно убедиться, что ваш merchant account и процессор поддерживают метод, домен прошёл проверку, а кошелёк появляется в нужном месте корзины или оформления заказа.

Если кошельки не отображаются, сначала проверьте условия самого кошелька и NMI, затем тему, HTTPS, страну, валюту и cart/checkout layout. Визуальное отсутствие Apple Pay или Google Pay не всегда означает ошибку плагина: иногда метод скрывается, потому что устройство, браузер, валюта или аккаунт не соответствуют условиям.

Как работает Collect.js, токены и сохранённые способы оплаты

Collect.js - это JavaScript-библиотека NMI для сбора платёжных данных и превращения их в токен. В официальной документации NMI объясняется, что Collect.js создаёт payment_token, который заменяет чувствительные данные карты или банковского счёта при дальнейшей отправке транзакции. Поддержка токенизации важна для WooCommerce-плагина: покупатель вводит данные в защищённые поля, а магазин работает с токеном и заказом.

Для администратора это объясняет несколько типичных симптомов. Если поля карты пустые или серые, проблема может быть до токена: не загрузился Collect.js, конфликтует JavaScript, неверный public key, блокируется внешний запрос. Если поля видны, но заказ не завершается, проблема может быть после токена: wrong environment, security key, Direct Connect, 3DS, webhook или ответ процессора. Если сохранённая карта не работает, проблема может быть в связке token vault, WooCommerce payment token и подписки.

Почему токен нельзя считать “сохранённой картой”

В документации NMI подчёркивается, что payment token Collect.js предназначен для краткосрочного использования и может быть одноразовым. Для повторных платежей, подписок и сохранённых карт нужна связка с Customer Vault или с механизмом payment tokens в WooCommerce. Поэтому “получили token” и “покупатель сможет платить сохранённой картой” - разные уровни интеграции.

Если в магазине используются WooCommerce Subscriptions, проверьте три действия отдельно: первая покупка подписки, автоматическое продление и смена платёжного метода. WooCommerce хранит payment methods на стороне аккаунта покупателя, а Subscriptions копирует токен в подписку для будущих списаний. Если токен не синхронизирован или webhook не возвращает событие, продление может вести себя иначе, чем разовая покупка.

Сохранённые карты, eCheck и Add Payment Method

PatSaTECH указывает поддержку сохранённых карт, eCheck, Customer Vault и исправления для страницы Add Payment Method. Это значит, что после разовой оплаты надо проверить страницу аккаунта покупателя: может ли пользователь добавить новый способ оплаты, выбрать сохранённую карту, удалить старый метод и оплатить повторный заказ. Если магазин не предлагает сохранение карт, лучше не включать лишние настройки, чтобы не усложнять checkout.

Для eCheck и ACH будьте особенно осторожны: наличие технической поддержки в плагине не означает, что ваш NMI account, процессор и страна позволяют этот метод. В статье можно говорить о возможности только условно: если она доступна в вашей версии и разрешена провайдером. В интерфейсе оплаты не должно быть метода, который вы не готовы обработать, объяснить покупателю и сверить в учёте.

Block Checkout, CheckoutWC и HPOS: что проверить отдельно

Современный WooCommerce может работать через классический shortcode checkout, блоки оформления заказа, сторонний checkout-дизайн и HPOS. Для платёжного плагина это не косметика. Payment method должен быть зарегистрирован для нужного checkout-механизма, передавать данные в серверную обработку заказа, корректно сохранять order meta и не ломаться на новых таблицах заказов.

Карточка CodeCanyon и changelog указывают поддержку Block Checkout, CheckoutWC и HPOS. Это хорошие признаки, но проверка всё равно нужна на вашем сайте. WooCommerce developer docs объясняют, что Checkout Block передаёт payment data на сервер и вызывает обработку payment gateway, а HPOS переносит данные заказов из классических таблиц WordPress в специальные таблицы WooCommerce. Если расширение совместимо в теории, но тема или другой плагин меняет checkout, фактический результат может отличаться.

Проверка для Block Checkout

Если страница оформления заказа собрана блоками, создайте отдельный тест:

1. Откройте редактор страницы checkout и убедитесь, что там используется блок оформления заказа, а не старый shortcode в соседнем блоке.
2. Добавьте простой товар в корзину и проверьте, появляется ли NMI payment method.
3. Выберите способ оплаты, заполните тестовые данные и завершите заказ.
4. Проверьте, что заказ получил ожидаемый статус, а payment method записан в заказе.
5. Откройте журнал WooCommerce, если checkout завис или блок показал ошибку без деталей.

Если метод оплаты не появляется только в блоках, но работает на классическом checkout, причина часто связана именно с Block Checkout integration или конфликтом скриптов. Не лечите это сменой ключей NMI, пока не проверили, работает ли классический поток.

Проверка для CheckoutWC и кастомной темы

CheckoutWC меняет интерфейс оформления заказа. Плагин заявляет поддержку этого решения, но checkout всё равно нужно тестировать как отдельный сценарий. Проверьте отображение inline-полей, popup, wallet-кнопки, сообщение об ошибке и повторную попытку после отказа карты. Если тема или checkout-плагин перемещает блоки формы, Collect.js iframe может получить слишком узкий контейнер или скрытый родительский элемент.

Если проблема появляется только с кастомным checkout, временно переключитесь на стандартную тему и стандартный checkout на staging. Это быстрый способ понять, ломается ли gateway сам по себе или конфликтует с оформлением. После подтверждения можно решать: менять режим полей, отключать конфликтующий скрипт на checkout или обращаться в поддержку с точным сценарием воспроизведения.

Проверка для HPOS

HPOS влияет на хранение заказов. WooCommerce рекомендует проверять совместимость расширений и держать compatibility mode во время перехода, пока данные синхронизируются. Для платёжного плагина важно, чтобы заказ, transaction ID, статус, refund, order notes и subscription data сохранялись корректно. Если магазин уже работает на HPOS, не откатывайте хранение заказов без причины, но проверьте платёжный поток на тестовом заказе и возврате.

Для HPOS-проверки лучше использовать один простой товар, один товар с доставкой и один сценарий возврата. Так вы видите не только успешный платёж, но и запись результата в заказе.

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

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

Цель

Получить успешный тестовый заказ, в котором покупатель проходит checkout, WooCommerce создаёт заказ, NMI возвращает ответ, а администратор видит в заказе способ оплаты и понятные order notes. В этом примере мы не проверяем подписки, сохранённые карты и wallets, чтобы не смешивать несколько источников ошибок.

Подготовка

• Создайте простой товар с небольшой тестовой ценой и без сложных условий доставки.
• Включите sandbox mode и используйте ключи того же окружения.
• Отключите кеширование checkout, если оптимизатор сайта умеет кешировать страницы WooCommerce.
• Включите логирование gateway, если такая настройка доступна в вашей версии плагина.
• Проверьте, что в WooCommerce есть валюта и страна, разрешённые вашим NMI account.

Шаги

1. Откройте настройки gateway и включите только базовую оплату картой.
2. Оставьте короткий title, например “Credit card”, чтобы не перегружать checkout.
3. Выберите transaction type, который соответствует будущему рабочему процессу. Для быстрой проверки обычно проще начать с immediate sale, если ваш аккаунт это позволяет.
4. Сохраните настройки и откройте checkout в приватном окне браузера.
5. Добавьте тестовый товар в корзину, заполните адрес и выберите NMI payment method.
6. Введите тестовые данные, разрешённые вашим NMI sandbox, и отправьте заказ.
7. Откройте созданный заказ в админ-панели и проверьте статус, order notes, transaction ID или сообщение gateway.
8. Сверьте попытку оплаты в NMI merchant portal, если у вас есть доступ к журналу транзакций.

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

Покупатель должен попасть на страницу “order received” или увидеть понятное сообщение об ошибке, если тестовая карта отклонена. В заказе должен быть указан способ оплаты NMI, а статус должен соответствовать сценарию: например, оплачен/processing для успешной sale-транзакции или ожидающий ручного действия для авторизации. В логах не должно быть ошибок вида “Payment Token not received”, “Invalid or missing payment token fields”, 3DS auth failed без объяснения или webhook signature mismatch.

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

Если покупатель вводит данные, но checkout “тонко сереет”, зависает или не завершает заказ, не меняйте сразу все настройки. Сначала проверьте Public Checkout Key и страну аккаунта, затем JavaScript-консоль, доступность Collect.js, совпадение sandbox/live ключей и журналы WooCommerce. У этой проблемы есть конкретная подсказка в support-блоке товара: для пользователей из США поле Public Checkout Key может быть не нужно.

Практичные идеи применения в разных магазинах

Плагин не является конструктором маркетинговых сценариев, но его настройки можно применить по-разному в зависимости от бизнес-процесса. Ниже - не “универсальные преимущества”, а рабочие варианты, которые опираются на подтверждённые функции: transaction type, tokenization, saved cards, subscriptions, wallets, 3DS, refunds и WooCommerce order flow.

Магазин с ручной проверкой заказа

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

Подписочный сервис

Для подписок важны сохранённые payment methods, Customer Vault и webhooks. Сначала проверьте покупку новой подписки, затем продление и смену карты. Если покупатель не может удалить карту из аккаунта, связанного с активной подпиской, это может быть не ошибка, а защитная логика подписочного сценария. Важно объяснить это поддержке магазина, чтобы она не обещала покупателю невозможное действие.

Магазин, где нужен быстрый checkout

Если покупатели часто оплачивают с мобильных устройств или повторяют покупки, проверьте Apple Pay, Google Pay и сохранённые карты. Эти методы сокращают ввод данных, но требуют совместимости аккаунта, устройства, браузера, домена и валюты. Результат проверки - кошелёк появляется в корзине или checkout, заказ создаётся, а в order notes видно, каким способом прошла оплата.

Магазин с повышенным риском отказов

Если у магазина много отказов по картам или спорных транзакций, включайте 3DS и AVS/CVV-диагностику только после теста базовой оплаты. В changelog плагина есть упоминания AVS/CVV response details и логирования 3DS auth failed events. Это полезно для поддержки: вместо “платёж не прошёл” можно смотреть конкретный слой - проверка карты, 3DS, токен, ответ gateway или заказ WooCommerce.

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

Проверка результата должна быть повторяемой. Составьте небольшой чек-лист и проходите его после установки, обновления WooCommerce, обновления темы, включения HPOS, перехода на Block Checkout, добавления CheckoutWC и изменения NMI-ключей. Платёжный плагин может работать месяцами, но одна смена checkout-скрипта способна сломать поля карты.

Минимальный набор тестов

• Разовая успешная оплата картой в sandbox.
• Отклонённая оплата с понятным сообщением для покупателя и записью в логах.
• Проверка inline и popup-режима, если вы меняете отображение полей.
• Проверка 3DS, если он включён в аккаунте и настройках.
• Проверка refund из заказа WooCommerce, если вы планируете делать возвраты из админ-панели.
• Проверка сохранённой карты и страницы My Account только если эта функция нужна магазину.
• Проверка subscription renewal, если используются WooCommerce Subscriptions.
• Проверка Block Checkout или CheckoutWC в фактическом checkout-шаблоне магазина.

Если тестовый заказ прошёл, но письмо не пришло, это уже не обязательно проблема gateway. Проверьте статус заказа, настройки писем WooCommerce и почтовую доставку. Если заказ не создан вообще, возвращайтесь к checkout, токену и JS. Если заказ создан, но NMI не видит транзакцию, смотрите настройки gateway и API-ответ. Если NMI видит транзакцию, а WooCommerce нет, проверяйте webhook URL, подпись и доступность сайта снаружи.

Что записывать после проверки

Хорошая практика - вести короткий внутренний протокол: версия плагина, версия WooCommerce, тип checkout, HPOS включён или нет, transaction type, режим 3DS, результат тестовой карты, наличие webhook-события, статус заказа и место логов. Не публикуйте в таком протоколе секретные ключи. Достаточно последних 4 символов или пометки “sandbox key set A”.

Эта запись особенно полезна после обновлений. Если через месяц появится ошибка, вы будете знать, что изменилось: тема, checkout, HPOS, версия плагина, ключи или настройки NMI.

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

Для платёжного плагина лучше избегать агрессивных доработок. Не меняйте ядро WordPress, WooCommerce или файлы gateway. Не перехватывайте платёжные данные JavaScript-кодом и не пытайтесь “упростить” Collect.js. Если нужна кастомизация, начинайте с настроек gateway, текста checkout и внешнего CSS, который не вмешивается в обработку транзакции.

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

Документация NMI по Collect.js описывает классы CollectJSValid и CollectJSInvalid как внешние контейнеры iframe-полей. Это даёт безопасную точку для лёгкого визуального оформления. Пример ниже не меняет бизнес-логику и не читает карточные данные. Его можно добавить в CSS дочерней темы или в штатный инструмент пользовательского CSS, если ваша тема его поддерживает.

#payment .payment_box .CollectJSValid {
  border-color: #2f8f5b;
  box-shadow: 0 0 0 1px rgba(47, 143, 91, 0.18);
}

#payment .payment_box .CollectJSInvalid {
  border-color: #c83d3d;
  box-shadow: 0 0 0 1px rgba(200, 61, 61, 0.18);
}

#payment .payment_box .CollectJSValid,
#payment .payment_box .CollectJSInvalid {
  border-radius: 6px;
  transition: border-color 0.15s ease, box-shadow 0.15s ease;
}

Проверьте результат на checkout после очистки кеша. Если класс не применяется, не форсируйте селекторы через нестабильные внутренние элементы iframe. Откат простой: удалите CSS и снова проверьте checkout. Любая правка оформления платежных полей должна проходить тестовый заказ, а не только визуальный просмотр.

Что лучше не дорабатывать

Не добавляйте собственный JavaScript, который меняет отправку платежной формы, не подменяйте tokenization key на клиенте и не скрывайте ошибки gateway ради “чистого” checkout. Если нужны дополнительные merchant fields, карточка CodeCanyon упоминает поддержку передачи полей с именами вида merchant_defined_field_x через checkout field editor, но этот сценарий нужно согласовать с тем, какие поля реально принимает ваш NMI-настройка. Не отправляйте лишние персональные данные без понятной причины.

Диагностика ошибок оплаты и зависшего checkout

Проблемы платёжного шлюза лучше разбирать по слоям: отображение метода, загрузка Collect.js, получение токена, отправка в NMI, 3DS, webhook, запись заказа и возврат. Такой порядок быстрее, чем хаотично менять ключи и режимы. Ниже - типовые симптомы для NMI/WooCommerce связки и безопасные проверки.

Способ оплаты не отображается на checkout

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

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

• Откройте WooCommerce payment settings и убедитесь, что gateway включён.
• Проверьте обычный checkout без кастомного checkout-плагина на staging.
• Отключите кеш для cart, checkout и account pages.
• Проверьте, появляется ли метод на классическом checkout, если блоки не показывают его.

Исправление зависит от слоя. Если метод работает на классическом checkout, проблема ближе к Block Checkout или checkout-дизайну. Если не работает нигде, проверьте активацию плагина, настройки WooCommerce и журнал ошибок PHP.

Поля карты серые, пустые или checkout зависает

Симптом: покупатель выбирает NMI, но поля карты неактивны, отображается тонкая серая линия или форма не завершает заказ. Для этого продукта в support-блоке CodeCanyon есть конкретная подсказка: пользователям из США при похожем зависании предлагают оставить Public Checkout Key пустым, потому что он обязателен только для Великобритании.

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

• Совпадают ли sandbox/live режим и введённые ключи.
• Загружается ли скрипт Collect.js в браузере без блокировки.
• Нет ли ошибок JavaScript на checkout от темы или оптимизатора.
• Не скрывает ли checkout-плагин контейнеры iframe до момента выбора оплаты.

Исправление: проверьте ключи, временно отключите объединение и отложенную загрузку checkout-скриптов, протестируйте стандартную тему на staging, затем возвращайте оптимизацию по одной настройке.

Ошибка “Payment Token not received” или “Invalid or missing payment token fields”

Симптом: форма видна, но заказ не проходит из-за отсутствующего или некорректного токена. В changelog плагина есть исправления, связанные с “Payment Token not received” и “Invalid or missing payment token fields”, особенно в сценариях сохранённых карт. Это показывает, что слой токенизации нужно проверять отдельно.

Проверьте public tokenization key, режим Collect.js, сохранённые карты, включён ли параметр “save to account”, а также нет ли старых сохранённых payment methods в тестовом аккаунте. Если ошибка появляется только с сохранённой картой, создайте новый тестовый пользовательский аккаунт и повторите заказ новой картой. Если новый заказ проходит, проблема может быть в старом токене или синхронизации сохранённых способов оплаты.

3D Secure не проходит или покупатель возвращается без оплаты

Симптом: 3DS challenge открывается, но после проверки заказ получает ошибку или зависает. Возможные причины - несовместимость processor/account, неправильная настройка 3DS window, ошибка billing state, конфликт checkout-плагина или блокировка callback-события. В changelog есть упоминания исправлений 3DS, включая ошибку из-за поля state и логирование 3DS auth failed events.

Проверьте 3DS в sandbox по тестовым картам, которые поддерживает ваш NMI-провайдер. Затем сравните inline и popup challenge. Если в одном режиме ошибка исчезает, проблема может быть в контейнере темы или overlay checkout. Не отключайте 3DS на рабочем магазине без согласования с требованиями процессора и рисковой политикой.

Webhook не доходит до WooCommerce

Симптом: платежи видны в NMI, но WooCommerce не обновляет заказ или подписку. Проверьте URL /wc-api/woocommerce_nmipay, доступность сайта извне, SSL, firewall, security plugin, webhook signing key и правильность окружения. Если сайт закрыт базовой авторизацией на staging, внешние webhooks не смогут дойти без отдельного разрешения.

Исправление: временно проверьте endpoint снаружи, внесите webhook URL в NMI заново, убедитесь, что ключ подписи относится к тому же окружению, и повторите тестовый заказ. Если используется CDN или web application firewall, проверьте, не блокирует ли он запросы gateway.

Refund не отражается или заказ остаётся в старом статусе

Симптом: администратор делает refund из WooCommerce, но статус или сумма не сходится с NMI. Возможные причины - транзакция ещё не eligible для refund, вместо refund нужен void, transaction type был authorization, webhook не вернулся или у gateway нет прав на операцию. Проверьте transaction ID, статус в NMI и order notes.

Если возврат критичен для магазина, протестируйте его до запуска. Не обещайте поддержке магазина “возврат одним кликом” без проверки именно вашей связки NMI account, WooCommerce, gateway и статуса транзакции.

Ограничения и решения, которые стоит принять заранее

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

Одна платёжная логика на один вид checkout

Если магазин одновременно тестирует классический checkout, Block Checkout, CheckoutWC и несколько оптимизаторов, диагностика усложняется. Выберите основной checkout и проводите все тесты на нём. Альтернативный checkout держите только как способ изоляции ошибки. Это особенно важно для Collect.js, где внешний JavaScript и iframe-поля должны попасть в правильные контейнеры.

Нельзя обещать поддержку всех карт и стран

Плагин позволяет выбрать card types и подключает NMI, но фактическая поддержка брендов карт, стран, валют, wallets и eCheck зависит от merchant account и процессора. В тексте checkout лучше не перечислять методы, которые вы не проверили. Если Apple Pay или ACH доступны только части покупателей, объясните это в FAQ магазина или в служебной инструкции поддержки.

Подписки требуют отдельной дисциплины

WooCommerce Subscriptions не просто повторяет обычную оплату. Там есть сохранённый payment method, future renewal, failed renewal, смена карты и иногда ручная корректировка дат. Changelog продукта содержит отдельные изменения по subscription renewal synchronization и webhooks. Значит, если подписки важны, нужен отдельный тестовый набор, а не один checkout разового товара.

Когда CodeCanyon Network Merchants Payment Gateway будет удачным выбором

CodeCanyon Network Merchants Payment Gateway стоит использовать, если магазин WooCommerce уже ориентирован на NMI, владелец понимает, какие ключи и методы оплаты доступны в его merchant account, а команда готова проверять checkout как критичный бизнес-процесс. Сильная сторона продукта - не “волшебная оплата в один клик”, а связка WooCommerce с NMI-функциями: Collect.js, режимы транзакции, 3DS, wallets, refunds, subscriptions, Block Checkout, CheckoutWC и HPOS.

Перед рабочим запуском пройдите минимум один тестовый заказ, один сценарий отказа, один refund и одну проверку webhook. Если используются подписки или сохранённые карты, добавьте отдельный тест продления и смены способа оплаты. Если checkout построен блоками или CheckoutWC, не переносите результат классического checkout на него автоматически.

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