MevvPos — Документация Mevvsoft

Установка

MevvPos требует WordPress 6.0+ и PHP 8.1+. WooCommerce не обязателен. При активном WooCommerce 9.0 или новее MevvPos регистрирует себя как способ оплаты на странице оформления заказа; без него платёжный движок всё равно загружается и может управляться другим плагином. Более ранние версии объявляли WooCommerce жёсткой зависимостью, и WordPress отказывался активировать плагин без него — это требование убрано.

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

Загрузите плагин в разделе Плагины → Добавить новый → Загрузить плагин и активируйте его.
Откройте MevvPos в левом меню админки. Есть и ярлык внутри WooCommerce — там, где продавцы обычно ищут настройки платежей.
На вкладке Общие включите способ оплаты и задайте название, которое покупатель увидит при оформлении заказа.
На вкладке Bank API выберите провайдера — турецкий банковский виртуальный POS или одного из международных провайдеров — и введите выданные им учётные данные.
Если вы выбрали международного провайдера, скопируйте адрес вебхука, указанный на той же вкладке, в собственную панель провайдера. Без него ничего не завершится.
В разделе Рассрочка и комиссия введите свои ставки по рассрочке.
Проверьте работу с тестовыми учётными данными банка, прежде чем выходить в боевой режим.

The free plugin creates no database tables and registers no scheduled job. Everything lives in WordPress options and in order meta.

Pro — это отдельный плагин, который устанавливается рядом с бесплатным, а не заменяет его. Бесплатный плагин публикуется на WordPress.org, где всё опубликованное можно распространять дальше по GPL; если бы платный исходный код лежал в том же пакете, любой, кто удалил бы проверки лицензии, имел бы законное право его распространять. Лицензионный ключ вводится на вкладке Лицензия.

Открытие WooCommerce → Настройки → Платежи → MevvPos перенаправляет вас на экран MevvPos. Это сделано намеренно: у этих настроек одно место, а не два, которые могут разойтись.

Как это работает

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

Подписанная форма — Турция: Семь семейств турецких виртуальных POS. MevvPos формирует платёжные поля, подписывает их вашим ключом магазина и отправляет их в банк методом POST. Клиент проходит аутентификацию через 3-D Secure, и банк возвращается на ваш сайт; именно подпись при этом возврате завершает заказ.
Размещённая страница и вебхук — международные провайдеры: Stripe, PayPal, Mollie, Square, Authorize.Net, Checkout.com, Razorpay и Paystack. MevvPos создаёт платёж у провайдера через его REST API и отправляет клиента на собственную страницу провайдера. Заказ завершает ответ провайдера: подписанное уведомление, которое приходит на ваш адрес webhook, или — если клиент вернётся раньше — межсерверный запрос статуса, сделанный со страницы возврата. Что никогда не завершает заказ само по себе — это возвращение браузера.

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

Вы определяете одну или несколько записей POS. Запись POS — это виртуальный POS одного банка: его учётные данные, адрес шлюза, ставки рассрочки.
При оформлении заказа покупатель вводит карту. Первые шесть цифр — BIN — определяют выпустивший её банк.
MevvPos ищет этот BIN и отправляет платёж на ваш POS в этом банке, если он у вас есть. Иначе платёж уходит на ваш POS по умолчанию.
Рассрочка предлагается только тогда, когда карта принадлежит собственному банку этого POS, потому что банки не дают рассрочку по картам другого банка.
Покупатель проходит 3-D Secure в банке, и банк возвращается на единственный адрес обратного вызова на вашем сайте.
Подпись на возврате проверяется ключом того POS, который заказ действительно использовал, заказ завершается, а результат записывается.

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

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

Международные провайдеры

Международные провайдеры покрывают мир за пределами Türkiye. Все они используют собственную размещённую или перенаправляемую страницу провайдера, поэтому данные карты никогда не вводятся на вашем сайте. Аутентификация тоже проходит там, но результат там не остаётся: MevvPos фиксирует, был ли плательщик аутентифицирован, отправляет его в банк, когда эмитент требует дополнительной проверки, и читает ECI, чтобы записать, перешла ли ответственность за чарджбэк. Если провайдер не сообщает результат, он записывается как неизвестный, а не как ваш. Помимо карты, локальные методы уходят в собственном поле каждого провайдера: iDEAL, Bancontact, прямое дебетование SEPA, Klarna, EPS, Przelewy24, BLIK, TWINT, Multibanco и кошельки. Вы выбираете, какие из них предлагает счёт, и невыбранный метод никогда не отправляется. Метод, валюта которого не совпадает с заказом, отбрасывается сразу: предложить iDEAL для заказа в долларах означало бы лишь провалить платёж у провайдера.

Stripe: Checkout Session в режиме mode=payment, которая создаёт Payment Intent за собственной страницей Stripe. Секретный ключ вводится в поле ключа продавца, а Webhook signing secret — в дополнительное поле. Заказ завершается подписанным событием payment_intent.succeeded. Elements намеренно не используется: его применение перенесло бы поля карты на вашу страницу и увеличило бы объём PCI.
PayPal: Orders v2, в три шага: создать заказ, клиент подтверждает его в PayPal, а MevvPos списывает средства. Третий шаг легче всего упустить из виду — одобренный, но так и не списанный заказ оставляет деньги не полученными, хотя заказ выглядит оплаченным. Идентификатор REST-клиента вводится в поле номера продавца, секрет клиента — в поле ключа продавца, а Webhook ID — в дополнительное поле.
Mollie: Payments API v2. API-ключ — live_… или test_… — вводится в поле ключа продавца, а дополнительного поля нет, потому что Mollie не подписывает свои уведомления. О том, что вместо этого делает MevvPos, — в разделе о вебхуках ниже.
Square: Payment Link через Checkout API. Введите токен доступа в поле ключа продавца, а также Location ID и Webhook signature key. Square привязывает каждую продажу к локации: без Location ID платёж вообще нельзя создать, а собственная ошибка Square не говорит об этом прямо.
Authorize.Net: Accept Hosted. API Login ID вводится в поле номера продавца, Transaction Key — в поле ключа продавца, а Signature key — в дополнительное поле; это другое значение, нежели Transaction Key, и его легко с ним перепутать. Это единственный провайдер, который не возвращает адрес перенаправления: он возвращает токен, который MevvPos отправляет на размещённую страницу в виде формы.
Checkout.com: Hosted Payments Page. Секретный ключ (sk_…) вписывается в ключ мерчанта, а ключ подписи webhook — в дополнительное поле; уведомление подписывается HMAC-SHA256 по сырому телу. Одно поведение, к которому стоит подготовиться: возврат принимается асинхронно. Checkout.com отвечает на вызов возврата кодом 202 и идентификатором действия — это значит, что запрос принят, а не что деньги уже вернулись.
Razorpay: Payment Link — для магазинов, продающих в Индию, где одной карты мало, а UPI, интернет-банк и кошельки собраны на странице провайдера. Key ID вписывается в номер мерчанта, Key Secret — в ключ мерчанта, а секрет webhook (значение, отдельное от Key Secret) — в дополнительное поле. Razorpay возвращает два идентификатора, и они не взаимозаменяемы: статус запрашивается по идентификатору ссылки (plink_…), тогда как возврат возможен только по идентификатору платежа (pay_…), который ссылка сообщает после оплаты.
Paystack: Размещённая страница транзакции — для магазинов, продающих в Нигерию, Гану, ЮАР, Кению и Кот-д’Ивуар, где USSD, банковский перевод и мобильные деньги значат не меньше карты. Секретный ключ (sk_live_… или sk_test_…) вписывается в ключ мерчанта, дополнительного поля нет — уведомление подписывается HMAC-SHA512 тем же секретом. Всё держится на одной ссылке-референсе: запуск платежа, запрос его статуса и возврат используют её же.

Тестовый режим подставляет собственный адрес песочницы провайдера для PayPal, Square и Authorize.Net. Stripe и Mollie отделяют боевой режим от тестового по ключу, а не по адресу, поэтому там решающим является вставленный вами ключ.

Суммы переносятся из конца в конец как целые числа в минимальной единице валюты — куруш, центы — и никогда как десятичная дробь. Mollie — единственный провайдер, которому нужна строка с десятичным числом, причём с точным числом знаков для данной валюты: 10.0 отклоняется там, где принимается 10.00. Эта строка строится из целого числа, а не из числа с плавающей точкой.

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

Записи POS

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

По умолчанию: POS, который принимает платёж, когда лучшего совпадения не нашлось. Он всегда ровно один.
Неактивен: Сохранён, но не принимает платежи. Используйте это вместо удаления, когда POS настроен, но ещё не запущен в банке, — иначе покупатель с картой этого банка не сможет заплатить.
Ожидание лицензии: Запись существует, но спит, потому что лицензия неактивна. Ничего не удалено; при продлении лицензии она продолжит с того же места.
Данные API не введены: У записи ещё нет номера магазина.

Банки обозначены цветной полосой, а не логотипом. Логотипы банков — товарные знаки, а пятнадцать логотипов — это и юридический риск, и постоянное сопровождение; вы и так знаете, какой банк ваш.

Последний POS нельзя удалить, а последний включённый — отключить. Чтобы полностью перестать принимать оплату картой, отключите способ оплаты на вкладке Общие.

There is no cap on the number of provider accounts, and routing between them — by the card’s issuing bank and by the order’s currency — is part of the free plugin. Earlier releases allowed one account; that limit was removed in 4.9.0.

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

API банка — учётные данные и адрес шлюза

Провайдер: Список разбит на две группы: Турция — банковский виртуальный POS и Международные платёжные провайдеры. Всё остальное, что спрашивает форма, вытекает из этого единственного выбора, а настройки, которые не могут относиться к вашему выбору, вообще не показываются.
Банк: Выберите банк, в котором открыт ваш POS. От этого выбора зависят и адрес шлюза, и список BIN, используемый для рассрочки. Организации, для которых реализации ещё нет, помечены «— yakında» (скоро) и выбрать их нельзя.
Номер продавца (Client ID): Номер магазина, который выдал вам банк.
Ключ продавца (Store key): Ключ безопасности магазина. Хранится как поле пароля; после сохранения показывается замаскированным.
Gate URL: Адрес, на который отправляется форма оплаты.
Отправлять в банк собственную валюту заказа: Только для турецкого виртуального POS, по умолчанию выключено: MevvPos отправляет турецкую лиру, которую и ожидает ваш банк, если у вас нет мультивалютного договора. Валюта — часть подписи, поэтому значение, которое банк не принимает, отклоняется без объяснения. Международные провайдеры принимают валюту заказа как есть, и этот вопрос им никогда не задаётся.
Включить тестовый режим: Останавливает автоматическое перенаправление, чтобы вы могли изучить запрос до отправки.

Оставленное пустым поле Store Key при сохранении означает «не менять». Запись пустого значения стёрла бы ключ, и ваш магазин перестал бы принимать платежи без единого сообщения об ошибке. То же правило действует и для остальных секретных полей.

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

Garanti BBVA — Merchant ID, имя пользователя для авторизации, пароль авторизации.
VakıfBank — Terminal No и адрес MPI (оставьте пустым, чтобы использовать тестовый адрес).
PayTR — Merchant Salt.
iyzico, Craftgate, Sipay — дополнительных полей нет: ключ API вводится в поле «Номер продавца», а секрет — в «Ключ продавца».
Stripe — Webhook signing secret.
PayPal — Webhook ID.
Square — Location ID и Webhook signature key.
Authorize.Net — Signature key, используется только для вебхуков.
Mollie — дополнительных полей нет: API-ключ вводится в Merchant key.

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

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

Тринадцать поддерживаемых организаций

NestPay / Asseco (Payten): İş Bankası, Akbank, Halkbank, QNB, Şekerbank, TEB, Ziraat Bankası
Garanti GT3D: Garanti BBVA
PayFlex V4: VakıfBank
Платёжные организации: iyzico, PayTR, Craftgate, Sipay

Организации без реализации намеренно остаются в списке банков с пометкой «— yakında». Если их убрать, станет не видно, каких семейств протоколов ещё нет. Если ваш банк из их числа, сообщите об этом на вкладке Запрос по банку.

Только подпись NestPay имеет эталонный тест по опубликованному примеру самого банка. Каждый другой провайдер помечен в своём исходном коде как beta: поток реализован по документации, но ещё не проверен от начала до конца на действующем торговом аккаунте в этой организации. Эта пометка остаётся до тех пор, пока проверка не будет проведена.

Платёжные организации не выпускают карты, поэтому списка BIN у них нет. Вы выбираете их как свой POS, а не маршрутизируете к ним.

Вебхуки — где заказ на самом деле завершается

Каждому международному провайдеру нужен один адрес на вашем сайте, и его форма у всех одинаковая: ?mevvpos-webhook=<provider> к вашему главному адресу. Точное значение выводится в режиме «только для чтения» на вкладке Bank API; клик по полю выделяет его.

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

Скопируйте адрес с вкладки Bank API.
Mollie — исключение, и никуда ничего вставлять не нужно: MevvPos отправляет адрес вместе с каждым создаваемым платежом. Он опускается, если сайт отвечает на локальном адресе, потому что Mollie всё равно не смог бы до него достучаться — при локальной разработке результат вместо этого приходит из запроса статуса.
Вставьте его в собственную панель провайдера точно в том виде, в котором он показан. Square вычисляет подпись по адресу уведомления вместе с телом запроса, поэтому разница даже в один символ — достаточно завершающего слэша — приводит к тому, что каждое событие незаметно не проходит проверку.
Сохраните секрет подписи, который вернул провайдер, в дополнительном поле этого провайдера.
Отправьте тестовое событие из панели провайдера и проверьте, что заказ действительно сдвигается.

Mollie вообще не подписывает своё уведомление — в теле нет ничего, кроме идентификатора платежа. Это выглядит небезопасно, а на деле безопаснее: MevvPos не доверяет уведомлению, а воспринимает его как дверной звонок. Он берёт идентификатор и напрямую спрашивает Mollie, каков статус платежа, и только ответ paid порождает событие. Злоумышленник может позвонить в звонок с выдуманным идентификатором, но не может подделать ответ Mollie, поэтому поддельное уведомление никогда не сможет пометить заказ как оплаченный. Если до Mollie не удаётся достучаться, ответ — «не знаю», и ничего не меняется.

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

Для каждого провайдера действуют три правила. Ответ — всегда пустой 200: проверенное событие, дубликат и мусор получают один и тот же ответ, потому что другой ответ подсказал бы злоумышленнику, какая из его попыток была ближе, а ответ с ошибкой лишь заставил бы провайдера повторять событие, которое никогда не пройдёт проверку. PayTR — единственное исключение: он хочет получить буквальный текст OK и без него повторяет уведомление часами. Повторная доставка того же события не имеет второго эффекта. А то, по какому счёту проверяется событие, читается из вашей собственной конфигурации, а не из запроса — иначе злоумышленник мог бы сам назначить ключ, которым проверяется его же подделка.

Вебхук не проходит через конечную точку WooCommerce. У него собственная переменная запроса, и он перехватывается ещё до того, как вообще запускаются тема, страница и механизм запросов — именно поэтому он работает и на сайте без установленного WooCommerce.

Маршрутизация по BIN

Первые шесть цифр карты определяют выпустивший её банк. MevvPos сопоставляет ровно по этим шести цифрам.

A snapshot of the BIN table ships inside the plugin — 1.449 BINs across 36 banks in the current build — so routing works offline, with no account of any kind, from the moment you install it.
Pro обновляет её еженедельно с наших серверов. Обновление накладывается на упакованную таблицу, а не заменяет её: частичный или пустой ответ ни в коем случае не должен оставить магазин вообще без данных BIN.
Ответ, содержащий меньше сотни BIN, отклоняется как неправдоподобный и не записывается.
Конфликты — когда один и тот же BIN заявляют два банка — разрешаются на нашей стороне до отправки списка. Магазин, разрешающий их у себя, мог бы одновременно считать карту «своей» и направлять её в другое место.

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

Та же таблица при оформлении заказа отвечает и на второй, другой вопрос: принадлежит ли эта карта собственному банку данного POS? Именно это решает, предлагать ли рассрочку, — см. ниже.

Точность BIN не является платной возможностью. Pro оплачивает свежесть, а не правильность: упакованный список — тот же самый список, просто зафиксированный на момент сборки.

Рассрочка и комиссия

Ставки задаются для каждого POS, от разового платежа до двенадцати частей, на вкладке Рассрочка и комиссия. Это проценты: пишите 5.50 для 5,5 %.

Это работает на обеих поверхностях оформления. На блочной странице таблицу рассрочки рисует сам блок, а надбавка добавляется в корзину как сбор — ровно как на классической странице, поэтому выбор рассрочки обновляет итог до оформления заказа.

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

0: Вариант показывается, комиссия не добавляется.
Пусто: Вариант не показывается вовсе. Пусто и ноль — не одно и то же.

Комиссия появляется в корзине как облагаемый налогом сбор с названием «N Taksit Komisyonu» и рассчитывается от суммы корзины, включая доставку и налог.

Рассрочка предлагается только по картам, выпущенным собственным банком этого POS, и это проверяется на сервере, а не просто скрывается в интерфейсе. Карта другого банка принудительно возвращается к единовременному платежу, а сбор снимается.

The ceiling is twelve in every installation — that is the limit the banks themselves apply, not a product limit. It is enforced in three places: the list the customer sees, the value that arrives with the form, and the value the engine sends to the provider. A modified form cannot buy more instalments than you offer.

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

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

Поток оплаты и обращение с картой

Каждое турецкое семейство проходит через 3-D Secure. Режима без 3D нет, и нет настройки, которая бы его отключала. На международной стороне MevvPos говорит на EMV 3-D Secure 2: он фиксирует, был ли плательщик аутентифицирован с дополнительной проверкой или без неё, отправляет клиента в банк, когда эмитент её требует, и читает ECI, чтобы записать, перешла ли ответственность за чарджбэк. Двух вещей он намеренно не делает: никогда не заявляет освобождение, для которого у провайдера нет поля, и никогда не записывает ответственность как вашу, когда провайдер не сообщает нам результат, — «мы не знаем» и «ответственность на продавце» это разные ответы.

Поток через форму: NestPay, Garanti, PayTR и Sipay: браузер отправляет подписанную форму в банк, покупатель проходит аутентификацию, и банк возвращается на ваш сайт.
Поток через сервер: VakıfBank, iyzico и Craftgate: ваш сервер общается с провайдером, получает страницу 3-D, показывает её и после аутентификации завершает продажу в режиме сервер-сервер.
Поток с перенаправлением: Stripe, PayPal, Mollie, Square, Checkout.com, Razorpay и Paystack: MevvPos создаёт платёж через REST API провайдера и отправляет клиента по адресу, который провайдер возвращает.
Поток с формой-токеном: Authorize.Net: вместо адреса провайдер возвращает токен, и этот токен отправляется на его размещённую страницу в виде формы. Запись токена в URL привела бы к его утечке в историю браузера и журналы сервера.

Турецкие банки всегда возвращаются на один и тот же адрес вашего сайта: ?wc-api=mevvpos_callback. Подпись при этом возврате проверяется ключом того POS, который заказ действительно использовал, записанным в самом заказе — при нескольких POS проверка не тем ключом даёт ошибку хеша на каждом платеже.

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

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

Каждая попытка фиксирует использованный POS, банк и BIN карты, число платежей рассрочки и ставку, результат, код и сообщение ответа банка, а также ссылки авторизации и транзакции.

Предавторизация, платёжные ссылки и правила риска

Авторизовать сейчас, списать позже

Каждая запись POS несёт способ списания: списать сразу или заблокировать сумму и списать позже. Во втором случае деньги резервируются на карте при оформлении заказа, а на экране заказа появляются две кнопки — списать (полностью или частично) и отменить блокировку. Списывайте, когда посылка отправляется; отменяйте блокировку, если поставить товар не удаётся.

Настройка появляется только там, где провайдер её действительно поддерживает: банковское семейство NestPay (İşbank, Akbank, Halkbank, QNB, Şekerbank, TEB, Ziraat), а также Stripe, Authorize.Net и Checkout.com. Для всех остальных провайдеров выбор вообще не предлагается — вместо того чтобы предложить его и получить ошибку на шлюзе.

Платёжная ссылка

Экран «Платёжные ссылки» создаёт ссылку на сумму и, при желании, с описанием и сроком действия. Тот, кто откроет её, попадает на обычную страницу оформления заказа магазина с уже созданным отложенным заказом, а значит — с тем же маршрутом по BIN, той же таблицей рассрочки и тем же шагом 3-D Secure, что и при любой другой оплате. Ничто не обходит платёжный движок.

Токен — это 32 случайных байта; адрес нельзя угадать по другому адресу.
Срок действия ссылки истекает в указанную вами дату.
Работает один раз. После оплаты заказа ссылка перестаёт открываться, поэтому пересланное сообщение нельзя оплатить дважды.

Правила риска

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

Попытки на адрес — сколько попыток оплаты может сделать один посетитель за заданный промежуток времени.
Попытки на карту — тот же счётчик для одной карты.
Подряд идущие отказы — серия отказов подряд.
Несовпадение страны — карта, выпущенная в Турции, с адресом выставления счёта за пределами Türkiye.
Потолок суммы — итог заказа, выше которого вы хотите сначала посмотреть сами.

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

Возвраты

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

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

Возврат по турецкому банковскому виртуальному POS из WordPress пока невозможен, и MevvPos говорит об этом прямо, а не делает вид, что это не так. Верните операцию с собственного экрана вашего банка. Тихий отчёт об успехе заставил бы WooCommerce пометить заказ как возвращённый, пока деньги остаются в банке — неверная бухгалтерская запись обходится намного дороже, чем неработающая кнопка.

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

Отчёты

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

The revenue summary covers 7, 30 or 90 days in every installation. The Pro add-on adds three breakdowns on top of it:

Нагрузка по рассрочке и комиссии — количество, выручка и нагрузка по комиссии на каждой ступени рассрочки.
Разбивка по POS и банкам — выручка, успехи, отказы и доля успеха по каждому POS и по каждому банку-эмитенту.
Распределение кодов отказа — с экспортом в CSV. Повторяющийся код отказа указывает на то, что можно исправить: нехватка средств — проблема покупателя, но ошибки проверки 3-D и настройки POS — ваши.

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

У только что установленного магазина графика нет. Запись начинается вместе с плагином, и экран заполняется после первой попытки оплаты.

Использование движка без WooCommerce

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

MevvPos_Payment_Engine::start() начинает платёж и возвращает, что браузеру делать дальше.
MevvPos_Payment_Engine::handle_webhook() — единственный путь, который меняет состояние платежа. Событие, чья подпись не проходит проверку, ничего не меняет и записывается в журнал.
MevvPos_Payment_Engine::webhook_url() формирует адрес, который вы вставляете в панель провайдера.
Потолок рассрочки применяется и внутри движка — как последний рубеж защиты: вызывающий экран мог быть отрисован ещё до того, как истёк срок действия лицензии.

Если вы зарегистрировали собственного провайдера через фильтр mevvpos_providers до версии 4.0.0, теперь он получает намерение платежа вместо WC_Order. Запросы и подписи для семи турецких семейств не изменились, поэтому существующие настройки POS продолжают работать без изменений.

Заявки в банк и поддержка

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

Форма поддержки просит не указывать номер карты и код безопасности. Для диагностики проблемы с платежом они не нужны никогда, и ни одна из форм не отправляет платёжных данных или данных карты.

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

Free и Pro

Nothing in the free plugin is locked, limited or counted. Every Turkish institution, every international provider, 3-D Secure, hosted-page checkout, wallets, multi-currency, currency and BIN routing, as many POS accounts as you have merchant agreements, instalments to twelve, test mode, refunds, pre-authorisation, payment links, the risk rules and the 7 / 30 / 90 day revenue report all work with no key and no account. Pro is a separate plugin whose code is not in the free package at all — it adds capabilities rather than raising a ceiling.

Бесплатно: Everything on this page unless it says otherwise: unlimited provider and POS accounts with BIN and currency routing, instalments to twelve, the 7 / 30 / 90 day revenue report, the packaged BIN table, pre-authorisation, payment links, risk rules, refunds and unlimited transaction volume. Apple Pay and Google Pay too, because they appear on the provider’s hosted page by themselves.
Pro: Recurring payments and subscription billing, the mandate store, stored payment authorisations in My Account, SCA exemption requests, the POS / bank / instalment / decline-code breakdowns with CSV export, and a weekly live BIN refresh. A separate plugin, downloaded from your account here — it is not on WordPress.org.

Multi-currency and routing by currency are both free. They were briefly sold with Pro; charging for the ability to point a euro order at the euro account was pricing a limitation rather than a capability, and it is gone.

Когда лицензия истекает или отсутствует:

Nothing in the free plugin changes. It does not ask about licences at all — the question was removed from that package in 4.9.1 — so every account, every instalment plan, every route and the whole revenue report keep working exactly as before.
Your store keeps taking payments. There is no licence check anywhere on the payment path. Cutting off a shop’s revenue is not an acceptable way to send a renewal reminder.
Возвраты продолжают работать, потому что они вообще не заблокированы.
Recurring charges already scheduled stop being taken, and the subscription screens go quiet. Mandates and stored authorisations are never deleted; they resume on renewal.
The breakdowns and CSV export stop. The 7 / 30 / 90 day report underneath them is in the free plugin and stays. Collected history is not deleted.
Живое обновление BIN прекращается; упакованная таблица продолжает работать.

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

Обновления

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

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

Когда что-то не работает

Банк отклоняет каждый платёж без полезного сообщения: Почти всегда дело в подписи. Неверная подпись нигде не вызывает ошибки — банк просто отказывает. Проверьте номер магазина, ключ магазина и все дополнительные учётные данные для этого семейства: все они входят в подпись. Полезная проверка: банки по-разному отвечают на ошибку подписи и на недействительную карту; сообщение «недействительная карта» означает, что подпись у вас верная.
«Hash error» на обратном пути, когда POS несколько: Возврат — это отдельный запрос без сессии. MevvPos записывает, какой POS использовал заказ, и проверяет его ключом. Если вы удалили запись POS, через которую был оплачен заказ, проверка откатывается к POS по умолчанию и может не пройти.
Клиент платит через Stripe или PayPal, но заказ остаётся в ожидании: Адрес вебхука недоступен или не зарегистрирован. Заказ завершает уведомление, а не возврат клиента, поэтому отсутствующий вебхук выглядит точно так же, как клиент, который так и не заплатил. Проверьте, что адрес на вкладке Bank API совпадает с тем, что сохранён в панели провайдера, и что тестовое событие провайдера доходит.
Все события Square отклоняются: Square подписывает адрес уведомления вместе с телом запроса. Адрес, зарегистрированный в Square, должен посимвольно совпадать с тем, что на вкладке Bank API — достаточно завершающего слэша, http вместо https или www, которого нет на одной из сторон.
События Authorize.Net никогда не проходят проверку: Signature key — отдельное значение от Transaction Key, и их легко перепутать местами. Вебхуки проверяются только с помощью Signature key.
Покупатель попадает на пустую страницу оплаты, или кнопка Öde (оплатить) ничего не делает: Плагин кеширования или оптимизации откладывает скрипты. В LiteSpeed исключите mevvpos, jquery и фронтенд-скрипты WooCommerce из списка задержки. Форма карты показывается по умолчанию, поэтому поток всё равно работает, а вот автоматическое перенаправление — нет.
После успешного платежа заказ остаётся в статусе «в ожидании»: Банк или провайдер не достучался до адреса обратного вызова. Проверьте, что ?wc-api=mevvpos_callback доступен снаружи — режим обслуживания, ограничение по IP или требование входа перед сайтом его заблокируют.
Форма оплаты отправляется обратно на ту же страницу: Поле Gate URL пусто для банка, чей адрес не подставляется заранее. Введите адрес, который дал вам банк или провайдер.
Тестовый режим включён, но платёж всё равно уходит в боевой банк: Тестовый режим останавливает автоматическое перенаправление и показывает вам запрос; для банков NestPay он не меняет адрес шлюза. На время тестирования введите тестовый адрес вашего банка в поле Gate URL. У Stripe и Mollie переключатель тоже не меняет адрес — там песочницу выбирает тестовый ключ.
Рассрочка не появляется: Either the rate for that count is empty rather than zero, the card is from another bank, or the selected provider is an international one and has no instalments at all.
После обновления карты уходят не на тот POS: В более старых версиях были написанные вручную диапазоны BIN, частично неверные. Проверьте, что каждый POS записан на тот банк, в котором он действительно открыт.
Экран админки выглядит без стилей, или исправление не появляется: Устаревший кеш браузера. Перезагрузите страницу в обход кеша.

Ограничения

Список ниже составлен намеренно. Ничто из этого не является ошибкой.

Возвраты для турецких банковских виртуальных POS не поддерживаются. Ни одно турецкое семейство не содержит вызова возврата; возвращайте через экран своего банка. Международные провайдеры это умеют, и WooCommerce показывает для них кнопку возврата.
The updater depends on where you got the plugin. The build downloaded from mevvsoft.com updates itself from our servers. The build published on WordPress.org does not carry that code at all — a plugin hosted there must be updated through WordPress.org, so the two packages differ in exactly this one file.
Регулярные платежи работают только с международными провайдерами, и выбора сохранённой карты нет. Сохранённое разрешение на списание создаётся, продлевается, повторяется и помечается как просроченное, а товар WooCommerce Subscriptions настраивает его без кода. Чего не хватает: турецкие семейства банковских виртуальных POS его не несут, покупатель не может выбрать сохранённую карту при оформлении, и нет ни графика напоминаний, ни отмены из админки.
Предавторизация есть, но не везде. POS может заблокировать сумму и списать её позже — полностью или частично — с экрана заказа, либо отменить блокировку. Это поддерживают только банковское семейство NestPay, Stripe, Authorize.Net и Checkout.com; у всех остальных провайдеров это прямая продажа, и настройка им вообще не показывается.
No rule-based routing. Routing is by currency and issuing bank only — not by amount, card brand or country.
Routing asks the currency first and the issuing bank second, in every installation. What is still missing is everything past that: no failover to a second account, no cascading retry, and no routing by amount, card brand or country.
Поддерживаются оба варианта оформления заказа. Классическая форма оплаты и блок Checkout WooCommerce обслуживаются оба, и таблица рассрочки с наценкой ведут себя одинаково в обоих случаях. Блок записывает выбранные BIN и рассрочку через Store API, поэтому наценка рассчитывается тем же кодом, что и на классической странице.
3D Pay Hosting был отвергнут намеренно. Размещённая страница снимает объём PCI, но заодно убирает и BIN, и таблицу рассрочки — а вся ценность турецкой стороны заключается именно в маршрутизации, которую они делают возможной. Международные провайдеры работают через размещённую страницу именно потому, что там маршрутизировать нечего.
Редактора BIN нет. Таблицу ведём мы и объединяем её с живым обновлением; экрана для ручного редактирования нет.
Двадцать шесть организаций перечислены, но не реализованы. Они остаются на виду, чтобы был виден и пробел.
Каждый провайдер, кроме NestPay, сам объявлен бетой до проверки от начала до конца на действующем торговом аккаунте.
Вкладки находятся внутри страницы. Пункты бокового меню открывают экран MevvPos; переключайте вкладки на самой странице.

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

Единый механизм: турецкий банковский виртуальный POS и международные провайдеры.