Фискализация онлайн-платежей через сайт: что нужно знать предпринимателю в РК

Если сайт принимает оплату за товар или услугу, предпринимателю в РК обычно нужно фискализировать расчёт и выдать покупателю электронный чек. Способ оплаты - банковская карта, Kaspi, QR или платёжная ссылка - сам по себе не отменяет эту задачу. Конкретную схему определяют по виду деятельности, налоговому режиму, участникам расчёта и возможностям платёжного сервиса.

Когда онлайн-платёж через сайт нужно фискализировать

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

В схеме участвуют продавец, платёжный сервис, касса и оператор фискальных данных. После успешного расчёта сведения о продаже передаются в кассовую систему, а покупатель получает электронный чек по номеру телефона, адресу электронной почты или другому предусмотренному каналу.

Уведомление банка, квитанция эквайера или сообщение в приложении Kaspi подтверждают движение денег, но не всегда заменяют фискальный чек продавца. Это разные документы. Перед запуском нужно установить, кто формирует чек и каким способом он попадает к покупателю.

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

Какие данные должны попасть в электронный чек

В электронном чеке должны совпадать продавец, сумма и содержание операции. Для интернет-магазина это обычно наименование товара, количество, цена, итог, способ оплаты и реквизиты бизнеса. Если применимо, отдельно отражаются данные по НДС. Одной строки «Оплата заказа» недостаточно, когда покупатель приобрёл несколько разных позиций.

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

До настройки интеграции соберите исходные данные:

• ИИН или БИН продавца, название бизнеса и адрес, используемые в кассовой системе.
• Перечень товаров или услуг с названиями, ценами, единицами измерения и налоговыми параметрами.
• Контакт покупателя для отправки чека: телефон, электронная почта или другой доступный канал.
• Правила расчёта скидок, доставки, подарочных сертификатов, предоплаты и частичной оплаты.
• Сценарии отмены заказа, полного возврата, частичного возврата и корректировки суммы.

Для клиента чек - не единственный нужный документ. Он может ждать ссылку на заказ, уведомление о доставке и понятный статус оплаты. Эти сообщения не заменяют фискальный документ, но их стоит связать с номером заказа. Тогда менеджер быстро находит покупку, чек и историю переписки.

Как выбрать способ фискализации для сайта

Небольшому бизнесу часто подходит виртуальная касса или готовая фискализация внутри платёжного сервиса. Если есть торговая точка, шоурум и курьеры, удобнее согласовать единую схему для офлайн- и онлайн-продаж. Прямую интеграцию по API выбирают при нестандартной платформе, большом ассортименте или сложных возвратах.

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

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

Как связать сайт, Kaspi, эквайринг и ОФД

Рабочая цепочка выглядит так: сайт создаёт заказ, платёжный сервис подтверждает транзакцию, касса регистрирует расчёт, ОФД принимает фискальные сведения, а сайт получает результат и отправляет клиенту чек. Страница «Оплата прошла» не доказывает завершение операции: сервер должен проверить уведомление и статус транзакции.

Интеграцию лучше разбить на отдельные этапы:

• Создание заказа с уникальным номером и сохранением состава корзины до оплаты.
• Переход клиента на страницу платёжного провайдера или открытие платёжного окна.
• Получение серверного уведомления об успешной, отменённой или просроченной транзакции.
• Передача в кассу позиций, суммы, скидки, доставки и контакта покупателя.
• Сохранение номера чека и фискального признака в карточке заказа.
• Отправка клиенту чека и уведомление менеджера, если фискализация завершилась ошибкой.

С Kaspi и другими каналами есть отдельный риск: предприниматель видит деньги в приложении, но не понимает, кто выдаёт чек. Если платёж проходит через ссылку, QR, встроенную кнопку или агрегатор, заранее зафиксируйте роль каждой стороны. Название платёжного сервиса не заменяет техническую и договорную схему.

На сайте не следует хранить данные банковской карты. Платёжный провайдер обрабатывает карточные реквизиты, а сайт сохраняет безопасные идентификаторы заказа и транзакции. Это уменьшает объём чувствительных данных в собственной инфраструктуре и упрощает разбор спорных операций.

Что происходит с возвратом, отменой и частичной оплатой

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

Представим заказ из двух товаров: клиент получил один, а второй вернул. Сайт должен сохранить исходный чек, провести возврат только по возвращённой позиции и показать менеджеру новую сумму. При полной отмене заказ не должен оставаться в базе как оплаченный без связанной возвратной операции.

Чаще всего требуют отдельной проверки такие сценарии:

• частичная предоплата с последующей доплатой;
• скидка на весь заказ при возврате одной позиции;
• доставка, которая возвращается или не возвращается покупателю;
• оплата сертификатом и доплата банковской картой;
• дублирование уведомления от платёжного сервиса;
• повторный запрос после временного сбоя кассы или ОФД.

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

Типичные ошибки при фискализации онлайн-платежей

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

• Чек формируется вручную вечером или на следующий день вместо автоматической регистрации расчёта.
• Страница «Спасибо за оплату» открывается, но сервер не получил подтверждение от эквайера.
• В чек попадает одна общая позиция вместо фактического состава заказа.
• Сумма доставки, скидка или комиссия платёжного сервиса учитывается неправильно.
• Возврат денег проводится в банке, но возвратная операция в кассе не создаётся.
• При сбое нет очереди повторной отправки и уведомления ответственному сотруднику.
• Проверяется только одна сумма, хотя в работе есть промокоды, несколько товаров и частичные возвраты.
• Реквизиты продавца в тестовой и рабочей кассе различаются.

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

До начала работ спросите исполнителя:

• Кто регистрирует кассу и заключает договор с ОФД?
• Кто отвечает за чек при оплате через Kaspi, карту, ссылку и QR?
• Как обрабатывается повторное уведомление от платёжного сервиса?
• Где менеджер увидит ошибку и как запустит повторную фискализацию?
• Как проверяются полный и частичный возвраты?
• Какие операции входят в стоимость, а какие считаются отдельной доработкой?

Чек-лист перед запуском интернет-магазина

Перед публикацией сайта проверьте весь путь заказа - от корзины до чека, а не только тестовую оплату картой. Финальный запуск проводят после сверки кассы, ОФД, эквайера и реквизитов бизнеса. Тесты должны показать, что обычная продажа, ошибка платежа, возврат и повторное уведомление обрабатываются предсказуемо.

• Касса зарегистрирована на нужного предпринимателя или юридическое лицо, а реквизиты совпадают с договором эквайринга.
• Понятно, какой сервис формирует чек и кто передаёт данные в ОФД.
• В тестовом заказе правильно отражаются товар, количество, скидка, доставка и итоговая сумма.
• Чек приходит на указанный телефон или электронную почту, а его номер сохраняется в заказе.
• Повторное уведомление о той же оплате не создаёт второй чек.
• Проверены отказ оплаты, отмена, тайм-аут и повторная попытка.
• Проведены полный и частичный возвраты, включая возврат товара и доставки.
• При недоступности ОФД система фиксирует ошибку и сообщает ответственному сотруднику.
• В админке есть фильтры по номеру заказа, статусу оплаты и статусу фискализации.
• Бухгалтер или налоговый консультант подтвердил применимость выбранной схемы к вашему виду деятельности.

Результат тестов полезно сохранить во внутреннем журнале: дата, номер заказа, сумма, способ оплаты, номер чека, статус и итог возврата. Такая запись помогает найти расхождение между заказами сайта, выпиской банка и кассовой системой без ручного просмотра каждой операции.

Сколько стоит добавить фискализацию при разработке сайта

Стоимость зависит от готовности платёжного модуля и сложности заказов. Простая оплата услуги требует меньше работ, чем магазин с остатками, промокодами, доставкой и частичными возвратами. Точную сумму можно определить после брифа, проверки платформы и описания кассового сценария. Рекламный или кассовый тариф провайдера в цену разработки не входит, если это отдельно не согласовано.

В Pozhidayev новый интернет-магазин проектируют сразу с учётом оплаты, чеков и возвратов. Тогда карточки товаров, корзина, заказы и админка используют одну логику. Стоимость разработки интернет-магазина начинается от 500 000 ₸, срок - от 30 дней. Домен .kz, хостинг и SSL на первый год входят в стоимость разработки.

Если сайт уже работает, сначала нужен аудит CMS, сервера, базы заказов, платёжного модуля и текущей кассовой схемы. Мы работаем из Алматы с клиентами по всему Казахстану, в том числе удалённо, используем Next.js и React, закладываем SEO-структуру и удобную админку. На проект действует гарантия 12 месяцев, предусмотрены два бесплатных круга правок.

Частые вопросы

• Нужно ли пробивать чек, если клиент оплатил через Kaspi? Обычно да, если это расчёт за товар или услугу бизнеса. Нужно отдельно установить, кто формирует чек - ваша касса, платёжный сервис или другой участник схемы.
• Заменяет ли банковская квитанция фискальный чек? Нет. Подтверждение списания денег и фискальный документ выполняют разные функции. Покупателю нужно отправить документ, сформированный зарегистрированной кассовой системой.
• Можно ли отправлять чек вручную после оплаты? Такой порядок рискован: ручная отправка не решает проблему своевременной регистрации расчёта. Исключения и действия при техническом сбое лучше подтвердить с бухгалтером.
• Что делать, если деньги списались, а чек не сформировался? Зафиксировать заказ и транзакцию, не повторять списание, проверить журнал ошибок и запустить предусмотренную повторную передачу. Причину сбоя нужно устранить до следующих продаж.
• Нужна ли фискализация для сайта-визитки? Если на сайте только контакты, описание услуг и заявка без оплаты, отдельный онлайн-чек обычно не формируется за саму заявку. Обязанность связана с расчётом, а не с наличием сайта.
• Кто подключает ОФД - бухгалтер или разработчик? Регистрационные и налоговые вопросы ведёт предприниматель с бухгалтером, а техническую связь сайта, кассы и платёжного сервиса настраивает разработчик. Зоны ответственности фиксируют до запуска.

С чего начать

Начните с карты платежей: чем клиент платит, кто получает деньги, какой документ ему приходит и что происходит при возврате. Затем передайте схему бухгалтеру и разработчику. Если нет ответа хотя бы на один вопрос, запуск оплаты лучше отложить до согласования роли кассы, ОФД, эквайера и сайта.

Мы можем провести технический аудит действующего сайта или заложить фискализацию в новый интернет-магазин - от выбора платёжной связки до тестирования чеков и возвратов. Цена фиксируется после брифа. Поддержка и доработка действующего проекта предоставляются от 50 000 ₸ в месяц.