Как таковой, ее не существует (по крайней мере, мои попытки нагуглить таковую, не увенчались успехом).
Нам понадобится доступ к файлам, это может быть FTP, редактор файлов хостинга, SSH или любой другой удобный тебе способ.
Идем по пути: /components/com_jshopping/payments/ и создаем папку вида: pm_%payment_name%.
Где %payment_name% это имя нашего платежного сервиса. Например: pm_tinkoff, или pm_sber и т.д.
Внутри, для работы модуля хватит одного файла: pm_sber.php, который и будет реализовывать в себе, всю необходимую логику.
При желании, файлов может быть больше. Примеры реализации можно найти в гугле или на гитхабе.
Механизм модели, вызывающей пользовательский класс, при обработке платежа следует следующему порядку вызовов методов:
getUrlParams() - подготавливает базовый массив параметров, для дальнейшей работыcheckTransaction() - обрабатывает запрос и возвращает соответствующий ему массив, со статусом, описанием, данными транзакцииnofityFinish() - будет вызван, в случае, если обращение было совершено с параметром act=notifyfinish() - завершающий все манипуляции при обработке платежей
Из упомянутого списка, для работы в большинстве своем, хватит первых двух или первых трех методов.
Рассмотрим подробнее каждый из них.
Метод готовит набор параметров и указывает необходимость внутренних проверок, при обработке платежа.
пример реализации может выглядить следующим образом:
public function getUrlParams($config)
{
$params = [];
$params['order_id'] = JFactory::$application->input->getString('order_id', null);
$params['hash'] = '';
$params['checkHash'] = 0;
$params['checkReturnParams'] = 1;
return $params;
}
Метод проверки валидности платежа, вызывается при создании платежа, после возврата пользователя на страницу подтверждения заказа, так же вызывается при приходе нотификации от платёжной системы. Выполняет "проверку" транзакций (может проводить обработку запросов на Success Url, Fail Url и Result Url).
Возвращает Массив с 4-мя параметрами (первые два являются обязательными, остальные тоже могут присутствовать).
Настоятельно рекомендую обратить внимание на getStatusFromResCode() из родительского класса PaymentRoot{}. Этот метод вызывается в методе buy() модели CkeckoutBuyModel и в него будет передано значение $rescode которое как раз и должен вернуть checkTransaction() в первом элементе массива.
1 - $rescode - является идентификатором номера статуса заказа из $types_status, метода getStatusFromResCode($rescode, $pmconfigs) родительского класса PaymentRoot{}
2 - $restext - строка, с описание результата, например "оплачен", "ошибка", "возвращен" и т.д.
3 - $transaction - судя по всему, тип транзакции PAYMENT, DECLINED, CANCEL, т.д. (это не точно, возможно любое значение)
4 - $transactiondata - массив с данными транзакции платежа в виде key => value
$rescode будет преобразован в status_id соответствующей настройки модуля, и записан в _jshopping_orders, в соответствующие колонки заказа order_status. $transaction будет записываться в _jshopping_payment_trx, каждый раз, при изменении статуса заказа.
В зависимости от переданного кода происходит создание заказа, или изменение его статуса и email оповещение администратора магазина и покупателя. Дальнейшее управление передаётся на метод nofityFinish(), при условии, что act равен notify, иначе будет вызван метод finish() (однако он никак не используется, назначение не определено).
public function checkTransaction($pmconfigs, $order, $act)
{
// Здесь реализуется логика обработки платежа
return [
$rescode, // Номер статуса
$restext, // Описание статуса
$transaction, // Идентификатор транзакции
$transaction_data // Данные транзакции
];
}
Вызывается при входящем запросе с параметром act=notify. (при ином act вызван не будет)
В модели CheckoutBuyModel{} сохранение заказа предусмотрено только при условии, что назначаемый статус существует и больше 0, и $order->order_created равен 0 - создание заказа. В ином случае у заказа будет изменен статус на тот, что будет передан в return в checkTransaction() и отправлено письмо покупателю.
В этом методе, можно проверить $order->order_status на соответствие ожидаемого, так как nofityFinish() вызывается после checkTransaction(), и после манипуляция над самим заказом в buy() и скорректировать его, если он не соответствует нужному. Либо выполнить сопутствующие действия, например: отправить чек, рассылку, что-то записать и т.д.
Метод может ничего не возвращать void, так как его вызов никак и никуда не передается в методе buy() модели CheckoutBuyModel{}
Важный момент. При изменении статуса заказа в этом методе, необходимо самостоятельно вызывать $order->store(); чтобы изменения были зафиксированы.
public function nofityFinish($pm_config, $order, $rescode) {}
В принципе, этих трех методов достаточно для полноценной реализации обработки платежей для любой платежной системы.
Надеюсь, информация была полезна, и ищбавит кого-то от головной боли.
Сказать спасибо можно вслух, к черту рекламы и донаты!