Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 76
Спасибо, очень интересно:)
На мой взгляд пользователей карт на порядок больше, чем пользователей электронных систем.
Например, карту можно открыть в любом банке за 15 минут.
А где в провинции пополнить кошелек WebMoney? То-то и оно.
Например, карту можно открыть в любом банке за 15 минут.
А где в провинции пополнить кошелек WebMoney? То-то и оно.
Через терминалы ОСМП, например.
В 2006 году я обегал весь город в поисках терминала, в котором была бы платежная система вебмани — бесполезно. Оплатил с помощью предприятия ада — сбербанка, оплата шла неделю :(
Потом появился перевод «контакт»
Потом появился перевод «контакт»
А чего же саму систему ОСМП и QIWI не включили в обзор?
Динамика платежей в интернет-магазины через «Личный Кабинет QIWI»за последние месяцы впечатляет?
Динамика платежей в интернет-магазины через «Личный Кабинет QIWI»за последние месяцы впечатляет?
С какой целью?
В описанную схему ОСМП не вписывается, в качестве моментальной системы оплаты — тоже.
Всё равно придется переться куда-то еще.
Про осмп написано в полной версии статьи, где и первый способ взаимодействия описан.
В описанную схему ОСМП не вписывается, в качестве моментальной системы оплаты — тоже.
Всё равно придется переться куда-то еще.
Про осмп написано в полной версии статьи, где и первый способ взаимодействия описан.
Почему не вписывается в качестве моментальной оплаты? Куда переться? Не понимаю? Или чтобы пополнить ВМ переться не нужно?
А Вы про личный кабинет, доступный через Инет, или про терминалы?
В первую очередь про оплату выставленных счетов в терминалах QIWI.
Ну так это ж надо идти к теминалу и вводить туда денежку.
Это уже не моментально.
Это уже не моментально.
Ну тогда моментально это СМС и банковские карты. Все остальное нужно где-то пополнять:)
Есть еще вариант — это оплата счетов с баланса Билайн: habrahabr.ru/company/qiwi/blog/70238/
Но это вновь ограничение, что делать другим пользователям?
Есть еще вариант — это оплата счетов с баланса Билайн: habrahabr.ru/company/qiwi/blog/70238/
Но это вновь ограничение, что делать другим пользователям?
Моментально — это не выходить из дома при покупке.
И в случае смс, и в случае карт, и в случае денег, конечно, есть случаи, когда выходить придется:
sms — пополнить счет, если баланс нулевой
карта — пополнить счет, если баланс нулевой, или получить новую карту, если старая проэкспайрилась
деньги — пополнить счет, если баланс нулевой.
Но если со счетом всё хорошо, выходить никуда не потребуется, в отличие от ОСМП или Сбербанка, где выходить придется всегда.
И в случае смс, и в случае карт, и в случае денег, конечно, есть случаи, когда выходить придется:
sms — пополнить счет, если баланс нулевой
карта — пополнить счет, если баланс нулевой, или получить новую карту, если старая проэкспайрилась
деньги — пополнить счет, если баланс нулевой.
Но если со счетом всё хорошо, выходить никуда не потребуется, в отличие от ОСМП или Сбербанка, где выходить придется всегда.
наверное потому же, почему и freecash :)
Но в целом, конечно, хорошо уметь принимать и пластик.
Чем больше методов (я не беру всякую экзотику), тем легче «окучить» пользователя и побудить его оплатить что-либо.
Чем больше методов (я не беру всякую экзотику), тем легче «окучить» пользователя и побудить его оплатить что-либо.
здесь главный момент — доверие магазину
платить кредиткой на незнакомом сайте обычно не очень-то хочется
к платежным системам в этом плане доверия больше — на продавца всегда можно пожаловаться
платить кредиткой на незнакомом сайте обычно не очень-то хочется
к платежным системам в этом плане доверия больше — на продавца всегда можно пожаловаться
Сама оплата обычно производится на сайте платежной системы, того же Assist-а, например. По крайней мере, когда я платил, было так. Плюс к этому, у банков, как правило, существует возможность сделать ряд платежей непосредственно на сайте банка. Я, например, уже не помню, когда я пополнял счет мобильного телефона или оплачивал интернет где-нибудь за пределами личного кабинета банка.
В регионах с картами тоже все в порядке (хотя, конечно, за все города ручаться не могу). Пользуюсь пластиком уже лет 6 (4 из них в регионах, где собственно и получал свой первый пластик). Вебмани и яндекс-деньги, это, безусловно, хорошо. Но, на мой взгляд, у пользователя должна быть возможность оплаты пластиковой картой. Иначе просто можно лишиться клиентов, когда покупатель не захочет совершать лишних телодвижений и уйдет с сайта.
В регионах с картами тоже все в порядке (хотя, конечно, за все города ручаться не могу). Пользуюсь пластиком уже лет 6 (4 из них в регионах, где собственно и получал свой первый пластик). Вебмани и яндекс-деньги, это, безусловно, хорошо. Но, на мой взгляд, у пользователя должна быть возможность оплаты пластиковой картой. Иначе просто можно лишиться клиентов, когда покупатель не захочет совершать лишних телодвижений и уйдет с сайта.
Имеется ввиду, что эти электронные деньги в сети же и зарабатываются, там же и тратятся…
В общем и целом не плохо бы посмотреть на вариант реализации, хотя бы для одной платежной системы.
В общем и целом не плохо бы посмотреть на вариант реализации, хотя бы для одной платежной системы.
В с картой Альфы вы можете переводить деньги с карточки на ЯД и обратно. С ЯДа на Вебмани через любой обменник. Да, в итоге 2 операции, но делаются за пару минут и деньги переводятся моментально.Комиссия примерно 4% (2+ ~2) за вывод, за ввод только комиссия пеервода ЯД в Вебмани.
Карту, позволяющую осуществлять интернет платежи за 15 минут? За пределами Москвы? Год назад я бы сказал — за 2-4 недели… :( Сейчас всё стало настолько сильно лучше?
Откройте с сбербанке карту за 15 мин
Карт много — осознанных пользователей менее 4%.
Сильно не хватает графической схемы.
Не хватает диаграммы/схемы для полной картины.
да тут всё понятно, в общем ОБ — это твоя ПС (платёжная система), а БПС — проксики к внешним платёжным системам.
Т.о., резюмируя вышенаписанное, можно написать API взаимодействия с вашей ПС (ОБ), и получим ещё одну мегасуперпуперофигенную платёжную систему, которая умеет платить куда угодно.
Т.о., резюмируя вышенаписанное, можно написать API взаимодействия с вашей ПС (ОБ), и получим ещё одну мегасуперпуперофигенную платёжную систему, которая умеет платить куда угодно.
Если кто-то не нашел здесь того, что искал, попробуйте просто RoboxChange
Терминалы ОСМП подключаются за 10 минут по стандартному протоколу, т.е. если на сайте у пользователя есть баланс, то к списку видов ПС можно приписать еще и терминалы.
ОСМП работает по первому методу — с сообщением результатов операции на сайт Магазина.
Я не описывал этот метод, по сути он сводится к еще одной функции веб-интерфейса: определение какой терминал сообщает об оплате, вызове библиотеки, которая обработает этот вызов и вернет номер заявки в нашей системе (если мы опять организовали очередь). Далее библиотека работы с заявками поменяет статус. Фсё.
Я не описывал этот метод, по сути он сводится к еще одной функции веб-интерфейса: определение какой терминал сообщает об оплате, вызове библиотеки, которая обработает этот вызов и вернет номер заявки в нашей системе (если мы опять организовали очередь). Далее библиотека работы с заявками поменяет статус. Фсё.
Вообще платежки представляют собой как минимум трехсторонний обмен данными — сайт платежке передает данные о счете, количестве сайтовых у.е. (игровой валюты, уникальной валюты магазина или просто рубли) и переходит на страницу платежки. Затем платежка сообщает сайту о том, что счет был оплачен (если оплачен, если неоплачен, не хватило денег и проч. должен быть переход на страницу ошибки).
Второй вариант — платежка сообщает о факте перевода денег позже. Они могут высылать все платежи, или непроакцептованные вами платежи, или платежи, которые являются новыми за время, которое прошло с момента предыдущего уведомления. Последний способ сразу должен быть отметен, потому что если ваш сайт не принял данные о том, что платежи учлись, у вас будут расхождения в балансах.
А ОСМП действует в двустороннем режиме — от терминала уходят данные о том сколько денег и на какой аккаунт производится перевод, от вашего сайта идет ответ о том, что деньги зачислены / ошибка транзакции / аккаунт не найден и проч.
Второй вариант — платежка сообщает о факте перевода денег позже. Они могут высылать все платежи, или непроакцептованные вами платежи, или платежи, которые являются новыми за время, которое прошло с момента предыдущего уведомления. Последний способ сразу должен быть отметен, потому что если ваш сайт не принял данные о том, что платежи учлись, у вас будут расхождения в балансах.
А ОСМП действует в двустороннем режиме — от терминала уходят данные о том сколько денег и на какой аккаунт производится перевод, от вашего сайта идет ответ о том, что деньги зачислены / ошибка транзакции / аккаунт не найден и проч.
«да, да, жители Дефолт-Сити, за МКАДом тоже есть жизнь, готовая платить!» — а банки за МКАДом что, перестают существовать и выпускать пластиковые карты?
Тут дело не в том, выпускают ли они карты.
А в том как ими пользуются люди.
Для многих если карта и есть, то, как правило, — это способ получить зарплату и обналичить в банкомате.
У меня, к сожалению, нет данных в каких регионах люди платят картами лучше или хуже.
За такой статистикой нужно к платежным системам обращаться или к тому же Киберплату, Хронопэю или Ассисту.
Впрочем, статья-то не об этом, правда?
А в том как ими пользуются люди.
Для многих если карта и есть, то, как правило, — это способ получить зарплату и обналичить в банкомате.
У меня, к сожалению, нет данных в каких регионах люди платят картами лучше или хуже.
За такой статистикой нужно к платежным системам обращаться или к тому же Киберплату, Хронопэю или Ассисту.
Впрочем, статья-то не об этом, правда?
VISA ELECTRON, GOLD и Маэстро не помню какие тоже могут являться способом оплаты в интернете (например, посредством платеж.ру).
Такие карты выдаются и в Замкадье.
Такие карты выдаются и в Замкадье.
визами всеми кроме электрона обычно можно оплачивать в интернете, а где-то писали что некоторыми электронами (некоторых банков) тоже можно. Насчёт маэстро не знаю. Вообще, тут много от конкретного банка зависит — у меня например виза классик «открытия» (экс-РБР) не работает в paypal, там я пользую визу виртуон от «возрождения».
Уже вторая подобная статья… Я вот не совсем понимаю — вебмани и яндекс.деньги и так распространены. Процедуры внедрения их на свои сайты уже отлажены годами и описаны много где. Зачем про это писать?)
Про оплату через смс знают меньше народу, про оплату пластиковыми картами — еще меньше. А спрос на эти технологии при этом растет.
Думаю, ни с какими платежными системами проблем не будет, потому что они сами заинтересованы в сотрудничестве и оказывают посильную поддержку.
Но если уж так хотите написать, пишите лучше про PayPal, Chronopay и Assist (а можно и про то, как организовать свой акцептор платежей через пластиковые карты). Как клиенту, мне эти способы оплаты нравятся намного больше, а как программист, я еще недавно не знал, как внедрить их в свои приложения, и, в силу природной лени, избегал работы с ними.
Про оплату через смс знают меньше народу, про оплату пластиковыми картами — еще меньше. А спрос на эти технологии при этом растет.
Думаю, ни с какими платежными системами проблем не будет, потому что они сами заинтересованы в сотрудничестве и оказывают посильную поддержку.
Но если уж так хотите написать, пишите лучше про PayPal, Chronopay и Assist (а можно и про то, как организовать свой акцептор платежей через пластиковые карты). Как клиенту, мне эти способы оплаты нравятся намного больше, а как программист, я еще недавно не знал, как внедрить их в свои приложения, и, в силу природной лени, избегал работы с ними.
спасибо за статью, интересно почитать. а вот про диаграмму — согласен, не помешало бы
Вполне жизненно, я бы отдельно вывел модуль конвертации в некую внутреннюю условную единицу — ибо платят не только в разной валюте которую каким-то макаром биллинг должен уметь «оценить», но и с разными накладными расходами — от реальной стоимости SMS владелец сайта может получать 10% и соответсвенно система как-то должна учесть этот момент.
Ещё проблемной зоной является недо-апи (API) многих систем которые не передают владельцу полного контроля над выводимыми сообщениями. Стандартный пример — SMS биллинги, которые информацию о тарифах, выборе страны и прочем до конца не автоматизируют и тогда выстроить единую «библиотеку веб-интерфейса» становится проблематичным, да и вообще получается не единая библиотека
Так же надо учитывать специфику работы с балансом (ведения списка списаний, сальдо) и одноразовыми покупками, когда у пользователя в системе нету баланса а есть лишь на каждый конкретный продукт эдакий BuyNow, тогда и база выглядеть будет несколько проще, но сложнее будут выглядеть правила для товаров. Отдельно возможно стоит выделить функционал подписок (регулярных ребиллов), не всегда прозрачный (например в случае с SMS подписками).
Также биллинг бывает ручной, подразумевающий ввод данных оператором а не клиентом/API, так что возможно надо пилить не только клиентский но и служебный интерфейсы. Вообще надо заметить универсальный биллинг наверное сильно сложен в реализации и к этому не стоит стремиться — делать надо то что актуально плюс оглядка на общую структуру, но не универсализировать всё — иногда мне кажется что 10 таблиц чётко заточенных и 10 обработчиков очень понятных будет лучше чем один мегавраппер, универсальный диспетчер создающий один слой абстракции для 10 очень разных хендлеров. Имхо
Ещё проблемной зоной является недо-апи (API) многих систем которые не передают владельцу полного контроля над выводимыми сообщениями. Стандартный пример — SMS биллинги, которые информацию о тарифах, выборе страны и прочем до конца не автоматизируют и тогда выстроить единую «библиотеку веб-интерфейса» становится проблематичным, да и вообще получается не единая библиотека
Так же надо учитывать специфику работы с балансом (ведения списка списаний, сальдо) и одноразовыми покупками, когда у пользователя в системе нету баланса а есть лишь на каждый конкретный продукт эдакий BuyNow, тогда и база выглядеть будет несколько проще, но сложнее будут выглядеть правила для товаров. Отдельно возможно стоит выделить функционал подписок (регулярных ребиллов), не всегда прозрачный (например в случае с SMS подписками).
Также биллинг бывает ручной, подразумевающий ввод данных оператором а не клиентом/API, так что возможно надо пилить не только клиентский но и служебный интерфейсы. Вообще надо заметить универсальный биллинг наверное сильно сложен в реализации и к этому не стоит стремиться — делать надо то что актуально плюс оглядка на общую структуру, но не универсализировать всё — иногда мне кажется что 10 таблиц чётко заточенных и 10 обработчиков очень понятных будет лучше чем один мегавраппер, универсальный диспетчер создающий один слой абстракции для 10 очень разных хендлеров. Имхо
Достаточно актуальный материал, но хотелось бы так же услышать о пока что нераспространенной у нас оплате через банковские карты.
Посмею не согласится, в базе данных эффективнее хранить цифровые коды статусов, для уменьшения размера бд, и для более быстрой выборки. И если нам потребуется название статусов, можно их получать с помощью LEFT JOIN из другой базы.
Этот метод более выгодный также если потребуется переделать скрипты (добавить, переименовать или удалить статусы)
По крайней мере так рекомендуется в одной из книг по MySQL.
Этот метод более выгодный также если потребуется переделать скрипты (добавить, переименовать или удалить статусы)
По крайней мере так рекомендуется в одной из книг по MySQL.
а как же статусы хранить? полность слова «Оплачено» и т.п.? или циферки 1, 2, 3,
ну тут можно enum'ы завести
А историю статусов хранить не нужно?
Вряд ли для вебмагаза это нужно. Тут достточно будет логов. А статусы, что статусы? Добавьте ещё один статус: Ошибка, тогда будет понятно, что пользователь переходил к оплате, но что-то не срослось.
а как же статусы хранить?
В очереди, например, char(2). Почти 1300 статусов хватит за глаза.
Пары символов достаточно, чтобы примерно понять статус заявки, если приспичит сделать прямой SELECT.
а в коде писать
Нет, в коде писать
print $status_list->{ $status } || 'Неизвестный статус';Что-то быдлокодингом попахивает
Быдлокодинг — это программирование без включения головы.
Для данных, которые статичны 99% времени жизни проекта, Вы предлагаете плодить сущности в базе. Причем получать эти данные будете исключительно в веб-интерфейс и устанавливать из него же или из диспетчера. Что мешает завести конфиг (функцию, хэш, константы, что угодно), в котором хранить описание статусов и их коды?
Надо запихать статус в базу — взяли из конфига, запихали.
Надо вывести из базы, вывели построчно, в каждой строке заменили на текстовое представление если нужно.
Тем более, этих статусов по пальцам: «новая», «доставлена в ПС», «можно платить», «какая-то ошибка» (2-3 кода за глаза, дальше все равно в логи диспетчера лезть), «отказ платить», «отмена администратором», «устарела», «оплачена», «услуга оказана». Все остальные статусы — уже излишества. Итого 9-11 кодов максимум. И ради этого городить огород с таблицами, джойнами?
А историю статусов хранить не нужно?
Я считаю, что нет.
Там цепочка простая и часто однозначная:
новая → в ожидании → ошибка
или
новая → в ожидании → готово → изменился статус → выполнили услугу.
Вот логи диспетчера нужны обязательно.
Включая тексты ответов платежной системы.
пункт 1 решается просто: создаем у себя платёж, сохраняем, тычемся в ВПС, проводим его там. А потом до посинения проверяем статус нашего платежа в ВПС.
пункт 2: время обработки не важно, чел написал, что будет там демон или крон (в винде сервис), который раз в N секунд проверяет статус. Если статус поменялся, меняем наш платёж в базе.
пункт 3: проверке до фени, чё там с пунктом 1 и 2. Читаем наши платежи из базы на текущий момент и показываем пользователю.
пункт 4: см. пункт 1.
пункт 2: время обработки не важно, чел написал, что будет там демон или крон (в винде сервис), который раз в N секунд проверяет статус. Если статус поменялся, меняем наш платёж в базе.
пункт 3: проверке до фени, чё там с пунктом 1 и 2. Читаем наши платежи из базы на текущий момент и показываем пользователю.
пункт 4: см. пункт 1.
Не понял, что делает «Диспетчер обработки очереди»? Все ее функции выполняют остальные части.
По сути, диспетчер действительно просто объединяет в себе все части кроме веб-интерфейса.
Плюс делает какие-то доп.вещи, например, пишет логи ответов от платежных систем в едином формате.
В качестве аналогии приведу пример: есть наковальня, есть молот, есть изделие. Диспетчер — это кузнец. Или кузнецы, в зависимости от нагрузки.
Плюс делает какие-то доп.вещи, например, пишет логи ответов от платежных систем в едином формате.
В качестве аналогии приведу пример: есть наковальня, есть молот, есть изделие. Диспетчер — это кузнец. Или кузнецы, в зависимости от нагрузки.
У кого есть опыт внедрения cyberplat.ru в интернет-магазин, помогите пожалуйста, так как их техподдержка меня игнорирует
Чё-то как-то…
«правильно спроектировав систему приема платежей, подключать каждую новую систему не составит труда»
Какие из платёжных систем на рынке сейчас работают по первой схеме («Счёт на сайте->Редирект на сайт ПС->...->платёж->Редирект обратно->ждём от ПС весточки про платёж»), а какие — по предложенной второй?
Меня терзают смутные сомнения, что первых больше и они шире распространены.
Заточив на сайте систему работы с платежами под работу с ПС «второго рода» подключить ПС «первого рода» невозможно.
При этом работа с ПС «второго рода» требует от сайта магазина наличия механизмов, которые позволят самому сайту инициировать подключение к внешнему ресурсу.
И по сути получается, что такая ПС перекладывает затраты на разработку на плечи своих клиентов, как мне кажется…
«правильно спроектировав систему приема платежей, подключать каждую новую систему не составит труда»
Какие из платёжных систем на рынке сейчас работают по первой схеме («Счёт на сайте->Редирект на сайт ПС->...->платёж->Редирект обратно->ждём от ПС весточки про платёж»), а какие — по предложенной второй?
Меня терзают смутные сомнения, что первых больше и они шире распространены.
Заточив на сайте систему работы с платежами под работу с ПС «второго рода» подключить ПС «первого рода» невозможно.
При этом работа с ПС «второго рода» требует от сайта магазина наличия механизмов, которые позволят самому сайту инициировать подключение к внешнему ресурсу.
И по сути получается, что такая ПС перекладывает затраты на разработку на плечи своих клиентов, как мне кажется…
Какие из платёжных систем на рынке сейчас работают по первой схеме
Работают только по второй или умеют работать и так, и так?
Если последнее, то это и PayPal, и MoneyMail, и OSMP, например.
Заточив на сайте систему работы с платежами под работу с ПС «второго рода» подключить ПС «первого рода» невозможно.
Это не так. Чтобы началась работа с ПС «первого рода» достаточно:
1. Добавить новый статус а-ля «Пользователь ушел в ПС, но проверять статус не надо», который не будет обрабатываться диспетчером.
2. Добавить в БПС функцию разбора HTTP-запроса от ПС «check» и «pay» фаз с выдачей номера заявки в нашей системе и формированием корректного ответа этой ПС.
3. Добавить в веб-интерфейс функцию обращения к ОБ для получения номера из 2.
В этом случае на check определяем номер заявки, получаем статус заявки, если ее можно оплатить, возвращаем ПС ответ «Бери деньги с пользователя», сгенерированный в БПС.
На pay — определяем номер заявки и меняем статус, если это возможно.
Это гораздо более простой случай, поэтому я его не рассматривал.
Но он прекрасно ложится на описанную схему.
И по сути получается, что такая ПС перекладывает затраты на разработку на плечи своих клиентов, как мне кажется…
Так это смотря какая гибкость нужна сайту для работы с ПС.
Если она не нужна — имеем работу «первого рода» без диспетчера и с 2-3 статусами.
Если нужна — второй род, диспетчер, 10 статусов.
Архитектура одна и та же
То есть PayPal, MoneyMail и OSMP прекрасно умеют работать по первой схеме, если я тебя правильно понял?
А если так, то зачем же вообще городить работу по «второй схеме»? Для чего?
Если у магазина уже подключена ПС «первого рода» (а это скорее всего вебмани, яндекс или какой-нить киберплат), то зачем ему городить огород, когда можно сказать новой ПС «— Включайте первую схему, будем работать по ней»???
Под «невозможно» имелось в виду без переделок. Новые статусы, новые фунции — это всё переделки.
Ты так и не ответил, какие системы могут работать только по «второй схеме» и не умеют по первой.
И вообще, в каком случае работа по второй схеме вообще нужна магазину?
Потому как, на мой взгляд, «первая схема» абсолютно прозрачна и логична: я (магазин) делаю счёт на оплату->человек идёт в ПС и платит->ПС мне говорит удалось оплатить или нет, и возвращает человека на соответствующий урл моего мазагина->profit!
Так в какой же ситуации нужна «вторая схема»?
А если так, то зачем же вообще городить работу по «второй схеме»? Для чего?
Если у магазина уже подключена ПС «первого рода» (а это скорее всего вебмани, яндекс или какой-нить киберплат), то зачем ему городить огород, когда можно сказать новой ПС «— Включайте первую схему, будем работать по ней»???
Под «невозможно» имелось в виду без переделок. Новые статусы, новые фунции — это всё переделки.
Так это смотря какая гибкость нужна сайту для работы с ПС
Ты так и не ответил, какие системы могут работать только по «второй схеме» и не умеют по первой.
И вообще, в каком случае работа по второй схеме вообще нужна магазину?
Потому как, на мой взгляд, «первая схема» абсолютно прозрачна и логична: я (магазин) делаю счёт на оплату->человек идёт в ПС и платит->ПС мне говорит удалось оплатить или нет, и возвращает человека на соответствующий урл моего мазагина->profit!
Так в какой же ситуации нужна «вторая схема»?
А если так, то зачем же вообще городить работу по «второй схеме»? Для чего?
Во-первых, для большей гибкости.
Архитектурно первый способ от второго отличается только отсутствием диспетчера.
И там, и там придется реализовывать остальные 5 компонентов.
Первая — частный случай второй. Но не наоборот.
Соответственно, реализовав описанную схему, мы сразу же фактически реализуем первую.
Но реализовав первую, вторую придется реализовывать отдельно.
Хорошо, если при этом пустят на единые рельсы, а не добавят костыль сбоку, как это часто случается.
Во-вторых, не все функции платежных систем доступны только по первой схеме.
Например, выставление счета (в терминологии платежной системы) пользователю возможно только, если инициатор — магазин. Это и для Пэйпала, и для ОСМП, и для Манимэйла и для других платежных систем характерно.
По сути, первая схема может применяться, если магазину не нужны расширенные функции платежной системы, а вполне достаточно базовых.
Если у магазина уже подключена
Во вступлении к статье я указал, что платежных систем по условиям задачи не подключено вообще.
Под «невозможно» имелось в виду без переделок. Новые статусы, новые фунции — это всё переделки.
Статус по умолчанию при создании заявки — это 6 байт в модуле работы со счетами:
$status ||= <код_по_умолчанию> Новые функции нужны только для модуля работы с конкретной платежной системой, а его и так в каждом случае реализовывать. В целом же они ровно те же — сформировать параметры для передачи в платежную систему / разобрать ответ платежной системы.
Доделки минимальны, они не влияют на архитектуру в целом.
Резюмируя:
1. отличия первой схемы от второй — минимальны.
2. вторая — общий случай первой.
3. Нужна простота — первая. Нужна гибкость — вторая.
… вдвое. Можете в 3.14519…
Побуду занудой ^_^, просто в глаза бросилось… думаю, правильно 3.14159…
Побуду занудой ^_^, просто в глаза бросилось… думаю, правильно 3.14159…
Вообще, было бы интереснее все-таки прочесть про реализацию с нуля. Допустим, какие ньюансы при размещении платежной системы от Яндекс, WebMoney и других компаний. Возможно ли это для физических лиц… Ну и соответственно те мелочи, с помощью которых можно избежать ошибок при реализации данного функционала на сайте…
Статья очень хорошо раскрывает, что можно реализовать с наименьшими затратами… теперь интересно узнать, как это все сделать) И не допустить глупых ошибок.
Статья очень хорошо раскрывает, что можно реализовать с наименьшими затратами… теперь интересно узнать, как это все сделать) И не допустить глупых ошибок.
всем, кто заинтересован в снижении операторской комиссии за платные СМС предлагаю подписаться под обращением к президенту: community.livejournal.com/mobile_commerce
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Архитектура системы приема электронных платежей на сайте