Перейти до

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


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

Предлагаю решение для автоматизации приёма платежей. Мой способ не претендует на идеал :) но для сети до 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.

Ссылка на сообщение
Поделиться на других сайтах
  • 2 weeks later...
Предлагаю решение для автоматизации приёма платежей. Мой способ не претендует на идеал :) но для сети до 100-150 человек подойдёт :)

 

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

 

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

Ссылка на сообщение
Поделиться на других сайтах
  • 2 weeks later...
На сегодня всё. Через недельку попробую тоже самое только с webmoney.

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

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

 

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

 

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

Ссылка на сообщение
Поделиться на других сайтах
Разумеется, для этого платежные системы и делают, что бы ими пользовались, и делали модули :rolleyes:

 

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

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

Ссылка на сообщение
Поделиться на других сайтах
Не волнуйся, Борис сюда уже давно не заглядывает :rolleyes:

 

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

 

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

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

 

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

 

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

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

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

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

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

 

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

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

 

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

 

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

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

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

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

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

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

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

Ссылка на сообщение
Поделиться на других сайтах
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. Файрвол и так отдельная структура дергает.

 

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

 

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

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

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

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

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

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

 

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

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

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

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

 

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

 

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

 

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

 

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

 

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

 

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

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

 

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

 

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

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

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

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

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

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

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

Вхід

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

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

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

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