Что должно быть в модуле эквайринга

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

Какие же задачи обычно ставят перед таким модулем? Вот основные:

1. Работа с любыми видами платёжных транзакций — от простых до самых сложных.
2. Возможность выбирать между одностадийной или двухстадийной схемой оплаты.
3. Умение обрабатывать уведомления (callback) от платежного шлюза и проверять их корректность.
4. Шифрование данных и защита входящих сообщений — безопасность прежде всего.
5. Контроль: сумма оплаты должна точно соответствовать стоимости товаров или услуг.
6. Автоматические проверки статуса платежей через cron-задачи — потому что никто не любит зависшие заказы.
7. Частичные оплаты и возвраты — для тех случаев, когда нужно немного больше гибкости.
8. Инструменты для выявления подозрительных транзакций и работы с фрод-статусами.
9. Генерация ссылки для оплаты и отправка её на электронную почту клиента. Плюс автоматическое уведомление о том, что оплата прошла успешно (или не прошла).
10. Передача данных в ОФД для печати фискальных чеков — всё строго по закону.
11. Работа с предварительными и закрывающими чеками.
12. Автоматическая отмена неоплаченных заказов через установленное время — потому что порядок должен быть всегда.
13. API для интеграции с другими системами — например, чтобы клиент мог оплачивать прямо с мобильного телефона.
14. Возможность настройки атрибутов товаров, отвечающих за ставку НДС.
15. И, конечно, поддержка товаров с обязательной маркировкой.

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

Клиенты нередко задают вопрос:
“Почему бы не использовать готовый модуль? Ведь такие решения либо бесплатны, либо стоят недорого, а иногда их вообще предоставляет сам эквайринг.”

Разберём этот вопрос подробно, пункт за пунктом.

Платежные транзакции

Этот функционал часто становится настоящим спасением для операторов колл-центров и служб поддержки. В кастомных модулях прямо в карточке заказа отображается вся история транзакций: холдирование, списание, возвраты. Указаны суммы, статусы, даты — вся информация доступна мгновенно.

Что предлагают готовые модули? Обычно лишь общее состояние: “Оплачено 3500 из 3500 рублей.” Был ли возврат? Когда была проведена операция? Такие детали остаются за кадром.

В итоге операторам Customer Care приходится вручную заходить в личный кабинет эквайринга, чтобы разобраться с транзакцией. Это влечёт за собой:

1. Потерю времени – клиенту приходится ждать.
2. Увеличение нагрузки на сотрудников, что отражается на фонде оплаты труда.
3. Дополнительные сложности для службы безопасности, связанной с управлением доступами к личным кабинетам эквайринга.

Счёт: 1–0 в пользу кастомного решения

Поддержка одностадийных и двухстадийных платежей.

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

Счёт: 1–1

Поддержка callback-уведомлений.

Это один из самых критичных моментов. Необходимо не просто получать уведомления от эквайринга, но и проверять, откуда они пришли, и корректны ли они (включая шифрование).

Большинство готовых модулей такие проверки не выполняет. Это создаёт уязвимость: злоумышленники, изучив работу модуля, могут сформировать “правильный” ID транзакции и отправить его через Postman. Если служба поддержки упустила это из виду, а сверка платежей не проводится ежедневно, заказ может быть отгружен мошенникам. Выявить проблему удастся лишь спустя несколько дней, когда товар уже окажется в руках злоумышленников.

Счёт: 2–1 в пользу кастомного решения

Сбои в IT-инфраструктуре

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

Эту проблему решает cron-задача, которая проверяет статус неоплаченных заказов через заданные интервалы времени. В готовых модулях такой функции, как правило, нет.

Счёт: 3–1 в пользу кастомного решения

Частичные оплаты и возвраты

Функционал частичных оплат и возвратов — ещё одна важная опция для гибкой работы с клиентами.

Счёт: 3–2

Fraud-платежи

К сожалению, некоторые эквайринговые сервисы либо блокируют такие операции, либо вовсе не уведомляют о проблемах. Итог для бизнеса — отсутствие ясности. В этом случае кастомный и готовый модули работают на равных, счёт остаётся прежним: 3-2.

Уведомления клиентов и ссылки на оплату

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

Счёт: 3–3

Интеграция с ОФД

Когда речь заходит об обмене данными с операторами фискальных данных (ОФД), готовые модули часто демонстрируют слабые места:

1. Проблемы с кодировкой, из-за которых передаётся неполная информация о товарах.
2. Некорректная обработка статусов чеков.
3. Ошибки расчёта сумм, например, неверное округление копеек.

На крупных eCommerce-проектах (с объёмом 400 000+ заказов в месяц) такие недочёты буквально парализуют работу службы поддержки. Без надёжной интеграции с ОФД избежать хаоса невозможно.

Счёт: 4–3 в пользу кастомного модуля

Ещё один нюанс — работа с чеками предоплаты и закрывающими чеками. Например, если вы продаёте косметику, то при оплате заказа клиенту нужно отправить чек предоплаты, а при получении товара — в тот же день сформировать закрывающий чек. Готовые модули с такими задачами справляются крайне редко.

Счёт: 5–3

Работа с маркировкой товаров

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

Счёт: 6–3.-

Функционал автоотмены заказа

Для товаров с высоким спросом — например, лимитированных коллекций кроссовок или дорогих духов — важна возможность автоматической отмены неоплаченных заказов. Если клиент не завершил оплату в течение нескольких минут, товар должен вернуться в продажу. Готовые модули не предоставляют такого функционала «из коробки», его придётся дорабатывать.

Счёт: 7–3

API для внешних систем

Многие платформы, такие как «Битрикс», не предоставляют нативного полноценного API для интеграции с внешними сервисами. Готовые модули, как правило, тоже не покрывают этот пробел.

В то же время Magento предлагает более гибкие возможности. Она поддерживает REST API и GraphQL, но и здесь не всё идеально. REST API используется в стандартных сценариях, а для современных headless-магазинов, работающих через GraphQL, потребуется дополнительная доработка.

Счёт: 8–3

Выбор ставки НДС

В крупных eCommerce-проектах товары часто имеют разные ставки НДС. Установить одну ставку для всех — не вариант. Здесь кастомное решение становится единственным выходом.

Итоговый счёт: 9–3 в пользу кастомного модуля эквайринга.-

Когда кастом – это необходимость

Безусловно, готовый модуль может стать временным решением, если запуск проекта должен был состояться «ещё вчера». Но в этом случае руководитель eCommerce, глава клиентского сервиса и IT-департамент должны осознавать и согласовать все связанные риски.

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