Архитектура системы приема электронных платежей на сайте

    Для многих проектов наступает момент, когда хочется, чтобы сайт приносил прибыль.
    И не только в виде оплаты рекламных баннеров или контекстной рекламы, но и в виде денежек от своих посетителей.

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

    Такое ограничение сразу приводит к вычеркиванию из списка методов оплаты заполнение квитанции в Сбербанке. Да, это тоже метод, но метод небыстрый. Особенно, если на дворе поздний вечер, пользователь расслабился за бутылкой пива чашкой чая. Какой Сбербанк, тёпленьким его брать, тёпленьким!



    Какие же способы организации приема более-менее моментальных платежей приходят на ум в первую очередь? Лично мне только что пришли на ум сразу три:
    • смс
    • пластиковые карты
    • электронные деньги
    У каждого метода свои достоинства и свои недостатки.
    Платежи через смс — большая комиссия, но зато мобильник почти у каждого пользователя.
    Пластиковые карты — недостаточно распространены (да, да, жители Дефолт-Сити, за МКАДом тоже есть жизнь, готовая платить!), зато комиссия минимальная.
    Электронные деньги — множество разных систем, технические и юридические трудности подключения, зато и аудитория большая! А уж способов пополнения!

    Не останавливаясь в этой статье на первых двух методах, хочу поговорить об организации приема на сайте электронных валют. Таких как ВебМани, Яндекс.Деньги, Деньги@Mail.Ru и им подобных. Реализация работы в каждом конкретном случае нас не волнует, об этом можно почитать и в документации к этим платежным системам (ПС), и в различного рода историях успеха и неудач.

    Основная мысль, которая должна возникнуть после прочтения статьи (и надеюсь, возникнет) — правильно спроектировав систему приема платежей, подключать каждую новую систему не составит труда.

    Сразу оговорюсь, дальше под «счетом» я буду понимать не account, а скорее invoice. И для удобства, чтобы не путаться между счетом пользователя, который содержит сведения о платежах, размер платежного баланса пользователя итп, и счетом на оплату чего-либо, последний буду называть «заявкой» или «заказом».

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

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


    Раз зашла речь о платежах, то понятное дело, для учета платежей/заявок пользователя понадобится какой-то биллинг. Он может быть сколь угодно сложным или простым, для нас он может быть «черным ящиком»: от него нам понадобится всего две вещи: сумма заявки и ее номер.
    Думаю, не стоит специально рассуждать, почему этот номер должен быть уникальным, правда?
    Остальные данные от биллинга (например, какое-то текстовое описание услуги) — опциональны.

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

    Итак, начнем с общей архитектуры.

    Как это не покажется странным, рецепт архитектуры системы приема платежей по описанному сценарию очень и очень прост. Нам потребуется:

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

    Теперь подробнее о каждой из частей.

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

    Читатели, уже узнавшие слова «нормализация» и «реляционная база данных», возразят, чтобы таблиц должно быть больше, но я утверждаю, что достаточно одной.

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

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

    4. Веб-интерфейс.
    Для чего он нужен, понятно — чтобы вывести пользователю информацию о заказе и чтобы пользователь смог нажать на кнопку «Оплатить».

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

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

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

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


    Как же изменится описанный сценарий работы в новой терминологии?

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

    Веб-интерфейс выводит список доступных платежных систем и информацию о платеже.
    Пользователь жмет «Оплатить», создается заявка со статусом «новая», информация о ней попадает в очередь. Пользователю в этот момент выдаем сообщение «Ща всё будет, подожди» и проверяем время от времени статус заявки. Вот тут понадобятся те же данные о заявке в JSON — пока мы рисуем пользователю на экране всякие часики, прогрессбары итп, с помощью AJAX опрашиваем очередь о статусе заявки.

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


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

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

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

    5. изменение статуса заявки в нашей системе, оказание услуги пользователю.
    Как только статус поменялся, в зависимости от ответа платежной системы диспетчер помечает заявку как «оплаченная» или «отклоненная». Больше она диспетчеру не попадет. Теперь фоновые скрипты биллинга получат информацию, что счет оплачен и окажут пользователю заказанную услугу.

    Чем хороша описанная система?

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

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

    3. Она проста.
    Подключение новой платежной системы — всего лишь добавление новой библиотеки, которая должна уметь всего 4 вещи, описанные выше.

    Конкретные детали реализации я не озвучиваю в этой статье — инструменты неважны.

    Это может быть Perl или PHP, или Питон для веба/работы с БД.
    Это может быть MySQL, или SQLite, или Oracle, или PosgreSQL для организации очереди.
    Это может быть file_get_contents(), LWP::UserAgent или CURL для работы с HTTP.
    Вы можете увеличивать интервал опроса статуса заявки в платежной системе вдвое. Можете в 3.14159…

    Реализация — за вами.

    upd: Полный текст (в том числе со схемами и дополнениями) выложен у меня на сайте
    Метки:
    Поделиться публикацией
    Похожие публикации
    Комментарии 76
    • –1
      Спасибо, очень интересно:)
      • +8
        На мой взгляд пользователей карт на порядок больше, чем пользователей электронных систем.
        Например, карту можно открыть в любом банке за 15 минут.
        А где в провинции пополнить кошелек WebMoney? То-то и оно.
        • +4
          Через терминалы ОСМП, например.
          • +3
            В 2006 году я обегал весь город в поисках терминала, в котором была бы платежная система вебмани — бесполезно. Оплатил с помощью предприятия ада — сбербанка, оплата шла неделю :(

            Потом появился перевод «контакт»
            • +2
              тем не менее сейчас на дворе 2009 год заканчивается и терминалов с wm, яд и тп — как грязи… более того хорошо поискав можно найти даже с 0% комиссией терминала.
              • +1
                Можно… но не везде и далеко не везде :)
                • 0
                  а терминалы киви есть почти везде. лучit на прямую подключить.
            • 0
              А чего же саму систему ОСМП и QIWI не включили в обзор?

              Динамика платежей в интернет-магазины через «Личный Кабинет QIWI»за последние месяцы впечатляет?
              • 0
                С какой целью?
                В описанную схему ОСМП не вписывается, в качестве моментальной системы оплаты — тоже.
                Всё равно придется переться куда-то еще.
                Про осмп написано в полной версии статьи, где и первый способ взаимодействия описан.
                • 0
                  Почему не вписывается в качестве моментальной оплаты? Куда переться? Не понимаю? Или чтобы пополнить ВМ переться не нужно?
                  • 0
                    А Вы про личный кабинет, доступный через Инет, или про терминалы?
                    • 0
                      В первую очередь про оплату выставленных счетов в терминалах QIWI.
                      • 0
                        Ну так это ж надо идти к теминалу и вводить туда денежку.
                        Это уже не моментально.
                        • 0
                          Ну тогда моментально это СМС и банковские карты. Все остальное нужно где-то пополнять:)

                          Есть еще вариант — это оплата счетов с баланса Билайн: habrahabr.ru/company/qiwi/blog/70238/
                          Но это вновь ограничение, что делать другим пользователям?
                          • 0
                            Моментально — это не выходить из дома при покупке.
                            И в случае смс, и в случае карт, и в случае денег, конечно, есть случаи, когда выходить придется:

                            sms — пополнить счет, если баланс нулевой
                            карта — пополнить счет, если баланс нулевой, или получить новую карту, если старая проэкспайрилась
                            деньги — пополнить счет, если баланс нулевой.

                            Но если со счетом всё хорошо, выходить никуда не потребуется, в отличие от ОСМП или Сбербанка, где выходить придется всегда.
                            • 0
                              Но баланс Личного Кабинета QIWI тоже можно пополнить заранее. То есть и есть электронные деньги:)
                • 0
                  наверное потому же, почему и freecash :)
              • +2
                Но в целом, конечно, хорошо уметь принимать и пластик.
                Чем больше методов (я не беру всякую экзотику), тем легче «окучить» пользователя и побудить его оплатить что-либо.
                • +1
                  здесь главный момент — доверие магазину
                  платить кредиткой на незнакомом сайте обычно не очень-то хочется
                  к платежным системам в этом плане доверия больше — на продавца всегда можно пожаловаться
                  • +2
                    Сама оплата обычно производится на сайте платежной системы, того же Assist-а, например. По крайней мере, когда я платил, было так. Плюс к этому, у банков, как правило, существует возможность сделать ряд платежей непосредственно на сайте банка. Я, например, уже не помню, когда я пополнял счет мобильного телефона или оплачивал интернет где-нибудь за пределами личного кабинета банка.

                    В регионах с картами тоже все в порядке (хотя, конечно, за все города ручаться не могу). Пользуюсь пластиком уже лет 6 (4 из них в регионах, где собственно и получал свой первый пластик). Вебмани и яндекс-деньги, это, безусловно, хорошо. Но, на мой взгляд, у пользователя должна быть возможность оплаты пластиковой картой. Иначе просто можно лишиться клиентов, когда покупатель не захочет совершать лишних телодвижений и уйдет с сайта.
                  • 0
                    Имеется ввиду, что эти электронные деньги в сети же и зарабатываются, там же и тратятся…

                    В общем и целом не плохо бы посмотреть на вариант реализации, хотя бы для одной платежной системы.
                    • 0
                      В с картой Альфы вы можете переводить деньги с карточки на ЯД и обратно. С ЯДа на Вебмани через любой обменник. Да, в итоге 2 операции, но делаются за пару минут и деньги переводятся моментально.Комиссия примерно 4% (2+ ~2) за вывод, за ввод только комиссия пеервода ЯД в Вебмани.
                      • 0
                        Да, это так. Но зачем заставлять пользователя совершать эти дополнительные операции? С той же картой Альфы (если уж речь зашла о безопасности) вы можете самостоятельно сгенерировать себе виртуальную карту и платить ей, не опасаясь, что у вас украдут деньги с основного счета.
                      • +1
                        Карту, позволяющую осуществлять интернет платежи за 15 минут? За пределами Москвы? Год назад я бы сказал — за 2-4 недели… :( Сейчас всё стало настолько сильно лучше?
                        • –1
                          сейчас почти везде можно платить самой простой — visa electron, правда сколько времени её оформлять нужно не помню
                          • +1
                            очень сильно некоторыми из электронов очень сильно некоторых банков.
                            • 0
                              хм, видимо мне просто повезло)
                        • 0
                          Откройте с сбербанке карту за 15 мин
                          • 0
                            Карт много — осознанных пользователей менее 4%.
                          • +2
                            Сильно не хватает графической схемы.
                            • 0
                              Не хватает диаграммы/схемы для полной картины.
                              • +1
                                да тут всё понятно, в общем ОБ — это твоя ПС (платёжная система), а БПС — проксики к внешним платёжным системам.

                                Т.о., резюмируя вышенаписанное, можно написать API взаимодействия с вашей ПС (ОБ), и получим ещё одну мегасуперпуперофигенную платёжную систему, которая умеет платить куда угодно.
                                • +1
                                  По сути да.
                                  Описанные методы взаимодействия с ПС и организация обработки характерны не столько для Магазинов, сколько для агрегаторов вроде Robox'а.
                                • 0
                                  Если кто-то не нашел здесь того, что искал, попробуйте просто RoboxChange
                                  • 0
                                    Терминалы ОСМП подключаются за 10 минут по стандартному протоколу, т.е. если на сайте у пользователя есть баланс, то к списку видов ПС можно приписать еще и терминалы.
                                    • 0
                                      ОСМП работает по первому методу — с сообщением результатов операции на сайт Магазина.

                                      Я не описывал этот метод, по сути он сводится к еще одной функции веб-интерфейса: определение какой терминал сообщает об оплате, вызове библиотеки, которая обработает этот вызов и вернет номер заявки в нашей системе (если мы опять организовали очередь). Далее библиотека работы с заявками поменяет статус. Фсё.
                                      • 0
                                        Вообще платежки представляют собой как минимум трехсторонний обмен данными — сайт платежке передает данные о счете, количестве сайтовых у.е. (игровой валюты, уникальной валюты магазина или просто рубли) и переходит на страницу платежки. Затем платежка сообщает сайту о том, что счет был оплачен (если оплачен, если неоплачен, не хватило денег и проч. должен быть переход на страницу ошибки).

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

                                        А ОСМП действует в двустороннем режиме — от терминала уходят данные о том сколько денег и на какой аккаунт производится перевод, от вашего сайта идет ответ о том, что деньги зачислены / ошибка транзакции / аккаунт не найден и проч.
                                        • 0
                                          А ОСМП действует в двустороннем режиме

                                          Именно это я и понимаю под «первым методом» — когда обмен информацией начинается с платежной системы.
                                    • 0
                                      «да, да, жители Дефолт-Сити, за МКАДом тоже есть жизнь, готовая платить!» — а банки за МКАДом что, перестают существовать и выпускать пластиковые карты?
                                      • +1
                                        Тут дело не в том, выпускают ли они карты.
                                        А в том как ими пользуются люди.
                                        Для многих если карта и есть, то, как правило, — это способ получить зарплату и обналичить в банкомате.

                                        У меня, к сожалению, нет данных в каких регионах люди платят картами лучше или хуже.
                                        За такой статистикой нужно к платежным системам обращаться или к тому же Киберплату, Хронопэю или Ассисту.

                                        Впрочем, статья-то не об этом, правда?
                                        • –1
                                          не об этом — я просто к тому что преуменьшать роль карт не стоит. ну и то что люди не знают/не хотят ими пользоваться никак не связано с тем, находятся они вне или внутри мкада — карты ведь у всех одинаковые (условно).
                                          а статистику по регионам таки было бы занятно посмотреть.
                                        • –1
                                          VISA ELECTRON, GOLD и Маэстро не помню какие тоже могут являться способом оплаты в интернете (например, посредством платеж.ру).
                                          Такие карты выдаются и в Замкадье.
                                          • +1
                                            визами всеми кроме электрона обычно можно оплачивать в интернете, а где-то писали что некоторыми электронами (некоторых банков) тоже можно. Насчёт маэстро не знаю. Вообще, тут много от конкретного банка зависит — у меня например виза классик «открытия» (экс-РБР) не работает в paypal, там я пользую визу виртуон от «возрождения».
                                        • +3
                                          Уже вторая подобная статья… Я вот не совсем понимаю — вебмани и яндекс.деньги и так распространены. Процедуры внедрения их на свои сайты уже отлажены годами и описаны много где. Зачем про это писать?)
                                          Про оплату через смс знают меньше народу, про оплату пластиковыми картами — еще меньше. А спрос на эти технологии при этом растет.
                                          Думаю, ни с какими платежными системами проблем не будет, потому что они сами заинтересованы в сотрудничестве и оказывают посильную поддержку.
                                          Но если уж так хотите написать, пишите лучше про PayPal, Chronopay и Assist (а можно и про то, как организовать свой акцептор платежей через пластиковые карты). Как клиенту, мне эти способы оплаты нравятся намного больше, а как программист, я еще недавно не знал, как внедрить их в свои приложения, и, в силу природной лени, избегал работы с ними.
                                          • 0
                                            Вы не знали, как внедрить карты, а кто-то не знает, как правильно спроектировать подобную систему и в итоге для каждой новой платежной системы Магазин пишет свой костыль. Никто не знает всего, правда?
                                          • 0
                                            спасибо за статью, интересно почитать. а вот про диаграмму — согласен, не помешало бы
                                            • +1
                                              Заголовок статьи не соответствует содержанию, однако.
                                              • +1
                                                Вполне жизненно, я бы отдельно вывел модуль конвертации в некую внутреннюю условную единицу — ибо платят не только в разной валюте которую каким-то макаром биллинг должен уметь «оценить», но и с разными накладными расходами — от реальной стоимости SMS владелец сайта может получать 10% и соответсвенно система как-то должна учесть этот момент.
                                                Ещё проблемной зоной является недо-апи (API) многих систем которые не передают владельцу полного контроля над выводимыми сообщениями. Стандартный пример — SMS биллинги, которые информацию о тарифах, выборе страны и прочем до конца не автоматизируют и тогда выстроить единую «библиотеку веб-интерфейса» становится проблематичным, да и вообще получается не единая библиотека
                                                Так же надо учитывать специфику работы с балансом (ведения списка списаний, сальдо) и одноразовыми покупками, когда у пользователя в системе нету баланса а есть лишь на каждый конкретный продукт эдакий BuyNow, тогда и база выглядеть будет несколько проще, но сложнее будут выглядеть правила для товаров. Отдельно возможно стоит выделить функционал подписок (регулярных ребиллов), не всегда прозрачный (например в случае с SMS подписками).
                                                Также биллинг бывает ручной, подразумевающий ввод данных оператором а не клиентом/API, так что возможно надо пилить не только клиентский но и служебный интерфейсы. Вообще надо заметить универсальный биллинг наверное сильно сложен в реализации и к этому не стоит стремиться — делать надо то что актуально плюс оглядка на общую структуру, но не универсализировать всё — иногда мне кажется что 10 таблиц чётко заточенных и 10 обработчиков очень понятных будет лучше чем один мегавраппер, универсальный диспетчер создающий один слой абстракции для 10 очень разных хендлеров. Имхо
                                                • +1
                                                  Достаточно актуальный материал, но хотелось бы так же услышать о пока что нераспространенной у нас оплате через банковские карты.
                                                  • 0
                                                    Читатели, уже узнавшие слова «нормализация» и «реляционная база данных», возразят, чтобы таблиц должно быть больше, но я утверждаю, что достаточно одной.
                                                    а как же статусы хранить? полность слова «Оплачено» и т.п.? или циферки 1, 2, 3, а в коде писать:
                                                    if (status == 1) print «Оплачено»
                                                    Что-то быдлокодингом попахивает ;)
                                                    А историю статусов хранить не нужно? Например, если заявка отменена, кто отменил (демон, администратор или пользователь), переходил ли пользователь к оплате и т.п., что может пригодиться для саппорта при разрешении конфликтов.
                                                    • 0
                                                      Посмею не согласится, в базе данных эффективнее хранить цифровые коды статусов, для уменьшения размера бд, и для более быстрой выборки. И если нам потребуется название статусов, можно их получать с помощью LEFT JOIN из другой базы.
                                                      Этот метод более выгодный также если потребуется переделать скрипты (добавить, переименовать или удалить статусы)
                                                      По крайней мере так рекомендуется в одной из книг по MySQL.
                                                      • 0
                                                        Прошу прощения, не до конца понял, ты прав, я это же самое практически сказал.
                                                      • 0
                                                        а как же статусы хранить? полность слова «Оплачено» и т.п.? или циферки 1, 2, 3,

                                                        ну тут можно enum'ы завести
                                                        А историю статусов хранить не нужно?

                                                        Вряд ли для вебмагаза это нужно. Тут достточно будет логов. А статусы, что статусы? Добавьте ещё один статус: Ошибка, тогда будет понятно, что пользователь переходил к оплате, но что-то не срослось.
                                                        • 0
                                                          ну тут можно enum'ы завести
                                                          они есть не во всех субд
                                                          Тут достточно будет логов
                                                          уже вижу, как девочка из поддержки лезет в серверные логи выяснять, почему отменилась заявка :)
                                                          • 0
                                                            а кто говорил про перечисления в БД? :)
                                                            А для девочки можно написать тулу, которая логи в понятном ей виде выводит.
                                                            • 0
                                                              ну или отчёт на вебформе, тут как вам будет угодно
                                                              • 0
                                                                в общем, я это всё к тому, что можно обойтись одной таблицей, и никакого быдлокода не будет
                                                          • +1
                                                            а как же статусы хранить?

                                                            В очереди, например, char(2). Почти 1300 статусов хватит за глаза.
                                                            Пары символов достаточно, чтобы примерно понять статус заявки, если приспичит сделать прямой SELECT.

                                                            а в коде писать

                                                            Нет, в коде писать

                                                            print $status_list->{ $status } || 'Неизвестный статус';

                                                            Что-то быдлокодингом попахивает

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

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

                                                            Тем более, этих статусов по пальцам: «новая», «доставлена в ПС», «можно платить», «какая-то ошибка» (2-3 кода за глаза, дальше все равно в логи диспетчера лезть), «отказ платить», «отмена администратором», «устарела», «оплачена», «услуга оказана». Все остальные статусы — уже излишества. Итого 9-11 кодов максимум. И ради этого городить огород с таблицами, джойнами?

                                                            А историю статусов хранить не нужно?

                                                            Я считаю, что нет.
                                                            Там цепочка простая и часто однозначная:
                                                            новая → в ожидании → ошибка
                                                            или
                                                            новая → в ожидании → готово → изменился статус → выполнили услугу.

                                                            Вот логи диспетчера нужны обязательно.
                                                            Включая тексты ответов платежной системы.
                                                          • 0
                                                            На самом деле реальность доставляет нам ещо нюансы:
                                                            1) обрывы связи во время платежей — надо не потерять деньги и точно знать статус платежа в другой ПС если платеж совершается туда
                                                            2) время обработки может быть варьироваться очень сильно — от долей секунд до десятков минут, при этом тоже надо статус получить.
                                                            3) проверки балансов клиентов при платеже с учетом п.1 и п.2
                                                            4) отмены платежей

                                                            То, что Вы описали — это ясно даже школьнику, который провел пару платежей через любую ПС. Реальность — куда суровее ;)) Это я могу сказать, как прошедший все эти этапы — с проектирования до внедрения подобной ПС.
                                                            • 0
                                                              пункт 1 решается просто: создаем у себя платёж, сохраняем, тычемся в ВПС, проводим его там. А потом до посинения проверяем статус нашего платежа в ВПС.
                                                              пункт 2: время обработки не важно, чел написал, что будет там демон или крон (в винде сервис), который раз в N секунд проверяет статус. Если статус поменялся, меняем наш платёж в базе.
                                                              пункт 3: проверке до фени, чё там с пунктом 1 и 2. Читаем наши платежи из базы на текущий момент и показываем пользователю.
                                                              пункт 4: см. пункт 1.
                                                              • 0
                                                                Именно так, браво!
                                                            • 0
                                                              Не понял, что делает «Диспетчер обработки очереди»? Все ее функции выполняют остальные части.
                                                              • 0
                                                                По сути, диспетчер действительно просто объединяет в себе все части кроме веб-интерфейса.
                                                                Плюс делает какие-то доп.вещи, например, пишет логи ответов от платежных систем в едином формате.

                                                                В качестве аналогии приведу пример: есть наковальня, есть молот, есть изделие. Диспетчер — это кузнец. Или кузнецы, в зависимости от нагрузки.
                                                              • 0
                                                                У кого есть опыт внедрения cyberplat.ru в интернет-магазин, помогите пожалуйста, так как их техподдержка меня игнорирует
                                                                • 0
                                                                  вы через апи их тычетесь, или в базу ползаете?
                                                                • 0
                                                                  Чё-то как-то…

                                                                  «правильно спроектировав систему приема платежей, подключать каждую новую систему не составит труда»
                                                                  Какие из платёжных систем на рынке сейчас работают по первой схеме («Счёт на сайте->Редирект на сайт ПС->...->платёж->Редирект обратно->ждём от ПС весточки про платёж»), а какие — по предложенной второй?
                                                                  Меня терзают смутные сомнения, что первых больше и они шире распространены.

                                                                  Заточив на сайте систему работы с платежами под работу с ПС «второго рода» подключить ПС «первого рода» невозможно.
                                                                  При этом работа с ПС «второго рода» требует от сайта магазина наличия механизмов, которые позволят самому сайту инициировать подключение к внешнему ресурсу.
                                                                  И по сути получается, что такая ПС перекладывает затраты на разработку на плечи своих клиентов, как мне кажется…
                                                                  • 0
                                                                    Какие из платёжных систем на рынке сейчас работают по первой схеме

                                                                    Работают только по второй или умеют работать и так, и так?
                                                                    Если последнее, то это и PayPal, и MoneyMail, и OSMP, например.

                                                                    Заточив на сайте систему работы с платежами под работу с ПС «второго рода» подключить ПС «первого рода» невозможно.

                                                                    Это не так. Чтобы началась работа с ПС «первого рода» достаточно:

                                                                    1. Добавить новый статус а-ля «Пользователь ушел в ПС, но проверять статус не надо», который не будет обрабатываться диспетчером.

                                                                    2. Добавить в БПС функцию разбора HTTP-запроса от ПС «check» и «pay» фаз с выдачей номера заявки в нашей системе и формированием корректного ответа этой ПС.

                                                                    3. Добавить в веб-интерфейс функцию обращения к ОБ для получения номера из 2.

                                                                    В этом случае на check определяем номер заявки, получаем статус заявки, если ее можно оплатить, возвращаем ПС ответ «Бери деньги с пользователя», сгенерированный в БПС.

                                                                    На pay — определяем номер заявки и меняем статус, если это возможно.

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

                                                                    И по сути получается, что такая ПС перекладывает затраты на разработку на плечи своих клиентов, как мне кажется…

                                                                    Так это смотря какая гибкость нужна сайту для работы с ПС.
                                                                    Если она не нужна — имеем работу «первого рода» без диспетчера и с 2-3 статусами.
                                                                    Если нужна — второй род, диспетчер, 10 статусов.
                                                                    Архитектура одна и та же

                                                                    • 0
                                                                      То есть PayPal, MoneyMail и OSMP прекрасно умеют работать по первой схеме, если я тебя правильно понял?
                                                                      А если так, то зачем же вообще городить работу по «второй схеме»? Для чего?

                                                                      Если у магазина уже подключена ПС «первого рода» (а это скорее всего вебмани, яндекс или какой-нить киберплат), то зачем ему городить огород, когда можно сказать новой ПС «— Включайте первую схему, будем работать по ней»???

                                                                      Под «невозможно» имелось в виду без переделок. Новые статусы, новые фунции — это всё переделки.

                                                                      Так это смотря какая гибкость нужна сайту для работы с ПС


                                                                      Ты так и не ответил, какие системы могут работать только по «второй схеме» и не умеют по первой.

                                                                      И вообще, в каком случае работа по второй схеме вообще нужна магазину?
                                                                      Потому как, на мой взгляд, «первая схема» абсолютно прозрачна и логична: я (магазин) делаю счёт на оплату->человек идёт в ПС и платит->ПС мне говорит удалось оплатить или нет, и возвращает человека на соответствующий урл моего мазагина->profit!

                                                                      Так в какой же ситуации нужна «вторая схема»?
                                                                      • 0
                                                                        А если так, то зачем же вообще городить работу по «второй схеме»? Для чего?

                                                                        Во-первых, для большей гибкости.
                                                                        Архитектурно первый способ от второго отличается только отсутствием диспетчера.
                                                                        И там, и там придется реализовывать остальные 5 компонентов.
                                                                        Первая — частный случай второй. Но не наоборот.
                                                                        Соответственно, реализовав описанную схему, мы сразу же фактически реализуем первую.
                                                                        Но реализовав первую, вторую придется реализовывать отдельно.
                                                                        Хорошо, если при этом пустят на единые рельсы, а не добавят костыль сбоку, как это часто случается.

                                                                        Во-вторых, не все функции платежных систем доступны только по первой схеме.
                                                                        Например, выставление счета (в терминологии платежной системы) пользователю возможно только, если инициатор — магазин. Это и для Пэйпала, и для ОСМП, и для Манимэйла и для других платежных систем характерно.

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

                                                                        Если у магазина уже подключена

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

                                                                        Под «невозможно» имелось в виду без переделок. Новые статусы, новые фунции — это всё переделки.


                                                                        Статус по умолчанию при создании заявки — это 6 байт в модуле работы со счетами:

                                                                        $status ||= <код_по_умолчанию>

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

                                                                        Доделки минимальны, они не влияют на архитектуру в целом.

                                                                        Резюмируя:
                                                                        1. отличия первой схемы от второй — минимальны.
                                                                        2. вторая — общий случай первой.
                                                                        3. Нужна простота — первая. Нужна гибкость — вторая.
                                                                  • 0
                                                                    … вдвое. Можете в 3.14519…

                                                                    Побуду занудой ^_^, просто в глаза бросилось… думаю, правильно 3.14159…
                                                                    • 0
                                                                      Я ж не написал, что речь о числе пи :)
                                                                      Но вообще, да, спасибо
                                                                    • 0
                                                                      Вообще, было бы интереснее все-таки прочесть про реализацию с нуля. Допустим, какие ньюансы при размещении платежной системы от Яндекс, WebMoney и других компаний. Возможно ли это для физических лиц… Ну и соответственно те мелочи, с помощью которых можно избежать ошибок при реализации данного функционала на сайте…

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

                                                                        теперь интересно узнать, как это все сделать

                                                                        Что именно? Какие поля нужны в таблице очереди или что использовать для демонизации диспетчера?
                                                                        • 0
                                                                          Скажем так, хотелось бы услышать что-нибудь про это:
                                                                          Как грамотно написать биллинг — речь для целой группы статей, поэтому сейчас не о нем.


                                                                          Если конечно есть возможность)
                                                                          • 0
                                                                            Ближайшие несколько статей у меня выйдут на несколько другие темы, но потом может и до биллинга доберусь.
                                                                      • 0
                                                                        всем, кто заинтересован в снижении операторской комиссии за платные СМС предлагаю подписаться под обращением к президенту: community.livejournal.com/mobile_commerce

                                                                        Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.