Пришлось мне недавно писать модуль платежной системы для разных 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");
Из минусов могу сказать только про привычно плохую документацию у Битрикс. Мне она просто не пригодилась.
Давыдов Сергей, я кстати, не писал, что в 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С-Битрикс».