Перейти до

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

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

Подскажите пожалуйста где копнуть и нет ли проблемы со стороны протокола взаимодействия сити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 користувачів

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

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

    • Від maxkorn
      Доброго дня!
      На Mikrotik NAS, створив нову підмережу для клієнтів, все наче порядок, тільки помітив, що не створюються шейпери в Queues для клієнтів цієї підмережі.
      В логах Stargazer наступне:
      2025-12-29 09:05:57 - [Ubilling] - OnConnect started for user `xxasdb5rzm`:
      2025-12-29 09:05:57 - [Executer] - Success: Firewall entry was updated/created
      2025-12-29 09:05:57 - [Executer] - Error: Queue entry can't be updated, missing
      2025-12-29 09:05:57 - [Executer] - Success: Queue_tree entry was updated/created
      2025-12-29 09:05:57 - [Executer] - Success: DHCP entry was updated/created
      2025-12-29 09:05:57 - [Executer] - Success: ARP entry was updated/created
      2025-12-29 09:05:57 - [Ubilling] - QC: 6, elapsed time: 0.064 sec.
       
      При чому, на тому ж мікротіку є ще кілька підмереж, в яких все проходить нормально:
       
      2025-12-29 08:30:17 - [Ubilling] - OnConnect started for user `22zxp7u58x`:
      2025-12-29 08:30:17 - [Executer] - Success: Firewall entry was updated/created
      2025-12-29 08:30:17 - [Executer] - Success: Queue entry was updated/created
      2025-12-29 08:30:17 - [Executer] - Success: Queue_tree entry was updated/created
      2025-12-29 08:30:17 - [Executer] - Success: DHCP entry was updated/created
      2025-12-29 08:30:17 - [Executer] - Success: ARP entry was updated/created
      2025-12-29 08:30:17 - [Ubilling] - QC: 6, elapsed time: 0.602 sec.
       
      Налаштування аналогічні, в чому може бути причина?
    • Від ProstoName
      Змінювали мережеву карту. Здається все поправив. Працює. Але є невелика проблема - після внесення коштів (коли абонент був відключений), інет в нього не з'являється. Тільки після заміни тарифу на інший (і потім вернувши тариф) в абонента з'являється інет. 
    • Від ppv
      Собака-посилака перестала відправляти повідомлення. Підкажіть де шукати.
      Можливо таке після пропадання світла, сервер ребутнувся, але я не впевнений. Візуально все працює, крон працює, а повідомлення висять в черзі, смс така ж картина.

    • Від camchatix
      Привіт!
       
      Є багато запитів, щоб інтернет не виключався у північ, а скажімо в день (сигналізації, камери під охороною і тд)
      При щоденній абонплаті - як знімати гроші не у 12:00 у північ, а наприклад у 11 годин дня ?
    • Від camchatix
      Добрий день,
      створили запасний NAS із зайвою хромосомою, все працює але коли треба вбити сесію користувача - то у списку NAS серверів лише один (той що основний)
      переназначити швидкість теж не можу
      я так розумію пакети CoA Disconnect, CoA connect, PoD - ідуть на IP адресу старого NAS ?
×
×
  • Створити нове...