Пришлось мне недавно писать модуль платежной системы для разных CMS. Bitrix, UMI CMS, NetCat, Drupal (6 и 7), HostCMS и WordPress. В этом посте хочу провести легкий сравнительный анализ по сложности интеграции платежной системы в разных CMS.
Пишу с точки зрения разработчика, которому пришлось окунуться в незнакомые CMS. Я их не знаю, и знать не хочу. Постараюсь избежать предвзятости.
NetCat Начну с плохого. Первое что требуется сделать для установки это выполнить огромный и жуткий SQL запрос.
А теперь зайти в админку и разобраться там. Мое сверхконсервативное воспитание не позволяет мне ругаться матом тут, но это ад. Какие-то системные переменные, не системные переменные. Интерфейс разработчика и пользователя, в которых не ясно в чем разница.
Потратил очень много времени только на поиск в админке нужных функций, а потом еще на отладку. После уведомления от ПС о платеже в админке статус выставляется «оплачен», а в пользовательской части — нет. Оказалось, что баг в стандартном шаблоне NetCat. В общем, отвратительная CMS. Первый опыт был и никому не посоветую.
Из плюсов могу ответить, что достаточно одного php файла для обработки всех действий и более-менее понятную логику класса Payment.
UMI CMS Нужно выполнить еще страшнее SQL запрос.
Тут примерно 1/3 всего запроса видна. Но это далеко не самое страшное.
Во-первых, нужно делать шаблоны для двух версий xslt и tpl, что уже немного усложняет процесс. А самое интересное начинается при интеграции платежной системы.
Нужно модифицировать системный файл __payment.php Можно его сразу сделать и сказать пользователю просто заменить его при установке, но если у него там уже были кастомные ПС, то они перестанут работать. Так что приходится объяснять пользователю, как его модифицировать. И писать что-то типа: в файле __payment.php примерно в 140 строке напишите:
Тут мы по переменным в запросе должны как-то однозначно идентифицировать платежную систему.
Из плюсов стоит отметить очень простой код и реализацию класс payment. Легко найти ПС в админке и настроить даже неподготовленному пользователю.
HostCMS Для установки модуля ПС в HostCMS нам уже не нужно делать SQL запросы. Отлично. Но требуется от пользователя редактировать достаточно громоздкие и страшные файлы с PHP. При этом, таких файла два. Также пользователю нужно «увидеть» ID новой ПС и добавить его в название класса. Еще к минусам можно отнести средней грязности код в реализации класса Shop_Payment_System_Handler.
Из плюсов нужно отметить приятную админку. Какая-то она теплая и ламповая. Но сначала очень непривычная. К ней нужно привыкать, но пользоваться ей можно. Найти нужные разделы не так уж сложно, но сложнее, чем в UMI.
Потратил не мало времени на отладку. Хоть и застрял на очевидных вещах.
Drupal Тут очень кратко напишу: — отвратительная установка Drupal; — отвратительная установка Ubercart; — ужасный код с реализацией платежной системы;
Провел очень много времени в отладке. Из плюсов только отличная документация на русском языке.
WordPress А он мне понравился. Всего один файл. Никаких SQL запросов для установки.
Не понравился слегка грязный код в классе платежной системы. Необходимость прямых запросов в БД для изменения статуса и формирование формы настроек в админке на HTML. С одной стороны последний пункт это минус, но с другой это позволяет нам сделать интерфейс нашей ПС любым.
Bitrix Тут стоит сказать, что с Битриксом я знаком и делал уже не раз модули платежных систем.
Сложно быть объективным, но попробую. Из плюсов: 1. Пользователю нужно только скопировать папку с модулем в корень сайта и модуль работает. 2. Отдельно настройки интерфейса администратора, платежной формы и обработчика. Удобно и все на своих местах. 3. Никаких прямых запросов к БД в классе ПС. Оплата успешна? Ок.
CSaleOrder::PayOrder($arOrder["ID"], "Y");
Из минусов могу сказать только про привычно плохую документацию у Битрикс. Мне она просто не пригодилась.
Интеграция изначально происходила неправильно. Прямые запросы к базе данных и изменение системных файлов по условиям лицензионного соглашения запрещены, для добавления пользовательских методов существую специальные файлы, которые не перезаписываются при обновлении. В самом коде для платёжных систем нет прямых запросов к базе данных, только обращение средствами API. Описание принципа добавления новой платёжной системы можно увидеть на странице wiki ресурса посвящённого umi.cms http://wiki.umisoft.ru/Общий_принцип_...ой_системы. Здесь же указано и то, что пользовательские методы необходимо добавлять в отдельный файл в директории /classes/modules/emarket/classes/payment/systems/. Новые же справочники и типы данных можно создать и отредактировать как средствами api, так и через панель администрирования. Документация по api доступна по адресу http://api.umi-cms.ru/ для работы с объектами, типами и справочниками документацию можно найти на странице
http://api.umi-cms.ru/api.part.DataModel.html В случае возникновеня проблем с написанием кастомных методов всегда можно обратиться к документации или в Службу Заботы, мы будем рады помочь в решении проблем.
По мне так вышел пост, похожий на классический "не разобрамшись, но г... и всё через ж...", каких и про битрикс полно, точно так же, одну систему знаю, в другой всё не так, что делать непонятно, изучать некогда - система хреновая. Ну неправильно это, товарищи. Ладно хоть здесь не всё так плохо, а более-менее толерантно и обосновано для фёст-лука.
Давыдов Сергей, я кстати, не писал, что в UMI приходилось делать прямые запросы к БД в посте. Это откуда-то потом вылезло.
$this->order->setPaymentStatus('accepted');
Так делалось. Больше всего мне в UMI не понравилось создание первоначального огромного SQL запроса. Вот пользователю неподготовленному радость будет его выполнять.
Вот в __payments.php есть public function gateway() Именно в нем происходит вызов соответствующего класса платежной системы и вызов $payment->poll();
Допустим, у меня номер заказа передается в $_POST["my-order-id"] Метод poll() моего класса не будет выполнен, если в методе gateway() не передать в переменную $orderId правильный ID заказа.
Поясните, пожалуйста, если не сложно, именно вот этот момент: как получить мой ID заказа и вызывать нужный метод poll() для проверки параметров с ответом от ПС.
Куклин Евгений, все верно, это именно такой пост и есть. В тысячный раз напишу, что просто поверхностный взгляд при интеграции ПС.
Ох много я платежек пересмотрел как-то (там и Зенкарт в разных вариациях был, и Престашоп, и Магенто (единственная CMS, которую мне так и не удалось осилить за отведенное время)). Везде говнокода в меру, где-то чрезмерно.
Битрикс по удобству действительно занимает топ (и это не предвзятость, это взгляд с опытом со стороны). Только, справедливости ради, замечу, что документация для создания по сути и не нужна - там два файла, один описание, второе получатель платежа, все. И для каждой новой платежки начинается муторный процесс понимания тонкостей оплаты и прочего.
Группы на сайте создаются не только сотрудниками «1С-Битрикс», но и партнерами компании. Поэтому мнения участников групп могут не совпадать с позицией компании «1С-Битрикс».