Зачастую в процессе эволюции проекта наступает момент, когда владельцу судорожно начинает хотеться денег, которые можно получать благодаря этому проекту.
Бабла алчется не только в виде копеек от контекстной и банерной рекламы и реферальных систем, но и в виде денежек от своих посетителей.
При этом совершенно неважно, что предлагается посетителю — супермегакрутой джедайский меч в онлайн игре, сувениры с атрибутикой проекта, именная полированная арматурина или доступ к Очень Секретному Любительскому Видео Главной Одминши. Важно, как получить честно отнятые деньги, причем желательно все и сразу пока у пользователя еще [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 вещи, о которых было сказано выше.
А конкретная реализация - тут уж кто как хочет - так и РЕАЛИЗУЕТ.
Звиздец рекомендует поделиться ссылкой с камрадами и откомментить эту заметку: