Отличия методов оплаты на сайте
Работая с e-commerce рано или поздно столкнёшься с приёмом платежей на сайте. Вариантов реализации формы оплаты не так уж и много. Но в их особенностях путаются зачастую не только заказчики, но и сами разработчики.
Для начала разберём кто и как участвует в процессе покупки.
Участники
- Продавец, на чьём сайте расположен магазин
- Покупатель, посетивший магазин
- Платёжный провайдер (Payment Service Provider или PSP) — сервис, получающий информацию и обрабатывающий платежи
Шаги оплаты
- Создать форму оплаты и вывести её в браузер покупателя
- Покупатель вводит данные карточки и отправляет форму
- Данные платёжной формы получаются и пересылаются на обработку
И, собственно, сами варианты реализации
Редиректы
Первый способ — редирект. В этом случае покупателей пересылают со страницы магазина на отдельный сайт платёжного сервиса, где и находится платёжная форма. Такой способ часто используется в маленьких магазинах. Из плюсов — приходится поддерживать меньше кода, ответственность за безопасность и обработку платежа ложится на плечи сервиса.
- Сайт продавца отправляет браузеру покупателя информацию о редиректе
- Покупатель попадает на форму оплаты на сайте платёжного сервиса
- PSP генерирует форму
- Покупатель заполняет форму
- PSP получает данные карточки и обрабатывает платёж
При использовании редиректа существует вероятность атаки посредника (man-in-the-middle attack). Хакер получает доступ к управлению магазином и изменяет адрес редиректа на сторонний сайт. На своём ресурсе получает из запроса данные карточки. И, возможно, возвращает покупателя ещё одним редиректом на сайт платёжного сервиса для завершения покупки. Чаще всего информация о подобных атаках становится известна после проверки выписки с баланса счёта покупателем. В этой ситуации уже нельзя говорить об ответственности сервиса, так как атака скомпрометировала сам магазин. И все издержки по возврату средств и штрафам понесёт продавец.
IFrame
Использование Iframe’а — метод при котором платёжная форма, расположенная на другом сайте, встраивается в страницу магазина. Одним из плюсов данного метода является простота, с которой владелец магазина может контролировать вид страницы оплаты (фрейм отображает только стилизованную форму). Платёжная форма так же как и при редиректе располагается на сайте платёжного сервиса.
- Сайт продавца создаёт родительскую страницу
- Браузер покупателя на странице магазина запрашивает во фрэйме форму оплаты
- PSP генерирует и отдаёт форму
- Покупатель заполняет форму и отправляет данные прямиком на сервис
- PSP получает данные карточки и обрабатывает платёж
Работу IFrame’а можно показать как
Слева изображена родительская страница. Она является частью магазина. В середине фрейм. Его содержимое — это форма оплаты, сгенерированная платёжным сервисом. Справа — финальный вид страницы, как она загрузится для покупателя. С точки зрения пользователя мы имеем целостную страницу с формой оплаты.
Iframe-метод подвержен тому же виду атак, что и редирект. В ситуации, когда хакер получит доступ к магазину, адрес загружаемого фрэйма может быть изменён и данные карточки уплывут налево.
Прямой запрос
Прямой запрос («direct post», «browser post», «silent order post») отличается от первых двух методов. В данном случае платёжная форма расположена прямо на странице магазина, а не на сайте платёжного сервиса. Это даёт продавцу больше возможностей контролировать процесс оплаты. Но, так же повышает требования к безопасности самого магазина и совершаемых транзакций.
- На странице магазина создаётся форма оплаты
- Покупатель заполняет форму, и данные отправляются на платёжный сервис
- Сервис получает информацию о карточке и обрабатывает платёж
Из-за того, что при использовании данного метода PSP появляется только в момент отправки данных, любое вмешательство третих лиц в процесс платежа очень трудно отследить. При прохождении PCI DSS сертификации продавцам с подобным типом оплаты приходится не только заполнять опросник из 139 вопросов (AQ A-EP), но и проходить полный аудит безопасности (внутреннее и внешнее сканирование, тестирование на проникновение).
Метод с использованием JavaScript
Страница формируется полностью на стороне магазина. Но браузер покупателя модифицирует форму, используя скрипт, загружаемый с ресурсов платёжного сервиса.
- На странице магазина создаётся форма оплаты
- Браузер покупателя запрашивает JavaScript
- PSP генерирует JavaScript
- Браузер на основании полученного скрипта формирует платёжную форму на странице
- Покупатель заполняет форму, и данные отправляются на платёжный сервис
- Сервис получает информацию о карточке и обрабатывает платёж
Так же, как в случае прямого запроса, данный метод требует повышенных мер безопасности со стороны владельца магазина.
API
API («merchant gateway») отличается от других методов в лучшую сторону благодаря тому, что предоставляет практически полный контроль за всем процессом оплаты. Данные о транзакциях хранятся в магазине, что позволяет реализовать более тесное взаимодействие продавца и покупателя.
- На странице магазина создаётся форма оплаты
- Покупатель заполняет форму, и данные отправляются в магазин
- Магазин оправляет данные карты платёжному сервису
- Сервис получает информацию о карточке и обрабатывает платёж
Как всегда, как только кто-то умудряется получить доступ к магазину — данные скомпрометированы. А учитывая, что при использовании API в магазине хранится намного больше информации о транзакции, то ущерб может быть весьма ощутимым. Магазины с подобными методами оплаты проходят самую суровую проверку при PCI DSS сертификации.
Что значит «дьявол кроется в деталях»?
Как я уже раньше замечал, запрос о дьяволе, который в деталях, привлекает энное количество людей. Только находят они малость не то :-)
Распространённая трактовка идиомы «дьявол кроется в деталях» («дьявол скрыт в мелочах», «the devil is in the details») — в любом плане есть пара мелочей на которые стоит обратить внимание, иначе, в дальнейшем, проблем не оберёшься. Так же, как вариант, — при реализации плана недосмотр в, казалось бы, незначительных местах может привести к краху.
Моя любимая Википедия (на которую, говорят, ссылаться стало моветоном) говорит так:
Идиома «Дьявол кроется в деталях» говорит о некой непредусмотренной планированием мелоче, и восходит к «Бог в деталях» («Бог в мелочах»), выражающую идею что любое дело должно быть сделано тщательно (любая деталь имеет значение).
Авторство выражения «Бог в мелочах» приписывается разным людям. The New York Times в некрологе от 1969 года связвает эту фразу с архитектором немецкого происхождения Людвигом Мис ван дер Роэ (Ludwig Mies van der Rohe (1886–1969)). На данный момент уже общепризнано, что авторство принадлежит не ему.
Часто это выражение упоминается у немецкого историка искусства Аби Варбурга (Aby Warburg (1866–1929)). Хотя, биограф Варбурга Эрнст Гомбрих (Ernst Hans Gombrich) сомневается в авторстве.
Ранняя форма «Le bon Dieu est dans le détail» (хороший Бог в деталях) приписывается Густаву Флоберу (1821–1880).
«Знакомые Цитаты Бартлетта» («Bartlett's Familiar Quotations») отмечают это выражение как анонимное.
Google Ngram Viewer (забавный сервис, не знал о нём) утверждает, что фраза «the devil is in the details» не появляется в коллекции до 1975 года. В Google Books фраза упоминается в книге 1969 года как уже устойчивое выражение.
Иногда встречаются модификации: «Управление в деталях», «Правда в деталях».
Так же Уильям Сафир (William Safire (1929–2009) упоминает эту фразу в статье для The New York Times (30 июля 1989 г.) и цитирует редактора «Знакомых Цитат Бартлетта»: «Нам до сих пор не ясно с „Бог (или дьявол) кроется в деталях“. Мы знаем что Мис ван дер Роэ использовал её обсуждая архитектуру; предполагается авторство Флобера, но до сих пор не найдено подтверждение в его записях. Мне кажется, это мог сказать Джон Рёскин (John Ruskin), фраза как раз в стиле его высказываний о качестве исполнения, но для подтверждения нам всё так же не хватает цитатат».
31716 downloads
Между тем, тихой сапой Facebook Connect and Like Free для Magento скачали уже 31716 раз (22399 пришлось на magentocommerce.com).
До миллионных скачек мобильных приложений далеко, конечно. Но, и ёмкость рынка не так велика.
Следующая цель — 50 тысяч. Дождёмся модерации новой версии и вперёд.
P.S. вообще, приятно на совершенно сторонних сайтах встречать свой модуль. Жаль только, что не всегда ребята тратят время для толковой привязки к имеющейся теме магазина.
P.P.S. 31716 — число не круглое, но прошлый раз, когда я смотрел статистику по этому модулю, было чуть больше двух тысяч. Так что радуюсь любому поводу, да.
Всё хорошо, или что-то пошло не так
Прошёл месяц с момента публикации тестового задания, и можно подвести какие-то промежуточные итоги.
Каких-то ошеломительных результатов я не ожидал. Но, то что получается сейчас, честно говоря, удивило. Свои резюме прислали за месяц 28 человек. Шестерым отказали сразу, остальным предложили выполнить тестовое задание. Из оставшихся 22 человек по ссылке перешли 11. Архив с доп. файлами скачали 7. Выполнили и прислали задание — (барабанная дробь) 0. Ноль, Карл!
И вот с какой-то оценкой я затрудняюсь.
Задание-то не сложное. Требует немного включить думалку, да. Но не rocket science же. Когда-то давно, когда снег был белее, а в колбасе ещё встречалось мясо, людей просили написать чуть-ли не полноценную CMS со специфическим функционалом или реализовать хитрый алгоритм. Это я о вебе и php, если что. И такие задания выполнялись. Сейчас же получается полная муть.
С другой стороны, вакансии тоже стали какими-то облегчёнными. Знакомство с фреймворком, чуть-чуть сопутствующих технологий. И всё.
Соискателей на рынке много, вакансий не меньше. Понимаю, что потратить час на выполнение задания сложнее, чем нажать на «Apply» в соседней вакансии. А мы никогда не позиционировались как компания мечты. Так что, возможно, имеем просто проигрыш по конкурентной привлекательности. Вообще, забавно получается — нам требуются новые люди, но не то чтобы срочно, и можно повыбирать. Людям так же работа как бы и нужна, но потратить от 40 минут до пары часов на дорогу и собеседование кажется проще и дешевле, чем сделать задание в комфортной обстановке. И имеем в итоге две стороны, которым как бы и надо, а как бы и не так чтобы очень.
Хотя, предпочту пока думать, что это были не наши люди. А те самые-самые ещё будут. Позже.
Очередной эксперимент
Продолжу-ка я, ребята, о наболевшем — о собеседованиях.
Когда я устраивался на нынешнее место, вопросы были не страшные и общедоступные. Что-то типа «а не совсем ли ты валенок и встречал ли где-то такие слова?». На том уровне развития этого было вполне достаточно. Вроде шарит — а как на самом деле работа покажет.
Постепенно опрос кандидатов перешёл ко мне. Одновременно с этим возросло и количество проходящих собеседование. Какое-то время пользовал ту же систему, что и прошлый товарищ.. Но спрашивать у каждого первого: «знаешь ли ты про каскадное обновление в MySql» очень быстро надоело.
Так родилась первая версия более-менее структуризированного опросника. На его же основе сформировались основные требования, превышающие банальные LAMP + JS.
И опять всё хорошо — понятно что когда спрашивать, куда свернуть, если кандидат плавает, и стоит ли вообще продолжать.
Так и жили. Список вопросов дополнялся. Часть пунктов заменялась на более современные. Люди приходили, отвечали и были наняты. Красота.
И тут появилось то самое пресловутое «Но». Люди, конечно, собеседование проходили, отвечали охотно и полно. Но сама система структурной анкеты подразумевает под собой стандартизацию вопросов. И, прочитав пару десятков ссылок из выдачи гугла по «вопросы на собеседовании PHP MySql», можно успешно справиться с заданием. Встречал где-то у буржуев опреление «interview hackers». Очень похоже.
Отвечать-то он отвечает, но первые же дни показывают что что-то не так. И решения странные, и очевидные вещи не знает. Пора, значит, снова открывать вакансию.
Да, испытательный срок как раз для таких случаев, я знаю. Он-то как раз и спасает. Но набирать пяток человек, чтобы потом остался только один, идея не есть гуд. Добавить сюда специфику и долгое время вхождения. Так что хочется всё же найти того самого, чтобы не зря.
Следующим шагом стало требование предоставлять вместе с резюме примеры кода. Мысль здравая, но, на самом деле, не сработала. Отсеивались наболее неадекватные. Можно было оттолкнуться от чего-то более приблежённого к земле, чем тупо теория. И, одновременно, кто-то же должен во всё присланное вникать и искать смысл. Из забавного были три человека, приславшие один и тот же код, и «да, прислал код, но его писали у нас на прошлом месте и я не вникал, но точно могу так же». Выхлоп у затеи получился, скажем так, маленький.
Постепенно, отошли от следования чёткой линии допроса. И собеседование превратилось в долгую беседу по заявленным в резюме навыкам, упоминающимся в процессе разговора технологиям и «а как бы вы сделали...». Долго, всеобъемлюще и непродуктивно. Хотя, слабые и сильные стороны человека понимаешь хорошо, да.
Дальше продолжился, как говорят художники, поиск новых форм.
Пишут тут разное про «посадить за машину и написать что-то простое прямо здесь». Говорят, показывает подготовку сразу. Так вот, не работает. Человек теряется в новом окружении (это и люди, и среда разработки не под тебя настроена, и банальное волнение). В итоге, максимум что получается выжать — рассказ как планировалось сделать. А этого можно добиться и простым разговором. Не тратя время на писанину. А стиль всегда можно поправить. Да и принимать только по коду, без разговора, не получится. Со всех сторон бессмысленная трата времени.
И доползли мы в конце концов до самого гадкого — тестового задания перед собеседованием. Задание не трудоёмкое и много времени занять не должно, но пару областей (не)знания, думаю, способно отсечь. Теперь будем смотреть что из этого получится и куда приведёт.
I like it!
Есть всё же что-то неправильно-порочное в фэйсбуковском принципе лаков-рекомендаций.
Умер в автокатастрофе Джон Нэш, и толпа леммингов тут же — I like it!
Разбился самолёт, весь экипаж и пассажиры погибли — I like it!
Цунами разрушило 2 города, тысячи людей пострадали — I like it!
И так на любой чих.
Не, я понимаю что тех же детей и котиков грех не залайкать. Что-то подобное, видимо, и было в первоначальном плане. Но сейчас, когда Фэйсбук перерос две странички с тремя картинками, стоило бы как-то задуматься и разграничить тип постов. Не надо вводить дополнительный элемент, ломать голову как бы поудобнее его назвать и приучить людей им пользоваться. Просто дайте при публикации, рядом с настройками приватности, эмоциями и геопозицией маленький чекбокс — «без лайков». Всё.
Людвиг Быстроновский. Лекции
Наконец, добрался Людвиг Быстроновский с лекциями и до Минска.
Понравилось. Можно было бы и больше. Хотя, до конца не отпускало чувство, будто ты опять в университете и очередной преподаватель, умный и интересный, но, бляха, въедливый, читает вводную лекцию и обещает, что будет тяжело. Ну, так мне воспринималось, не знаю.
Интересно и тяжело, кстати, — одна из основных идей на обеих лекциях. Хотите развиваться — ищите для себя интересные задачи, каждый раз сложнее предыдущих. Нет интересных и сложных — придумаете себе челлендж сами. Не в смысле дотянуть до дедлайна и сделать за одну ночь, а попробовать новые инструменты, проверить идеи, потратить меньше времени, чем обычно, etc. Тот самый пресловутый выход из зоны комфорта, да.
Лекции сильно пересекаются с методиками бюро Горбунова, рассылкой Мегаплана, «Психбольницей в руках пациентов» и книгами от Basecamp (ex. 37signals). Cложно сказать, что было что-то совсем новое и неожиданное, но, как этакий сжатый экстракт из большого массива информации, поданый живо и с юмором, зашло очень хорошо.
Разбитие лекций на 2 части для менеджеров и дизайнеров, как мне показалось, весьма условно. Обе лекции сильно связаны, хоть и не пересекаются. То, как ты, управляя собой, помогаешь другим, и как заставить себя расти и добиваться результата — одна большая тема. И одно без другого просто не может существовать.
И, собственно, основные тезисы.
Мантра «надо просто больше работать» — не работает. Хозяином твоего времени становятся другие люди.
Контролируй своё время. Если ты занят — нет необходимости объяснять это другим. Ты просто занят.
Если бэйджи на приложениях, сообщения и только что пришедшее письмо вынуждает мгновенно посмотреть, что же там такое — выключить всю нотификацию. Избавиться от подобных раздражителей.
Не важно, сколько часов ты работаешь. Важно, чтобы ты принимал правильные решения.
Нельзя всегда контролировать ситуацию. Контролируй себя. Ясность ума — единственное, что поможет выйти из кризиса.
Стоит вести себе правило: не отвечать, когда устал и зол.
Не доёбывайся. Дай людям обосраться. Ошибаться надо давать на мелких вещах, чтобы не рухнул весь проект.
Старайся задавать открытые вопросы. Ответы «да» и «нет» — зло.
Джим Кэмп обязателен к прочтению. Несколько раз.
Не надо тянуть всё на себя. Научись делегировать. Не становить бутылочным горлышком в проекте.
Используйте электронный ящик — хорошая напоминалка и таск менеджер (привет гугль инбокс). Письмо во входящих — ответить и удалить. Если ответ не требуется — удалить. Непрочитанное письмо лежит уже две недели? Удаляй.
Человек должен становиться сложнее. Для этого надо постоянно узнавать что-то новое.
Если все мелкие задачи сделаны хорошо, то и весь проект не может получиться плохим.
Дизайн — это решение задач. Дизайнер — человек, любящий решать задачи.
Дизайн начинается, когда вы остаётесь на проекте после реализации и проверяете гипотезы.
Если крутая идея пришла вам в конце проекта — не надо обязательно впихнуть её прямо сейчас. Ваша задача — прокачивать себя, а не пытаться впихнуть все идеи в один проект.
Прокачивай один, максимум два навыка за раз, за задачу, за проект. Иначе сдуреешь и сгоришь. Как в спорте: «Сегодня учимся правильно дышать» и все.
Дизайнер с закрытыми глазами стреляет идеями, а арт-директор оценивает, попала ли пуля в цель, и корректирует прицел.
Изучая новый инструмент, надо в первую очередь выяснить его минусы. Тогда станет понятно, когда есть смысл его применять.
Знание нельзя просто знать. Его нужно использовать.
Перестаньте переживать об управлении другими. Управляйте собой.
У каждого решения есть польза и вред.
Все можно делать проще.
Как-то так. Организаторы обещались выложить видео. Будем подождать.
UPD. Начали публиковать записи
Первая часть
Вторая часть
Третья часть