У биллинге використовується модульна система для інтеграції з платіжними системами. Для того щоб підключити нову систему необхідно написати модуль для неї.
Вибір системного імені
Кожна платіжна система в биллинге має системне ім'я, яке може складатися з одного латинського слова і цифр. Системне ім'я використовується в іменах файлів і класів.
Як приклад, ми будемо вважати що наша нова платіжна система називається «New Payment System», а її системне ім'я - newpayment. Тут і далі newpament потрібно буде замінювати на системне ім'я вашої платіжної системи.
Файли і папки
Модулі платіжних систем зберігаються в папці system / controllers / billing / systems. Всередині цієї папки необхідно створити папку для нової платіжної системи. Назва папки збігається з системним ім'ям.
В папці системи потрібно створити два PHP-файлу:
Файл, що містить опис форми налаштувань платіжної системи.
Отримання списку полів для платіжної форми
Зазвичай, проведення платежу в будь-якій системі починається з відправки платіжної форми на спеціальний URL. наданий системою. Цей URL вказується в налаштуваннях системи в адмінці білінгу. Форма ж генерується динамічно.
Коли користувач поповнює баланс, він спочатку вибирає кількість валюти для покупки і натискає «Продовжити». Після цього він потрапляє на сторінку «Перевірте правильність замовлення». Насправді ця сторінка потрібна тому, що саме на ній виводиться платіжна форма. І натискання кнопки «Перейти до оплати» відправляє платіжну форму на потрібний URL.
Метод getPaymentFormFields () повертає набір полів, які будуть додані в платіжну форму. Цей набір унікальний для кожної системи. Набір повертається у вигляді масиву, в якому ключі це назви полів, а елементи - значення.
Наприклад, якщо наша платіжна система вимагає наявності в формі полів shop_id і summ. то метод може виглядати так:
Крім того, в платіжну форму можна додати інтерактивні поля, значення яких повинен буде заповнити користувач. У цьому випадку, як значення поля в повернутому масиві використовується екземпляр класу поля. наприклад:
Додаткова обробка даних після платіжної форми
Деякі платіжні системи використовують більш складні механізми для запуску платежу, ніж проста відправка форми. Тому передбачена можливість віддати модулю платіжної системи повний контроль над відправленням запиту про платіж.
Схема реалізується в три етапи:
Як платіжний URL в настройках системи вказується: billing / prepare / newpayment;
Платіжна форма як і раніше формується, але відправляється вже не в систему, а на внутрішній URL. вказаний вище;
За даним URL спрацьовує метод preparePayment () в нашому класі, і цей метод самостійно виробляє спілкування з реальною платіжною системою (наприклад, за допомогою CURL) і редирект куди потрібно.
Така схема використовується у випадках, коли:
Приклади реалізації описаного підходу ви можете подивитися в коді модулів для систем Test і Qiwi зі стандартної поставки білінгу.
Перевизначення платіжного URL
Деякі платіжні системи використовують динамічний URL для відправки платежу. Тоді його не вийде просто вказати в настройках, тому що при кожному платежі він буде різним.
Спеціально на цей випадок в класі може бути описаний метод getPaymentURL (). який повертає URL для відправки платіжної форми. Якщо цього методу немає - використовується URL з налаштувань платіжної системи.
Приклад методу з модуля для системи OnPay:
Отримання сповіщення про платіж
Більшість платіжних систем вміють повідомляти про оплату замовлення шляхом виклику певного URL на сайті магазина. Найчастіше в налаштуваннях Мерчант він називається як Result URL або Status URL. Виклик цього URL відбувається у фоновому режимі, непомітно для користувача і без використання його браузера.
При виклику даного URL в класі модуля системи запускається метод processPayment ().
Усередині методу зазвичай реалізується наступний алгоритм:
Отримуємо дані, передані платіжною системою (номер замовлення, сума, статус оплати тощо);
За номером замовлення отримуємо інформацію про замовлення з бази;
Звіряємо правильність даних (що сума замовлення не змінена, цифровий підпис збігається і т.п.);
Якщо все вірно - відзначаємо замовлення як оплачений (на внутрішній баланс користувача при цьому зараховується куплена ним внутрішня валюта);
Повертаємо відповідь в форматі, необхідному платіжною системою.
Дані, що передаються на Result URL кожної платіжною системою унікальні. Їх опис потрібно дивитися в документації по API платіжної системи. Отримання даних із запиту (GET / POST) відбувається за допомогою об'єкта $ request. наприклад:
Отримання замовлення за відомим ID здійснюється за допомогою моделі:
Зміна статусу замовлення на «оплачений» відбувається також за допомогою моделі:
Приклад реалізації методу для системи Robokassa:
Отримання оповіщення про успіх платежу
Тому, для уникнення неприємностей, на Success URL ми повинні упевнитися що замовлення оплачений і баланс користувача поповнений. І якщо це не так, то змусити користувача чекати поки сайт не отримає повідомлення про проведений платіж.
Оскільки номер замовлення приходить на Success URL разом з користувачем, в модулі платіжної системи повинен бути визначений метод:
Цей метод повинен отримувати з об'єкта $ request значення ID замовлення, передане платіжною системою на Success URL. і повертати його. Використовуючи отриманий ID білінг знайде замовлення і перевірить його статус. Якщо замовлення виявиться як і раніше не оплаченими, білінг перевірятиме його статус кожні кілька секунд, до тих пір поки повідомлення про оплату не зробить. Користувач при цьому буде бачити прохання почекати.
Отримання оповіщення про невдачу платежу
Ніяких додаткових дій в модулів платіжної системи для обробки невдалих платежів не потрібно.
приклади підключень
З прикладами реалізацій модулів для кілька платіжних систем ви можете ознайомитися в папці system / controllers / billing / systems з комплекту поставки білінгу.