Пришлось мне недавно писать модуль платежной системы для разных 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");
Из минусов могу сказать только про привычно плохую документацию у Битрикс. Мне она просто не пригодилась.
Катя Маршалкина, а я даже не собираюсь спорить. Я бы не был здесь, если бы мне не нравился Битрикс. Друпал не хотел ставиться на хостинг с multibyte кодировкой, который хочет Битрикс. Потом еще какие-то проблемы с установкой были. Уже мелочи не помню, это было несколько недель назад. Но бесил он меня ужасно.
У всех честно написал плюсы и минусы, с которыми столкнулся именно при разработке платежного модуля. Не хочу очередного спора про качество той или иной CMS.
UMI CMS: Нужно модифицировать системный файл __payment.php
Зачем все так усложнять? модифицировать системные файлы это вообще не гуд. В классе платежной системы в методе process передается параметром урл для ответа - собственно создаете в этом же файле обработчик ответа, который будет разбирать параметры и вызывать метод gateway. Не забудьте прописать разрешения на вызов метода http запросом в файле permissions.custom.php
Агеев Андрей , автор схитрил вряд ли будет уместно рассказывать об API других систем на блоге битрикса. Пусть читатель просто имеет ввиду, что всё не так плохо.
Агеев Андрей, все делалось по образу и подобию других ПС. UMI никак не хотела переходить в метод process, в файле __payment.php можно явно указать вызов нужного метода, если пришли определенные параметры. API у них документировано еще хуже, чем у Битрикса. Про БД так и не нашел ничего. И, да, в модулях платежных систем, которые идут вместе с UMI они сами используют прямые запросы к БД.
Лебедев Олег, давно известно, что друпал это развлечение для сильных духом. Опять же повторюсь, что я описывал я свой первый взгляд достаточно опытного пользователя на CMS.
Катя Маршалкина, никто не не запрещает рассказать про API других систем. Моя предвзятость в случае с Битриксом только в том, что я его знаю, а другие системы нет. И совершенно не значит, что я его люблю, а остальные системы нет.
Пост потихоньку перерос в срач на тему «что лучше», чего я так не хотел.
Орестов Олег , ох не знаю чем вам так нравится файл __payments.php, ведь все можно сделать в файле /classes/modules/emarket/classes/payment/systems/{paymentName}.php. Метод process вызывается на странице emarket/purchase/payment/{paymentName}/.Про БД в документации ничего и нет по вполне понятным причинам - в UMI нет аналога CDatabase от Битрикс... Посмотрите в сторону таких классов как selector, umiObjectType и соседние ) В модулях платежных систем прямых запросов к БД не нашел о.0
Задойный Алексей , почему же сразу налетели - просто делимся опытом - плох тот программист который не оценит совет по оптимизации своего кода
Катя Маршалкина , ну мне кажется что если пост затрагивает несколько cms, то вкратце упомянуть их особенности (в том числе и API) вполне уместно в любом блоге
Интеграция изначально происходила неправильно. Прямые запросы к базе данных и изменение системных файлов по условиям лицензионного соглашения запрещены, для добавления пользовательских методов существую специальные файлы, которые не перезаписываются при обновлении. В самом коде для платёжных систем нет прямых запросов к базе данных, только обращение средствами 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С-Битрикс».