sanyadnepr

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

Используется 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 містить номер транзакції на стороні провайдера.

С базой все ОК. 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 )

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

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

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

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

Покупай микротик, шишки надо набивать на своем опыте. ))) В гугле забанили? Бери у кайота он херню не предлагает.

Он тебе возможно напишет, но... Готов наступить на грабли? Это не про него...

У тебя опять что то сломалось? Пиши если что.

Так ты тоже согласно букве закона не используешь ЭЭ когда ее нет от постачальныка, но есть из альтернативных источников? Не весели, весь прям в белом и на коне? Не путай провода/линии связи без договоров на столбах и питание оборудки в многоэтажках. Еще раз, никто не оспаривает что договора необходимы, мне еще не приходилось что сначала договора с облами а потом устанавливается оборудование в многоэтажках, обычно все наоборот, сначала оборудование, потом договора с облами.

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

Платит ОСББ. А ОСББ никто за ээ не платит. Есть конечно и другие варианты, но за рамками этой темы. Хорошо что его вспомнил, у него была одна ошибка, он вместо того чтоб "бороться" на "стенде" (каком то зарезервированном или не критически важном участке сети), "боролся" там где не надо. Никто не оспаривает что необходимы договора с облами, если ты вдруг не понял. Оспаривается "всеобъемлемое право облов" делать все что им захочется.

Тебе плохо? ОСББ никто не платит за ээ. Максимум что можно платить ОСББ за аренду чего то там. Даже за распределение ОСББ ничего не получает. Это в основной массе, кроме всяких там модных ЖК.

Читал и тебе советую почитать.)