HOSTPLUS

причину нашел, вопрос закрыт

с января месяца на всех СМС, отправленных с биллинга стоит статус -1 в самом биллинге и СМС нет в http://myatompark.com SMS GATEWAY ERROR (try again in ~5 minutes): -1

Нужно API https://blockchain.info/ru/api/api_receive или какое-то другое? Подумаю и скорее всего реализую бесплатно после получения Вашего ответа. Верно, именно его я имею ввиду, рынок Bitcoin пока не очень большой, но он растет каждый год, мне кажется у них большое будущее Возможно сделаю в одной из сборок bpanel. Однако в bitcoin частенько прыгает курс. Полагаю, что добавлю и автообновление курсов данной валюты. Там все несколько сложнее и иначе, этот курс меняется от торгов на биржах сообщества, то есть это по сути альтернативная валюта (привязка к доллару там номинальная и может быть привязана с таким же успехом к курсу любой другой валюты или криптовалюты. Курс к тому же доллару нужно устанавливать в ручном режиме (авто по желанию через крон). То есть требуется так же, как и в любых других мерчантах (можно установить в ручном режиме курс для скажем z-payment, а может автоматически через крон)

Я бы посоветовал попросить эту систему оплатить создание мерчанта в bpanel обычно новые мерчанты заинтересованы в этом. От себя могу также к ним обратиться с этой просьбой. Не очень верю в успех такой затеи, но можно попробовать

Нужно API https://blockchain.info/ru/api/api_receive или какое-то другое? Подумаю и скорее всего реализую бесплатно после получения Вашего ответа. Верно, именно его я имею ввиду, рынок Bitcoin пока не очень большой, но он растет каждый год, мне кажется у них большое будущее

Нет в планах добавить возможность приема оплаты с помощью Bitcoin, мне кажется система очень перспективна

подробно изложено тут: https://capitalist.net/uploads/files/capitalist.merchant.pdf вроде все достаточно стандартно, как у всех мерчантов

Просьба рассмотреть возможность добавления мерчанта https://www.capitalist.net/

Мерчант робокассы перестал работать. Видимо причина в том, что файл robo.php обращается к отключенному домену roboxchange.com (merchant.roboxchange.com) Просьба исправить скрипт (нужно исправить URL адрес мерчанта на auth.robokassa.ru)

при переходе по кнопке (ссылке) "войти" (меню системы тикетов, права сотрудника поддержки), при открытии профиля пользователя (с которым идет диалог в тикете) появляются ошибки: Notice: Undefined variable: lang_m_answer in /pay/html/index.php on line 1620 Warning: Cannot modify header information - headers already sent by (output started at /pay/html/index.php:1620) in /pay/html/index.php on line 1717 Warning: Cannot modify header information - headers already sent by (output started at /pay/html/index.php:1620) in /pay/html/index.php on line 1718 p.s. сборка последняя

добавил сегодня всем (почти) аккаунтам карты экспресс-оплаты, после чего перестал работать скрипт крона, ошибки при запуске: Warning: include_once(/../admin/modules/client_sql.php) [function.include-once]: failed to open stream: No such file or directory in/pay/html/admin/modules/payment_calculate.php on line 33 Warning: include_once() [function.include]: Failed opening '/../admin/modules/client_sql.php' for inclusion (include_path='.:/usr/lib/php:/usr/local/lib/php') in/pay/html/admin/modules/payment_calculate.php on line 33 Warning: require(/../admin/modules/payment_calculate.php) [function.require]: failed to open stream: No such file or directory in/pay/html/admin/modules/index_cards.php on line 62 Fatal error: require() [function.require]: Failed opening required '/../admin/modules/payment_calculate.php' (include_path='.:/usr/lib/php:/usr/local/lib/php') in/pay/html/admin/modules/index_cards.php on line 62

некорректно работают опции в настройки - Автоматизация: CRON Выставлены нужные значения (НЕТ) для мерчантов, у которых НЕ требуется обновление курса, но при запуске крон скрипта курсы обновляются всё равно (особенно весело для робокассы, где используется USD а биллинг после запуска крона туда пихает значение курса рубля, в итоге счета очень весёлые выставляются пока руками не изменишь назад все значения в настройках - Курсы & Выбор Валют

получил на днях такое сообщение от z-payment.ru: в биллинг добавлены данные изменения?

присоединяюсь к запросу

раньше много не было, что фактически должно было быть (поддержка панелей, регистраторов, мерчантов и т.д.) сейчас все основные системы поддерживаются, не думаю, что можно придумать что-то глобально нужное и полезное, а вот что не хватало ранее, так это как раз таки стабильности, если теперь не нужно будет ждать месяцами, пока исчезнут ошибки в работе, которые появлялись почти при каждом обновлении, то это будет куда важнее и нужнее, чем новые ф-ции, нужность которых возможно будет сомнительным.

опционно или в индивидуальном порядке пожалуйста, глобально не нужно такого делать!

http://forums.cpanel.net/f145/multiple-php-5-x-versions-136101-p4.html

ну почему...всё решаемо при желании (сейчас только руками, соорудив велосипед из собственных обработчиков для отдельных аккаунтов, кому нужен другой php, а в будущем вроде как планируется и автоматом, если используется cPanel, на форуме есть ветка, где обсуждают возможность одновременного использования на сервере и php 5.2.x и php 5.3.x по аналогии как сейчас можно установить php 5 и php 4)

во первых ситуация напоминает переход с 4 на 5 версию PHP (фактически были те же сложности), согласен с Алексеем, нужно двигаться вперёд и работать с ПО, которое больше не обновляется нельзя (как то apache 1.3 php до 5.3 mysqld до 5.1 и т.д.) а во вторых если для бизнеса жалко потратить 10-30 баксов на VPS (для биллинга), тогда это не бизнес, а что-то очень не серьёзное, ИМХО

публично релиз под PHP 5.3 станет доступен с 1 Августа (через order.bpanel.ru)?

я могу ошибаться, но на сколько я понимаю речь идёт не сколько о биллинге, сколько про сетевой экран (файрвол etc) сервера Вашего

1) При чём тут были или не были взломы, если Вы всё делаете по вечному русскому принципу (пока гром не грянет, мужик не перекрестится), если с Вами не было ни разу ничего, это не значит, что у Вас всё на столько хорошо (нарушения доступа бывают даже у ресурсов платёжных систем), просто Вам повезло (не нашлось никого, кого бы Вы и Ваши сервера заинтересовали) 2) Никаких инцидентов с биллингом у нас тоже не было (опять же это не имеет никакого отношения к теме) 3) Речь идёт о том, что даже на отдельном сервере в любой момент могут случится ситуации несанкционированного доступа (в районе осени 2010 публично стало известно про существование серьёзной уязвимости в ядре CentOS 64-битной архитектуры, поищите в поиске, удивитесь столько провайдеров тогда получили проблемы, а сколько ПОСТОЯННО появляются только ПУБЛИЧНЫХ уязвимостей в Exim, Bind, FTP демоны вообще многие очень дырявые). Но это только если говорить про случай, когда закрыты основные источники нарушения доступа и вот тут как раз и появляются Ваши клиенты (обычно сами того не зная). Очень распространённый пример (возможно он именно Вас не касается, но такая опасность есть очень у многих провайдеров, причём некоторые из них знают про данный факт, но фактически ничего не делают, ибо (как я уже сказал ранее) если всё закрыть, просто ничего не будет работать. Пример: PHP работает в режиме DSO (у апача), на сервере живёт юзверь с CMS старых типов (например Joomla 1.0), или в ручном режиме или используя ботов нашли этот сайт, через XSS (и прочее) заливается ряд скриптов, те (через exec ф-ции)заливают бинарник и запускают его в /tmp, бинарник является экслоитом (бекдором и т.д. на выбор), далее в зависимости от ряда факторов (версии, наличие патчей и т.д.) выполняются деструктивные действия (от банальных перехватов управления процессов апача и выставления заставок на сайтах Ваших клиентов, что мол есть такие крутые перцы, что сделали это, до повышения привилегий до уровня root со всеми вытекающими). Если в системе стоят запреты на исполнение данных ф-ций (PHP), их обходят через .htaccess (в DSO) или через загрузку своего php.ini (в CGI режимах) п.с. указанный выше пример можно при желании закрыть, но обратно клиенты получат ограничения в использовании серверного ПО (например сложности с использованием imagick), что отрицательно будет сказываться на гибкости услуг, почему собственно некоторые провайдеры тупо забивают на такие вещи (правда при этом они никогда не будут размещать биллинги рядом с такими опасностями) удачи (думаю хватит всем нам троллить, я тоже согласен с тем, что каждый сам должен думать за себя и отвечать за последствия своих действий или бездействий)

Наивное заблуждение, *хорошо* настроенных серверов в данном аспекте НЕ бывает в природе Просто разница между тем где размещён биллинг (на отдельном сервере или вместе с клиентами) заключается в том, что кроме потенциальных нарушений безопасности, основанных на использовании уязвимостей серверного ПО (ядра и прочее) ещё добавляется опасность потенциальных нарушений безопасности, основанных на использовании уязвимостей скриптов Ваших клиентов (на любом хостинге полно старых CMS, написанных кем попало и как попало). Всё закрыть нельзя (точнее теоретически можно, только тогда ничего работать не будет вообще фактически).

между *совать свой нос* и *рекомендовать что-то, принимая во внимание ряд аспектов* огромная разница п.с. просьба оставить Ваше детское самолюбие при себе

Готовить нужно пасту с соусом и сыром на ужин. Странная у Вас логика... п.с. а про биллинг и сервер, как раз нужно, так как это деньги, держать биллинг на одном сервере с клиентами тоже самое, что хранить деньги в общественном парке, закопанными под ёлку...