Тут показані розбіжності між вибраною ревізією та поточною версією сторінки.
| Порівняння попередніх версій Попередня ревізія | Попередня ревізія | ||
|
openpayz [2020/10/26 18:25] |
openpayz [2025/03/11 19:14] (поточний) nightfly [Режим високої продуктивності] |
||
|---|---|---|---|
| Рядок 1: | Рядок 1: | ||
| + | ====== OpenPayz ====== | ||
| + | ===== Ой що це? ===== | ||
| + | |||
| + | |||
| + | OpenPayz - існує для отримання інформації про онлайн-платежі здійснені з зовнішніх платіжних систем. Надає спільні інтерфейси для реєстрації та обробки повідомлень, | ||
| + | \\ | ||
| + | |||
| + | ===== Чим приймаються оплати? | ||
| + | |||
| + | На даний момент підтримуються і **безкоштовно** поширюються фронтенди/ | ||
| + | |||
| + | ^ Платіжна система | ||
| + | | [[https:// | ||
| + | | [[http:// | ||
| + | | [[http:// | ||
| + | | [[http:// | ||
| + | | [[https:// | ||
| + | | [[https:// | ||
| + | | [[https:// | ||
| + | | [[http:// | ||
| + | | [[https:// | ||
| + | | [[https:// | ||
| + | | [[https:// | ||
| + | | [[https:// | ||
| + | | [[http:// | ||
| + | | [[https:// | ||
| + | | [[http:// | ||
| + | | [[http:// | ||
| + | | [[http:// | ||
| + | | [[http:// | ||
| + | | [[http:// | ||
| + | | [[http:// | ||
| + | | [[http:// | ||
| + | | [[http:// | ||
| + | | [[https:// | ||
| + | | [[https:// | ||
| + | | [[http:// | ||
| + | | [[http:// | ||
| + | | [[https:// | ||
| + | | [[http:// | ||
| + | | [[https:// | ||
| + | | [[https:// | ||
| + | | [[https:// | ||
| + | | [[https:// | ||
| + | | [[https:// | ||
| + | | [[https:// | ||
| + | | [[https:// | ||
| + | | [[https:// | ||
| + | | [[https:// | ||
| + | | Platonmobile | Google Pay\\ Apple Pay\\ Visa\\ Mastercard | [[openpayz# | ||
| + | | [[https:// | ||
| + | | [[https:// | ||
| + | |||
| + | |||
| + | ===== Як це працює? | ||
| + | |||
| + | В цілому якось так: | ||
| + | |||
| + | {{: | ||
| + | |||
| + | |||
| + | З чого випливає, | ||
| + | |||
| + | |||
| + | Транзакції реєструються для конкретного " | ||
| + | |||
| + | ===== Встановлення ===== | ||
| + | |||
| + | Починаючи з Ubilling 1.3.4 OpenPayz вже попередньо сконфігуровано інсталятором системи та готово до розгортання одразу після встановлення Ubilling. Вам залишається тільки скопіювати OpenPayz в директорію в якій він працюватиме та налаштувати необхідні вам фронтенди. | ||
| + | |||
| + | |||
| + | Отож кладемо OpenPayz десь подалі і за межі кореневої директорії Ubilling: | ||
| + | |||
| + | # cp -R / | ||
| + | |||
| + | Та запам' | ||
| + | |||
| + | # cd / | ||
| + | |||
| + | |||
| + | Після чого перевіряємо очима, чи відповідають налаштування в **config/ | ||
| + | <file ini mysql.ini> | ||
| + | ;database host | ||
| + | server = " | ||
| + | ;database port | ||
| + | port = " | ||
| + | ;user login | ||
| + | username = " | ||
| + | ;user password | ||
| + | password = " | ||
| + | ;database name to use | ||
| + | db = " | ||
| + | ;connection codepage | ||
| + | character = " | ||
| + | ;tables prefix | ||
| + | prefix = " | ||
| + | </ | ||
| + | |||
| + | та зазираємо в конфіг **config/ | ||
| + | <file ini openpayz.ini> | ||
| + | ; Вносити оплати до Stargazer напряму за допомогою sgconf? | ||
| + | STG_DIRECT=1 | ||
| + | ; Шлях до sgconf | ||
| + | SGCONF=/ | ||
| + | ; Хост на якому встановлено Stargazer | ||
| + | STG_HOST=localhost | ||
| + | ; Порт stargazer | ||
| + | STG_PORT=5555 | ||
| + | ; Логін адміністратора stargazer | ||
| + | STG_LOGIN=admin | ||
| + | ; Пароль адміністратора stargazer | ||
| + | STG_PASSWD=123456 | ||
| + | ;ID типу оплат Ubilling (Взагалі хорошою практикою було б додати для цього окремий, | ||
| + | UB_CASHTYPE=1 | ||
| + | |||
| + | ; Надсилати сповіщення про отримані платежі електропоштою? | ||
| + | SEND_MAIL=0 | ||
| + | ; Пошта на котру надсилатимуться сповіщення (DEPRECATED) | ||
| + | NOTIFY_MAIL=notify@ourisp.ua | ||
| + | |||
| + | ; Режим сильнонавантаженого OpenPayz із мульйонами транзакцій. При включенні цієї опції всі транзакції | ||
| + | ; повинні періодично оброблятися в окремому потоці, | ||
| + | OP_HIGHLOAD_ENABLE=0 | ||
| + | |||
| + | ; У такому форматі можна вказувати кастомні типи платежів для різних платіжних систем. | ||
| + | ; Але ми все ж таки рекомендуємо використовувати один загальний UB_CASHTYPE для цих цілей, і розрізняти платіжні системи налаштувавши відповідний довідник. | ||
| + | ; | ||
| + | ; | ||
| + | </ | ||
| + | |||
| + | Щиро сподіваюсь, | ||
| + | |||
| + | **Увага: | ||
| + | \\ | ||
| + | |||
| + | ===== Режим високої продуктивності ===== | ||
| + | При ввімкненні опції | ||
| + | <code ini> | ||
| + | OP_HIGHLOAD_ENABLE=1 | ||
| + | </ | ||
| + | |||
| + | вся обробка транзакцій перестає здійснюватися вбудованими у фронтенди викликами op_ProcessHandlers і повинна бути винесена в окремий воркер **op_WorkerPaymentsProceed** або **opprocessing**, | ||
| + | |||
| + | якось так (до релізу Ubilling 1.5.3, рахується застарілим): | ||
| + | <code bash> | ||
| + | */2 * * * * / | ||
| + | </ | ||
| + | |||
| + | чи ось так, після Ubilling 1.5.3 (рекомендовано) | ||
| + | <code bash> | ||
| + | */2 * * * * / | ||
| + | </ | ||
| + | |||
| + | Варіант виклику обробки транзакцій за допомогою виклику opprocessing з [[remoteapi|RemoteAPI]] також потребує ввімкнення опції OPENPAYZ_HIGHLOAD_ENABLE в [[alteriniconf|alter.ini]]: | ||
| + | |||
| + | <file ini alter.ini> | ||
| + | OPENPAYZ_HIGHLOAD_ENABLE=1 | ||
| + | </ | ||
| + | |||
| + | Обробка виклику opprocessing відбувається в рамках унікального процесу OP_PROCESSING [[stardust|StarDust]], | ||
| + | |||
| + | Слід також зауважити, | ||
| + | |||
| + | ===== Альтернативні Платіжні ID ===== | ||
| + | |||
| + | В деяких, | ||
| + | |||
| + | ==== Рекомендований за замовчуванням ==== | ||
| + | |||
| + | <file sql op_customers_crc32_full.sql> | ||
| + | CREATE OR REPLACE VIEW op_customers (realid, | ||
| + | </ | ||
| + | |||
| + | ==== З можливістю оверрайду статикою ==== | ||
| + | |||
| + | <file sql op_customers_crc32_plus_static.sql> | ||
| + | CREATE OR REPLACE VIEW op_customers (realid, | ||
| + | LEFT JOIN op_static on op_static.realid=users.login | ||
| + | LEFT JOIN op_denied ON users.login = op_denied.login WHERE op_denied.login IS NULL; | ||
| + | </ | ||
| + | |||
| + | ==== Без заборон ==== | ||
| + | власне все той же за замовчуванням, | ||
| + | <file sql op_customers_crc32_fast.sql> | ||
| + | -- transform users.login -> crc32(users.login); | ||
| + | CREATE OR REPLACE VIEW op_customers (realid, | ||
| + | </ | ||
| + | |||
| + | ==== Використовуємо IP ==== | ||
| + | Або якось так, для використання IP адрес користувачів у вигляді INT | ||
| + | <file sql op_customers_aton.sql> | ||
| + | -- transform users.login -> ip2int(users.IP); | ||
| + | CREATE OR REPLACE VIEW op_customers (realid, | ||
| + | </ | ||
| + | |||
| + | ==== Використовуємо логіни ==== | ||
| + | Або якось так, у випадку якщо у вас повністю цифрові логіни користувачів: | ||
| + | <file sql op_customers_login.sql> | ||
| + | -- transform users.login -> users.login; | ||
| + | CREATE OR REPLACE VIEW op_customers (realid, | ||
| + | </ | ||
| + | |||
| + | ==== Використовуємо угоди ==== | ||
| + | Або якось так, якщо ви впевнені, | ||
| + | <file sql op_customers_contract.sql> | ||
| + | -- transform contracts.login -> contracts.contract; | ||
| + | CREATE OR REPLACE VIEW op_customers (realid, | ||
| + | </ | ||
| + | |||
| + | ==== Непорожні угоди ==== | ||
| + | Можна якось так, якщо ви впевнені, | ||
| + | <file sql op_customers_login_contract2.sql> | ||
| + | -- transform contracts.login -> contracts.contract; | ||
| + | CREATE OR REPLACE VIEW `op_customers` (`realid`, | ||
| + | </ | ||
| + | |||
| + | ==== Знову угоди ==== | ||
| + | Наступне представлення більш універсальне, | ||
| + | <file sql op_customers_login_contract_pautina.sql> | ||
| + | CREATE OR REPLACE VIEW `op_customers` (realid, | ||
| + | </ | ||
| + | |||
| + | ==== Логін + угода ==== | ||
| + | Також ви можете спробувати використовувати два різних платіжних ID для ваших користувачів, | ||
| + | |||
| + | <file sql login_plus_contract.sql> | ||
| + | CREATE OR REPLACE VIEW `op_customers` (realid, | ||
| + | SELECT DISTINCT `users`.`login` AS `realid`, | ||
| + | `users`.`login` AS `virtualid` | ||
| + | FROM `users` | ||
| + | LEFT JOIN `op_denied` ON `users`.`login` = `op_denied`.`login` WHERE `op_denied`.`login` IS NULL | ||
| + | UNION | ||
| + | SELECT DISTINCT `contracts`.`login` AS `realid`, | ||
| + | `contracts`.`contract` AS `virtualid` | ||
| + | FROM `contracts` | ||
| + | LEFT JOIN `op_denied` ON `contracts`.`login` = `op_denied`.`login` | ||
| + | WHERE `op_denied`.`login` IS NULL AND `contracts`.`contract` !='' | ||
| + | </ | ||
| + | |||
| + | Загалом як не складно помітити все лімітовано тільки збоченістю вашої фантазії ;)\\ | ||
| + | (Переконайтесь що у вас всюди увімкнено OPENPAYZ_REALID для використання Платіжних ID з БД, до слова " | ||
| + | |||
| + | ==== Статичні платіжні ID ==== | ||
| + | |||
| + | У випадку, | ||
| + | |||
| + | <file sql op_static_payids.sql> | ||
| + | CREATE OR REPLACE VIEW op_customers (realid, | ||
| + | </ | ||
| + | |||
| + | ===== Розробка власного фронтенду ===== | ||
| + | |||
| + | Далі, щоб було зрозуміло як це насправді працює ми можемо наприклад, | ||
| + | |||
| + | Специфікація отримання повідомлення про успішну оплату користувачем від платіжної системи " | ||
| + | | ||
| + | | ||
| + | user - ідентифікатор користувача від якого отримано платіж | ||
| + | | ||
| + | cash - сума платежу | ||
| + | | ||
| + | Де " | ||
| + | OK - все добре, платіж отримано та оброблено | ||
| + | | ||
| + | DONE – платіж вже оброблений, | ||
| + | | ||
| + | | ||
| + | http:// | ||
| + | | ||
| + | <file php frontend/ | ||
| + | <?php | ||
| + | |||
| + | /** | ||
| + | * Just sample frontend intended only for OpenPayz testing | ||
| + | */ | ||
| + | include (" | ||
| + | |||
| + | $reply = ''; | ||
| + | |||
| + | /** | ||
| + | * Check is transaction unique? | ||
| + | | ||
| + | * @param string $hash - hash string to check | ||
| + | | ||
| + | * @return bool | ||
| + | */ | ||
| + | function corovan_checkTransaction($hash) { | ||
| + | $hash = mysql_real_escape_string($hash); | ||
| + | $query = " | ||
| + | $data = simple_query($query); | ||
| + | if (!empty($data)) { | ||
| + | return (false); | ||
| + | } else { | ||
| + | return (true); | ||
| + | } | ||
| + | } | ||
| + | |||
| + | if ((isset($_GET[' | ||
| + | $allcustomers = op_CustomersGetAll(); | ||
| + | $hashRaw = trim($_GET[' | ||
| + | $hash = ' | ||
| + | $summ = $_GET[' | ||
| + | $customerid = trim($_GET[' | ||
| + | |||
| + | |||
| + | if (isset($allcustomers[$customerid])) { | ||
| + | if (is_numeric($summ)) { | ||
| + | //maybe already processed? | ||
| + | if (corovan_checkTransaction($hash)) { | ||
| + | op_TransactionAdd($hash, | ||
| + | op_ProcessHandlers(); | ||
| + | $reply = $hashRaw . ': | ||
| + | } else { | ||
| + | $reply = $hashRaw . ': | ||
| + | } | ||
| + | } else { | ||
| + | $reply = $hashRaw . ': | ||
| + | } | ||
| + | } else { | ||
| + | $reply = $hashRaw . ': | ||
| + | } | ||
| + | } else { | ||
| + | $reply = ' | ||
| + | } | ||
| + | |||
| + | die($reply); | ||
| + | </ | ||
| + | |||
| + | Ось власне і все, у разі успіху - // | ||
| + | |||
| + | ===== Налаштування платіжних систем (очевидні і не дуже) ===== | ||
| + | ==== Platonmobile ==== | ||
| + | <hidden onHidden=" | ||
| + | Мабуть, | ||
| + | \\ | ||
| + | Ітак: | ||
| + | * вмикаємо модуль [[contragentextinfo|Додаткова інформація про контрагентів]]\\ | ||
| + | * для необхідного нам контрагента створюємо новий запис для нашої платіжної системи в " | ||
| + | {{ : | ||
| + | * або не помилитись - найменування платіжної системи бажано не вписувати руками, | ||
| + | * **Merchant ID** та його **пароль** мають бути вписані точно в ті ж самі поля, які ви бачите на скріні вище, тобто **Код контрагента в платіжній системі** та **Пароль сервісу** відповідно | ||
| + | * звичайно, | ||
| + | |||
| + | Ось і все - налаштування креденшлів платіжної системи **Platonmobile** для певного господарюючого суб' | ||
| + | </ | ||
| + | \\ | ||
| + | ==== Providex ==== | ||
| + | <hidden onHidden=" | ||
| + | * вмикаємо модуль [[contragentextinfo|Додаткова інформація про контрагентів]] \\ | ||
| + | * для необхідного нам контрагента створюємо новий запис для нашої платіжної системи **PROVIDEX** в " | ||
| + | {{ : | ||
| + | * звичайно, | ||
| + | </ | ||
| + | \\ | ||
| + | |||
| + | ==== PRIVAT_MULTISERV ==== | ||
| + | <hidden onHidden=" | ||
| + | * вмикаємо модуль [[contragentextinfo|Додаткова інформація про контрагентів]]\\ | ||
| + | * для необхідного нам контрагента створюємо новий запис для нашої платіжної системи **PB_MULTISERV**(нехай вас не бентежить трохи різне найменування, | ||
| + | {{ : | ||
| + | * звичайно, | ||
| + | </ | ||