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

Мы обсуждали, как в агентстве появляются нужные запросы. И вот он говорит:Мы пишем в свой канал, что умеем делать сложные проекты — и приходят запросы на сложные задачи.

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

И я задумался: сам бы я пришёл к себе на консультацию как директор агентства? Наверное, да, но не факт. А если бы я был директором e-commerce проекта? Вероятно, нет.

Поэтому с сегодняшнего утра — курс корректируем. Буду больше писать о том, в чём мы сильны: разработка и развитие B2B / D2C / B2C ecommerce-проектов.

Погнали.

Что не так с оформлением заказа
Как проходит оплата в типичном интернет-магазине на Bitrix или другом типовом движке?
Форма заказа — часто многошаговая. Потом сообщение: «Спасибо, ваш заказ оформлен, сейчас мы переведём вас на оплату». Следом — редирект на платёжный шлюз, где вводим данные карты, иногда повторно. Оплачиваем, нажимаем «вернуться на сайт».
Итого — два редиректа, три интерфейса. И куча поводов для сомнений и отказа от покупки. Особенно если это повторный заказ или импульсная покупка.

Как делают маркетплейсы
Вот кто действительно короли в этом процессе — маркетплейсы. Они не просто обрабатывают платежи, они выжимают максимум. Оформление заказа там — это одна кнопка, если заказ повторный. Карта уже сохранена, адрес ПВЗ стоит, оформление — по сути, мгновенное. Никаких лишних переходов, одно окно, одна кнопка. Всё продумано под повторные заказы, минимальное трение.

Какие есть варианты, если хочется так же
Если вы хотите принимать оплату картой прямо на сайте, у вас есть два пути. Первый — обрабатывать данные карты самостоятельно. Это значит, что ваш сервер будет напрямую принимать номер карты (PAN), срок действия, CVV и другие чувствительные данные. Такой подход возможен, но связан с огромными сложностями: вы обязаны пройти полную сертификацию PCI DSS (уровень 1), настроить сквозное шифрование, защиту каналов передачи, использовать сертифицированные HSM-модули и регулярно проходить аудит. Это дорого, долго, и требует штатных специалистов по безопасности. Любая ошибка — и вы нарушаете международные стандарты, рискуя не только деньгами, но и репутацией.

Второй путь — использование SDK/API от платёжной системы. В этом случае пользователь визуально вводит данные карты у вас на сайте, но технически эти данные отправляются напрямую платёжному провайдеру. Ваш сервер не видит и не хранит информацию карты — вы получаете только токен, с которым уже можно списывать средства. Это решение не требует сложной сертификации, укладывается в минимальные требования PCI DSS (SAQ A) и значительно упрощает внедрение. Вы получаете современный UX и безопасность без лишних затрат и рисков.

Мы в проектах чаще используем SDK/API или редирект (классика)— в зависимости от задач клиента, типа заказов и повторных покупок.

Что даёт ввод карты прямо на сайте (SDK или самостоятельный приём)
Плюсы:
– Повторная покупка — одна кнопка
– Меньше отказов — пользователь не покидает сайт

Минусы:
– Ограниченная вариативность — СБП и др. нужно подключать отдельно
– Не все готовы вводить данные на малознакомом сайте

Что выбрать?
Если вы не входите в топ-100 eCom по DataInsight, но хотите увеличить повторные заказы и не терять клиента на каждом шаге — SDK будет отличным решением. Редирект — это рабочий компромисс. Но если вы хотите UX как у маркетплейсов — без SDK никак.

В следующих постах разберём практику:
— Зачем вам PIM-система и как внедрять
— Интегрируем логистику без привязки к внешним сервиса
— Что должно быть в личном кабинете eCom-проекта
— Делаем бонусныу систему и при чем тут фальшивомонетничество