Как мы подбирали платежный шлюз для сайта

Облачный провайдер 1cloud о том, как настроить удобную для клиента систему оплаты услуг в онлайне.

Когда мы только зашли на рынок IaaS-услуг, то поставили себе задачу — создать простой и удобный сервис, которым могли бы пользоваться люди с любым уровнем понимания IT-тематики. Так, чтобы развернуть виртуальный сервер можно было также просто, как завести почтовый ящик на «Яндексе».

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

Из каких платежных систем выбирали

С 2012 года мы успели поработать с большим количеством платежных шлюзов. Одним из первых был «Деньги Online». После двух лет сотрудничества возник инцидент с доступностью к сервису, поэтому решили подключить альтернативные платежные системы на случай технических сложностей.

В качестве альтернативы выбрали PayPal — в первую очередь из-за существенного потока зарубежных клиентов, которые хотели оплачивать наши услуги с помощью этого сервиса.

Интеграция потребовала от нас различных хитростей с точки зрения разработки. Пришлось корректировать CSS-правила и модифицировать стандартные элементы на веб-странице. Так или иначе, мы заключили прямое соглашение и благополучно добавили PayPal в качестве нового метода оплаты.

Затем подключили «Робокассу» — более знакомый шлюз для русскоязычного сегмента Сети. В ситуации с «Робокассой» ряд запросов в API не соответствовал своему описанию, но с помощью техподдержки ситуацию удалось разрешить.

Позже начали работать с платежной системой PayMaster, которая предложила нам выгодные условия по комиссии и удобный API. Долгое время этот платежный шлюз выступал в качестве основного.

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

Оплата без перехода на страницу платежного шлюза

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

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

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

С помощью chekout-скрипта от компании CloudPayments мы реализовали платежную форму прямо в панели управления. При этом конфиденциальность данных сохраняется в полной мере. Несмотря на то, что клиент вводит номер карты внутри нашего сервиса, данные передаются платежному шлюзу и не сохраняются на нашей стороне.

Для реализации скрипта нам пришлось пройти сканирование на безопасность по стандарту PCI DSS у одной из аккредитованных организаций — таково было требование CloudPayments. Сканирование нужно, чтобы подтвердить техническое соответствие стандарту и исключить вероятность кражи данных пользователей во время заполнения форм на сайте.

Аудит на соответствие требованиям PCI DSS проводила компания ARinteg. Мы отправили им заявку, в которой обозначили желание пройти аудит, заполнили анкету и назначили дату проверки. На стороне ARinteg подготовка к сканированию занимает где-то полдня, однако мы взяли дополнительные четыре–пять дней на подготовку своей инфраструктуры.

Сканирование длилось примерно 15 часов, хотя бывает, что проверка идет несколько суток. Специалисты ARinteg проверяли наличие SSL и защиты от запросов-инъекций и других уязвимостей на нашем сайте.

Первичный тест мы не прошли, и нам предоставили список проблем, которые нужно было устранить. Все они были незначительны, например, имелся post-метод, который использовался, когда пользователь оценивал наши пошаговые инструкции на сайте. Мы устранили все замечания, и вторая попытка аудита прошла успешно. Далее мы могли перейти к реализации chekout-скрипта.

Скрипт прописан на нашем сайте, собирает из указанной формы карточные данные и составляет из них криптограмму для оплаты через API CloudPayments. Сама форма для ввода данных банковской карты выглядит вот так:

Во время реализации скрипта и формы мы сумели сократить количество заполняемых пользователем полей до минимума. Оставили только те, которые реально необходимы для проведения операции. Например, убрали поля «Имя» и «Фамилия». Как нам объяснили представители платежного шлюза, банки не проверяют эти данные (важны лишь номер карты, дата и CVV), поэтому мы решили их опустить и упростить весь процесс.

Дополнительно мы сделали более наглядной информацию о нашей дисконтной программе. Ранее она выглядела так:

Автоплатеж по остатку на счете, а не по расписанию

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

Для реализации автоплатежа мы использовали метод оплаты с «запомненной» карты (по временному токену). Работает это следующим образом: после первого успешного платежа, совершенного пользователем, шлюз генерирует для пары «сервис — карта» свой токен и отправляет его в postback-ответе. Этот токен сохраняется, и при повторной оплате уже передается он, а не данные карты. Получается, что мы направляем шлюзу запрос, в котором указываем наш API-ключ (идентификатор того, что запрос поступил от 1cloud), токен и сумму. Шлюз проверяет, создавался ли такой токен, и если все в порядке, то обрабатывает платеж на указанную сумму.

Дату, когда необходимо произвести автоплатеж, мы рассчитываем динамически исходя из текущего потребления услуг пользователем и остатка средств на счете. Допустим, у клиента тысяча рублей на балансе, а потребил он за последний десятиминутный интервал два рубля. Понятно, что приблизительная дата обнуления наступит через пятьсот десятиминутных интервалов — это примерно 34 дня. Таким образом, мы можем провести автоплатеж за несколько дней до окончания средств. Размер автоплатежа клиент выбирает самостоятельно.

Что дальше

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

0
3 комментария
Aka Bydionis

"А еще, я слышал, что учёные разрабатывают новое устройство, которое сможет поджаривать два куска хлеба одновременно!" 🤫
Из фильма

Ответить
Развернуть ветку
Denis Kiselev

Усе. Все вопросы теперь - к МТС

Ответить
Развернуть ветку
Alex Ivanov

Отлично, стали понятны некоторые аспекты.

Ответить
Развернуть ветку
0 комментариев
Раскрывать всегда