Случайный альбом
KUBANA-2011
Некультурный отдых - KUBANA-2011
Изображений: 67
Косово поле-2011
Некультурный отдых - Косово поле-2011
Изображений: 214
Flash Point 2011
Некультурный отдых - Flash Point 2011
Изображений: 77
Меточки:
Нацарапано:  17.11.2009
Категория: Работа
Метки новости:
Зачастую в процессе эволюции проекта наступает момент, когда владельцу судорожно начинает хотеться денег, которые можно получать благодаря этому проекту.
Бабла алчется не только в виде копеек от контекстной и банерной рекламы и реферальных систем, но и в виде денежек от своих посетителей.



При этом совершенно неважно, что предлагается посетителю — супермегакрутой джедайский меч в онлайн игре, сувениры с атрибутикой проекта, именная полированная арматурина или доступ к Очень Секретному Любительскому Видео Главной Одминши. Важно, как получить честно отнятые деньги, причем желательно все и сразу пока у пользователя еще [strike]стоит[/strike] горят глаза и не включился моск.

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

Каким же способом[strike] честного отъема денег[/strike] организации приема более-менее моментальных платежей можно воспользоваться в данном случае? Как минимум тремя:
  • sms (и появившейся в последнее время возможности оплаты звонком);
  • пластиковые карты
  • электронные деньги


Рассмотрим блеск и нищету каждого из предложенных способов:

  • Платежи с помощью sms — нехилая комиссия, однако телефон под рукой почти у каждого пользователя.
  • Пластиковые карты — пригодные для оплаты (формат как минимум Visa Classic, а не задротский Electron и их эквиваленты) недостаточно распространены, зато комиссия при подобном платеже минимальна.
  • Электрические деньги — масса различных систем, существуют трудности технического и юридического плана в моментах подключения и вывода электробабла, однако и и аудитория немаленькая и есть масса способов пополнения.


В данной заметке мы не будем останавливаться на первых двух способах, а рассмотрим лучше организацию приема на сайте электронных денег платежных систем ВебМани, Яндекс.Деньги, Деньги@Mail.Ru и аналогичных [toolfaq]тысячи их! [/toolfaq]. В подробности конкретной реализации для каждой платежной системы мы вдаваться не будем, читайте мануалы по организации гейтов - они есть для каждой системы в документации, и во всякого рода описаниях в блогах типа "Как я хотел заработать стопицот денег и че из этого вышло".

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

Заранее проведя дефиницию терминов скажем, что далее под «счетом» будет пониматься не account, а invoice. И чтобы не путать [strike]мягкое с теплым[/strike] счет пользователя, который содержит сведения о платежах, размер платежного баланса и т.п., и счетом для оплаты, оный счет будем называть к примеру «заказом». Ну или заявкой. [toolfaq]Ара, минэ похуй [/toolfaq]

Как правило, платежные системы делятся на два типа:

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


Схема работы с обоими типами реализуется практически одинаково, однако первый способ проще — достаточно выделить из потока данных номер заказа в системе и вызывать функцию, меняющую статус заявки на «оплачена».

Теперь о втором типе.
Тривиальный сценарий при работе с такими системами с точки зрения барыги выглядит примерно так:

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


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

Про то, как грамотно написать биллинг - тема для группы статей, а сегодня у нас не про это. Сегодня у нас про другое.

Ну-сс, начнем, помолясь, с общей архитектуры.

На самом деле архитектура системы приема электронных платежей достаточно проста:
Компоненты:

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


Теперь остановимся подробнее на каждом из этапов Болшого пути:

Что такое очередь заявок?
Всё предельно просто — дас ист таблица заявок различных статусов (грубо говоря «уплОчено», «неуплОчено», «в обработке»). Сия таблица понадобится нам и для того, чтобы сохранять инфу о заявке, и для того, чтобы ориентироваться какие заявки нужно отдать на обработку диспетчеру.

Диспетчер обработки очереди.
Некий гипотетический скрипт, болтающийся в бэкграунде как демон или по Cron.
Его боевая задача - пережевывать очередь заявок, взывать к платежным системам и менять статусы заявок.

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


Веб-интерфейс.
Предназначен для вывода пользователю информации о заказе и нашей любимой кнопы «Оплатить».

От веб-интерфейса нам нужно, чтобы он умел выдавать одни и те же данные в разных форматах: html, json/xml. HTML известно для чего, а JSON - чтобы можно было пользовать AJAX и не обновлять страницы.

От веб-интерфеса нам необходимо:
  • вызывать функции создания заявки
  • вызывать функции получения данных о заявке
  • вызывать функции удаления заявки
  • и базовая функция обработки ошибок и вывода данных в нужном формате.


Библиотеки взаимодействия с платежными системами (далее БПС) должны:
  • формировать URL и данные для запроса на создание заявки в ПС.
  • разбирать ответ платежной системы и возвращать номер заказа в нумерации платежной системы
  • формировать URL и данные для запроса статуса заявки
  • разбирать ответ платежной системы и возвращать статус заявки.


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


И как теперь все у нас выглядит?

0. инициализация пользователем процесса проведения платежа.

Веб-интерфейс кажет список платежных систем и платежные данные.
Пользователь кликает «Оплатить», материализуется заявка со статусом «новая», информация о ней поступает в очередь[toolfaq]В очередь, сукины дети, в очередь![/toolfaq]. Пользователю сей же момент выдаем сообщение «Братуха, жди, ща все будет!» и проверяем периодически статус заявки. Именно тут понадобятся те же данные заявки в JSON - в то время как мы отрисовываем пользователю всякого рода часики, прогресс-бары, танцуем польку-дристушку, в то же самое время под покровом ночи с помощью AJAX судорожно опрашиваем очередь о статусе заявки.

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


Тем временем наш диспетчер выуживает из очереди заявку со статусом «Новая», изменяет ейный статус на «в обработке», отправляет данные в ОБ, получает данные для отправки в ПС. Передает их, получает ответ, отправляет его в ОБ, она в свою очередь в БПС и в итоге получает номер заказа. Номер заказа и URL для оплаты сохраняется в нашу очередь, меняет статус заявке на «готова к оплате».

При очередном допросе очереди посылаем пользователя на URL для продолжения оплаты. Че он там сотворит - его сугубо личное дело. На тот случай, ежли сообразит, что этой электронной валюты у него нетути, на страничке со статусом заказа любезно выдадим ему ссыль на удаление заявы и порождение новой уже с выбором другой валюты.

4. опрос системы электроплатежей на тему изменения статуса заказа.
Иногда диспетчер получает заявку со статусом «готова к оплате» и тщательно проверяет ее статус в ПС. Ежели статус не изменяется, откладывает заявку на полку до лучших времен.
Необходимо еще учитывать «срок годности» заявки, чтобы не доставать платежную систему своими опросами бесконечно.

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

В чем ништяк описанной системы?

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

  • Система может масштабироваться до неимоверных размеров.
    Есть возможность организовать десятки очередей[toolfaq]Как при развитом социализьме[/toolfaq], пользуясь различными методами партиционирования.
    Стопицот демонов для обработки каждой отдельно взятой очереди или статуса, или может быть даже валюты.

  • Простота - хуже воровства.
    Чтобы подключить новую платежную систему - надо всего лишь добавить новую библиотеку, коя должна уметь всего 4 вещи, о которых было сказано выше.


А конкретная реализация - тут уж кто как хочет - так и РЕАЛИЗУЕТ.

Звиздец рекомендует поделиться ссылкой с камрадами и откомментить эту заметку:
для печатиПечатай!  
 
ZviZdeZ.ru
Придет серенький Фенрир и укусит нас за мир

2009-2011©