Перейти до

openpayz кілька питань.


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

Руками через браузер происходит тоже самое, платеж "застряёт" в openpeyz и "плюсиком" его надо руками проводить.

 

мой айпи - - [16/Dec/2015:16:58:25 +0300] "GET /qiwi/index.php?command=check&txn_id=17790876372006&account=00396&sum=1000.00&prv_id=64690&sum_from=1.00%20HTTP/1.1 HTTP/1.1" 200 195
мой айпи - - [16/Dec/2015:16:59:04 +0300] "GET /qiwi/index.php?command=check&txn_id=17790876372006&account=00396&sum=1.00&prv_id=64690&sum_from=1.00%20HTTP/1.1 HTTP/1.1" 200 195
Этот платеж не прошел.

мой айпи - - [16/Dec/2015:17:01:32 +0300] "GET /qiwi/index.php?command=check&txn_id=17790876372007&account=00396&sum=100.00&prv_id=64690&sum_from=1.00%20HTTP/1.1 HTTP/1.1" 200 195
мой айпи - - [16/Dec/2015:17:02:49 +0300] "GET /qiwi/index.php?command=check&txn_id=17790876372007&account=00396&sum=100.00&prv_id=64690&sum_from=100.00%20HTTP/1.1 HTTP/1.1" 200 195
мой айпи - - [16/Dec/2015:17:04:11 +0300] "GET /qiwi/index.php?command=check&txn_id=17790876372008&account=00396&sum=100.00&prv_id=64690&sum_from=100.00%20HTTP/1.1 HTTP/1.1" 200 195

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

Top Posters In This Topic

  В 16.12.2015 в 14:30, l1ght сказав:

 

  В 16.12.2015 в 12:09, dnet сказав:

OPENPAYZ_MANUAL=1

выставить в 0 же

 

  В 11.02.2014 в 23:05, nightfly сказав:

Змінює можливість розносити оплати вручну, у випадку STG_DIRECT=0 (угу, бувають шизофреніки, котрим хочеться кожну оплату рученьками перевірити і внести). Для здорових людей OPENPAYZ_MANUAL нічого не міняє.

Спасибо, попробую, но этот параметр как и другие не изменялся. Изменился только внешний айпи адрес.

Ссылка на сообщение
Поделиться на других сайтах
  В 16.12.2015 в 14:30, l1ght сказав:

выставить в 0 же

Неудачная идея, платеж как и раньше "застряет" в openpаyz, в графе "обработан" состояние "красный" без возможности провести его руками :(

Вернул OPENPAYZ_MANUAL=1, и STG_DIRECT=1.

 

Какие будут еще предложения ?

 

nightfly у нас "особенный" южный, немного специфический киви, для которого вы что то "шаманили", чтоб не повторялись платежи, это не может быть каким либо образом взаимосвязано ?

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

 

 

  В 16.12.2015 в 12:52, dnet сказав:
Изменил на 0 непомогло.

А кто вам сказал, что это нужно менять, и это как-то должно помочь? Давайде менять все опции в рандомные значения, а?

 

 

 

  В 16.12.2015 в 14:54, dnet сказав:
Неудачная идея, платеж как и раньше "застряет" в openpаyz, в графе "обработан" состояние "красный" без возможности провести его руками :( Вернул OPENPAYZ_MANUAL=1, и STG_DIRECT=1.

Извините, а чего вы ожидали?

 

 

 

  В 16.12.2015 в 14:54, dnet сказав:
Какие будут еще предложения ?

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

 

 

 

  В 16.12.2015 в 14:54, dnet сказав:
nightfly у нас "особенный" южный, немного специфический киви, для которого вы что то "шаманили", чтоб не повторялись платежи, это не может быть каким либо образом взаимосвязано ?

У вас "особенные" южные  администраторы - точно с этим связано.

Ссылка на сообщение
Поделиться на других сайтах
  В 16.12.2015 в 15:02, nightfly сказав:

А кто вам сказал, что это нужно менять, и это как-то должно помочь?

  В 16.12.2015 в 14:30, l1ght сказав:

выставить в 0 же

 

Каким образом "особенность" коррелирует с возникшей на ровном месте проблемой ?

Платежка пуляет по домену, сменился айпи - вполне нормальная ситуация. Платежи приходят, не разносятся автоматически.





sgconf set -s localhost   -p 5555 -a admin -w password  -u00008 -c 1
2015-12-16 19:15:26 -- Admin 'admin', 127.0.0.1: User '00008': 'cash' parameter changed from '48.000000' to '49.000000'. 

Руками в консоли как и руками в админке(плюсик) работает, где еще посмотреть ?

С Вашей точки зрения администратор по умолчанию обязан заниматься написанием(изменением, ковырянием) php кода ?

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

Да я написал выставить в 0, ибо опция сама это подразумевает. Я и не знал даже про STG_DIRECT, и как оно меж собой корелирует.

Выше nightfly расписал что и как.

Как бы от того что сменился внешний адрес - оплаты сами собой ходить не перестанут. Ищите что ещё менялось.

Проверяйте валидность настроек старгейзера в openpayz.ini

Ссылка на сообщение
Поделиться на других сайтах
  В 16.12.2015 в 16:53, l1ght сказав:
Как бы от того что сменился внешний адрес - оплаты сами собой ходить не перестанут. Ищите что ещё менялось.

Ничего больше не менялось ! В этом то и дело.

Оплаты приходят, не пополняются автоматически.

 

 

 

  В 16.12.2015 в 16:53, l1ght сказав:
Проверяйте валидность настроек старгейзера в openpayz.ini


pfdf; Вносить платежи напрямую в stargazer при помощи sgconf
STG_DIRECT=1
; Путь sgconf
SGCONF=/usr/sbin/sgconf
; Хост на котором установлен sgconf
STG_HOST=localhost
; Порт stargazer
STG_PORT=5555
; Логин администратора stargazer под которым будут внесены платежи
STG_LOGIN=admin
; Пароль администратора stargazer
STG_PASSWD=пароль
;ID типа оплаты для UBILLING
UB_CASHTYPE=1

Руками же вносится на счет пользователю !

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

Подскажите какая прокладка между openpayz и старгейзером ? Как ее работоспособность диагностировать ?

Я уже и написал. Причем доступно и пошагово. Вы прочитали, проигнорировали, сделали херню. В чем ваша проблема? Відредаговано nightfly
Ссылка на сообщение
Поделиться на других сайтах

 

 

  В 17.12.2015 в 08:43, nightfly сказав:
Я уже и написал. Причем доступно и пошагово. Вы прочитали, проигнорировали, сделали херню. В чем ваша проблема?
Об этом ?

 

 

  В 16.12.2015 в 15:02, nightfly сказав:
Читать документацию, пользоваться мозгом, понять, что не отрабатывают обработчики взаимодействия с sgconf ?
Кто такие эти обработчики ? Где их искать ? Как диагностировать ? 

Наша проблема - поламалось на ровном месте.

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

Прочитали, процитировали, даже не попытались подумать. Продолжаете продуцировать какой-то детский лепет, про "поломалось само". Но нет, учитывая, что я слишком хорошо знаю, насколько оно все примитивное внутри - не ведусь. Там нечему физически "поломаться".

 

Последний бесплатный совет - прочитайте еще раз, зырните в конфиг/документацию, сделайте хоть какие-то выводы.

Ссылка на сообщение
Поделиться на других сайтах
  В 17.12.2015 в 09:15, nightfly сказав:

Но нет, учитывая, что я слишком хорошо знаю, насколько оно все примитивное внутри - не ведусь. Там нечему физически "поломаться".

Вы утверждали что и "двойные" платежи приходить/пополнять счет абону не могут, платежи не переставали периодически повторяться, до момента Вашего вмешательства Jul 10 2014.

 



ls -l /usr/local/www/qiwi/public_html/
total 24
-rw-r--r--  1 root    1000    457 Jul 10  2014 handlers.php
-rw-r--r--  1 stm  wheel  3726 Jul 10  2014 index.php
-rw-r--r--  1 root    1000   2143 Dec 28  2013 index.php.old.28.12.2013

 

  Відновити прихований контент

 

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

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

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

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

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

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

Вхід

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

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

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

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

    • Від 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.
    • Від vde
      День добрый!

      Тинькофф обновили форму оплаты, может уже кто написал готовый код (с формированием чека)? 
      https://www.tinkoff.ru/kassa/develop/widget/receipt/
    • Від Andy_km
      Добрый день, форумчане.
       
      Помогите, уже сломал голову.
       
      Фронтенд privatx несколько лет безотказно работал на старом сервере. Выполнили перенос биллинга на новый и фронтенд начал банку отправлять ответ следующего содержания:
       
      "DT":"2021.06.25 11:22:31.146" "REF":"SEARCH" URI":"http://billing_host/openpayz/frontend/privatx/index.php" "REQUEST_BODY": "<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <Transfer action="Search" interface="Debt" xmlns="http://debt.privatbank.ua/Transfer"> <Data xsi:type="Payer" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <Unit name="bill_identifier" value="5200000"/> </Data> </Transfer>" "RESPONSE_BODY": "<br /> <b>Fatal error</b>: Uncaught Error: [] operator not supported for strings in /usr/local/www/apache24/data/openpayz/libs/api.mysql.php:85Stack trace: #0 /usr/local/www/apache24/data/openpayz/libs/api.openpayz.php(201): simple_queryall('SELECT * from `...') #1 /usr/local/www/apache24/data/openpayz/frontend/privatx/index.php(304): op_CustomersGetAll() #2 /usr/local/www/apache24/data/openpayz/frontend/privatx/index.php(499): pbx_ReplySearch('5200000') #3 {main} thrown in <b>/usr/local/www/apache24/data/openpayz/libs/api.mysql.php</b> on line <b>85</b> <br />"  
      Помогите понять с чем связан Fatal error.
       
      Благодарен за любую помощь.
    • Від ProstoName
      Прикручиваю платежи через приват.
      Настроил фронтенд privatmulti и Openpayz по доке. Базы и вьюшка созданы.
      В дебаг режиме поиск работает. Но при проверке с привата, вылетает такая ошибка:
       
      Что мог не донастроить???
    • Від Vitaliy1984
      где искать файлы config/mysql.ini и config/openpayz.ini и где можно взять фронтпед  yndex деньги сбербанк  и tachcard и самое главное как это все запилить в убиллинг
       

×
×
  • Створити нове...