Покупатель оплатил заказ: как связать mag1c, оплату и учёт в 1С

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

Коротко: включить оплату на витрине недостаточно. Перед запуском проверьте всю цепочку от заказа до результата в учёте.

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

Практические разборы интеграций и проверки перед запуском публикуем в Telegram-канале B2C и канале B2C в MAX: там удобно следить за следующими материалами по интернет-продажам и учёту.

Автор: Редакция B2C. Факты проверены 12 октября 2026 года. Это плановый практический разбор сообщения 1С от 1 октября, а не новость о выпуске функции сегодня.

Обложка — иллюстрация процесса интернет-заказа, созданная с помощью ИИ. Она не показывает интерфейс mag1c или результат реальной оплаты.

Что изменилось в оплате mag1c

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

Сообщение 1С от 01.10.2026 посвящено оплате веб-витрины. В инструкции от 24.09.2026 перечислены интернет-эквайринг, СБП по универсальному платёжному коду, Ozon Pay, Яндекс Пэй, перевод по реквизитам, наличные и карта при получении. Администратор включает нужные варианты. Для юридических лиц описаны реквизиты и СБП по УПК.

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

Существующую витрину не нужно переключать вслепую

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

1С отдельно предупреждает: если существующий магазин намерен пользоваться ЮKassa, наличными и картой, переключаться на новый модуль не следует; прежний продолжит работать. Новым магазинам новый модуль доступен по умолчанию. Это рекомендация производителя, а не наша догадка о совместимости.

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

Три результата, которые нельзя считать одним

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

• Заказ: что покупатель выбрал, в каком количестве, с какой доставкой и итоговой суммой.
• Платёж: какое подтверждение получено от используемого сервиса, к какому заказу относится сумма и завершён ли нужный этап.
• Учёт: появился ли ожидаемый документ в нужной базе и организации, корректны ли товары, суммы и состояние обработки.

Красивое сообщение после возвращения с платёжной страницы — не достаточный контроль для сотрудника, который выдаёт товар. Например, документация ЮKassa различает события успешного платежа, ожидания подтверждения списания и отмены. Это пример устройства платёжного сервиса, не доказательство одинаковых статусов каждого подключения mag1c.

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

Что проверить в обмене с 1С

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

Сервис mag1c описывает передачу товаров из 1С и загрузку заказов обратно. Документация УТ 11.5 связывает настройку с синхронизацией данных и указывает заказы клиентов в разделе «Продажи». Этот путь относится к УТ 11.5: переносить названия меню на УНФ, «Розницу» или ДАЛИОН нельзя.

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

Если магазин работает в ДАЛИОН или использует Frontol на кассе, не считайте их автоматически подтверждёнными участниками этого обмена. Состав решения и точки интеграции проверяются отдельно. Работа витрины не доказывает готовность кассового маршрута.

Пять минут — не срок действия банковского платежа

Возврат к оплате удобен покупателю, но ограничение интерфейса нельзя превращать в правило отмены заказа.

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

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

Контрольный набор B2C перед запуском

Проверяйте не только удачную покупку, но и ситуацию, в которой обычный сотрудник не знает следующий шаг.

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

1. Успешная оплата: один заказ с известным составом. Сопоставьте сумму, подтверждение и учётный документ; запишите результат и идентификаторы без публикации персональных данных.
2. Покупатель отказался: заказ существует, но успешного подтверждения нет. Проверьте, что сотрудник не воспринимает его как разрешение на выдачу.
3. Платёж ещё не завершён: покажите сотруднику, где виден промежуточный результат и кто должен дождаться подтверждения.
4. Повторное открытие оплаты: сначала в пределах описанного интервала, затем после. Проверьте связь с исходным заказом и отсутствие необъяснённых дублей в учёте.
5. Перевод по реквизитам: отделите сформированный счёт от подтверждённого поступления; закрепите ответственного за сверку.
6. Проблема обмена: заказ виден в витрине, но ожидаемого документа в 1С нет. Зафиксируйте причину, повторную обработку и итоговую сверку без слепого повторения операции.

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

Кто разбирает исключения

Неопределённость должна получать ответственного и следующий шаг, а не исчезать в переписке.

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

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

Что входит в подготовку решения B2C

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

Маршрут проекта: проверить текущую учётную систему и программное обеспечение, согласовать товары, склад и цены, определить доступные способы оплаты, настроить обмен, выполнить контрольный набор, обучить сотрудника и сохранить протокол приёмки.

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

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

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

Нужно ли подключить сразу все способы оплаты?

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

Заказ появился в 1С — значит деньги получены?

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

Можно ли автоматически переключить старый магазин на новый модуль?

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

Эта статья заменяет настройку чеков и юридическую проверку?

Нет. Здесь разбираются витрина, платёж и учёт заказа. Требования к оформлению продажи, кассовому маршруту и конкретному договору проверяются отдельно; универсальных фискальных выводов мы не делаем.

Следующий безопасный шаг

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

Следующие контрольные списки по заказам, обменам и работе магазина собираем в Telegram B2C и MAX B2C. Выберите удобный канал, чтобы возвращаться к практическим разборам при настройке своей системы.

Источники: сообщение 1С от 01.10.2026; инструкция по оплате от 24.09.2026; действующая страница mag1c; документация УТ 11.5; документация уведомлений ЮKassa. Прямые ссылки приведены в соответствующих разделах. Актуальность проверена 12.10.2026; доступность функций в конкретной базе до публикации не испытывалась.