Розбіжності

Тут показані розбіжності між вибраною ревізією та поточною версією сторінки.

--- openpayz [2023/04/26 15:30]
nightfly [Альтернативні Платіжні ID]
+++ openpayz [2024/03/25 13:49]
nightfly [З можливістю оверрайду]
@@ Рядок 38: / Рядок 38: @@
 | [[http://www.pay-logic.ru/|Paylogic / ОСМП]] | Термінали | osmp |
 | [[http://www.sberbank.ru/|Сбербанк России]] | Готівкові платежі | sberbank |
-| [[https://www.portmone.com.ua/r3/|Portmone]] | VISA\\ Visa Electron\\ MasterCard\\ Cirrus\\ Maestro | portmone |
+| [[https://www.portmone.com.ua/r3/|Portmone]] | VISA\\ Visa Electron\\ MasterCard\\ Cirrus\\ Maestro | portmone \\ portmonemulti |
 | [[http://www.platezhka.com.ua/|platezhka.com.ua]] (Банк Національный Кредит) | Термінали | platezhka |
 | [[https://money.yandex.ru/|Яндекс.Деньги]] | Яндекс.Деньги\\ VISA\\ MasterCard | yandex_notify |
@@ Рядок 49: / Рядок 49: @@
 | [[https://globalmoney.ua/|GlobalMoney]] | Термінали | globalmoney |
 | [[https://platon.ua/|Platon]] | Google Pay\\ Apple Pay\\ Приват24\\ Privat Pay\\ Masterpass\\ VisaCheckout\\ Visa\\ Mastercard\\ Простір | platon |
+| [[https://providex.net/uk/|Providex]] | Google Pay\\ Apple Pay\\ Visa\\ Mastercard | [[openpayz#providex|providex]] |
 ===== Як це працює? =====
-В цілому якось так:\\
-{{:opzarch.png?400|}}
+В цілому якось так:
+{{:opzarch.png|}}
 З чого випливає, що платіжні системи безпосередньо спілкуються зі своїми "фронтендами", абоненти у разі потреби спілкуються з "бекендами" інтегрованими в кабінет користувача або прямо в сайт провайдера, а OpenPayz реєструє транзакції, що надійшли від "фронтендів", вносить їх до загального реєстру транзакцій і викликає для них різноманітні "обробники".\\
@@ Рядок 142: / Рядок 145: @@
 </code>
-Слід також зауважити, що експлуатація OpenPayz з вимкненою опцією OP_HIGHLOAD_ENABLE у реальному світі та на продакшні вкрай не рекомендується. Відключати його має сенс лише при тестуванні та запуску нових фронтендів платіжних систем.
+Слід також зауважити, що експлуатація OpenPayz з вимкненою опцією OP_HIGHLOAD_ENABLE у реальному світі та на продакшні вкрай не рекомендується. Відключати його має сенс лише при тестуванні та запуску нових фронтендів платіжних систем. В іншому випадку, ви можете банально напоротись на дублікати оплат, та інші в цілому очікувані ефекти.
 ===== Альтернативні Платіжні ID =====
@@ Рядок 148: / Рядок 151: @@
 В деяких, випадках, наприклад, з "міркувань легасі" вам може захотітись використовувати "якісь інші Платіжні ID". Для цього варто знати, що усі меппінги "Логін"=>"Платіжний ID" лежать в view вашої БД з іменем **op_customers**. Власне для того аби на ходу замінити їх всі на потрібне вам представлення трансформуючи дані ваших користувачів для цього як вам заманеться. Нижче декілька прикладів:
-Рекомендований варіант що розгорнуто за замовчуванням:
+==== Рекомендований за замовчуванням ====
 <file sql op_customers_crc32_full.sql>
 CREATE OR REPLACE VIEW op_customers (realid,virtualid) AS SELECT users.login, CRC32(users.login) FROM users LEFT JOIN op_denied ON users.login = op_denied.login WHERE op_denied.login IS NULL;
 </file>
-Ну або він же але трішечки швидший за рахунок ігнорування заборон.
+==== З можливістю оверрайду статикою ====
+<file sql op_customers_crc32_plus_static.sql>
+CREATE OR REPLACE VIEW op_customers (realid,virtualid) as SELECT DISTINCT users.login as realid, COALESCE(op_static.virtualid,CRC32(users.login)) as virtualid FROM users
+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>
+==== Без заборон ====
+власне все той же за замовчуванням, але з ігноруванням заборон за рахунок чого є трішечки швидшим
 <file sql op_customers_crc32_fast.sql>
 -- transform users.login -> crc32(users.login);
@@ Рядок 159: / Рядок 172: @@
 </file>
+==== Використовуємо IP ====
 Або якось так, для використання IP адрес користувачів у вигляді INT
 <file sql op_customers_aton.sql>
@@ Рядок 165: / Рядок 179: @@
 </file>
+==== Використовуємо логіни ====
 Або якось так, у випадку якщо у вас повністю цифрові логіни користувачів:
 <file sql op_customers_login.sql>
@@ Рядок 171: / Рядок 186: @@
 </file>
+==== Використовуємо угоди ====
 Або якось так, якщо ви впевнені, що у всіх ваших користувачів є унікальні номери угод:
 <file sql op_customers_contract.sql>
@@ Рядок 177: / Рядок 193: @@
 </file>
+==== Непорожні угоди ====
 Можна якось так, якщо ви впевнені, що у всіх ваших користувачів унікальні номери угод - в різниці від попереднього, не буде записів для користувачів з порожніми угодами:
 <file sql op_customers_login_contract2.sql>
@@ Рядок 183: / Рядок 200: @@
 </file>
+==== Знову угоди ====
 Наступне представлення більш універсальне, теж створює платіжний ID на базі номеру угоди, але виникають помилки при відсутній угоді.
 <file sql op_customers_login_contract_pautina.sql>
@@ Рядок 188: / Рядок 206: @@
 </file>
-Також ви можете спробувати використовувати два різних платінжних ID для ваших користувачів, наприклад використовуючи для цього одночасно їх логін (сподіваємось що він цифровий) а також можливо номер угоди цього користувача, у випадку якщо він не порожній. Якось так:
+==== Логін + угода ====
+Також ви можете спробувати використовувати два різних платіжних ID для ваших користувачів, наприклад використовуючи для цього одночасно їх логін (сподіваємось що він цифровий) а також можливо номер угоди цього користувача, у випадку якщо він не порожній. Якось так:
 <file sql login_plus_contract.sql>
@@ Рядок 205: / Рядок 224: @@
 Загалом як не складно помітити все лімітовано тільки збоченістю вашої фантазії ;)\\
-(Переконайтесь що у вас всюди увімкнено OPENPAYZ_REALID для використання Платіжних ID з БД, дло слова "всюди" це в [[alteriniconf|alter.ini]] та в [[userstats|userstats.ini]])
+(Переконайтесь що у вас всюди увімкнено OPENPAYZ_REALID для використання Платіжних ID з БД, до слова "всюди" це в [[alteriniconf|alter.ini]] та в [[userstats|userstats.ini]])
+==== Статичні платіжні ID ====
+У випадку, якщо вам треба з якоїсь причини (ну наприклад хочете зберегти старі, які були до міграції), щоб платіжні ідентифікатори наглухо лежали в якійсь табличці в БД, ви можете налаштувати опцію **OPENPAYZ_STATIC_ID** конфігу [[alteriniconf|alter.ini]] та зберігати їх собі у окремій табличці **op_static**. В цьому вигляді вьюшка повинна мати наступний вигляд:
+<file sql op_static_payids.sql>
+CREATE OR REPLACE VIEW op_customers (realid,virtualid) AS SELECT op_static.realid, op_static.virtualid FROM op_static LEFT JOIN op_denied ON op_static.realid = op_denied.login WHERE op_denied.login IS NULL;
+</file>
 ===== Розробка власного фронтенду =====
@@ Рядок 289: / Рядок 313: @@
 Ось власне і все, у разі успіху - //op_TransactionAdd// створює нову транзакцію, а //op_ProcessHandlers// викликає стандартні обробники для всіх поки що необроблених транзакцій. Тепер Ubilling вміє грабувати коровани :)
+===== Налаштування платіжних систем (очевидні і не дуже) =====
+==== Providex ====
+<hidden onHidden="Відобразити конфіг" onVisible="Сховати конфіг">
+Мабуть, одна з перших "платіжок", що своїм конфігом спирається не тільки на доволі звичний багатьом власний **config/providex.ini**, а й вимагає трохи додаткових рухів безпосередньо в біллінгу. \\
+\\
+Ітак:
+  * вмикаємо модуль [[contragentextinfo|Додаткова інформація про контрагентів]]\\
+  * для необхідного нам контрагента створюємо новий запис для нашої платіжної системи в "Додатковій інфо про контрагента":
+{{ :contraextinfo3.png }}
+  * або не помилитись - найменування платіжної системи бажано не вписувати руками, а вибрати з випадаючого списку наявних платіжних систем, бо найменування платіжної системи - **критично важливе**
+  * **Merchant ID** та його **пароль** мають бути вписані точно в ті ж самі поля, які ви бачите на скріні вище, тобто **Код контрагента в платіжній системі** та **Пароль сервісу** відповідно
+Ось і все - налаштування креденшлів платіжної системи **Providex** для певного господарюючого суб'єкта - завершено.
+</hidden>

Ubilling Wiki

Користувальницькькі налаштування

Налаштування сайту

Розбіжності

Налаштування сторінки