Отличия методов оплаты на сайте
Работая с 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 сертификации.