Перейти до

Рекомендованные сообщения

Приветствую всех.

Подскажите пожалуйста где копнуть и нет ли проблемы со стороны протокола взаимодействия сити24 или возможно не учтена необходимая проверка в модуле сити24 в Ubilling, пока писал понял что похоже в проверке payID, но это не точно.  

Недавно обнаружилось с сити24 начали прилетать дубликаты платежей, в целом платежей мало, два одинаковых запроса Pay с одинаковым transactionID и payID в одну секунду одному платежному ID при этом биллинг "думает" примерно чуть больше минуты и отвечает одним ответом <result>0</result>, сити24 утверждает что ответ они не получили и по протоколу дальше повторяет запросы дублем, биллинг ответ и так по кругу, сити24 спрашивает каким образом с одинаковым payID от сити24 билл продолжает обрабатывать запросы и пополнять абоненту счет раз в 5 минут примерно, на одну и туже сумму, ведь этот payID уже был обработан предполагают сити24 согласно протоколу.

Конечно есть вопрос к сити24 зачем они дублем присылают два запроса, но они отвечают что эта ситуация учтена в протоколе и проблема на стороне биллинга, потому что он пополняет счет по уже обработанному одинаковому payID.

При этом transactionID в дублях одинаковый, но с каждым новым дублем разный.

Если зафаерволить запросы от сити24, но оставить возможность отвечать то после блокировки билл отправляет 2-3 минуты 6 ответов <account>0001</account>  <result>0</result>.

После снятия блокировки, дубли и платежи нескольких проблемных абонентов прилетают так же по кругу, при этом и с некоторыми новыми пополнениями происходит аналогичная ситуация.

В openpayz в платежах transactionID и не видно payID.

Ссылка на сообщение
Поделиться на других сайтах
4 минуты назад, sanyadnepr сказав:

два одинаковых запроса Pay с одинаковым transactionID и payID в одну секунду одному платежному ID

На жодні думки не наштовхує, ніт?

 

spacer.png

 

ну там з документацією ознайомитись... якісь очевидні аналогії з тим, що ви тут описуєте там знайти... ні, не варіант?

 

9 минут назад, sanyadnepr сказав:

при этом биллинг "думает" примерно чуть больше минуты и отвечает одним ответом <result>0</result>

Перекладаю - вашій СУБД походу кранти, там якесь м'ясо, робити там щось більше кількох сотих секунди фронтенду нічому. Розбирайтесь чому так.

 

10 минут назад, sanyadnepr сказав:

Если зафаерволить запросы от сити24, но оставить возможность отвечать то после блокировки билл отправляет 2-3 минуты 6 ответов <account>0001</account>  <result>0</result>.

Якщо робити якісь хаотичні дії - результат, теж буде очікувано хаотичним.

Ссылка на сообщение
Поделиться на других сайтах
Опубліковано: (відредаговано)
6 minutes ago, nightfly said:

Перекладаю - вашій СУБД походу кранти, там якесь м'ясо, робити там щось більше кількох сотих секунди фронтенду нічому. Розбирайтесь чому так.

Проблема именно когда два одинаковых прилетает, один ответ и сити его не видит.
Если один запрос без дубля то в ту же секунду ответ. Документацию читал.

Відредаговано sanyadnepr
Ссылка на сообщение
Поделиться на других сайтах
7 minutes ago, nightfly said:

На жодні думки не наштовхує, ніт?

Что это некорректно сити24 шлет запрос, но они объясняют что эта ситуация учтена в протоколе и мы не отправляем ответ, хотя отправляем.

Самый главный вопрос, проверяется ли payID в модуле? и если платеж с таким payID уже был обработан и внесен в базу почему следующий одинаковый payID далее заносится в базу платеж и пополняется счет абоненту.

Ссылка на сообщение
Поделиться на других сайтах

Ну вам ответили уже и даже сказали что и как, для начала проверьте что с вашей базой, например в модуле module=report_sysload проверить состояние БД 

https://wiki.ubilling.net.ua/doku.php?id=paymentsduplicates   

Дублювання оплат в OpenPayz

Ви можете налаштувати і використовувати Режим високої продуктивності OpenPayz aka OP_HIGHLOAD_ENABLE, забравши обробку всіх транзакцій, що надійшли, в окремий і єдиний потік, який під час своєї роботи не породжуватиме колізій.

  • Like 1
  • Thanks 1
Ссылка на сообщение
Поделиться на других сайтах
Опубліковано: (відредаговано)
21 hours ago, skybetik said:

Ну вам ответили уже и даже сказали что и как, для начала проверьте что с вашей базой, например в модуле module=report_sysload проверить состояние БД 

С базой все ОК. OP_HIGHLOAD_ENABLE это понятно, меня интересует проверка по payID есть или нет в модуле для сити24?

Array
(
    [id] => 5648
    [hash] => PLTZ_5648
    [date] => 2024-02-25 12:00:00
    [summ] => 100
    [customerid] => 0001
    [paysys] => CITY24M
    [processed] => 1
    [note] => transactionID:8938030549 amount:10000
)

Відредаговано sanyadnepr
Ссылка на сообщение
Поделиться на других сайтах
1 час назад, sanyadnepr сказав:

С базой все ОК. OP_HIGHLOAD_ENABLE это понятно, меня интересует проверка по payID есть или нет в модуле для сити24?

Array
(
    [id] => 5648
    [hash] => PLTZ_5648
    [date] => 2024-02-25 12:00:00
    [summ] => 100
    [customerid] => 0001
    [paysys] => CITY24M
    [processed] => 1
    [note] => transactionID:8938030549 amount:10000
)

Что вам мешает посмотреть это ? 

https://github.com/nightflyza/Ubilling/blob/master/docs/openpayz/frontend/city24/index.php

К слову Сити24 Юзаем больше 2 лет нет не каких проблем ?

Ссылка на сообщение
Поделиться на других сайтах
Опубліковано: (відредаговано)
3 hours ago, skybetik said:

Что вам мешает посмотреть это ? 

https://github.com/nightflyza/Ubilling/blob/master/docs/openpayz/frontend/city24/index.php

К слову Сити24 Юзаем больше 2 лет нет не каких проблем ?

Используется https://github.com/nightflyza/Ubilling/blob/master/docs/openpayz/frontend/city24_multi/index.php посмотреть нет проблем, в коде не силен. не смотря на ответ  <result>0</result>  платеж с одинаковым payID вносится еще раз в базу, вероятней всего проверки нет.
Описание что проверить надо по payID не вижу есть ли проверка в коде, поэтому и уточняю. Если вы разбираетесь в коде подскажите пожалуйста есть проверка по payID или нет?

Вижу что есть информация о платеже transactionID но payID одинаковый и нет о нем информации.
if (pltz_CheckTransaction($extTransactionID)) {  //Обязательно нужно проверить(по $payID) платеж в Вашей системе, если платеж оплачен -  возвращаем result - 0

 

https://docs.google.com/document/d/1PQUiDnyZ7rMZ0wggIETbEyEF2xH3usKCuPxgZX9dPM4/edit#

 

Увага!
Відповідно до таблиці  “Список кодів завершення”, є фатальні та нефатальні помилки (коди) відповіді на <command>pay</command>


Для того щоб уникнути втрат коштів у випадку технічних несправностей або тайм-аутів, існує можливість повторити транзакцію з тим самим `payID` у випадку фатальних помилок. Ініціатором такого повторення може бути КЦ або технічна підтримка, наприклад, за зверненням платника.

Якщо наш сервер відправляє повторний запит на поповнення з `payID`, який вже існує (тобто оплата вже була успішно проведена раніше), провайдер просто повертає позитивну відповідь (значення `result=0`), не повторюючи при цьому поповнення рахунку чи облікового запису. Це є механізмом захисту від фінансових втрат у разі технічних проблем.

У випадку, коли `payID` має фатальний статус на боці провайдера, служба підтримки може повторити запит на оплату з тим самим `payID` після обробки транзакції.

Отже:

Якщо існує успішна оплата за `payID`, провайдер повинен повернути статус попередньої успішної оплати, не повторюючи її.

Якщо успішної оплати за `payID` немає, потрібно провести оплату.

У необов'язковому полі comment міститься службовий коментар.

Поле відповіді extTransactionID містить номер транзакції на стороні провайдера.

Відредаговано sanyadnepr
Ссылка на сообщение
Поделиться на других сайтах

Включение режима высокой продуктивности никак не влияет на отсутствие проверки payID, платеж с одинаковым payID зачисляется на счет абоненту.

Ссылка на сообщение
Поделиться на других сайтах
В 25.02.2024 в 17:52, sanyadnepr сказав:

Используется https://github.com/nightflyza/Ubilling/blob/master/docs/openpayz/frontend/city24_multi/index.php посмотреть нет проблем, в коде не силен. не смотря на ответ  <result>0</result>  платеж с одинаковым payID вносится еще раз в базу, вероятней всего проверки нет.

Зачем вам city24_multi ? 

Ссылка на сообщение
Поделиться на других сайтах
1 час назад, skybetik сказал:

Зачем вам city24_multi ? 

ну а для чего он нужен?)) очевидно для работы с контрагентами

Ссылка на сообщение
Поделиться на других сайтах
Только что, datakrava сказав:

ну а для чего он нужен?)) очевидно для работы с контрагентами

Многим нравится название, потому и спрашиваю )

Ссылка на сообщение
Поделиться на других сайтах

Создайте аккаунт или войдите в него для комментирования

Вы должны быть пользователем, чтобы оставить комментарий

Создать аккаунт

Зарегистрируйтесь для получения аккаунта. Это просто!

Зарегистрировать аккаунт

Вхід

Уже зарегистрированы? Войдите здесь.

Войти сейчас
  • Зараз на сторінці   0 користувачів

    Немає користувачів, що переглядають цю сторінку.

  • Схожий контент

    • Від mac
      Глюк в тому, що один (так - тільки один) mac адрес onu існує в білінгу у вигляді строки. Це трохи заважає.
      olt - bdcom gepon.
      Наскільки зрозумів, це виключно проблема реалізації snmpwalk у freebsd, де snmpwalk може на свій розсуд віддати mac адресу не як hex-string, а як звичайний string.
      Можливо snmpwalk тригериться на якомусь символі, мені невідомо.
       
      # tcpdump -vv -i em0 udp port 161 and host olt and host ub | grep "3320.101.10.4.1.1.241 ... olt.snmp > ub.47940: [udp sum ok] { SNMPv2c C="*****" { GetResponse(44) R=93278354 E:3320.101.10.4.1.1.241="8LO"W*" } } ub.47940 > olt.snmp: [udp sum ok] { SNMPv2c C="*****" { GetNextRequest(34) R=93278355 E:3320.101.10.4.1.1.241 } } snmpwalk -c***** -v2c -t5 olt .1.3.6.1.4.1.3320.101.10.4.1.1 SNMPv2-SMI::enterprises.3320.101.10.4.1.1.241 = STRING: "8LO\"W*" snmpwalk -Ox -c***** -v2c -t5 olt .1.3.6.1.4.1.3320.101.10.4.1.1 SNMPv2-SMI::enterprises.3320.101.10.4.1.1.241 = Hex-STRING: 38 4C 4F 22 57 2A  
      Це стосується таких параметрів у snmp конфізі bdcom
       
      [signal] MACINDEX=".1.3.6.1.4.1.3320.101.10.4.1.1" [misc] ONUINDEX=".1.3.6.1.4.1.3320.101.11.1.1.3"  
      За для усунення глюку спробував трошки змінити код і завдати тип snmp параметру явно у ./api/libs/api.ponbdcom.php у function collect()
      Це працює. Мабуть станеться у нагоді:
       
      # diff api.ponbdcom.php{.new,.bak} 37c37 < $onuIndex = $this->snmp->walk('-Ox ' . $oltIp . ':' . self::SNMPPORT, $oltCommunity, $onuIndexOid, self::SNMPCACHE); --- > $onuIndex = $this->snmp->walk($oltIp . ':' . self::SNMPPORT, $oltCommunity, $onuIndexOid, self::SNMPCACHE); 91c91 < $macIndex = $this->snmp->walk('-Ox ' . $oltIp . ':' . self::SNMPPORT, $oltCommunity, $macIndexOID, self::SNMPCACHE); --- > $macIndex = $this->snmp->walk($oltIp . ':' . self::SNMPPORT, $oltCommunity, $macIndexOID, self::SNMPCACHE);  
      P.S. Створив тему, а зараз міркую: а може це глюк у ПЗ olt. Оновлю фірмваре olt та перевірю...
       

    • Від Plastilin
      Вітаю. Маю наступний комплект. Ubilling на Debian + Mikrotik CHR як маршрутизатор. Наче все запустилось, але виникло питання яке не вдається розрулити. Читав Wiki, ковиряв, читав знову Wiki, знову ковиряв - не допомогло.
      Чи можливо якось визначити конкретну IP адресу з пулу який видає Mikrotik клієнту через Radius? Мені пропонує обрати наступну вільну адресу з пулу при спробі зміни адреси?
      З цього з'являється додаткове питання, чи можливо контролювати доступ користувачам у яких IP назначений статично, тобто прописаний вручну? Наприклад при зміні статусу не активний - пхати до Firewall Mikrotik правила заборони доступу з IP адреси визначеної вручну, навіть якщо вона не отримана по DHCP.
       
      UPD: з першою частиною знайшов: IP_CUSTOM=1 в alter.ini 
    • Від ppv
      Потрібно було витерти одну мережу, всі абоненти з неї були перенесені в іншу. Але світить що 6 IP зайняті, хоча вона повністю вільна.
       
      ID    Мережа/CID           RВсього IP        Використано IP ▾           Вільно IPСервіс
      6      172.16.70.0/23        506                    6                                       500
       
      Підкажіть як правильно це підчистити щоб видалити мережу.
    • Від nightfly
      Ubilling 1.4.3 rev 9058 The Bladewood Grove
       
      Зміни в структурі БД. alter.ini: нові опції OPHANIMFLOW_ENABLED та OPHANIMFLOW_URLS котрі вмикають та керують інтеграцією з OphanimFlow. alter:ini: нова опція PHOTOSTORAGE_POSTPROCESSING, що вмикає післяобробку зображень при завантаженні в Сховище зображень. alter:ini: нова опція PHOTOSTORAGE_WATERMARK, що вмикає розміщення вотермарки на всіх зображеннях, що завантажуються. alter:ini: нова опція PHOTOSTORAGE_RECOMPRESS, що вмикає зміну компрессії завантажених зображень. alter:ini: нова опція PHOTOSTORAGE_AUTORESIZE, що вмикає автоматичне та лагідне масштабування зображень конячих розмірів. alter:ini: нова опція PHOTOSTORAGE_DRAWIMGINFO, що вмикає вдруковування в зображення відлагоджувальної інформації. alter.ini: нова опція ONDEMAND_CHARTS, що вмикає відкладене завантаження графіків завантаження користувацької смуги. userstats.ini: нова опція OPHANIM_ENABLED, що вмикає інтеграцію OphanimFlow в кабінеті користувача. Модуль Заздрість: тепер авторизаційні дані пристроїв, не відображаються в списку пристроїв. Модуль “Заздрість”: при створенні та редагуванні пристроїв, для полів “пароль” та “enable пароль” тепер використовуються інпути паролів. Модуль “Заздрість”: заздрісним пристроям додано нове поле “Порт”. Тепер в скриптах можна використовувати, відповідний макрос {PORT}. Модуль “Статистика трафіку користувача”: проведено радикальний рефакторинг. Модуль “Статистика трафіку користувача”: додано опційну можливість, відображення трафіку отриманого з OphanimFlow. Модуль “Статистика трафіку користувача”: виправлено проблему невірного відображення залишку коштів на кінець місяця, при використанні Ішимури. Модуль “Статистика трафіку користувача”: додано можливість відображення графіків за останню годину з OphanimFlow. Модуль “Користувачі”: додано опційну можливість, відображення трафіку отриманого з OphanimFlow. Модуль “Сховище зображень”: тепер додатково перевіряє завантажувані зображення на тему їх валідності. Модуль “Фінансові операції”: виправлено відображення суми платежів користувача. Remote API: новий виклик ophanimtraff, який просто бере і синхронізує локальну БД з віддаленими джерелами OphanimFlow. Remote API: виклик userbynum тепер також опційно містить поле з “Платіжним ID” користувача. Глобально: у всіх полях вводу паролів, окрім форми входу, тепер відображається елемент керування “показати/приховати” пароль. Кабінет користувача: в модулі “Трафік” додано опційну можливість, відображення трафіку отриманого з OphanimFlow. Кабінет користувача: в модулі “Трафік” виправлено проблему невірного відображення залишку коштів на кінець місяця, при використанні Ішимури. Кабінет користувача: в модулі “Відеоспостереження” для NVR WolfRecorder замінено розділювач попередньо заповнених даних авторизації. OpenPayz: додано frontend portmonemulti, для отримання платежів від різних контрагентів. Інформацію по контрагентам бере з біллінгу, також використовую розширену інформацію контрагента. Платіжна система в контрагенті мусить бути створена, як PORTMONE 1984tech: додано функціонал генерації RPZ для isc-bind, спасибі @misterromanbush  
      Повний чейнджлог
      Оновлена демка
       

    • Від mac
      Здається, після оновлення PHP 7.4 до PHP 8.2 feesharvester припинив працювати:
       
      /usr/local/bin/curl "http://127.0.0.1/billing/?module=remoteapi&key={SERIAL}&action=feesharvester" <br /> <b>Fatal error</b>: Uncaught TypeError: Unsupported operand types: string - string in {UBPATH}/billing/api/libs/api.fundsflow.php:570 Stack trace: #0 {UBPATH}/billing/modules/remoteapi/feesharvester.php(22): FundsFlow-&gt;harvestFees('2024-01') ...  
      Невеличке розслідування врешті з'ясувало, що це через наявність пробілу у деяких логінах абонентів. Як так сталося? Тому що інколи був неуважно додан трейлінг пробіл до номеру будинка і цей пробіл потрапив до логіну абоненту. Логін абоненту неможливо змінити ніяким чином штатними засобами. Я не розглядаю створення нового абонента для усунення помілки.

      Був обран такий шлях вирішення проблеми. Заміну функції php explode() знайшов у мережі. Мабуть це станеться в нагоді:

       
      diff api.fundsflow.php.bak api.fundsflow.php.new 559c559 < $eachfee = explode(' ', $eachline); --- > $eachfee = preg_split("~(?<!\\\\)(?:\\\\{2})*'[^'\\\\]*(?:\\\\.[^'\\\\]*)*'(*SKIP)(*F)|\s+~s" , $eachline);  
×
×
  • Створити нове...