Выберите тему — соберём контекст
Подключаем интернет-эквайринг банка, СБП по QR-коду и по ссылке, рекуррентные списания для подписок и фискализацию по 54-ФЗ. Платёж, возврат и чек идут одним путём: от корзины до ОФД и строки в сверке. Отдельно закрываем идемпотентность, ретраи и поведение витрины, когда шлюз недоступен.
Или сразу: +7 (962) 368-39-51 Telegram
Ситуации из практики: формально интеграция работает, но деньги, чеки и статусы заказов постепенно расходятся с реальностью.
Покупатель оплатил, но закрыл браузер до возврата на сайт, а статус заказа ждал именно этого события. Заказ остаётся неоплаченным и товар не резервируется. Статус нужно строить на уведомлении банка, а не на возврате покупателя.
Сеть подвисла, покупатель нажал «Оплатить» второй раз — и создались две операции по одному заказу. Без ключа идемпотентности и проверки уже существующих платежей такие дубли приходится разбирать вручную и возвращать деньги.
Чек уходит в ОФД до отгрузки, а состав заказа потом меняется, либо оплата есть, а чека нет вовсе. Нужен согласованный с бухгалтерией сценарий: признак способа расчёта, предмет расчёта и способ оплаты для каждого случая.
Частичный возврат оформляют в кабинете банка, а в магазине заказ остаётся оплаченным целиком. Оборотка и отчёт о реализации расходятся, поддержка не понимает, что происходило с заказом. Возврат должен создаваться из карточки заказа и менять его статус.
Провайдер отвечает таймаутом или недоступен — и корзина просто отдаёт ошибку. Витрине нужны короткие таймауты, повторные попытки, понятное сообщение покупателю и сохранённый заказ. Для критичных проектов имеет смысл предусмотреть резервный маршрут оплаты.
Тариф зависит от способа оплаты, оборота и категории товара, а фиксированная часть делает дешёвые заказы убыточными. Прежде чем включать новый способ оплаты, стоит посчитать стоимость приёма денег по каждому каналу.
Собираем оплату как один сценарий: способы оплаты, статусы, чеки, возвраты и сверка работают согласованно, а не по отдельности.
Подключаем карты, СБП, рассрочку и оплату по ссылке — с одинаковым набором статусов для покупателя и оператора.
Выносим карточные данные из своего контура, чтобы объём требований PCI DSS оставался минимальным и предсказуемым.
Описываем жизненный цикл платежа так, чтобы статус заказа всегда совпадал с движением денег на счёте.
Связываем оплату с кассой и ОФД: от признака расчёта до повторной регистрации чека при сбое.
Двигаемся итерациями: сначала минимальный работающий контур, затем расширение способов оплаты и автоматизация финансов.
Разбираем корзину, оформление заказа, учётную систему и действующие договоры с банком. Определяем, какие способы оплаты действительно нужны и как будет устроен возврат.
Регистрируем магазин в кабинете провайдера, настраиваем ключи и уведомления, реализуем создание платежа, холдирование и подтверждение списания.
Связываем оплату с кассой и ОФД, реализуем полные и частичные возвраты, ежедневную сверку и журнал платежей для службы поддержки.
Проверяем поведение при таймаутах и недоступности провайдера, добавляем повторные попытки, оповещения и, если требуется, резервный маршрут оплаты.
Выбор провайдера начинается не с тарифа, а с того, какие способы оплаты нужны вашим покупателям. Если основная аудитория в России, базовый набор — карты и СБП; для дорогих позиций имеет смысл добавить рассрочку или оплату долями. Зарубежные продажи требуют отдельного контура, потому что международные сервисы не работают с российскими юридическими лицами.
Дальше смотрим на техническую часть: есть ли поддержка двухстадийной оплаты и холдирования, как устроены возвраты, доступны ли тестовый контур и документация, как быстро отвечает поддержка при сбое. Отдельно проверяем, кто отвечает за фискализацию — провайдер или ваша касса, — потому что от этого зависит и объём работ, и схема интеграции.
Минимальный набор — договор с банком или провайдером, тестовые доступы, реквизиты для чеков и описание того, как заказ проходит по статусам. Полезно заранее решить, в какой момент выставляется чек: при оплате или при отгрузке, и кто отвечает за возвраты — оператор в магазине или бухгалтерия в банковском кабинете.
Отдельно стоит описать поведение витрины при неудачной оплате: сохраняется ли заказ, резервируется ли товар и что видит покупатель. Если в компании несколько учётных систем, сразу договоритесь, какая из них считает оплату состоявшейся. Эти решения дешевле принять на бумаге, чем переделывать после запуска.
Помимо работ по интеграции есть постоянные расходы: комиссия за приём платежей, аренда или покупка онлайн-кассы, тариф ОФД и, при необходимости, услуги антифрод-сервиса. Для подписочных моделей добавляется стоимость токенизации и повторных списаний, а также потери от неуспешных продлений.
Вторая часть — эксплуатация: сверка с банком, разбор спорных операций, обновление правил антифрода и поддержка при сбоях. На практике эти задачи занимают больше времени, чем сама разработка, поэтому их стоит закладывать и в бюджет, и в регламент работы поддержки с первого дня.
От двух до четырёх недель вместе с фискализацией. Подключение платёжного шлюза и оплата картой занимают обычно около недели, остальное — чеки в ОФД, возвраты, сверка и обработка сбоев. Если договор с банком уже подписан и есть тестовые доступы, срок сокращается до одной-двух недель.
Из трёх частей: комиссия банка или провайдера за приём платежей, стоимость кассы и ОФД и работы по интеграции. Для магазинов с подписками добавляется стоимость токенизации и рекуррентных списаний. Точную оценку даём после аудита корзины, кассы и учётной системы. Для ориентира: постоянные расходы на приём платежей со временем превышают разовые работы по интеграции.
Основные — потеря платежей при сбое возврата на сайт, двойные списания без ключа идемпотентности, чеки, не соответствующие оплате, и отсутствие сверки. Такие ошибки редко заметны сразу: они накапливаются и выясняются при закрытии месяца или в обращении покупателя. Отдельный риск — необработанные уведомления банка: если сайт не принимает их повторно, часть оплат остаётся неучтённой.
Витрина должна сохранять заказ и предлагать другой способ оплаты, а не отдавать ошибку. Уведомление от банка обрабатывается отдельно от браузера покупателя и принимается повторно. Мы настраиваем таймауты, повторные попытки, оповещения дежурному и, если нужно, резервный маршрут через второго провайдера. Главное — не потерять корзину покупателя из-за чужой аварии.
Смежные задачи, которые обычно решаются в одном проекте с этой.
Опишите способы оплаты, кассу и учётную систему — предложим схему интеграции и назовём сроки.
Cookie и аналитика
Мы используем необходимые cookie для работы сайта и форм. Аналитические cookie (Яндекс.Метрика, включая запись сессий) подключаем только с вашего согласия — от него можно отказаться. Подробнее: Политика использования cookie и обработка персональных данных.