Расчёты через Яндекс.Деньги

[DoS 0]

Предлагаю решение для автоматизации приёма платежей. Мой способ не претендует на идеал но для сети до 100-150 человек подойдёт

 

Давно слежу за форумом и не раз замечал появление тем на подобие "Как сделать приём платежей через мультикассу" и т.п.

Один раз увидел чью-то мысль по поводу завести каждому пользователю уникальный кошелёк (благо в webmoney classic это делается двумя кликами). Затем в панели управления аккаунтом (например в stg-web, или в любой другой самописной), вывести кнопку "Приём платежей через мультикассу", при нажатии на которую будет показываться следующая инструкция:

1. В мультикассе выбираете электронные платежи

2. Выбираете webmoney

3. Вводите ваш уникальный кошелёк: $id - тут личный идентификатор пользователя

4. Оплачиваете

 

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

 

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

 

К сожалению, сейчас нахожусь на стадии получения персонального сертификата, поэтому начать писать скриптик не могу чисто технически. Но через недельку обещаю заняться На текущий момент - от делать нефик - решил попробывать тоже самое, только не в webmoney, а в яндекс.деньгах. Создал тестовый аккаунт на васю пупкина и завёл кошелёк.

 

После 15 минут работы набросал такой скриптик с использованием Zend Framework:

 

public function getMoney($login, $password)
   {
       $client = new Zend_Http_Client();
       $client->setCookieJar();
       $client->setUri('http://passport.yandex.ru/passport?mode=auth');
       $client->setParameterPost('login', $login);
       $client->setParameterPost('passwd', $password);
       $response = $client->request('POST');
       $response = $client->request();
       $client->setUri('http://money.yandex.ru/');
       $response = $client->request('GET');
       $body     = $response->getBody();
       $money    = strstr($body, 'balance');
       $money    = substr($money, 9);
       $pos      = stripos($money, '.');
       $pos      = $pos - 4;
       $money    = substr($money, 0, $pos);
       return $money;
   }

public function indexAction()
   {
       $money = $this->getMoney('логин_кошелька', 'пароль');
       echo $money;
   }

 

ф-ия getMoney возвращает текстовое значение баланса кошелька. Не сложно догадаться, что можно в крон запихать проверку кошельков и при изменении баланса изменять таковой в sql-базе stargazer'а.

 

На сегодня всё. Через недельку попробую тоже самое только с webmoney.

[vop 370]

Предлагаю решение для автоматизации приёма платежей. Мой способ не претендует на идеал но для сети до 100-150 человек подойдёт

 

То, что ты называешь решением, обычно называется "платежным агрегатором". По сути, это набор программных средств, которые позволяют организовать прием платежей разными способами. Обычно, агрегаторы являются либо частью основного ПО, либо поставляются в виде независимого ПО, либо пишутся самостоятельно. Из отдельных агрегаторов мне в голову приходит только продукт Чекркашина (это если не считать мой, но я его не раздаю). Реально, их, видимо, больше.

 

К чему я это все, а, ну да. Будешь писать свой - делай сразу его в виде независимого агрегатора с четким API. Это позводит тебе в будушем, если будешь переходить на другой биллинг или добавишь новых услуг, использовать то же ПО.

[Cell 7]

На сегодня всё. Через недельку попробую тоже самое только с webmoney.

)) попробуй, только для webmoney есть готовое решение http://local.com.ua/forum/index.php?showtopic=1140 которое реально работает. По образу и подобию можно сделать модуль для ЛЮБОЙ платежной системы, нужно только знать механизмы ее работы.

[vop 370]

По образу и подобию можно сделать модуль для ЛЮБОЙ платежной системы, нужно только знать механизмы ее работы.

 

Разумеется, для этого платежные системы и делают, что бы ими пользовались, и делали модули

 

Проблема, в общем-то, не совсем в модуле, как таковом. Но я не буду развивать тут эту тему и действовать на нервы Борису

[madf 279]

Разумеется, для этого платежные системы и делают, что бы ими пользовались, и делали модули

 

Проблема, в общем-то, не совсем в модуле, как таковом. Но я не буду развивать тут эту тему и действовать на нервы Борису

Не волнуйся, Борис сюда уже давно не заглядывает

[vop 370]

Не волнуйся, Борис сюда уже давно не заглядывает

 

Ну вот, нам его будет сильно не хватать? Ну раз нету, значит можно поглумиться над продуктом немного? Я какое-то время не наблюдал за продуктом, посему задам пару актуальных вопросов:

 

1. Арифметику перевели уже на целчисленное исчисление, или все так же флоатами мутим?

2. Сделали накопительную систему расчета денег за предоставленные услуги, или так и продолжается "снятие" маленькими кусочками?

 

Вопрос про добровольное убиваение старгейзером своих файлов пропускаем. Раз уж добавили еще одно звено нестабильности - sql

 

Ну и классический вопрос - не пора ли исправить изначальную логическую ловушку: т.е. разнести разные задачи в разные программные структуры - I meant учет клиентов и денег отдельно, считание байтов и дергание фаервола - отдельно?

[Cell 7]

Глумиться, так глумиться )))

Убил я старгайзер на новый год после 4 лет эксплуатации. Жалко было конечно, но уперся в проблему которую никто не мог (вернее не хотел) решать: в приобретенном за 30 баксов модуле карточек напрочь отсутствовал 2009 год как класс (надо же было так тупо программировать, чтобы список лет не генерился динамически) т.е. там была заложена бомба которая сработала в нужный момент. Обратившись за помощью к разработчикам я получил (абсолютно бесплатно кстати!!!) доработанный модуль который абсолютно не работал!!!!! выдавая эррор 500. Общение с техподдержкой не привело ни к чему т.к. было удобнее забить на меня чем решить проблему. Ну да... исходников нет, чтобы самому подправить (ну да... это ж бабло!) Проблему никто не решает. И мы сказали Stargaser - гудбай. Поставил Ideco - 5 месяц нарадоваться не могу сертифицированным биллингом. Нет, я его не покупал иссно - религия у меня не позволяет за так дорого покупать.

[madf 279]

Ну вот, нам его будет сильно не хватать? Ну раз нету, значит можно поглумиться над продуктом немного? Я какое-то время не наблюдал за продуктом, посему задам пару актуальных вопросов:

 

1. Арифметику перевели уже на целчисленное исчисление, или все так же флоатами мутим?

2. Сделали накопительную систему расчета денег за предоставленные услуги, или так и продолжается "снятие" маленькими кусочками?

 

Вопрос про добровольное убиваение старгейзером своих файлов пропускаем. Раз уж добавили еще одно звено нестабильности - sql

 

Ну и классический вопрос - не пора ли исправить изначальную логическую ловушку: т.е. разнести разные задачи в разные программные структуры - I meant учет клиентов и денег отдельно, считание байтов и дергание фаервола - отдельно?

1. Мы люди необразованные, деньги до сих пор как double считаем.

2. Что есть "накопительная система рассчета"?

3. В последней версии используется rename вместо copy. И вобще, витает в воздухе идея складывать данные в BerkleyDB а уже оттудова - хоть в sql.

4. Файрвол и так отдельная структура дергает.

[madf 279]

... Общение с техподдержкой не привело ни к чему т.к. было удобнее забить на меня чем решить проблему. Ну да... исходников нет, чтобы самому подправить (ну да... это ж бабло!) Проблему никто не решает...

Не помню такого

[Cell 7]

Не помню такого

да я не в обиде, а даже может где-то благодарен так что все ок.

[vop 370]

1. Мы люди необразованные, деньги до сих пор как double считаем.

 

Совершенно зря. Байты - вещи целочисленные. Рубли-копейки - тем более. Тут нет места для даблов, тем более, можно хорошо на конвертах пролететь. Для прикола, простой примерчик залета.

 

// gcc -o aaa aaa.c ; ./aaa
#include <stdio.h>
#include <stdlib.h>
#include <stdint.h>


int main(int argc, char *argv[]) {
   int traf=70;
   double cost=.6;
   int sum;

   sum=traf*cost;

   printf("%d\n", sum);

   return(0);
}

 

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

 

2. Что есть "накопительная система рассчета"?

 

Это значит, что в течении месяца количественные показания услуг (напр, трафик) накапливаются, а расчет происходит при закрытии месяца. В этом случае, баланс не "уплывает". Прим. уплывший баланс, по сути, обман клиента. При бориной системе расчета, взявши сумаррный месячный трафик (по категориям) и умноживши на его стоимость (так же по категориям) мы не получим сумму:, которую "снял" старгейзер. "Обман" может достигать до 15%.

 

3. В последней версии используется rename вместо copy. И вобще, витает в воздухе идея складывать данные в BerkleyDB а уже оттудова - хоть в sql.

 

Заглянул для любопытство. Не то. Ну, в принципе, rename используется, но не там, так-как не достигается главная цель - надежное неисчезающее хранение данных. Мое многолетнее взывание к Борису, все же, в ключевом моменте заключалось не в команде rename, а немного в дрогом. Правило простое - ни при каких условиях, ни в каком случае, ну просто никогда нельзя открывать файл данных на запись, ибо, это означает обнуление данных. А это означает, что если в этот момент старгейзер завершит работу, причем, нормльно, по sigint, данные пропадут (а вовсе не при повреждении файловой системы, как Борис настаивал). оэтому алгоритм работы с файлом данных очень простой. Если хотим что-то изменить в файле данных, то поступаем просто:

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

2. Закрываем файл, и проверяем, как минимум, размер созданного файла (желательно, при создании, мониторим количество записываемой информации).

3. Вот тут уже делаем rename временного файла на постоянный файл.

Это и будет неисчезающее изменение файла данных. И в этом случае ему ничего не гроизт, ни ^C, ни падение, ни конец места на диске или упор в квоту, ни падение сервера.

 

Честно говоря, я так и не доехал, почему Борис столько лет так упорно сопротивлялся в понимании такого простого алгоритма, который используют многие программы (тот же rsync).

 

Мораль тут немоног другая. Если не хватает сил сделать элементарную работу с данными, то переход на более технологичные способы хранения в базах данных не спасет. Ибо, подход тот же

 

4. Файрвол и так отдельная структура дергает.

 

А кто эту структуру дергает?

 

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

[madf 279]

1. У тебя потери происходят только при преобразовании в целочисленную переменную. На самом деле деньги хранят в целочисленных переменных по другому поводу. А именно - для точного округления до двух знаков после запятой (чтобы не оставалось вещественного "хвоста").

2. То что ты описал - это просто post-paid. Stargazer сейчас, фактически, работает по pre-paid-системе. Не всем удобно post-paid. И можно тут раскрыть момент про "уплывающий" трафик?

3. В целом я согласен с твоей позицией. Вопросы возникают только по поводу SIGINT, но тут надо подумать, покурить маны, потестировать... В любом случае существующая система не хуже предлагаемой.

4. Структуру эту дергает подсистема управления юзерами через IPC. А кто по твоему ее еще должен дергать?

 

По поводу структуры системы я могу сказать только одно: ее надо менять. Но путанницы там никакой нет. Она просто плохая. Ну я меняю потихоньку...

[madf 279]

К стати, еще по поводу п. 3. Т.к. ФС сейчас умные, журналируемые, с отложенной записью и т.д. - катаклизмы типа Reset или пропадания питания все равно могут привести к потере данных. А делать постоянный sync - это очень сильно скажется на производительности системы.

[vop 370]

1. У тебя потери происходят только при преобразовании в целочисленную переменную. На самом деле деньги хранят в целочисленных переменных по другому поводу. А именно - для точного округления до двух знаков после запятой (чтобы не оставалось вещественного "хвоста").

 

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

 

2. То что ты описал - это просто post-paid. Stargazer сейчас, фактически, работает по pre-paid-системе. Не всем удобно post-paid. И можно тут раскрыть момент про "уплывающий" трафик?

 

Вообще-то к "пре" и "пост" паиду это не имеет никакого отношения. Финансовая модель должна быть отделена логически вообще от считалки байтов, и быть самодостаточной. Просто никто не отменял учет текушего затратного баланса с блокировочной суммой. Система совершенно аналогична работе расчетов банковскими картами - текущая аторизация затрат с блокировкий суммы и дальнейший батч (рельное списание) суммы.

 

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

 

3. В целом я согласен с твоей позицией. Вопросы возникают только по поводу SIGINT, но тут надо подумать, покурить маны, потестировать... В любом случае существующая система не хуже предлагаемой.

 

Вообще-то, существующая схема хуже, так-как она реализует исчезающее изменение данных. А неисчезающая схема только одна - та, про которую я написал, и та, которая гарантируется реализацией любой OS. Именно такая схема и реализуется в разного рода системных утилитах, типа rsync или scp.

[vop 370]

К стати, еще по поводу п. 3. Т.к. ФС сейчас умные, журналируемые, с отложенной записью и т.д. - катаклизмы типа Reset или пропадания питания все равно могут привести к потере данных. А делать постоянный sync - это очень сильно скажется на производительности системы.

 

Исторический вопрос пропадания данных в старгейзере никак не связан с аварийными ситуациями, такими, как резет или пропадание питания. При существующей схеме данные пропадают при штатном завершенни работы приложения по sigint. Правда, нынешняя подпорочка минимизирует эту проблему, но вовсе не устраняет. Вот в чем там проблема.

 

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