Интеграция оплаты на сайт и в приложение: ЮKassa, чеки по 54-ФЗ, ОФД
Мы в WAPP восемь лет делаем веб-сервисы и мобильные приложения, и почти в каждом проекте есть оплата. Интеграций платёжных систем за это время было больше двадцати. Вывод из них простой: подключить оплату — это дни, а вот сделать так, чтобы платёж, заказ, чек и доставка не расходились между собой, — недели. Ниже то, на чём мы сами спотыкались, и что советуем клиентам до старта.
С чего мы начинали: 54-ФЗ и онлайн-кассы
Когда мы открыли студию, требования 54-ФЗ к онлайн-кассам уже действовали: каждый, кто принимает оплату через интернет, обязан выдавать покупателю электронный чек. Первые интеграции мы делали на LIFE PAY — я до WAPP работал в этой компании и хорошо знал их кассу изнутри. С тех пор фискализация чеков для нас — не отдельная задача, а обязательная часть любой интеграции оплаты.
Цепочка выглядит так: клиент платит → система меняет статус заказа → формируется чек по 54-ФЗ → данные уходят в ОФД → покупатель получает электронный чек. Сам платёж почти никогда не ломается. Ломается всё, что после него.
По закону расчёт без чека грозит штрафом до 100% от суммы расчёта (КоАП 14.5 ч. 2), а ошибки в реквизитах чека — предупреждением или штрафом до 10 000 ₽ для юрлица (ч. 4). Ошибки в чеках обычно не видны сразу: они копятся месяцами и всплывают при проверке.
Если продаж мало: не делайте интеграцию
Владельцу небольшого бизнеса, который хочет «просто кнопку оплаты за три дня», я обычно советую вообще не интегрировать оплату в сайт. Достаточно формы заявки и ссылки на оплату. Интернет-эквайринг банка (например, Т-Банка) или ЮKassa позволяют сгенерировать ссылку и отправить её клиенту. Подключение согласуют быстро, а у ЮKassa есть свои электронные чеки: она фискализирует платёж как агент, и отдельная касса не нужна.
Интеграция с системой нужна тогда, когда платежей много, они регулярные и обрабатывать их вручную уже тяжело.
Как выбрать провайдера: агрегатор или эквайринг банка
Мой совет — начинать с того, что дешевле. Чаще всего это прямой интернет-эквайринг банка с хорошим API и понятной документацией. Агрегаторы вроде ЮKassa и CloudPayments дороже по комиссии, но подключаются быстро и сразу дают карты, СБП, кошельки, Яндекс Пэй и оплату частями.
По нашему опыту внедрения:
- ЮKassa — внедряется легко, есть встроенная фискализация.
- Т-Банк — тоже легко, быстро согласовывают подключение.
- CloudPayments — удобно внедрять.
- LIFE PAY — интегрируется просто, но комиссия высокая.
- Сбер — с документацией сложнее всего. В одном проекте мы начали интеграцию со Сбером и в итоге перешли на ЮKassa.
Актуальные тарифы проверяйте на сайтах провайдеров: они зависят от оборота и способа оплаты, по СБП комиссия обычно ниже, чем по картам.
Главное правило: два независимых эквайринга. Если у вас больше пяти продаж в день, подключайте две платёжные системы, которые не зависят друг от друга. Мы поняли это на Xstreet. По выбору клиента там стоял эквайринг Райффайзенбанка, и в какой-то момент он начал падать. Пришлось срочно подключать второй, резервный — эквайринг Тинькофф (сейчас Т-Банк). Пока работает только один провайдер, его сбой — это остановка продаж.
Способы подключения: ссылка, виджет, API, SDK
Ссылка или платёжная страница. Клиент переходит к провайдеру, платит и возвращается. Подходит для старта и небольших объёмов.
Встраиваемый виджет. Оплата не уводит с сайта, но виджет — ещё одно звено, которое может сломаться. В сети коворкингов, с которой мы работаем, кнопка «Оплатить онлайн» на сайте в какой-то момент перестала открывать окно ЮKassa: клиент выбирал переговорную, нажимал оплату — и ничего не происходило. Чеки при этом формировались корректно, проблема была в связке виджета с платёжным шлюзом. Заодно мы убрали из клиентского интерфейса оплату по счёту и оставили только карту, а у администраторов этот способ остался. Способы оплаты должны настраиваться по ролям.
Интеграция через API. Своя платёжная форма, полный контроль над статусами, возвратами и чеками из кода. Нужна, когда оплату надо связывать с личными кабинетами, 1С и доставкой.
SDK для мобильных приложений. Оплата в мобильном приложении идёт через платёжный SDK провайдера для iOS и Android. Помните про правила сторов: за цифровые товары и услуги Apple и Google берут комиссию до 30% и требуют свою систему оплаты. Физические товары и офлайн-услуги можно проводить через сторонний SDK. Подробнее о выборе стека для платёжных сценариев — в статье React Native или натив.
Фискализация чеков: 54-ФЗ и ОФД
Есть два сценария. Если вы используете электронные чеки ЮKassa, провайдер сам формирует чек и передаёт его в ОФД, а договор с оператором фискальных данных вам не нужен. Если работаете со своей облачной кассой, договор с ОФД заключаете сами, а чек формирует касса по данным из вашей системы.
Частая ошибка — ставка НДС в чеке не совпадает с налоговым режимом. С 2025 года ИП и компании на упрощённой системе налогообложения с доходом свыше 60 млн ₽ в год платят НДС (5%, 7% или 20%), ниже порога ставка — «без НДС». Проверьте ставку в настройках кассы до запуска.
При предоплате формируется чек с признаком предоплаты, при передаче товара — второй чек с полным расчётом. Возврат тоже оформляется отдельным чеком. Тестовый режим провайдера не отправляет данные в реальный ОФД, поэтому после запуска сделайте пару реальных покупок на минимальную сумму и проверьте, что чек дошёл покупателю.
Подписки, тарифы и оплата частями
В Future Volleyball School ученики покупают тарифы на период. Оплата идёт через ЮKassa, она же фискализирует платежи, а все оплаченные периоды видны администратору в админке. В Glinka Digital оплачиваются и отдельные уроки по модели pay-as-you-go, и подписка, тоже через ЮKassa. Для рекуррентных платежей помните: чек формируется при каждом списании.
В сети коворкингов логика сложнее: у одной компании может быть несколько пакетов часов с разными сроками действия. Часы за месяц мы считаем по каждому пакету и потом суммируем, иначе клиент видит в личном кабинете не то, что оплатил.
Оплату частями через «Долями» мы подключали в Xstreet. Клиент хотел дать покупателям рассрочку на дорогие кроссовки, но сервисы рассрочки раз за разом отказывали ему в подключении, пока с «Долями» наконец не удалось договориться. Закладывайте время на согласование с провайдером: техническая часть здесь не самая долгая.
Оплата в приложении Xstreet
Итог заказа, комиссия сервиса, доставка и выбор способа оплаты — карта, Apple Pay, QR.
Связка оплаты с доставкой и статусами заказа
Xstreet — проект, на котором сошлось всё сразу. Вся цепочка «оплата → касса → доставка» заняла около двух месяцев. Само подключение оплаты и фискализации укладывается в месяц. Остальное время ушло на то, что клиенту нужно было управлять чеками: отправлять, отменять, собирать отчёты для бухгалтерии. Всё это пришлось разрабатывать. К тому же Xstreet работает как кассовый агент: после оплаты формируется не два, а три чека — один для реселлера и два для покупателя, а бухгалтерия выгружает отчёты агента.
С доставкой было ещё веселее. Сначала работали со СДЭК, а когда СДЭК взломали и сервис лёг, пришлось в срочном порядке подключать Яндекс Доставку. С ней мы получили новую проблему: посылка регистрировалась в системе Яндекса, курьер приезжал на отправку, а ему говорили, что в их системе такого заказа нет. Вывод: статусы заказа у вас, у платёжки и у службы доставки — три разные модели, и их согласование — отдельная работа, а не «подключение API».
Ещё одно слабое место — уведомление о платеже (вебхук). Если бэкенд ответил провайдеру «200 OK» до того, как обработал платёж, а потом упал, платёж может потеряться: провайдер повторяет уведомление, только если не получил успешный ответ. Отвечайте только после записи в базу и проверяйте идентификатор платежа, чтобы повторное уведомление не создало дубль заказа.
Типичные проблемы, которые мы видели
Человеческий фактор. Самая частая причина сбоев — не код. Менеджеры выставляют счета вне системы, и такие оплаты не подтягиваются, статус не обновляется, фискализация не запускается. Когда сотрудники придумывают свои процессы поверх системы вместо того, чтобы ей пользоваться, выходит плохо. Обучение команды — часть интеграции. Об этом подробнее — в статье про автоматизацию бизнес-процессов.
Автоотмена неоплаченных заказов. Неоплаченные заказы клиента разумно отменять автоматически: в сети коворкингов это 15 минут. Но то же правило задело заказы, которые администратор создавал вручную для юрлиц: такой заказ мог неделю ждать оплаты по счёту и отменялся. Правило пришлось разделить по тому, кто создал заказ.
Чек и учёт — разные звенья. В том же проекте фискализация работала без ошибок, но заказ уходил в 1С только после оплаты, а при создании иностранной организации интеграция с 1С плодила дубли клиентов. Связку с 1С тестируйте отдельно от кассы.
Сбой на стороне провайдера. Однажды ошибка оплаты оказалась сбоем в API ЮKassa, а не в нашем коде. Логи запросов к платёжке экономят часы поиска виноватого.
С чем мы работали
ЮKassa — Future Volleyball School, Glinka Digital, сеть коворкингов. Эквайринг Райффайзенбанка и Тинькофф, «Долями», касса LIFE PAY, СДЭК и Яндекс Доставка — Xstreet. Эквайринг Сбербанка в Казахстане — Fiftyfour: клиент сам выбрал Сбер. Платёжный SDK для iOS — Beeline Kazakhstan.
Чек-лист перед запуском
- Решите, нужна ли интеграция или хватит ссылки на оплату
- Если продаж больше пяти в день — подключите два независимых эквайринга
- Выберите сценарий фискализации: чеки провайдера или своя касса с договором ОФД
- Проверьте ставку НДС под ваш налоговый режим
- Настройте вебхуки: ответ только после записи в базу, проверка идентификатора платежа
- Разведите правила автоотмены для заказов клиента и администратора
- Проверьте связку с 1С и службой доставки отдельно от оплаты
- Проведите реальные покупки на минимальную сумму всеми способами оплаты и проверьте чеки
- Объясните менеджерам, почему счета нельзя выставлять мимо системы
Частые вопросы
Выводы
Интеграция оплаты — это не кнопка, а цепочка «платёж → статус → чек → доставка → учёт». Для маленького проекта достаточно ссылки на оплату от банка или ЮKassa. Когда платежей много, нужны интеграция, два независимых эквайринга и время на согласование статусов между всеми сервисами. По нашему опыту больше всего проблем создают не платёжные системы, а звенья вокруг них и процессы людей.
Если нужно подключить оплату к сайту или приложению и выстроить надёжную цепочку от платежа до чека, обсудите задачу с WAPP.