Частичная оплата, предоплата и депозит в 1С-Битрикс

Не каждая покупка укладывается в схему «нажал кнопку — оплатил всё сразу». Мебель на заказ, техника под клиента, дорогой товар с доставкой, бронь позиции на складе, услуги с этапами — во всех этих случаях магазину удобнее и безопаснее принимать деньги частями: предоплату сейчас, доплату при готовности или получении. Для покупателя это снижает порог входа, для магазина — фиксирует намерение и частично страхует от отказа. Но как только вы уходите от «одной оплаты на всю сумму», всплывает целый пласт вопросов: как вести несколько оплат по заказу, как считать остаток, как бить чеки по 54-ФЗ на аванс и зачёт, как возвращать частичную оплату и как всё это свести с 1С. Эта статья — подробный технический разбор темы «частичная оплата в Битрикс»: сценарии, реализация, чеки, сверка и типичные грабли.

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

Что такое частичная оплата и зачем она магазину

Частичная оплата — это когда стоимость заказа покупатель вносит не одним платежом, а несколькими: часть суммы сейчас, остаток — позже. За внешне простой формулировкой скрывается несколько разных по смыслу ситуаций, и их важно не смешивать. «Внести предоплату 30% за кухню на заказ» и «оставить депозит за бронь последней единицы товара» — это оба случая частичной оплаты, но с разной экономикой, разными правилами возврата и разной фискализацией.

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

Обратная сторона — сложность. Одна оплата на всю сумму — это простая и понятная механика. Как только оплат становится две и больше, появляются вопросы: как считать остаток, когда заказ считается оплаченным, какой чек бить на каждый платёж, что возвращать при отказе, как это увидит покупатель и как всё сойдётся в 1С. Именно поэтому частичную оплату нельзя «включить галочкой» — это проектируемая подсистема, которую выстраивают под конкретные сценарии бизнеса.

Сценарии частичной оплаты: обзор

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

Важно понимать: технически все эти сценарии реализуются через один и тот же механизм — несколько оплат на один заказ. Различаются они не кодом, а бизнес-правилами: суммой первого платежа, порядком и сроками доплат, правилами возврата и удержания, а также признаками расчёта в чеках. Поэтому внедрение начинается не с настройки Битрикса, а с описания сценариев: кто, за что, сколько и когда платит, и что происходит при отказе. Эти правила согласуют с бухгалтером и закрепляют в оферте, и только потом переносят в систему.

Предоплата % и доплата при получении

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

Как это выглядит по шагам в 1С-Битрикс:

1. Оформление заказа. Покупатель собирает корзину и на шаге оплаты выбирает вариант «внести предоплату». Система создаёт первую оплату (Payment) на сумму предоплаты, а не на всю стоимость заказа.
2. Оплата предоплаты. Первая оплата проходит через платёжную систему. Заказ получает статус «частично оплачен» (предоплата внесена, остаток открыт).
3. Чек аванса. На полученную предоплату формируется чек аванса по 54-ФЗ — деньги получены, товар ещё не передан.
4. Готовность / отгрузка. Когда товар готов или доставлен, покупателю предлагается доплатить остаток: в личном кабинете, по ссылке из письма, курьеру или в ПВЗ.
5. Доплата и зачёт. Создаётся вторая оплата на остаток. При передаче товара бьётся чек зачёта аванса, и заказ переходит в статус «оплачен полностью».

Ключевая техническая деталь: сумма первого платежа — это не вся стоимость заказа, а её часть, и система должна корректно понимать, что заказ оплачен не полностью. «Из коробки» витрина Битрикса обычно предлагает оплатить весь заказ, поэтому вариант «внести предоплату» — это доработка оформления: нужно дать выбор суммы (фиксированный процент, фиксированная сумма или выбор покупателя в допустимых пределах), создать оплату на эту часть и правильно рассчитать остаток. Размер предоплаты, порядок доплаты и правила при отказе — это то, что фиксируется в оферте и согласуется с бухгалтером.

Депозит и бронь товара

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

Экономика депозита отличается от простой предоплаты. Депозит может засчитываться в стоимость при выкупе, а при отказе — частично или полностью удерживаться, если так предусмотрено условиями. Именно здесь начинается юридическая зона: правила удержания депозита, сроки брони, порядок возврата — всё это должно быть прямо описано в оферте и согласовано с юристом и бухгалтером. Технически Битрикс позволяет реализовать любой из вариантов, но выбирать правила — не задача разработчика.

С технической стороны бронь через депозит устроена так:

1. Создание брони. Покупатель оформляет бронь на конкретную позицию. Создаётся заказ с депозитом как первой (частичной) оплатой и, как правило, резервируется товар на складе.
2. Оплата депозита и срок. Депозит оплачивается, заказу присваивается статус брони и срок её действия (до какой даты нужно выкупить).
3. Выкуп. В срок покупатель доплачивает остаток — создаётся вторая оплата, депозит засчитывается, товар переходит к выдаче.
4. Просрочка или отказ. Если срок истёк или покупатель отказался, заказ переводится в статус «бронь истекла/отменена», резерв снимается, а депозит возвращается или удерживается по условиям оферты.

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

Аванс за товар под заказ

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

Технически это разновидность схемы «предоплата + доплата», но с важными нюансами:

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

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

Внутренняя рассрочка и оплата частями

Важно сразу развести два разных понятия, которые в быту называют «рассрочкой». Есть банковская рассрочка/кредит — это когда деньги магазину сразу выплачивает банк или сервис (например, BNPL-сервисы), а покупатель уже должен банку. С точки зрения магазина это, по сути, обычная полная оплата от банка, и фискализация идёт по своим правилам. А есть внутренняя рассрочка от продавца — когда покупатель платит магазину напрямую несколькими частями по графику, без участия банка. Именно вторая — частный случай частичной оплаты, о котором мы говорим здесь.

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

• График платежей. Нужно хранить план: сколько платежей, на какие суммы и в какие даты. Обычно это отдельные оплаты или служебные записи, привязанные к заказу.
• Напоминания. Перед каждой датой платежа покупателю уходит напоминание со ссылкой на оплату очередной части.
• Контроль просрочки. Если очередной платёж не внесён, заказ помечается и обрабатывается по регламенту.
• Фискализация каждого платежа. Каждый взнос — это расчёт, который фискализируется; признаки расчёта для рассрочки/постоплаты согласуйте с бухгалтером.

Доплата за дополнительные услуги

Ещё один практичный сценарий частичной оплаты — когда основная сумма за товар оплачена, но потом добавляется отдельный платёж за дополнительные услуги: сборку, подъём на этаж, монтаж, расширенную гарантию, страховку доставки, срочность. По сути это тоже несколько оплат на один заказ, но вторая оплата не «доплата остатка», а платёж за новую позицию-услугу, добавленную в заказ.

Что здесь важно технически:

• Услуга как отдельная позиция. Доп.услуга добавляется в заказ отдельной строкой с признаком предмета расчёта «услуга» и своей ставкой НДС. Это влияет на чек: услуга должна быть проведена корректно, а не «спрятана» в цене товара.
• Отдельная оплата. Если услугу заказывают уже после оплаты товара, на неё создаётся новая оплата — и заказ снова становится «оплачен не полностью», пока услугу не оплатят.
• Изменение суммы заказа. Добавление услуги меняет стоимость заказа. Нужно, чтобы расчёт остатка и статус оплаты корректно пересчитались.
• Чек на услугу. Отдельный платёж за услугу фискализируется своим чеком с признаком «услуга».

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

Как модуль ведёт оплаты по заказу

Чтобы уверенно настраивать частичную оплату, нужно понимать внутреннюю модель модуля «Интернет-магазин». Ключевая идея: заказ и оплата — это разные сущности. Заказ (Order) — это «что купили, кому и на какую сумму». Оплата (Payment) — это «факт получения денег». И одному заказу может соответствовать несколько оплат.

Упрощённо структура выглядит так:

• Заказ (Order). Хранит состав (корзину), общую стоимость, покупателя, свойства, статусы. У заказа есть агрегированный признак оплаты — оплачен он или нет.
• Оплаты (Payment). Коллекция оплат заказа. У каждой оплаты — своя сумма, привязка к платёжной системе и флаг «оплачена». Именно наличие коллекции оплат позволяет вести частичную оплату.
• Отгрузки (Shipment). Отдельная сущность передачи товара. Разделение оплат и отгрузок — то, что делает возможной схему «аванс при оплате, зачёт при отгрузке».
• Статусы. Заказ имеет статус (этап обработки), а признак оплаты показывает, покрыта ли стоимость. Эти два измерения не одно и то же: заказ может быть «в работе» и при этом «оплачен частично».

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

Несколько оплат на один заказ: реализация

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

1. Первая оплата при оформлении. Вместо оплаты всей суммы на шаге заказа создаётся оплата на часть — предоплату/депозит/первый взнос. Сумма определяется правилом (процент, фиксированная сумма или выбор покупателя в допустимых пределах).
2. Расчёт остатка. Остаток = стоимость заказа − сумма проведённых оплат. Эту величину нужно уметь считать в любой момент: она нужна и покупателю, и для создания следующей оплаты.
3. Создание доплаты. Когда приходит время доплаты, создаётся новая оплата на остаток (или на очередную часть по графику). Покупатель оплачивает её через платёжную систему.
4. Обновление признака оплаты. После каждой успешной оплаты пересчитывается, покрыта ли стоимость заказа. Если да — заказ помечается оплаченным полностью, если нет — остаётся частично оплаченным.
5. Смена статуса и события. Изменение оплаченности триггерит нужные действия: пробитие чека, уведомление покупателя, событие для обмена с 1С, снятие/установку резерва.

Отдельно стоит решить, как именно покупатель инициирует доплату. Варианты: кнопка «Доплатить» в личном кабинете, ссылка на оплату из письма/SMS, счёт на доплату для B2B, оплата курьеру при получении. Каждый вариант — это свой путь создания новой оплаты, и их нужно предусмотреть в интерфейсе. Самая частая недоработка — реализовать красивый расчёт остатка, но не дать покупателю удобного способа доплатить: тогда доплаты собираются вручную через менеджеров.

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

Свойства заказа и служебные поля

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

Почему это важно: без явных полей логика частичной оплаты «размазывается» по коду и становится непрозрачной. Когда у заказа есть понятные свойства (тип оплаты, размер предоплаты, срок доплаты), и менеджер, и автоматика, и обмен с 1С работают с одними и теми же данными. Это резко упрощает и поддержку, и отладку. Плюс свойства заказа — это то, что штатно выгружается в 1С при обмене, а значит, тип оплаты и условия могут быть видны и в учётной системе.

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

Платёжные системы и частичная оплата

Частичная оплата опирается на приём платежей, поэтому важно, как настроены платёжные системы. Хорошая новость: с точки зрения платёжной системы каждая оплата (предоплата, доплата, взнос) — это обычный отдельный платёж на свою сумму. То есть платёжной системе всё равно, что этих платежей по заказу несколько: она просто принимает деньги по каждому.

На что обратить внимание при настройке:

• Возможность повторной оплаты по заказу. Витрина и личный кабинет должны позволять инициировать новую оплату по уже существующему заказу, а не только при первом оформлении. Это ключ к кнопке «Доплатить».
• Корректная сумма каждого платежа. В платёжную систему уходит сумма конкретной оплаты (предоплаты/доплаты), а не всего заказа. Ошибка здесь — самый частый баг: доплата уходит на сумму всего заказа.
• Фискализация каждого платежа. Если чек формирует платёжный сервис («касса от платёжки»), нужно проверить, что он корректно бьёт чек аванса и зачёта, а не только «полный расчёт». Не все «кассы от платёжки» одинаково гибки в признаках расчёта.
• Уведомления и статусы. Каждый платёж присылает своё уведомление о статусе; обработчик должен привязать его к нужной оплате заказа, а не к заказу в целом.

Про сам приём онлайн-оплаты и подключение платёжных систем мы подробно писали в статье про подключение ЮKassa, СБП и Т-Кассы — там разобрана механика платежей, на которую частичная оплата надстраивается сверху. Для частичной оплаты к этой механике добавляется главное требование: уметь принимать несколько платежей по одному заказу и правильно связывать каждый с нужной оплатой.

Чеки 54-ФЗ: аванс и зачёт

Фискализация — самая тонкая часть частичной оплаты, потому что каждый полученный платёж по 54-ФЗ, как правило, сопровождается чеком, а признаки расчёта зависят от того, получены ли деньги вперёд и передан ли товар. Ключевое различие 54-ФЗ: момент получения денег и момент передачи товара — это разные события, и при частичной оплате они почти всегда разнесены.

Базовая логика для схемы «предоплата + доплата»:

Иными словами, по заказу с частичной оплатой обычно получается несколько фискальных документов: чек(и) аванса на суммы, полученные до передачи товара, и чек зачёта в момент передачи, который «закрывает» ранее полученные авансы и фиксирует полный расчёт. Если платежей несколько и все они до отгрузки — на каждый бьётся чек аванса, а зачёт делается при передаче. Точная схема зависит от того, как разнесены платежи и отгрузка, поэтому её обязательно проектируют вместе с бухгалтером.

Техническую механику чеков аванса и зачёта, признаки способа и предмета расчёта, работу модуля касс ККМ и типичные ошибки фискализации мы подробно разобрали в отдельной статье про кассовые чеки по 54-ФЗ в 1С-Битрикс. Здесь важно зафиксировать связь: частичная оплата напрямую влияет на то, сколько чеков и какого типа вы пробьёте, а значит, фискализацию нельзя настраивать в отрыве от сценариев оплаты.

Возврат частичной оплаты

Возврат при частичной оплате сложнее, чем при полной, и его почти всегда недооценивают. Причина в том, что нужно понимать: что именно возвращается и от какой суммы считать. Вернуть можно предоплату целиком, часть суммы, депозит (полностью или за вычетом удержания), одну из позиций из нескольких. И каждый вариант имеет свою фискальную и учётную сторону.

Что учесть по возврату частичной оплаты:

• Считаем от проведённых оплат. Возвращать можно только реально полученные деньги. Если внесена только предоплата, вернуть больше неё нельзя — остаток-то ещё не оплачивался.
• Возврат аванса до передачи. Если покупатель отказался до отгрузки, а внесена предоплата, фискализируется возврат аванса и деньги возвращаются в платёжной системе на исходный платёж.
• Частичный возврат после передачи. Если вернули одну позицию из заказа, возвратный чек и сумма возврата считаются по этой позиции, а не по всему заказу.
• Депозит: возврат или удержание. Здесь ключевое — что говорит оферта. Депозит может возвращаться полностью, частично или удерживаться. Это юридическое решение, а система лишь исполняет его: возвращает согласованную часть и фиксирует итог.
• Возвратный чек. Любой возврат денег по 54-ФЗ сопровождается возвратным чеком с суммами и признаками, соответствующими исходной операции.

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

Синхронизация оплат с 1С

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

Как это устроено на уровне логики обмена:

• Оплаты выгружаются в 1С. Каждая оплата (Payment) может передаваться в учётную систему как факт получения денег. При частичной оплате в 1С приходит несколько оплат по одному заказу — ровно те, что проведены на сайте.
• Подтверждение из 1С. Для ряда сценариев (особенно оплата по счёту, B2B) бухгалтерия подтверждает оплату в 1С, и это подтверждение возвращается на сайт, меняя признак оплаты заказа.
• Сумма должна сходиться. Сумма проведённых оплат на сайте обязана совпадать с суммой поступлений по заказу в 1С. Любое расхождение — сигнал ошибки.
• Статусы и этапы. Смена этапов заказа (принят, поступил товар, готов, выдан) синхронизируется, потому что от неё зависит, когда предлагать доплату и когда бить чек зачёта.

Самые болезненные ошибки при частичной оплате возникают именно на стыке с 1С: на сайте заказ «оплачен наполовину», а в 1С — «оплачен полностью» (или наоборот). Причины бывают разные — обмен передал не все оплаты, менеджер в 1С провёл оплату вручную мимо обмена, задвоилось поступление. Результат один: деньги «не сходятся», и разбираться приходится вручную по каждому заказу. Поэтому обмен оплатами при внедрении частичной оплаты настраивают и сверяют отдельно, а не полагаются на то, что «обмен и так работает». Общие принципы обмена заказами и оплатами с учётной системой актуальны и здесь — при частичной оплате они просто становятся строже.

Отображение «оплачено X из Y»

Частичная оплата должна быть понятна не только вам, но и покупателю. Если человек внёс предоплату, он хочет видеть: сколько оплачено, сколько осталось, до какого срока доплатить и как это сделать. Данные для этого уже есть в заказе — нужно только вывести их на витрину.

Что обычно показывают покупателю:

• Прогресс оплаты. «Оплачено X из Y» — наглядно, часто с полоской прогресса или суммами. Считается как сумма проведённых оплат из стоимости заказа.
• Остаток к доплате. Явная сумма «к доплате: Z» — чтобы покупатель не считал сам.
• Срок доплаты / брони. Если есть срок, его показывают: «доплатите до такого-то числа», чтобы человек не потерял окно.
• Кнопка «Доплатить». Главный элемент — способ внести остаток в один клик, создающий новую оплату на нужную сумму.
• История оплат. Для рассрочки и сложных сценариев — список платежей с датами и статусами.

Ключевое требование — цифры на витрине должны совпадать с реальным состоянием заказа. Если покупатель видит «оплачено 5 000», а по факту проведено меньше или больше, это прямой путь к конфликту и валу обращений в поддержку. Поэтому расчёт остатка делают из тех же данных, что и вся система (сумма проведённых оплат), а не из отдельного «нарисованного» поля, которое можно забыть обновить.

Штатный личный кабинет 1С-Битрикс частичную оплату наглядно почти не показывает — он рассчитан на «оплачен/не оплачен». Поэтому блок статуса оплаты с прогрессом, остатком и кнопкой «Доплатить» — это, как правило, доработка личного кабинета и страницы заказа. Она окупается снижением нагрузки на менеджеров: покупатель сам видит, сколько должен, и доплачивает без звонков.

Напоминания о доплате и брошенная доплата

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

Как с этим работают технически:

1. Отслеживание непокрытого остатка. Система регулярно находит заказы, где есть остаток к доплате и наступает/прошёл срок.
2. Напоминания по расписанию. Покупателю отправляются письма, SMS или сообщения в мессенджер со ссылкой на доплату и указанием срока. Обычно несколько напоминаний с нарастающей срочностью.
3. Продление или подтверждение. Покупателю дают возможность продлить бронь или подтвердить намерение, если ему нужно больше времени.
4. Обработка просрочки. Если срок истёк, заказ переводится в отдельный статус («доплата не внесена», «бронь истекла»), резерв снимается, а депозит возвращается или удерживается по оферте.

Здесь частичная оплата смыкается с механикой брошенной корзины, но с важным отличием: деньги уже частично получены, ставки выше, и есть чёткий остаток и срок. Поэтому напоминания о доплате обычно делают настойчивее и конкретнее, чем про брошенную корзину: не «вы что-то забыли», а «по заказу №… осталось доплатить …, срок до …». Для отправки используют те же каналы, что и для остальных уведомлений магазина — email, SMS, мессенджеры.

Безопасность и сверка платежей

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

• Двойная оплата. Повторное нажатие «Доплатить» или дублирующее уведомление платёжной системы не должны создавать лишнюю оплату. Нужна идемпотентная обработка платёжных уведомлений.
• Подмена суммы. Сумма оплаты должна определяться на сервере (из заказа и правила предоплаты), а не приходить с клиента. Иначе можно «доплатить» символическую сумму и получить статус «оплачено».
• Проверка подлинности уведомлений. Уведомления о статусе оплаты от платёжной системы проверяются на подлинность (подпись/секрет), чтобы никто не «подтвердил» оплату поддельным запросом.
• Расхождение с 1С. Регулярная сверка сумм оплат сайта и поступлений 1С ловит ошибки обмена и ручные проводки мимо системы.
• Ограничение переплаты. Система должна корректно вести себя, если суммарно оплатили больше стоимости заказа (например, из-за изменения состава) — не «терять» переплату, а показывать её и давать вернуть.

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

Частичная оплата и оплата по счёту B2B

Для B2B частичная оплата особенно актуальна: работа по предоплате и доплате, авансы под поставку, оплата по счёту частями — обычная практика. И здесь техника частичной оплаты смыкается с механикой оплаты по счёту.

Отличия B2B-сценария:

• Оплата по счёту, а не картой. Юрлицо оплачивает по банковскому счёту, и факт оплаты подтверждается в бухгалтерии/1С, а не мгновенным уведомлением платёжной системы.
• Подтверждение из учёта. Признак «оплачено» по счёту приходит из 1С после того, как бухгалтер увидел поступление. При частичной оплате так же приходят частичные поступления.
• Несколько счетов на заказ. Предоплатный счёт и счёт на доплату — это, по сути, несколько оплат по одному заказу, каждая со своим счётом и подтверждением.
• Документы. Для юрлиц важны корректные счета, акты и закрывающие документы по каждому платежу — это уже зона бухгалтерии.

Механику приёма оплаты по счёту, статусы «выставлен/оплачен», подтверждение из 1С и особенности B2B мы подробно разобрали в статье про оплату по счёту для B2B на 1С-Битрикс. Для частичной оплаты важно, что B2B-сценарий добавляет ещё один канал подтверждения денег — через учётную систему, — и его нужно так же аккуратно свести с признаком оплаты заказа, как и онлайн-платежи.

Частые ошибки

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

• Доплата уходит на сумму всего заказа. Классический баг: кнопка «Доплатить» создаёт оплату на полную стоимость, а не на остаток. Всегда считайте остаток на сервере и передавайте в платёжную систему именно его.
• Не сформирован чек аванса. Приняли предоплату, но чек аванса не пробили — фискальное нарушение. Настройте пробитие чека на событие каждой оплаты и проверьте на тесте.
• «Полный расчёт» вместо аванса. На предоплату бьют чек полного расчёта, хотя товар ещё не передан. Признак способа расчёта должен соответствовать реальному этапу — согласуйте с бухгалтером.
• Статус оплаты не сходится с 1С. На сайте «оплачено наполовину», в 1С — «полностью» или наоборот. Настройте и регулярно сверяйте обмен оплатами, а не полагайтесь на «обмен и так работает».
• Нет способа доплатить. Остаток считается и показывается, но кнопки/ссылки «Доплатить» нет — доплаты собирают вручную. Дайте покупателю удобный способ внести остаток.
• Бронь без резерва. Взяли депозит, но товар не зарезервировали — его купил кто-то другой. Депозит-сценарий обязательно связывают с резервом склада.
• Нет срока и напоминаний. Заказ с непокрытым остатком «висит» бесконечно и морозит товар. Задайте срок доплаты и автоматические напоминания.
• Возврат частичной оплаты не продуман. Приём настроили, возврат — нет. Первый отказ по предоплате превращается в ручную возню. Тестируйте возврат наравне с приёмом.
• Депозит удерживают «на глаз». Правила удержания депозита не описаны в оферте, решения принимаются по ситуации — риск споров и претензий. Пропишите условия с юристом и бухгалтером.
• Сумма считается на клиенте. Сумму доплаты берут из данных браузера — можно подменить. Все суммы считайте на сервере от проведённых оплат.

Чек-лист внедрения

Короткий список, по которому удобно свериться перед запуском частичной оплаты на боевых заказах:

1. Сценарии описаны: какие именно (предоплата+доплата, депозит, аванс, рассрочка, доп.услуги), с суммами, сроками и правилами возврата.
2. Юридическая часть согласована: условия предоплаты, депозита и удержаний закреплены в оферте и проверены бухгалтером и юристом.
3. Несколько оплат на заказ работают: первая оплата на часть суммы, корректный расчёт остатка, создание доплаты.
4. Признак оплаты пересчитывается после каждой оплаты; «оплачен полностью» ставится только при покрытии стоимости.
5. Кнопка «Доплатить» и/или ссылка на доплату реализованы; сумма доплаты считается на сервере (остаток).
6. Чеки 54-ФЗ настроены: чек аванса на предоплату, чек зачёта при передаче; проверены на тестовых чеках.
7. Возврат частичной оплаты протестирован: возврат аванса, частичный возврат, возврат/удержание депозита, возвратный чек.
8. Резерв склада для депозита/брони связан с оплатой и корректно снимается при отмене.
9. Срок и напоминания о доплате настроены; обработка просрочки и брошенной доплаты определена.
10. Отображение «оплачено X из Y» в личном кабинете совпадает с реальным состоянием заказа.
11. Обмен оплатами с 1С настроен и сверен: суммы оплат сайта = суммы поступлений 1С.
12. Безопасность: суммы считаются на сервере, уведомления проверяются, двойная оплата исключена.

Вывод

Частичная оплата в 1С-Битрикс — это не «галочка», а проектируемая подсистема, которая опирается на штатную возможность вести несколько оплат по одному заказу. Технически всё держится на разделении сущностей: заказ отдельно, оплаты отдельно, отгрузка отдельно. На этой основе строятся все сценарии — предоплата с доплатой, депозит и бронь, аванс за товар под заказ, внутренняя рассрочка, доплата за услуги. Различаются они не кодом, а бизнес-правилами: сколько платить, когда, что возвращать и как фискализировать.

Три вещи определяют, будет ли частичная оплата работать без проблем. Первое — корректные чеки 54-ФЗ: аванс при предоплате, зачёт при передаче, возвратный чек при отказе (детали — в статье про кассовые чеки по 54-ФЗ). Второе — понятное покупателю отображение «оплачено X из Y» с кнопкой «Доплатить» и напоминаниями о доплате. Третье — сверка оплат с 1С, чтобы деньги на сайте и в учёте всегда сходились. И над всем этим — юридическая рамка: условия предоплаты, депозита и удержаний обязательно согласуйте с бухгалтером и юристом; техническая настройка лишь переносит их решения в систему.

Если нужна помощь с технической частью — от сценариев оплаты и нескольких платежей на заказ до чеков, возвратов и обмена с 1С — это наша услуга по магазинам с оплатой и доставкой и работа по интеграциям. Другие материалы по теме собраны в рубрике «Оплата и доставка», включая разбор подключения ЮKassa и СБП и оплаты по счёту для B2B.