Openpayz City24

[sanyadnepr]

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

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

[nightfly]

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

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

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

 

 

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

 

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

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

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

 

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

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

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

[sanyadnepr]

6 minutes ago, nightfly said:

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

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

Edited February 24, 2024 at 02:52 PM by sanyadnepr

[sanyadnepr]

7 minutes ago, nightfly said:

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

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

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

[skybetik]

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

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

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

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

[sanyadnepr]

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
)

Edited February 25, 2024 at 02:31 PM by sanyadnepr

[skybetik]

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 лет нет не каких проблем ?

[sanyadnepr]

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

Edited February 25, 2024 at 06:33 PM by sanyadnepr

[sanyadnepr]

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

[KaYot]

Не забывай юный падаван, ты помощи просишь у пони рыгающих.

[skybetik]

В 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 ? 

[datakrava]

1 час назад, skybetik сказал:

Зачем вам city24_multi ? 

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

[skybetik]

Только что, datakrava сказав:

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

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