Оплаты заказа: настройка и учёт

В 1С-Битрикс оплата заказа — это не одно поле, а отдельная сущность Payment внутри коллекции оплат заказа. Понимание этой модели снимает большинство вопросов: почему заказ считается оплаченным, откуда берётся статус PAID и как корректно провести оплату руками, не сломав учёт.

Разберём объектную модель D7, работу с внутренним счётом и бонусами, ручное проставление оплаты в админке и связку с платёжными системами.

Модель оплат: заказ и коллекция Payment

В ядре продаж (модуль sale) заказ описывается объектом Bitrix\Sale\Order. Деньги живут не в самом заказе, а в дочерней коллекции — PaymentCollection, которую возвращает метод $order->getPaymentCollection(). Каждый элемент коллекции — это объект Bitrix\Sale\Payment, то есть одна конкретная оплата.

Такая архитектура заложена намеренно: на один заказ можно повесить несколько оплат. Классический сценарий — предоплата 30% онлайн и доплата при получении, или оплата частью бонусов и частью картой. Каждая оплата хранит свою сумму (SUM), привязку к платёжной системе (PAY_SYSTEM_ID) и собственный флаг оплаченности.

Общая логика — заказ, коллекция оплат, коллекция отгрузок и коллекция корзины — обрабатывается транзакционно: изменения фиксируются одним вызовом $order->save(). Отдельно сохранять Payment в обход заказа не нужно и не рекомендуется.

Флаг PAID и статус оплаты заказа

У каждой оплаты есть булево поле PAID (значения Y/N). Именно оно определяет, засчитана ли конкретная оплата. Устанавливается флаг не присваиванием напрямую, а методом $payment->setPaid('Y') — так запускается корректная бизнес-логика: фиксируется дата оплаты (DATE_PAID), пользователь-плательщик и суммируется оплаченное по заказу.

На уровне всего заказа есть агрегирующее поле PAYED (историческое написание в API — именно так). Заказ переходит в состояние оплачен, когда суммарно оплаченные Payment покрывают сумму заказа. Проверить это можно методом $order->isPaid().

• $payment->isPaid() — оплачена ли отдельная оплата;
• $order->isPaid() — считается ли оплаченным весь заказ;
• $order->getSumPaid() — сколько уже оплачено по заказу.

Ручное проставление оплаты в админке

Оператор проводит оплату вручную, когда деньги пришли мимо онлайн-эквайринга: наличными, по банковскому счёту или переводом. Делается это в детальной карточке заказа: Магазин → Заказы → [заказ] → вкладка «Оплата».

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

После сохранения Битрикс проставит PAID = Y, зафиксирует дату и пересчитает статус заказа. Если магазин работает с онлайн-кассой, в этот момент штатно формируется чек прихода. Ручная отметка оплаты — легитимный и штатный механизм, а не «костыль»: он проходит по той же бизнес-логике, что и автоматическое зачисление от платёжной системы.

Внутренний счёт и бонусы

Отдельная платёжная система в Битрикс — внутренний счёт покупателя (обработчик inner). Это виртуальный кошелёк: баланс хранится в таблице b_sale_user_account и в объекте Bitrix\Sale\Internals\UserAccount. Покупатель пополняет счёт, а затем оплачивает им заказы полностью или частично.

Технически оплата внутренним счётом — это обычный Payment с PAY_SYSTEM_ID, указывающим на платёжную систему типа «Внутренний счёт». При установке setPaid('Y') ядро само списывает средства с баланса пользователя, а при отмене оплаты — возвращает их. Ручное «жонглирование» балансом через SQL приводит к рассинхрону между b_sale_user_account и историей транзакций.

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

Связь с платёжными системами

Каждая оплата ссылается на платёжную систему через PAY_SYSTEM_ID. Настраиваются они в Магазин → Настройки → Платёжные системы. Одна платёжная система — это набор из бизнес-значения (наличные, безнал, ЮKassa, СБП и т. п.) и обработчика, который умеет формировать форму оплаты и принимать ответ от эквайринга.

Для онлайн-систем ключевую роль играет обработчик результата — служебная страница, которую платёжный шлюз дёргает после успешной транзакции (callback / уведомление). Именно этот запрос, а не редирект покупателя, инициирует setPaid('Y'). Поэтому оплата фиксируется даже если клиент закрыл вкладку, не вернувшись на сайт.

События и учёт: где всё стыкуется

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

• OnSaleOrderPaid / OnSalePaymentEntitySaved — оповещение об оплате: сюда вешают отправку в 1С, письма, задачи в CRM;
• онлайн-касса формирует чек прихода именно по факту setPaid;
• обмен с 1С выгружает признак оплаты — важно, чтобы учёт на сайте и в учётной системе совпадал.

Отсюда практическое правило: оплата и отгрузка — независимые сущности. Заказ может быть оплачен, но не отгружен, и наоборот. Не пытайтесь связать их одним статусом заказа — используйте isPaid() и статус отгрузки раздельно, а бизнес-правила стройте на событиях.

Итог

Оплата в 1С-Битрикс — это коллекция объектов Payment внутри заказа: несколько оплат на заказ, флаг PAID у каждой, агрегирующий признак оплаченности у заказа. Проставлять оплату нужно только через API (setPaid) или штатную админку — тогда корректно спишутся бонусы, пробьётся чек и уйдёт обмен с 1С. Внутренний счёт и бонусы — это те же оплаты, но с виртуальным балансом, а платёжные системы фиксируют оплату по серверному уведомлению, а не по редиректу покупателя.

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