Скидки от банков-партнеров и платежных систем: как интегрировать их в платежный процесс и соблюсти интересы мерчанта
Как мотивировать пользователя совершить покупку в интернет-магазине или оплатить подписку? Один из самых действенных вариантов – предоставить ему скидку. Но для этого мерчанту нужно иметь доступ к карточным данным, а у многих мерчантов, пользующихся услугами процессинговых компаний, нет на это законных прав. На этот случай специалисты Payture придумали решение, о котором расскажем ниже.
Почему мерчант не может контролировать расчет скидки
Крупные мерчанты могут заключить уникальные договоры о скидках напрямую с банками-эмитентами, платежными системами или провайдерами. Например, держатель карты Visa мог бы получать скидки на поездки в приложении по заказу такси, а при оплате Apple Pay оплачивать лишь часть суммы при первой покупке в маркетплейсе. Это выгодно как для владельцев платежных решений, так как растет популярность продукта, так и для мерчантов, которые получают возможность стимулировать к покупке большой пласт клиентов.
Однако по закону ни одна компания не имеет права работать с карточными данными, не обладая сертификатом безопасности Payment Card Industry Data Security Standard (PCI DSS). При отсутствии данной сертификации, большинство мерчантов обращаются к платежному решению, уже сертифицированному по PCI DSS. При этом они лишаются возможности контролировать процесс одобрения и списания скидки, которую предоставляют МПС или банки-эмитенты. Пользователь вводит свои карточные данные в платежной форме на стороне провайдера и контроль механизма активации скидки остается за последним. Мерчант не может отслеживать этот процесс: он отправляет сумму заказа, которая впоследствии корректируется уже внутри шлюза.
Если скидок от платежных партнеров несколько, то у магазина есть риск запутаться в этих операциях. К тому же мерчант не сможет по своему желанию изменить условия акции или величину скидки самостоятельно.
Повышенные же риски для провайдера состоят в необходимости жёсткого контроля за логикой скидки и формирования суммы списания во всех внутренних системах, так как фактически от мерчанта он получает одну сумму, а списывает другую с учетом скидки.
Операции без скидок проводятся по понятной логике: если стоимость товара составляет 100 рублей, именно эта сумма и списывается без корректировок. А если в силу определенных условий необходимо изменить эту сумму, это предполагает корректное разделение логики между провайдером и мерчантом, которое позволит обеим сторонам нести равные риски и одновременно гибко управлять процессом предоставления скидки плательщику.
Решение Payture: как мы передали логику предоставления скидки на сторону мерчанта
Нам в Payture надо было придумать, как позволить мерчанту, не обладающему сертификатом PCI DSS, принимать решения о скидках на своей стороне, не потерять контроль над процессом вычета скидки и сделать его прозрачным. И мы придумали.
В схематичном изображении последовательность действий выглядит следующим образом:
Первые этапы вполне стандартные: мерчанты передают платежному решению данные о транзакции и сумме платежа.
Далее логика следующая:
1. Пользователь попадает на страницу платежной формы на стороне провайдера и вводит свои карточные данные. Когда в поле появляются первые 6 цифр, мы обращаемся к нашей базе и достаем оттуда все данные: номер заказа, номер карты, тип карты, банк-эмитент.
2. Эти данные мы отправляем на сервер мерчанта. Логика расчета скидки уже находится на его стороне и сам сервис/магазин принимает решение о необходимости предоставления скидки.
3. Как правило, мерчант одобряет вычет и отправляет новую сумму провайдеру вместе с текстом и изображениями, которые должны быть отражены в платежной форме при выдаче скидки. Мы тут же транслируем новую сумму платежа с учётом скидки в платежной форме вместе с извещением об акции.
4. После того как пользователь подтверждает операцию, нажав “Оплатить,” мы снова запрашиваем информацию у мерчанта с целью подтвердить итоговую сумму и запросить второй сопроводительный текст об успешном прохождении скидки.
В чем уникальность способа?
Особенность этой схемы в том, что провайдер дважды обращается к мерчанту. Сначала для получения новой суммы с учетом скидки и потом для повторного получения той же суммы после нажатия клиентом на кнопку оплаты.
Такая схема позволяет избежать некорректного списания средств в ситуации, когда пользователь сначала вводит одни карточные данные, провайдер в ответ меняет сумму платежа с учетом скидки, а потом пользователь вдруг решает изменить введенную информацию на данные другой карты, по которой скидки нет.
Таким образом, все операции по карте все равно совершаются через провайдера без нарушения протоколов безопасности, но настройка условий скидки и ее одобрение при каждой операции остается за магазином. Конечно, такая схема предполагает повышенную нагрузку по разработке по сравнению со стандартной интеграцией, много работы приходится проводить на стороне мерчанта, так как реализуется связка “сервер-сервер.” Но именно благодаря такому подходу мерчант может сам в любой момент поменять условия скидки или задать новые, и схема, реализованная единожды, продолжит работать уже без непосредственного привлечения к процессу провайдера.
Эту технологию сложно назвать массовой, так как обычно крупные финансовые партнеры идут на скидочные коллаборации только с крупным бизнесом. Но на случай подобных партнерств у специалистов Payture уже готово особое решение, безопасное и удобное как для мерчанта, так и для провайдера.