# Инвойсбокс API — Сценарии применения
> Раздел документации целиком. Полное оглавление: https://docs.invoicebox.ru/llms.txt
## Сценарии применения
- [Сценарии и бизнес-кейсы](https://docs.invoicebox.ru/raw/scenarios/scenarios.md)
- [🕓 B2B продажи 24/7](https://docs.invoicebox.ru/raw/scenarios/b2b-sales.md) (раздел «Сценарии и бизнес-кейсы»)
- [✈️ B2B продажи авиабилетов](https://docs.invoicebox.ru/raw/scenarios/air-carriers.md) (раздел «Сценарии и бизнес-кейсы»)
- [🛍️ B2B продажи товаров](https://docs.invoicebox.ru/raw/scenarios/retail.md) (раздел «Сценарии и бизнес-кейсы»)
- [🍽️ Системы автоматизации ресторанов](https://docs.invoicebox.ru/raw/scenarios/ras.md) (раздел «Сценарии и бизнес-кейсы»)
- [🚆 B2B продажи ж/д билетов](https://docs.invoicebox.ru/raw/scenarios/railway-carriers.md) (раздел «Сценарии и бизнес-кейсы»)
- [🏨 Управление средствами размещения (PMS)](https://docs.invoicebox.ru/raw/scenarios/pms.md) (раздел «Сценарии и бизнес-кейсы»)
- [⛽ B2B продажи на АЗС](https://docs.invoicebox.ru/raw/scenarios/gas.md) (раздел «Сценарии и бизнес-кейсы»)
- [🚕 B2B продажи такси и трансфера](https://docs.invoicebox.ru/raw/scenarios/taxi.md) (раздел «Сценарии и бизнес-кейсы»)
- [⭐ B2B продажи бизнес-залов](https://docs.invoicebox.ru/raw/scenarios/business-lounge.md) (раздел «Сценарии и бизнес-кейсы»)
- [☂️ B2B продажи услуг страхования пассажиров](https://docs.invoicebox.ru/raw/scenarios/insurance.md) (раздел «Сценарии и бизнес-кейсы»)
- [📦 Аренда складов, офисов и коворкингов](https://docs.invoicebox.ru/raw/scenarios/warehouses.md) (раздел «Сценарии и бизнес-кейсы»)
- [☁️ Подписки на сервисы для юрлиц (SaaS, хостинг, телеком)](https://docs.invoicebox.ru/raw/scenarios/saas.md) (раздел «Сценарии и бизнес-кейсы»)
- [🧾 Автоматизация дебиторки: счёт, оплата, закрытие](https://docs.invoicebox.ru/raw/scenarios/receivables.md) (раздел «Сценарии и бизнес-кейсы»)
- [🛒 Маркетплейс и сплит-корзина](https://docs.invoicebox.ru/raw/scenarios/marketplace-split.md) (раздел «Сценарии и бизнес-кейсы»)
- [🧩 Приём платежей без разработчика](https://docs.invoicebox.ru/raw/scenarios/no-code.md) (раздел «Сценарии и бизнес-кейсы»)
- [🎓 Корпоративное обучение и ДПО](https://docs.invoicebox.ru/raw/scenarios/education.md) (раздел «Сценарии и бизнес-кейсы»)
- [🎪 Событийная индустрия: конференции и выставки](https://docs.invoicebox.ru/raw/scenarios/events.md) (раздел «Сценарии и бизнес-кейсы»)
- [🏷️ Маркированные товары (Честный знак)](https://docs.invoicebox.ru/raw/scenarios/marked-goods.md) (раздел «Сценарии и бизнес-кейсы»)
- [🚛 Логистика и грузоперевозки](https://docs.invoicebox.ru/raw/scenarios/logistics.md) (раздел «Сценарии и бизнес-кейсы»)
- [⚡ Запрос о платеже (RtP)](https://docs.invoicebox.ru/raw/scenarios/rtp.md) (раздел «Сценарии и бизнес-кейсы»)
- [💳 Холдирование средств](https://docs.invoicebox.ru/raw/scenarios/guarantee.md) (раздел «Сценарии и бизнес-кейсы»)
- [📱 Оплата внутри приложения без платёжной страницы](https://docs.invoicebox.ru/raw/scenarios/in-app.md) (раздел «Сценарии и бизнес-кейсы»)
---
# Сценарии и бизнес-кейсы
# Оплата от юрлиц и ИП: сценарии по отраслям
Инвойсбокс принимает оплату от организаций и ИП и сразу готовит закрывающие документы. Покупатель платит
привычным способом — картой, через СБП, по счёту или с отсрочкой, — а акт, счёт-фактура и УПД уходят его
бухгалтерии сами. Договариваться с каждым банком отдельно не нужно.
## Что это даёт бизнесу
- **Корпоративный покупатель платит так, как ему удобно.** Классическая и ускоренная оплата по счёту,
обещанный платёж, гарантийный фонд, фонд с овердрафтом. [Чем они отличаются](/docs/merchant/payment-instruments/).
- **Документы формируются без участия людей.** Счёт, акт, счёт-фактура и УПД уходят по итогу оплаты в
электронном виде — [как устроен документооборот](/docs/merchant/documentflow/).
- **Отсрочку и риск неплатежа можно отдать платформе.** Покупатель подтверждает оплату сразу, а платит в
течение 30 дней. [Сроки и условия](/docs/terms/).
- **Физлица закрываются тем же вендором.** Чек и онлайн-касса уже внутри:
[схема для физлиц](/docs/merchant/schema/private/), [фискализация по 54-ФЗ](/docs/merchant/fz54/).
## Посмотреть, как это работает
Три интерактивных демо делают настоящие вызовы к демо-контуру. Счёт выставляется, приходит
уведомление, статус в карточке меняется сам. Читать документацию для этого не нужно.
- [Оплата бронирования](/demo/booking/) — гостиница выставляет счёт гостю-юрлицу и видит оплату.
- [Счёт юрлицу из CRM](/demo/crm/) — менеджер закрывает сделку счётом, не выходя из карточки.
- [Касса АЗС](/demo/fuel/) — счёт на лимит по талону и пересчёт по факту налива.
## Отрасли и кейсы
В каждом кейсе разобран путь денег и документов в конкретной отрасли: что происходит с заказом, какие
методы API за этим стоят, что видит покупатель. В подписи сказано, какую механику показывает кейс.
Отрасли, у которых пока нет своего кейса, закрываются теми же методами:
- **НКО, банки и платёжные агрегаторы** — [платёжный инструмент](/docs/payment/): подтверждение оплаты
на своей стороне и банковский вход. Схема подключения продавца через банк или PSP —
[в партнёрском разделе](/docs/partner/payment-service-provider/).
- **Медицина, ДМС и медосмотры** — механика та же, что в
[корпоративном обучении](/docs/scenarios/education/): счёт организации за группу сотрудников,
правка состава до оплаты и возврат с корректировкой после.
## Как подключиться
Четыре пути, от простого к гибкому. Механика везде одна: счёт для юрлица, оплата, документы
автоматически. Меняется только то, кто создаёт заказ.
| Путь | Кому подходит | Что нужно сделать |
|---|---|---|
| [Платёжный виджет](/widgets/) | нужен приём оплаты сегодня, разработчика нет | скопировать код и вставить на страницу |
| [Готовый модуль](/docs/merchant/cms/) | сайт или учётная система на популярной платформе | установить модуль для 1С-Битрикс, Тильды, WooCommerce, amoCRM, iiko |
| [ИИ-агент](/for-agents/) | есть Cursor, Claude Code или другой агент | дать агенту один промпт — интеграцию по API он сделает сам |
| [API и PHP SDK](/docs/merchant/) | заказы создаёт ваша система, нужен полный контроль | четыре вызова базового сценария — [быстрый старт](/quickstart/) |
Счёт может прийти покупателю прямо в приложение банка — это
[Запрос о платеже](/docs/scenarios/rtp/), он работает с любым из путей выше.
Проверить вызовы можно не выходя из документации: на странице каждого метода есть кнопка «Выполнить»,
она работает на демо-магазине. Машиночитаемый контракт — [в разделе схем](/schemas/).
## Перед боевым запуском
- [Уведомление об оплате](/docs/merchant/notification/status/) — как узнать о платеже: запросом к
Инвойсбоксу или уведомлением от него.
- [Чеклист запуска в прод](/go-live/) — идемпотентность, проверка подписи, документы, лимиты.
---
Не нашли свою отрасль или нужный модуль? [Напишите нам](https://www.invoicebox.ru/ru/contacts) —
подскажем ближайший сценарий или разработаем интеграцию под вашу инфраструктуру.
---
# 🕓 B2B продажи 24/7
# B2B-платежи, которые работают на ваш бизнес, а не против него
Покупатель-физлицо платит картой за минуту. Организация в это же время согласовывает счёт, ждёт
платёжного поручения и требует закрывающие документы — и каждый шаг делает человек. Добавьте отсрочку,
расчёты с нерезидентами ([как это работает](https://www.invoicebox.ru/ru/products/belarus)) и
регламенты, по которым нельзя платить иначе.
Инвойсбокс закрывает этот путь целиком: счёт, приём оплаты, поступление денег на расчётный счёт и
передача документов бухгалтерии покупателя. Менеджеру остаются только спорные случаи.
## Сначала - боль. Потом - решение.
Вот что обычно мешает продавать организациям.
- Один счёт занимает у менеджера полдня: договор, акт, накладная, согласование с бухгалтерией,
отправка почтой.
- Клиент просит отсрочку, а продавец не может её дать: работать в долг не на что, отказать — значит
потерять заказ.
- Оплата по счёту нужна всем корпоративным покупателям, но обрабатывать её вручную некому.
- Документы уходят с опозданием, и бухгалтерия клиента возвращается с вопросами.
Дальше — что с каждым из этих пунктов делает Инвойсбокс.
## Как это работает
### Отсрочку можно дать, не работая в долг
Постоплата, отсрочка, обещанный платёж — риск неплатежа берёт на себя Инвойсбокс. Деньги приходят
продавцу в обычный срок, а покупатель рассчитывается по условиям договора: до 30 дней —
[платёжные инструменты](/docs/merchant/payment-instruments/), [сроки расчётов](/docs/terms/).
### Документы формируются из данных заказа
Их не переписывают руками, поэтому расхождений с суммой заказа не бывает. Инвойсбокс оформляет счёт или
счёт-договор, акт выполненных работ, счёт-фактуру и УПД, а отправляет их через ЭДО или Почтой России —
[как устроен документооборот](/docs/merchant/documentflow/).
### Покупатель обслуживает себя сам
Корпоративный покупатель получает ссылку на оплату, выбирает способ — банковский счёт, карта,
[СБП B2B](https://www.invoicebox.ru/ru/products/sbp-b2b),
[Запрос о платеже](/docs/scenarios/rtp/) — и забирает документы без участия менеджера. От счёта до
закрывающих документов заказ проходит сам.
### С чего начинается интеграция
Механика одинакова для любой отрасли и укладывается в четыре вызова:
1. [Создание заказа](/docs/merchant/order/create/) — состав, сумма, данные плательщика-юрлица.
2. Оплата: платёжная страница, [Запрос о платеже](/docs/scenarios/rtp/) или
[холдирование](/docs/scenarios/guarantee/), если сумма уточняется по факту.
3. [Уведомление о смене статуса](/docs/merchant/notification/status/) — сигнал вашей системе
отгружать товар или оказывать услугу.
4. [Возврат](/docs/merchant/refund/create/), когда это нужно; закрывающие документы Инвойсбокс
формирует и отправляет [по ЭДО](/docs/merchant/documentflow/) сам.
Без разработки те же шаги закрывают [платёжный виджет](/docs/merchant/widget) и
[готовые модули CMS](/docs/merchant/cms).
## Что меняется в процессе
- Деньги поступают на расчётный счёт на следующий рабочий день после подтверждения оплаты —
[сроки расчётов](/docs/terms/).
- Постоянному покупателю можно дать отсрочку до 30 дней, а риск неплатежа взять на систему —
[платёжные инструменты](/docs/merchant/payment-instruments/).
- Счёт, акт, счёт-фактуру и УПД система формирует и отправляет сама —
[документооборот](/docs/merchant/documentflow/).
- Оплату принимает не менеджер по почте, а сайт или учётная система: счёт выставляется вызовом API
или [виджетом](/widgets/).
## Что закрывает какую задачу
Ниже — та же четвёрка препятствий из начала страницы и то, чем каждое снимается.
| Ваша боль | Наше решение |
|-----------------------------------------------------|---------------------------------------------------------------------------------------------|
| Хочу давать отсрочку, но боюсь не получить деньги | **[Обещанный платёж и Гарантийный фонд](/docs/merchant/payment-instruments/)** - мы платим вам сразу, клиент платит нам позже |
| Ручной документооборот тормозит сделки | **Полная автоматизация документов** - счёт, акт, счёт-фактура, УПД, ЭДО - всё в один клик |
| Клиенты хотят оплату по счёту, а у меня нет времени | **[Ускоренная оплата по счёту, СБП B2B и Запрос о платеже](/docs/merchant/payment-instruments/)** - клиент получает ссылку и оплачивает удобно по счёту, через [СБП B2B](https://www.invoicebox.ru/ru/products/sbp-b2b), [Запрос о платеже](/docs/scenarios/rtp/), банк-клиент |
| Нет интеграции с сайтом | **[Платёжный виджет и Инвойсбокс Кассир](/widgets/)** - выставляйте счета вручную или через приложение «[Инвойсбокс Кассир](https://www.invoicebox.ru/ru/products/kassir)» |
| Хочу привлечь СМБ, но у них сложные процессы | **Мы - доверенный платёжный агент** - упрощаем взаимодействие с юрлицами и ИП |
## С чего начать
[Заполните форму](https://www.invoicebox.ru/ru/contacts) - и мы покажем, как Инвойсбокс сэкономит вам время, деньги и нервы.
> В случае, если у вас возникли вопросы, пожалуйста, [обратитесь к специалистам](https://www.invoicebox.ru/ru/contacts)
> системы Инвойсбокс. Мы ответим на любые ваши вопросы!
## Читайте также
- [Быстрый старт](/quickstart/)
---
# ✈️ B2B продажи авиабилетов
# Автоматизация продаж авиабилетов юридическим лицам и ИП (b2b)
Командировка начинается с брони, а бронь живёт по тайм-лимиту: часы, иногда меньше. Корпоративный
клиент в это время ждёт счёт, потому что карту компания сотруднику не выдаёт.
Инвойсбокс закрывает этот разрыв: счёт выставляется сразу после бронирования, оплата подтверждается за
минуты, а закрывающие документы уходят бухгалтерии клиента без участия ваших менеджеров.
Что это даёт перевозчику:
- корпоративный клиент оплачивает билет привычным способом — по счёту, с отсрочкой или картой;
- деньги приходят на счёт на следующий рабочий день после подтверждения оплаты ([сроки](/docs/terms/));
- отчётные документы формируются после оплаты и уходят бухгалтерии клиента; какие именно — зависит от
вида перевозки, [подробнее ниже](#автоматизированный-документооборот);
- срок оплаты счёта задаёт сама система бронирования — через поле `expirationDate` при [создании заказа](/docs/merchant/order/create/).
### Оплата бронирований с любым тайм-лимитом
Способы оплаты Инвойсбокс для организаций и ИП позволяют корпоративным клиентам оплачивать электронные
билеты с любым тайм-лимитом (от одной минуты), открывая возможность покупки билетов по промо- и бюджетным тарифам
так же, как при покупке с помощью банковской карты.
Подтверждение оплаты приходит авиакомпании за считанные минуты — с той же скоростью, что при оплате
картой. Короткий тайм-лимит перестаёт быть причиной отказывать корпоративному клиенту в оплате по счёту.
Постоянные корпоративные клиенты могут получить отсрочку до 30 дней, при этом авиаперевозчик гарантированно
получает денежные средства на следующий рабочий день после подтверждения оплаты бронирования.
### Отчётность по правилам авиакомпании
Отчёты приходят перевозчику в том формате, который принят у него: состав полей и разбивку можно
расширить или собрать по требованиям авиакомпании при подключении. Бухгалтерии и отделу
взаиморасчётов не приходится переделывать выгрузки под новый способ оплаты.
### Обработка возвратов
Сервис Инвойсбокс поддерживает как автоматизированное оформление возвратов, так и в ручном режиме через
личный кабинет. Денежные средства по возврату зачисляются клиенту до двух рабочих дней — срок зависит от способа оплаты.
### Автоматизированный документооборот
Отчётные документы формируются автоматически после подтверждения оплаты, а оригиналы уходят
[каналами ЭДО](/docs/merchant/documentflow/) или в бумажном виде почтой. Состав документов зависит от
вида перевозки.
| Что продано | Отчётные документы |
|---|---|
| Регулярная перевозка | отчёт о переводе средств и маршрут-квитанция электронного билета |
| Чартер, грузоперевозка | акт, счёт-фактура или УПД |
Для регулярных перевозок акт и счёт-фактура не выпускаются: расходы клиент подтверждает
маршрут-квитанцией, а расчёты — отчётом о переводе средств. Поэтому в квитанции важно, чтобы был
выделен НДС.
### Работа с динамическим ценообразованием
Схема интеграции предполагает возможность изменения стоимости бронирования до момента его оплаты. На каждом этапе
оплаты от формирования счёта до его оплаты негативные сценарии отрабатываются как автоматически с использованием
информирования клиента, так и с привлечением специалистов службы клиентской поддержки.
Штатные ситуации — недоплата, просрочка тайм-лимита, отмена брони — отрабатываются автоматически: клиент получает
уведомление, а система бронирования — [сообщение о смене статуса заказа](/docs/merchant/notification/status/).
Комиссию за приём оплаты можно разделить между перевозчиком и покупателем в нужной пропорции или целиком
переложить на покупателя — тогда в счёте она идёт отдельной строкой.
Специалист поддержки Инвойсбокс подключается там, где автоматика бессильна: нестандартное билетооформление,
спорная оплата, ручной возврат.
### Схема взаимодействия с клиентом
- После того, как заказ/бронь сформирована, клиент переходит на страницу выбора способа оплаты. Как правило, мы
предлагаем перевозчику разместить на сайте дополнительный способ: "Оплата по счёту для организаций и ИП".
- Если клиент выбирает способ оплаты "Оплата по счёту для организаций и ИП", система бронирования
[создаёт заказ](/docs/merchant/order/create/) в Инвойсбокс, передавая состав перелёта и данные бронирования.
Номер брони (PNR) и тайм-лимит удобно положить в [метаданные заказа](/docs/merchant/order/metadata/) —
они вернутся во всех уведомлениях и в закрывающих документах.
- В зависимости от тайм-лимита (TL) бронирования, система автоматически формирует набор доступных способов оплаты.
Тайм-лимит у бронирования может быть любой.
- Если тайм-лимит короткий, подойдёт обещанный платёж: покупатель подтверждает заказ картой, сумма
счёта блокируется, билет оформляется сразу, а счёт уходит организации со сроком оплаты пять суток —
[платёжные инструменты для B2B](/docs/merchant/payment-instruments/). Отдельная механика —
[подтверждение оплаты кодом](/docs/merchant/guarantee/) из гарантийного фонда: она не блокирует
средства на карте, а списывает их с фонда постоянного покупателя.
- Если тайм-лимит свыше 24х часов, то ко всем возможностям, описанным выше, добавляется простой выпуск счёта с ожиданием
оплаты в течение суток.
- После оплаты счёта в срок бронирования Инвойсбокс отправляет системе перевозчика
[уведомление об оплате](/docs/merchant/notification/status/); по нему оформляется билет и сопутствующие услуги.
Тайм-лимит истёк, а деньги не пришли — заказ можно
[отменить](/docs/merchant/order/delete/) и освободить бронь.
- Отчётные документы оформляет и отправляет клиенту система Инвойсбокс — по регулярным перевозкам это
отчёт о переводе средств и маршрут-квитанция с выделенным НДС. Дополнительной нагрузки на бухгалтерию
авиакомпании запуск нового способа оплаты не создаёт.
- Возврат по вынужденному или добровольному отказу оформляется
[методом возврата](/docs/merchant/refund/create/). Если авиакомпания удерживает сбор, возврат проводится
[с корректировкой](/docs/merchant/refund/correction/): клиент получает разницу, а в закрывающих документах
остаётся удержанная сумма. Деньги уходят клиенту до двух рабочих дней после уведомления от перевозчика, в зависимости от способа оплаты.
### Проработанные интеграции
Интеграция Инвойсбокс отработана с решениями таких лидеров отрасли как [Сирена-Тревел (МПС)](/docs/merchant/pss/mps/), [ТАИС TravelShop](/docs/merchant/pss/tais/), SITA, Amadeus, Sabre.
Для настройки интеграции, пожалуйста, [напишите нам](https://www.invoicebox.ru/ru/contacts).
---
# 🛍️ B2B продажи товаров
# Автоматизация продаж товаров юридическим лицам и ИП (b2b)
Оптовый заказ редко уезжает целиком: часть товара отгружается сегодня, часть через неделю, а чего-то
не оказывается на складе вовсе. Покупатель должен заплатить за то, что доехало, и получить документы на
эту же сумму.
Инвойсбокс держит и то и другое: счёт организации с отсрочкой, отгрузки частями и корректировка, когда
привезли меньше, чем в счёте.
Что это даёт продавцу:
- покупатель-организация оплачивает заказ по счёту, с отсрочкой до 30 дней или картой;
- деньги приходят на счёт на следующий рабочий день после подтверждения оплаты ([сроки](/docs/terms/));
- счёт, акт и УПД формируются автоматически — ваша бухгалтерия к этому не подключается;
- отгрузку частями и возвраты закрывают [отгрузки](/docs/merchant/order/shipment_create/) и [корректировки](/docs/merchant/refund/correction/).
### Оплата заказов с любым сроком оплаты
Способы оплаты Инвойсбокс для организаций и ИП позволяют корпоративным клиентам оплачивать заказы
с любым сроком оплаты (от одной минуты). Магазину нет необходимости резервировать товар на складе
на длительное время.
Постоянные корпоративные клиенты могут получить отсрочку до 30 дней, при этом продавец гарантированно
получает денежные средства на следующий рабочий день после подтверждения оплаты заказа.
### Обработка возвратов
Сервис Инвойсбокс поддерживает как автоматизированное оформление возвратов, так и в ручном режиме через
личный кабинет. Денежные средства по возврату зачисляются клиенту до двух рабочих дней — срок зависит от способа оплаты.
### Автоматизированный документооборот
Отчётные документы для клиента формируются автоматически после подтверждения оплаты заказа, а оригиналы
могут быть отправлены в бумажном виде по почте или [каналам ЭДО](/docs/merchant/documentflow/). Дополнительно
см. [схему документооборота](/docs/merchant/schema/commission/).
### Схема взаимодействия с клиентом
- После того, как заказ сформирован, клиент переходит на страницу выбора способа оплаты. Как правило, мы
предлагаем разместить на сайте дополнительный способ: "Оплата по счёту для организаций и ИП".
- Если клиент выбирает способ оплаты "Оплата по счёту для организаций и ИП", ваша система передаёт в систему
Инвойсбокс состав заказа и данные для формирования счёта на оплату.
- В зависимости от срока оплаты заказа, система автоматически формирует набор доступных способов оплаты.
Срок оплаты у заказа может быть любой.
- После получения подтверждения оплаты по счёту в течение срока действия заказа, информация об оплате передаётся
в систему учёта Магазина, происходит отгрузка товара, оформление и обмен документами.
- Все закрывающие документы оформляет и отправляет клиенту система Инвойсбокс. Никакой дополнительной нагрузки на
вашу бухгалтерию, связанной с запуском нового способа оплаты, не возникает.
- Ваша учётная система может передавать информацию о возврате средств клиенту. Обычно после получения
уведомления деньги возвращаются до двух рабочих дней — срок зависит от способа оплаты.
## Отгрузка партиями: платит за то, что доехало
Корпоративный заказ редко уезжает одной машиной. Часть позиций на складе, часть под заказ, что-то
приедет через неделю — а счёт и закрывающие документы клиент ждёт по факту поставки.
1. Заказ создаётся целиком — [создание заказа](/docs/merchant/order/create/) со всей корзиной.
2. Каждая партия оформляется [отгрузкой](/docs/merchant/order/shipment_create/) с фактическим составом:
что уехало, в каком количестве, по какой цене.
3. Состав отгрузки уточняется [изменением отгрузки](/docs/merchant/order/shipment_update/) —
пересорт и недовоз фиксируются до закрытия документов.
4. Позиции, которых не оказалось, снимаются
[возвратом с корректировкой](/docs/merchant/refund/correction/): клиент получает разницу,
а в УПД остаётся фактически поставленное.
Если товара нет и отгрузка невозможна, продавец сообщает об этом
[уведомлением о невозможности отгрузки](/docs/merchant/notification/shipping-unavailable/) —
Инвойсбокс вернёт деньги клиенту, не дожидаясь обращения в поддержку.
## Регулярные поставки
Для постоянных клиентов со стабильным заказом подойдёт подписка — шаблон платежа: счёт уходит
покупателю по правилу (период, день или условие), менеджер не напоминает об оплате.
> [!NOTE]
> Организациям адресована именно подписка, а не привязка карты: владелец карты всегда физлицо, и
> сотруднику пришлось бы отчитываться за расход перед бухгалтерией —
> [почему так](/docs/merchant/order/recurring/#почему-для-организаций-регулярность-устроена-иначе).
> Счёт по подписке удобно доставлять [Запросом о платеже](/docs/scenarios/rtp/) — прямо в банковское
> приложение покупателя.
### Проработанные интеграции
Готовые модули: [CMS](/docs/merchant/cms) (1С-Битрикс, WooCommerce, OpenCart и другие),
[ERP и CRM](/docs/merchant/erp), [платёжный виджет](/docs/merchant/widget) без разработки.
Для настройки интеграции, пожалуйста, [напишите нам](https://www.invoicebox.ru/ru/contacts).
---
# 🍽️ Системы автоматизации ресторанов
# Системы автоматизации ресторанов (CRM, ERP, RAS)
Корпоративный гость в зале ресторана хочет уйти с закрывающими документами, а не с чеком на
физлицо. Мини-приложение Инвойсбокс выставляет счёт на организацию прямо со стола — по QR-коду,
номер стола уходит в метаданные заказа, оплата подтверждается на месте, а акт и счёт-фактура
отправляются в бухгалтерию клиента по электронному документообороту.
> [!IMPORTANT]
> Выступая в качестве партнёра Инвойсбокс, оператор системы автоматизации ресторанов получает вознаграждение от оборота — [как оно считается](/docs/partner/#вознаграждение-партнёра).
## Базовая схема взаимодействия
### Подключение ресторана к Инвойсбоксу
В ERP-системе может быть реализована возможность подключения приёма оплаты через систему Инвойсбокс.
При выборе такой опции ERP-система сможет направить по API [приглашение](/docs/partner/integration/invite/)
для прохождения процедур регистрации ресторана в системе Инвойсбокс. Приглашение будет отправлено
представителю по электронной почте.
По завершении регистрации система Инвойсбокс направит представителю ресторана специальный
код активации. С помощью кода активации ERP-система сможет получить [параметры авторизации](/docs/partner/integration/activation/), необходимые для дальнейшего использования API.
### Оформление заказа и счёта на оплату
После активации функции приёма платежей в кассах ресторана размещается способ оплаты **Оплата по счёту для организаций и ИП**.
**Сценарий с участием официанта**
Гость желает рассчитаться за обед как организация или ИП, сообщает об этом официанту.
При выборе способа расчёта на кассе (оплата по счёту) ERP-система [формирует заказ](/docs/merchant/order/create/)
от имени ресторана в системе Инвойсбокс, передавая состав заказа для оформления счёта и отчётных документов
(например, актов).
Официант выносит гостю пречек с QR-кодом. В QR-коде кодируется ссылка для перехода на платёжный шлюз. Ссылку возвращает [создание заказа](/docs/merchant/order/create/) — поле `paymentUrl`.
Гость сканирует QR-код и подтверждает оплату в приложении Инвойсбокс или мобильном браузере. После оплаты
заказ считается закрытым, а в ERP-систему поступает
[уведомление о смене статуса](/docs/merchant/notification/status/).
Если счёт открыт заранее — гость заказывает в течение вечера, а сумма растёт, — вместо оплаты по пречеку
подойдёт [холдирование](/docs/scenarios/guarantee/): при открытии стола резервируется предполагаемая сумма
[заказом с холдированием](/docs/merchant/order/hold/), а по закрытию списывается фактический счёт.
Блокировка средств — не оплата: деньги остаются у гостя до списания.
**Сценарий без участия официанта**
Ресторан формирует для каждого стола специальный статичный QR-код. QR-код может быть размещён в информационном
тейбл тенте. За таким QR-кодом стоит мини-приложение: гость открывает его, видит текущий счёт стола, а система
автоматизации [создаёт заказ](/docs/merchant/order/create/) с номером стола в
[метаданных](/docs/merchant/order/metadata/) — по нему счёт находится и закрывается без участия официанта.
Гость желающий рассчитаться за обед как организация или ИП, сканирует QR-код. Система Инвойсбокс запрашивает по
номеру стола актуальную корзину заказа для оплаты в кассовой системе. Пользователь подтверждает оплату заказа,
стол закрывается.
Система Инвойсбокс перечисляет денежные средства консолидированным платежом на следующий рабочий день на
расчётный счёт ресторана, а оператору ERP-системы - вознаграждение.
## Размещение информации в маркетплейсе Инвойсбокс
Информация о ресторане или множестве ресторанов может быть опубликована в [маркетплейсе Инвойсбокс](/docs/marketplace).
Маркетплейс Инвойсбокс позволит привлечь дополнительный поток клиентов за счёт продвижения информации на ресурсах сервиса
и его партнёров.
При наличии веб-витрины ресторана в ERP-системе (например, доставка еды или бизнес-ланчей) форма заказа может быть
размещена в маркетплейсе в виде [мини-приложения](/docs/marketplace/mini-apps/), реализованного на стороне ERP-системы.
Для дополнительной информации см. [схему взаимодействия](/docs/marketplace/mini-apps/schema/).
> В случае, если у вас возникли вопросы, пожалуйста, [обратитесь к специалистам](https://www.invoicebox.ru/ru/contacts)
> системы Инвойсбокс. Мы ответим на любые ваши вопросы!
---
# 🚆 B2B продажи ж/д билетов
# Автоматизация продаж ж/д билетов юридическим лицам и ИП (b2b)
У железной дороги свои правила: тайм-лимит брони короче авиационного, а сервисный сбор агентства
покупателю не возвращается. Оплата по счёту должна успеть в этот срок.
Инвойсбокс выставляет счёт организации сразу и подтверждает оплату до истечения тайм-лимита; акт и
счёт-фактура уходят клиенту по ЭДО после оплаты.
Что это даёт перевозчику:
- корпоративный клиент оплачивает билет по счёту, с отсрочкой или картой, не покидая сайт;
- деньги приходят на счёт на следующий рабочий день после подтверждения оплаты ([сроки](/docs/terms/));
- закрывающие документы формируются после оплаты и уходят клиенту по ЭДО;
- срок оплаты равен тайм-лимиту брони и задаётся полем `expirationDate` при [создании заказа](/docs/merchant/order/create/).
### Оплата бронирований с любым тайм-лимитом
Способы оплаты Инвойсбокс для организаций и ИП позволяют корпоративным клиентам оплачивать электронные
билеты с любым тайм-лимитом (от одной минуты), открывая возможность покупки билетов по промо- и бюджетным тарифам
так же, как при покупках с помощью банковской карты.
Постоянные корпоративные клиенты могут получить отсрочку до 30 дней, при этом перевозчик гарантированно
получает денежные средства на следующий рабочий день после подтверждения оплаты бронирования.
### Подтверждение за минуты и отчёты в своём формате
Подтверждение оплаты приходит перевозчику за считанные минуты — так же быстро, как при оплате картой,
поэтому короткий тайм-лимит не мешает продавать корпоративному клиенту по счёту
([платёжные инструменты](/docs/merchant/payment-instruments/)).
Отчёты приходят в том формате, который принят у перевозчика: состав полей и разбивку можно расширить
или собрать по его требованиям при подключении.
### Обработка возвратов
Сервис Инвойсбокс поддерживает как автоматизированное оформление возвратов, так и в ручном режиме через
личный кабинет. Денежные средства по возврату зачисляются клиенту до двух рабочих дней — срок зависит от способа оплаты.
### Автоматизированный документооборот
Отчётные документы для клиента формируются автоматически после подтверждения оплаты бронирования, а оригиналы
могут быть отправлены в бумажном виде по почте или [каналам ЭДО](/docs/merchant/documentflow/).
### Работа с динамическим ценообразованием
Схема интеграции предполагает возможность изменения стоимости бронирования до момента его оплаты. На каждом этапе
оплаты от формирования счёта до его оплаты негативные сценарии отрабатываются как автоматически с использованием
информирования клиента, так и с привлечением специалистов службы клиентской поддержки.
Штатные ситуации отрабатываются автоматически: клиент получает уведомление, а система бронирования —
[сообщение о смене статуса заказа](/docs/merchant/notification/status/). Специалист поддержки подключается
там, где автоматика бессильна: нестандартное оформление, спорная оплата, ручной возврат.
### Схема взаимодействия с клиентом
- После того, как заказ/бронь сформирована, клиент переходит на страницу выбора способа оплаты. Как правило, мы
предлагаем перевозчику разместить на сайте дополнительный способ "Оплата по счёту для организаций и ИП".
- Если клиент выбирает способ оплаты "Оплата по счёту для организаций и ИП", система бронирования передаёт в систему
Инвойсбокс состав заказа и данные бронирования для формирования счёта на оплату.
- В зависимости от тайм-лимита (TL) бронирования система автоматически формирует набор доступных способов оплаты.
Тайм-лимит у бронирования может быть любой.
- Если тайм-лимит короткий, оплату подтверждают до прихода денег: обещанным платежом (сумма счёта
блокируется на карте, счёт уходит организации на пять суток) или из гарантийного фонда — см.
[платёжные инструменты для B2B](/docs/merchant/payment-instruments/). Билет оформляется сразу вместе
со счётом.
- Если тайм-лимит свыше 24х часов, то ко всем возможностям, описанным выше, добавляется простой выпуск счёта с ожиданием
оплаты в течение суток.
- После получения подтверждения оплаты по счёту в течение срока действия бронирования, информация об оплате передаётся
в систему бронирования, происходит оформление билета и иных документов (например, при оплате дополнительных услуг).
- Все закрывающие документы оформляет и отправляет клиенту система Инвойсбокс. Важно, чтобы в билете был
выделен НДС. Никакой дополнительной нагрузки на бухгалтерию перевозчика, связанной с запуском нового способа оплаты, не возникает.
- Система бронирования может передавать информацию о возврате средств клиенту от перевозчика. Обычно после получения
уведомления от перевозчика деньги возвращаются до двух рабочих дней — срок зависит от способа оплаты.
## Чем железная дорога отличается от авиа
- **Короткий тайм-лимит.** Места в поезде удерживаются минутами, а не часами: пока корпоративный
клиент согласует счёт, бронь сгорает. Поэтому основной режим — оплата с подтверждением до прихода
денег: [обещанный платёж](/docs/merchant/payment-instruments/),
[подтверждение кодом](/docs/merchant/guarantee/) из гарантийного фонда или
[холдирование](/docs/scenarios/guarantee/). Билет оформляется сразу, деньги списываются после.
- **Сервисный сбор возвращается не всегда.** Возврат билета почти всегда частичный, и удержание
зависит от тарифа. Оформляйте [возврат с корректировкой](/docs/merchant/refund/correction/):
клиент получает разницу, а в закрывающих документах остаётся удержанная сумма.
- **Поездка редко бывает одна.** Командировка — это билеты туда и обратно, иногда с пересадками
и постельным бельём отдельной позицией. Чтобы бухгалтерия клиента получила один счёт вместо
четырёх, объедините заказы [контейнером](/docs/merchant/order/create-order-container/).
- **Номер заказа перевозчика** удобно передавать в [метаданных](/docs/merchant/order/metadata/) —
он вернётся в уведомлениях и попадёт в документы, по которым клиент сверяет поездки.
### Проработанные интеграции
Решение Инвойсбокс отработано с такими системами, как "Экспресс".
Для настройки интеграции, пожалуйста, [напишите нам](https://www.invoicebox.ru/ru/contacts).
## Читайте также
- [Оформление возврата](/docs/merchant/refund/create/)
---
# 🏨 Управление средствами размещения (PMS)
# Cистемы управления гостиницами, отелями и хостелами (PMS)
Гость бронирует номер, а платит за него компания: командировку оформляет работодатель, и ему нужен счёт
с реквизитами, акт и счёт-фактура. Пока документы едут по почте, номер уже занят и выезд состоялся.
Инвойсбокс встраивает в систему управления оплату картой, через СБП и по счёту для организаций и ИП.
Физлицу уходит [фискальный чек по 54-ФЗ](/docs/merchant/fz54/), организации — отчётные документы через
ЭДО, курьером или почтой.
> [!IMPORTANT]
> Выступая в качестве партнёра Инвойсбокс, оператор PMS получает вознаграждение от оборота — [как оно считается](/docs/partner/#вознаграждение-партнёра).
## Подключение средств размещения к Инвойсбоксу
В системе PMS может быть реализован автоматическое подключение средства размещения и запуск приёма оплаты
через систему Инвойсбокс. При выборе такой опции система PMS направляет по API [приглашение](/docs/partner/integration/invite/)
для прохождения регистрации средства размещения в системе Инвойсбокс. Приглашение будет отправлено
представителю средства размещения по электронной почте.
По завершении регистрации система Инвойсбокс направит представителю средства размещения специальный
код активации. С помощью кода активации система PMS получит [параметры авторизации](/docs/partner/integration/activation/),
необходимые для дальнейшего использования API от имени средства размещения.
## Оформление заказа и счёта на оплату
После активации функции приёма платежей на странице выбора способа оплаты бронирования размещаются
опции выбора - **Оплата онлайн** и **Оплата по счёту для организаций и ИП**. В системе PMS может быть
отрегулировано отображение той или иной опции. С точки зрения API, регулирование опции происходит за
счёт передачи параметра - [тип плательщика](/docs/merchant/order/create/#customer).
При выборе опции оплаты система PMS [формирует заказ](/docs/merchant/order/create/) от имени средства размещения
в системе Инвойсбокс, передавая параметры бронирования в [специальных метаданных](/docs/merchant/order/metadata/#данные-бронирования-места-проживания),
а также даты заселения и выезда для корректного оформления отчётных документов (например, акта, УПД и пр.) и тип плательщика.
После успешного формирования заказа система PMS переадресует гостя на платёжную страницу системы Инвойсбокс для подтверждения
оплаты заказа.
Так выглядит заказ на проживание: состав — ночи и допуслуги, в метаданных — бронь, номер и даты,
по которым бухгалтерия гостя поймёт, за что заплатила.
``` json
{
"merchantId": "01f1c3f8-0000-0000-0000-000000000001",
"merchantOrderId": "PMS-2026-04817",
"amount": "24800.00",
"currencyId": "643",
"description": "Проживание, Гранд Отель Европа, 12–14 августа",
"expirationDate": "2026-08-10T18:00:00+03:00",
"customer": {
"type": "legal",
"name": "ООО «Ромашка»",
"vatNumber": "7701234560",
"email": "buh@example.invbox.ru"
},
"basketItems": [
{
"sku": "ROOM-DBL",
"name": "Двухместный номер, 2 ночи",
"quantity": 2,
"amount": "22000.00",
"vatCode": "RUS_VAT22",
"measure": "сут."
},
{
"sku": "BREAKFAST",
"name": "Завтрак",
"quantity": 4,
"amount": "2800.00",
"vatCode": "RUS_VAT22",
"measure": "шт."
}
],
"metaData": {
"@type": "ReservationPackage",
"subReservation": [
{
"@type": "LodgingReservation",
"reservationId": "YQVM18",
"reservationStatus": "https://schema.org/ReservationConfirmed",
"checkinTime": "2026-08-12T14:00:00+03:00",
"checkoutTime": "2026-08-14T12:00:00+03:00"
}
]
}
}
```
Полный список полей брони — в [метаданных заказа](/docs/merchant/order/metadata/#данные-бронирования-места-проживания),
структура запроса целиком — на странице [создания заказа](/docs/merchant/order/create/).
После подтверждения оплаты заказа гость возвращается на страницу системы PMS, а система Инвойсбокс
асинхронно направляет [уведомление об оплате](/docs/merchant/notification), оплата бронирования подтверждается.
Гость получает ваучер или иной подтверждающий бронирование документ.
Система Инвойсбокс перечисляет денежные средства консолидированным платежом на следующий рабочий день на
расчётный счёт средства размещения, а оператору системы PMS - вознаграждение.
При выезде гостя из отеля, система PMS может [передать информацию](/docs/merchant/order/update/) об актуальной
стоимости проживая и дополнительных услугах, которые были предоставлены гостю. Актуальные сведения необходимы для
корректного формирования отчётных документов (в зависимости от типа плательщика).
В системе PMS могут быть также реализованы функции [отмены заказа](/docs/merchant/order/delete/) или
[оформления возврата](/docs/merchant/refund). Если отель удерживает часть суммы за поздний отказ,
возврат оформляется [с корректировкой](/docs/merchant/refund/correction/) — удержание остаётся
в закрывающих документах.
Акт, счёт-фактуру и УПД Инвойсбокс формирует сам и отправляет корпоративному гостю
[по каналам ЭДО](/docs/merchant/documentflow/) — отелю подключать оператора отдельно не нужно.
## Размещение информации в маркетплейсе Инвойсбокс
Информация о средстве или множестве средств размещения может быть опубликована в [маркетплейсе Инвойсбокс](/docs/marketplace).
Маркетплейс Инвойсбокс позволит привлечь дополнительный поток клиентов за счёт продвижения информации на ресурсах сервиса и
его партнёров.
Отдельным взаимодействием системы PMS и маркетплейса может быть [мини-приложение](/docs/marketplace/mini-apps/), реализованное и работающее на стороне системы PMS.
Мини-приложение представляет из себя форму заказа товаров или услуг в сервисе поставщика, которая открывается в маркетплейсе Инвойсбокс (веб или мобильное приложение) и взаимодействует с системой Инвойсбокс.
Мини-приложение сможет предлагать пользователям Инвойсбокс забронировать комнату или номер в качестве дополнительной услуги к основному заказу, например, при покупке авиабилета.
Для дополнительной информации см. [схему взаимодействия](/docs/marketplace/mini-apps/schema/).
> Если у вас возникли вопросы, пожалуйста, [обратитесь к специалистам](https://www.invoicebox.ru/ru/contacts)
> системы Инвойсбокс. Мы будем рады вам помочь!
---
# ⛽ B2B продажи на АЗС
# Сценарий продажи топлива и дополнительных услуг на АЗС
Топливо отпускают до того, как известна сумма: заправка идёт по лимиту талона, а платит клиент за
фактический налив. Инвойсбокс выставляет счёт на лимит у колонки или на кассе, а после налива заказ
пересчитывается на фактическую сумму — организация получает один счёт и закрывающие документы, без
авансовых отчётов и бумажных талонов.
> [!IMPORTANT]
> Выступая в качестве партнёра Инвойсбокс, оператор приложения или системы автоматизации АЗС получает
> вознаграждение от оборота — [как оно считается](/docs/partner/#вознаграждение-партнёра).
Водитель не ждёт у колонки: подтверждение оплаты приходит на кассу за минуты, как при оплате картой
([платёжные инструменты](/docs/merchant/payment-instruments/)).
## Базовая схема взаимодействия
### Реализация мини-приложения
На стороне системы АЗС формируется [мини-приложение](/docs/marketplace/mini-apps). В мини-приложении
реализуются следующие функции (экраны):
- Экран поиска АЗС (список или карта, опционально)
- Экран детальной информации по АЗС и форма заказа - выбор типа топлива, номера колонки, объёма и перечень доп. услуг (или товаров)
- Опционально, другие экраны в соответствии с процессами покупки в рамках АЗС или сети АЗС
- Экран подтверждения заказа
- Функция создания заказа в системе Инвойсбокс
- Экран успешного подтверждения оплаты заказа
Информация об АЗС или множестве АЗС публикуется в [маркетплейсе Инвойсбокс](/docs/marketplace).
Для получения дополнительной информации см. также [описание работы мини-приложения](/docs/marketplace/mini-apps/description/) с
мини-приложением.
### Оформление заказа и счёта на оплату
**Сценарий без участия оператора (автомат)**
Клиент в приложении Инвойсбокс находит подходящую АЗС или приложение подсказывает пользователю ближайшую АЗС
на основе его геопозиции. Приложение Инвойсбокс инициализирует мини-приложение АЗС, покупатель оформляет заказ
в мини-приложении и подтверждает его оплату. По факту подтверждения оплаты заказа, покупатель производит заправку
автомобиля или получает товары/услуги.
**Сценарий с участием оператора**
Клиент желает рассчитаться за топливо, товары или услуги как организация или ИП, сообщает об этом оператору АЗС на
кассе.
При выборе способа расчёта на кассе (оплата по счёту) ERP-система [формирует заказ](/docs/merchant/order/create/)
от имени АЗС в системе Инвойсбокс, передавая состав заказа для оформления счёта и отчётных документов
(например, актов).
Оператор передаёт клиенту пречек с QR-кодом. В QR-коде кодируется ссылка для перехода на платёжный шлюз. Ссылку возвращает [создание заказа](/docs/merchant/order/create/) — поле `paymentUrl`.
Клиент сканирует QR-код и подтверждает оплату в приложении Инвойсбокс или мобильном браузере. После успешного подтверждения
оплаты, заказ считается оплаченным, а в ERP-систему поступает [уведомление об оплате](/docs/merchant/notification).
Система Инвойсбокс перечисляет денежные средства консолидированным платежом на следующий рабочий день на
расчётный счёт юридического лица АЗС, а оператору ERP-системы - вознаграждение.
> В случае, если у вас возникли вопросы, пожалуйста, [обратитесь к специалистам](https://www.invoicebox.ru/ru/contacts)
> системы Инвойсбокс. Мы ответим на любые ваши вопросы!
## Читайте также
- [Открывайте заказ с холдированием на предельную сумму](/docs/merchant/order/hold/)
---
# 🚕 B2B продажи такси и трансфера
# Сценарий продажи услуг такси и трансфера пассажиров
Корпоративные поездки неудобны обеим сторонам: сумма известна только после поездки, а счетов за
месяц набирается несколько десятков. Инвойсбокс закрывает и то, и другое: сумму можно зарезервировать
на карте и списать по факту, а месячные поездки собрать в один счёт заказом-контейнером — бухгалтерия
клиента получает один документ вместо тридцати.
## Базовая схема взаимодействия
### Реализация мини-приложения
На стороне системы бронирования услуг такси или трансфера формируется [мини-приложение](/docs/marketplace/mini-apps).
В мини-приложении реализуются следующие функции (экраны):
- Экран выбора пункта отправления/назначения (список или карта, опционально)
- Экран детальной информации о поездке (пункт назначения, тариф, расстояние и пр.) и форма заказа
- Опционально, другие экраны в соответствии с процессами покупки в рамках системы бронирования
- Экран подтверждения заказа
- Функция создания заказа в системе Инвойсбокс
- Экран успешного подтверждения оплаты заказа
Информация о службе такси или трансфера публикуется в [маркетплейсе Инвойсбокс](/docs/marketplace).
Для получения дополнительной информации см. также [описание работы мини-приложения](/docs/marketplace/mini-apps/description/) с
мини-приложением.
### Оформление заказа и счёта на оплату
Клиент, на платёжной странице, в процессе оформления авиа- или ж/д- перевозки или в приложении Инвойсбокс, изъявляет
желание добавить к заказу услугу такси или трансфера. Платёжная страница или приложение Инвойсбокс инициализирует мини-приложение
системы бронирования такси или трансфера. Мини-приложение системы бронирования может подсказать подходящие параметры исходя из
пункта отправления/назначения. Покупатель оформляет заказ в мини-приложении и подтверждает его оплату. По факту
подтверждения оплаты заказа, покупатель получает ваучер на услугу или саму услугу.
Система Инвойсбокс перечисляет денежные средства консолидированным платежом на следующий рабочий день на
расчётный счёт юридического лица оператора услуг такси или трансфера.
## Расчёт по факту поездки
Стоимость поездки известна только на финише: маршрут изменился, клиент попросил заехать по пути,
добавилось время ожидания. Выставлять счёт заранее — значит каждый раз доначислять или возвращать.
Для этого есть [холдирование](/docs/scenarios/guarantee/): при подаче машины резервируется
максимальная стоимость маршрута — [заказ с холдированием](/docs/merchant/order/hold/), — а по
завершении поездки списывается фактическая сумма. Разница освобождается на карте клиента сама,
отдельный возврат не нужен.
Для корпоративных клиентов с регулярными поездками удобнее не резервировать каждый раз, а собирать
поездки за период в один счёт: заказы группируются
[заказом-контейнером](/docs/merchant/order/create-order-container/), и бухгалтерия клиента получает
один документ вместо тридцати.
> В случае, если у вас возникли вопросы, пожалуйста, [обратитесь к специалистам](https://www.invoicebox.ru/ru/contacts)
> системы Инвойсбокс. Мы ответим на любые ваши вопросы!
---
# ⭐ B2B продажи бизнес-залов
# Сценарий продажи услуг бизнес-залов
Доступ в бизнес-зал покупают и заранее, вместе с билетом, и на стойке за минуту до вылета — а
компания-плательщик в обоих случаях ждёт счёт и закрывающие документы. Инвойсбокс закрывает оба
пути: оплату можно подтвердить онлайн в момент оформления билета или на месте через
мини-приложение, документы уходят в бухгалтерию клиента по электронному документообороту.
Скорость здесь решает: пассажир стоит у стойки, и подтверждение оплаты приходит оператору за минуты —
столько же, сколько занимает оплата картой ([платёжные инструменты](/docs/merchant/payment-instruments/)).
Комиссию можно оставить оператору, разделить с пассажиром или переложить на его компанию —
[кто платит комиссию](/docs/terms/#кто-платит-комиссию).
## Базовая схема взаимодействия
### Реализация мини-приложения
На стороне системы бронирования бизнес-зала формируется [мини-приложение](/docs/marketplace/mini-apps).
В мини-приложении реализуются следующие функции (экраны):
- Экран выбора пункта отправления/назначения (список или карта, опционально)
- Экран детальной информации о бизнес-зале и форма заказа
- Опционально, другие экраны в соответствии с процессами покупки в рамках системы бронирования
- Экран подтверждения заказа
- Функция создания заказа в системе Инвойсбокс
- Экран успешного подтверждения оплаты заказа
Информация о бизнес-зале или множестве залов публикуется в [маркетплейсе Инвойсбокс](/docs/marketplace).
Для получения дополнительной информации см. также [описание работы мини-приложения](/docs/marketplace/mini-apps/description/) с
мини-приложением.
### Оформление заказа и счёта на оплату
**Сценарий онлайн оплаты услуги**
Клиент, на платёжной странице, в процессе оформления авиа- или ж/д- перевозки или в приложении Инвойсбокс, изъявляет
желание добавить к заказу услугу бизнес-зала. Платёжная страница или приложение Инвойсбокс инициализирует мини-приложение
системы бронирования бизнес-зала. Мини-приложение системы бронирования может подсказать подходящий бизнес-зал исходя из
пункта отправления/назначения. Покупатель оформляет заказ в мини-приложении и подтверждает его оплату. По факту
подтверждения оплаты заказа, покупатель получает ваучер на услугу или саму услугу.
**Сценарий с участием представителя (на месте)**
Клиент желает рассчитаться за услуги бизнес-зала как организация или ИП, сообщает об этом представителю на месте.
При выборе способа расчёта на кассе (оплата по счёту) ERP-система (или система бронирования) [формирует заказ](/docs/merchant/order/create/)
от имени оператора бизнес-зала в системе Инвойсбокс, передавая состав заказа для оформления счёта и отчётных документов
(например, актов).
Представитель передаёт клиенту пречек с QR-кодом. В QR-коде кодируется ссылка для перехода на платёжный шлюз. Ссылку возвращает [создание заказа](/docs/merchant/order/create/) — поле `paymentUrl`.
Клиент сканирует QR-код и подтверждает оплату в приложении Инвойсбокс или мобильном браузере. После успешного подтверждения
оплаты, заказ считается оплаченным, а в ERP-систему поступает [уведомление об оплате](/docs/merchant/notification).
Система Инвойсбокс перечисляет денежные средства консолидированным платежом на следующий рабочий день на
расчётный счёт юридического лица оператора бизнес-зала.
## Что происходит после оплаты
- Оператор бизнес-зала получает [уведомление об оплате](/docs/merchant/notification/status/) —
по нему ваучер активируется, а гостя пускают в зал без ожидания подтверждения от бухгалтерии.
- Если гость воспользовался не всеми услугами или не пришёл вовсе, состав уточняется
[изменением заказа](/docs/merchant/order/update/) до закрытия документов.
- Неиспользованный визит возвращается [возвратом](/docs/merchant/refund/create/);
при удержании по тарифу — [возвратом с корректировкой](/docs/merchant/refund/correction/).
- Закрывающие документы уходят корпоративному клиенту
[по ЭДО](/docs/merchant/documentflow/) — акт и счёт-фактуру оператору формировать не нужно.
Гостям, которые пользуются залами регулярно, подойдёт
[холдирование](/docs/scenarios/guarantee/): сумма резервируется при бронировании, а списывается
фактическое обслуживание — с допуслугами, если они были.
> В случае, если у вас возникли вопросы, пожалуйста, [обратитесь к специалистам](https://www.invoicebox.ru/ru/contacts)
> системы Инвойсбокс. Мы ответим на любые ваши вопросы!
---
# ☂️ B2B продажи услуг страхования пассажиров
# Сценарий продажи услуг страхования пассажиров
Полис продаётся вместе с билетом и возвращается вместе с ним же — с удержанием части премии по
правилам страховщика. Инвойсбокс позволяет продать страховку тем же заказом, что и билет, а при
отказе оформить частичный возврат: клиент-организация видит одну операцию и получает документы по
электронному документообороту.
## Базовая схема взаимодействия
### Реализация мини-приложения
На стороне учётной системы страховых услуг формируется [мини-приложение](/docs/marketplace/mini-apps).
В мини-приложении реализуются следующие функции (экраны):
- Экран детальной информации о страховании поездки и форма заказа
- Опционально, другие экраны в соответствии с процессами покупки в рамках системы страхования
- Экран подтверждения заказа
- Функция создания заказа в системе Инвойсбокс
- Экран успешного подтверждения оплаты заказа
Информация об услуге страхования публикуется в [маркетплейсе Инвойсбокс](/docs/marketplace).
Для получения дополнительной информации см. также [описание работы мини-приложения](/docs/marketplace/mini-apps/description/) с
мини-приложением.
### Оформление заказа и счёта на оплату
Клиент, на платёжной странице, в процессе оформления авиа- или ж/д- перевозки или в приложении Инвойсбокс, изъявляет
желание добавить к заказу услугу страхования. Платёжная страница или приложение Инвойсбокс инициализирует мини-приложение
системы страхования. Мини-приложение может подсказать подходящие параметры исходя из данных основного заказа.
Покупатель оформляет заказ в мини-приложении и подтверждает его оплату. По факту подтверждения оплаты заказа, покупатель
получает ваучер на услугу.
Система Инвойсбокс перечисляет денежные средства консолидированным платежом на следующий рабочий день на
расчётный счёт юридического лица оператора услуг страхования.
## Возврат страховки
Полис возвращают чаще, чем билет: пассажир отказался от перелёта, страховка оказалась дублем
корпоративной, изменились даты. Возврат оформляется
[методом возврата](/docs/merchant/refund/create/) — полностью или частично, если страховая
удерживает часть премии за прошедший период.
Когда удержание есть, используйте
[возврат с корректировкой](/docs/merchant/refund/correction/): клиенту уходит разница, а в
закрывающих документах остаётся фактически оказанная услуга. Состав возврата, доступный к оформлению,
можно получить [запросом позиций заказа](/docs/merchant/refund/get/) — так не придётся считать
остаток на своей стороне.
О каждом шаге система страховщика узнаёт из
[уведомления о смене статуса](/docs/merchant/notification/status/).
## Страховка вместе с билетом
Страховка почти никогда не продаётся отдельно. Чтобы у корпоративного клиента не появлялось
несколько счетов на одну поездку, объедините билет, страховку и допуслуги
[заказом-контейнером](/docs/merchant/order/create-order-container/): оплата одна, документы —
по каждой услуге.
> В случае, если у вас возникли вопросы, пожалуйста, [обратитесь к специалистам](https://www.invoicebox.ru/ru/contacts)
> системы Инвойсбокс. Мы ответим на любые ваши вопросы!
## Читайте также
- [Основной заказ описан в кейсе продажи авиабилетов](/docs/scenarios/air-carriers/)
---
# 📦 Аренда складов, офисов и коворкингов
# Автоматизация оплат за аренду складов, офисов и коворкингов организациям и ИП (b2b)
Арендатор платит одну и ту же сумму каждый месяц, и каждый месяц кто-то вручную выставляет ему счёт, а
потом сверяет оплату с выпиской. К этому добавляются доначисления: уборка, парковка, переработка по
времени.
Инвойсбокс убирает ручные шаги: счёт уходит арендатору по правилу, оплата возвращается уведомлением, а
акт за период формируется сам.
Что это даёт арендодателю:
- арендатор платит по счёту, с отсрочкой до 30 дней или по [подписке](/docs/merchant/order/recurring/);
- деньги приходят на счёт на следующий рабочий день после подтверждения оплаты ([сроки](/docs/terms/));
- акт и счёт-фактура за период формируются автоматически и уходят по ЭДО;
- срок оплаты счёта задаётся полем `expirationDate` при [создании заказа](/docs/merchant/order/create/).
### Оплата аренды с любым сроком
Способы оплаты Инвойсбокс для организаций и ИП позволяют корпоративным клиентам оплачивать услуги аренды
с любым сроком оплаты (от одной минуты), открывая возможность экстренного оформления или продления услуги.
Срок задаётся полем `expirationDate` при [создании заказа](/docs/merchant/order/create/): по его истечении
неоплаченный счёт можно [отменить](/docs/merchant/order/delete/) и освободить помещение под следующего клиента.
Постоянные корпоративные клиенты могут получить отсрочку до 30 дней, при этом арендодатель гарантированно
получает денежные средства на следующий рабочий день после подтверждения оплаты.
### Регулярные платежи за аренду
Аренда — это оплата каждый месяц в одну и ту же дату, и напоминать о ней менеджеру не нужно.
Подписка закрывает ежемесячную арендную плату и коммунальные услуги: счёт уходит арендатору по
правилу — в нужный день или по условию, — а документы формируются по ЭДО.
> [!NOTE]
> Арендатору-организации адресована подписка, а не привязка карты: карта всегда оформлена на человека,
> и сотруднику пришлось бы объяснять расход бухгалтерии —
> [чем подписка отличается от рекуррентов](/docs/merchant/order/recurring/#почему-для-организаций-регулярность-устроена-иначе).
> Доставить счёт удобно [Запросом о платеже](/docs/scenarios/rtp/): он приходит в банковское приложение,
> оплата в один шаг.
Разовые доначисления — уборка, парковочное место, переработка по времени — оформляются отдельным заказом
или [изменением текущего](/docs/merchant/order/update/) до его оплаты.
Тем, кто платит не картой, а по счёту, удобнее [Запрос о платеже](/docs/scenarios/rtp): уведомление
приходит прямо в банковское приложение арендатора.
### Обработка возвратов
Сервис Инвойсбокс поддерживает как автоматизированное оформление возвратов, так и в ручном режиме через
личный кабинет. Денежные средства по возврату зачисляются арендатору до двух рабочих дней — срок зависит от способа оплаты.
### Автоматизированный документооборот
Отчётные документы для арендатора формируются автоматически после подтверждения оплаты, а оригиналы
могут быть отправлены в бумажном виде по почте или [через ЭДО](/docs/merchant/documentflow/).
### Схема взаимодействия с арендатором
- После того, как услуга оформлена, клиент переходит на страницу выбора способа оплаты. Как правило, мы
предлагаем арендодателю разместить на сайте дополнительный способ: "Оплата по счёту для организаций и ИП".
- Если клиент выбирает способ оплаты "Оплата по счёту для организаций и ИП", система управления складом передаёт в систему
Инвойсбокс состав заказа и данные для формирования счёта на оплату.
- Инвойсбокс позволяет формировать шаблоны счетов, которые могут автоматически направляться в виде ссылки для оплаты
арендатору по электронной почте, SMS или в мессенджер.
- В зависимости от срока оплаты счёта, система автоматически формирует набор доступных способов оплаты.
Срок оплаты может быть любой.
- Если срок оплаты короткий, подойдут инструменты с подтверждением до прихода денег — обещанный
платёж и гарантийный фонд ([платёжные инструменты для B2B](/docs/merchant/payment-instruments/)) —
или способы с мгновенным подтверждением: СБП, Запрос о платеже, оплата через банк-клиент (Альфа-Бизнес
Онлайн, СберБизнес, Т-Бизнес и другие).
- Если срок оплаты свыше 24х часов, то ко всем возможностям, описанным выше, добавляется простой выпуск счёта с ожиданием
оплаты в течение суток банковским переводом.
- После получения подтверждения оплаты по счёту, информация об оплате передаётся в систему арендодателя, происходит оформление услуги
и иных документов (например, при оплате дополнительных услуг).
- Все закрывающие документы оформляет и отправляет клиенту система Инвойсбокс. Никакой дополнительной нагрузки на бухгалтерию арендодателя,
связанной с запуском нового способа оплаты, не возникает.
### Свяжитесь с нами
Для настройки интеграции, пожалуйста, [напишите нам](https://www.invoicebox.ru/ru/contacts).
---
# ☁️ Подписки на сервисы для юрлиц (SaaS, хостинг, телеком)
# Подписки на сервисы для организаций и ИП (SaaS, хостинг, телеком)
Продавать подписку физлицу просто: карта привязана, списание идёт само. С организацией так не выходит.
Бухгалтерия платит по счёту, деньги идут через банк, и каждый месяц повторяется одна и та же работа:
выставить счёт, дождаться перевода, свести оплату с лицевым счётом, отправить акт. Пока перевод идёт,
сервис или отключается раньше времени, или работает в долг.
Инвойсбокс закрывает этот цикл: счёт уходит покупателю сам, оплата подтверждается за минуты или
секунды — в зависимости от [платёжного инструмента](/docs/merchant/payment-instruments/), — а акт и
счёт-фактура за период формируются без участия менеджера.
## Подписка для юрлица — это счёт по правилу, а не привязка карты
> [!IMPORTANT]
> Списание по сохранённой карте работает, но владелец карты — всегда физлицо: даже корпоративная карта
> оформлена на сотрудника, и расход придётся объяснять бухгалтерии — чек, обоснование, авансовый отчёт.
> Поэтому организациям адресована подписка: счёт уходит компании по правилу —
> [чем это отличается от рекуррентов](/docs/merchant/order/recurring/#почему-для-организаций-регулярность-устроена-иначе).
Правило задаёт период, конкретный день или условие — например, снижение баланса до порога. Собрать
подписку можно двумя способами:
- **расписание держит ваша система.** На каждый оплачиваемый период она
[создаёт заказ](/docs/merchant/order/create/) со сроком оплаты и составом по тарифу — биллинг и так
знает, когда у клиента заканчивается период. Инвойсбокс берёт на себя счёт, приём оплаты и документы.
- **расписание держит подписка.** Заказ-подписка создаётся один раз с параметрами периода и условий,
клиент подписывается на неё, и счета уходят ему сами. Параметры настраиваются при подключении —
публичного описания полей пока нет, состав правил уточняйте в
[поддержке](https://www.invoicebox.ru/ru/contacts).
Дальше в кейсе разобран первый способ: он не требует ничего, кроме обычного создания заказа.
Так выглядит счёт за месяц по тарифу. Номер договора и период попадают в `merchantOrderId` и
`description` — по ним бухгалтерия клиента поймёт, за что платит, а вы найдёте оплату в своей системе.
``` json
{
"merchantId": "01f1c3f8-0000-0000-0000-000000000001",
"merchantOrderId": "SUB-4417-2026-08",
"amount": "48000.00",
"currencyId": "643",
"description": "Тариф «Команда», август 2026, договор 4417",
"expirationDate": "2026-08-05T23:59:00+03:00",
"customer": {
"type": "legal",
"name": "ООО «Ромашка»",
"vatNumber": "7701234560",
"email": "buh@example.invbox.ru"
},
"basketItems": [
{
"sku": "TEAM-30",
"name": "Тариф «Команда», 30 рабочих мест, август 2026",
"quantity": 1,
"amount": "48000.00",
"vatCode": "RUS_VAT22",
"measure": "мес."
}
]
}
```
В позиции корзины можно передать [данные подписки](/docs/merchant/order/metadata/#данные-подписки) —
объект `PaymentPlan` с периодом биллинга, датами начала и окончания договора и ценой. Тогда счёт несёт
не только сумму, но и условия: бухгалтерия клиента видит, за какой период и по какому договору платит.
Что происходит дальше:
1. Клиент получает счёт и оплачивает его — из своего банка, по
[Запросу о платеже](/docs/scenarios/rtp/) в приложении банка или подтверждением из гарантийного
фонда за секунды. Способ определяется договором и настройками в кабинете, запрос при этом одинаковый.
2. Инвойсбокс сообщает об оплате [уведомлением о смене статуса](/docs/merchant/notification/status/) —
ваш сервис продлевает период по этому сигналу, а не по факту прихода денег на счёт.
3. Акт и счёт-фактура за период уходят клиенту [через ЭДО](/docs/merchant/documentflow/) или на бумаге.
4. Деньги приходят на расчётный счёт на следующий рабочий день после подтверждения оплаты —
[сроки и условия](/docs/terms/).
## Срок оплаты и мягкое отключение
Поле `expirationDate` задаёт, до какого момента счёт живёт. Для подписки это удобно: счёт на следующий
месяц выставляется, скажем, за пять дней до его начала, и до этой даты клиент платит по прежней ссылке.
Когда срок проходит, заказ получает состояние `expired` — оплатить старую ссылку нельзя, нужен новый
заказ.
Отсюда же берётся политика отключения. Пока счёт не оплачен, сервис работает или не работает по вашим
правилам; Инвойсбокс лишь сообщает, оплачен счёт или нет. Неоплаченный счёт, который потерял смысл
(клиент сменил тариф или ушёл), [отменяется](/docs/merchant/order/delete/) до оплаты — в списке
клиента он не останется висеть.
Если клиент готов платить, но не успевает провести перевод, помогает
[обещанный платёж](/docs/merchant/payment-instruments/): покупатель подтверждает заказ картой за
минуту, вы продлеваете период сразу, а счёт организация оплачивает в течение пяти суток.
## Смена тарифа и доначисления сверх пакета
Подписка редко стоит одинаково весь год: клиент добавляет рабочие места, выходит за лимит трафика,
берёт дополнительный номер или диск. Есть два пути, и выбор зависит от того, оплачен ли текущий счёт.
- **Счёт ещё не оплачен** — [измените заказ](/docs/merchant/order/update/): состав и сумма
пересчитываются, ссылка остаётся прежней. Так удобно поправить тариф, о котором договорились уже
после выставления счёта.
- **Счёт оплачен** — доначисление оформляется отдельным заказом за тот же период. Прежний счёт и
документы по нему остаются неизменными, а бухгалтерия клиента видит два понятных документа вместо
одного исправленного.
Если период уже закрыт документами, а сумму нужно уменьшить — например, клиент оплатил тридцать
рабочих мест, а пользовался двадцатью, — это [возврат с корректировкой](/docs/merchant/refund/correction/):
возвращается часть суммы, а корректировочный документ уходит клиенту вслед за возвратом.
## Много клиентов — много счетов: как не потеряться
Телеком и хостинг выставляют счета сотнями, и главный вопрос к системе — не «как создать заказ», а
«как свести реестр». Для этого достаточно двух вещей:
- **Свой номер в каждом заказе.** `merchantOrderId` вида `SUB-4417-2026-08` — договор и период. По нему
[заказ находится](/docs/merchant/order/get/) без сохранения идентификаторов Инвойсбокса.
- **Выборки по состоянию и датам.** Список неоплаченных счетов с истекающим сроком собирается
[фильтрами](/docs/api/filters/): `status=created` и условие по `expirationDate`. Ночная сверка по
такому запросу заменяет обзвон клиентов.
Обработчик уведомлений стоит сделать идемпотентным: одно и то же уведомление может прийти дважды, и
период не должен продлеваться два раза — [как проверить свой обработчик](/docs/merchant/notification/status/).
## Что это даёт
- Клиент-организация платит привычным способом, а сервис продлевается по сигналу об оплате, а не через
два-три банковских дня.
- Счёт, акт и счёт-фактура за период формируются сами и уходят по ЭДО — менеджеру остаются только
спорные случаи.
- Отсрочку и риск неплатежа можно отдать платформе: постоянный клиент подтверждает оплату сразу, а
рассчитывается в течение 30 дней — [платёжные инструменты](/docs/merchant/payment-instruments/).
- Физлица закрываются тем же вендором: для них работают и
[списание по сохранённой карте](/docs/merchant/order/recurring/), и
[чек по 54-ФЗ](/docs/merchant/fz54/).
## Чем подключиться
| Путь | Когда подходит |
|---|---|
| [API и PHP SDK](/docs/merchant/) | биллинг сервиса ведёт расписание сам — обычный случай для SaaS и телекома |
| [Готовый модуль](/docs/merchant/cms/) | тарифы продаются на сайте: 1С-Битрикс, Тильда, WooCommerce и другие |
| [Платёжный виджет](/widgets/) | нужно принять оплату за подписку сегодня, до доработки биллинга |
| [ИИ-агент](/for-agents/) | интеграцию делает Cursor или Claude Code по одному промпту |
## Смежные кейсы
- [Аренда складов, офисов и коворкингов](/docs/scenarios/warehouses/) — та же регулярность, но с
привязкой к сроку договора.
- [B2B продажи 24/7](/docs/scenarios/b2b-sales/) — четыре вызова базового сценария.
- [Запрос о платеже](/docs/scenarios/rtp/) — счёт приходит клиенту в приложение банка.
Посмотреть, как выглядит выставленный счёт и уведомление об оплате, можно в демо
[Счёт юрлицу из CRM](/demo/crm/) — вызовы уходят на демо-контур.
---
---
# 🧾 Автоматизация дебиторки: счёт, оплата, закрытие
# Автоматизация дебиторки: от счёта до закрывающих документов
Дебиторка отнимает время не там, где её считают, а там, где её ведут вручную. Менеджер выставляет счёт
в учётной системе, выгружает его в PDF, отправляет письмом, отмечает в таблице, через неделю звонит
напомнить, ищет платёж в выписке, сводит сумму, отправляет акт. Ошибка на любом шаге превращается в
неоплаченный счёт, о котором никто не помнит.
Инвойсбокс убирает из этой цепочки ручные шаги: счёт уходит покупателю автоматически, оплата
возвращается в учётную систему уведомлением, а закрывающие документы формируются по факту оплаты.
Реестр перестаёт быть таблицей, которую кто-то поддерживает, и становится состоянием заказов.
## Как выглядит цикл
1. **Счёт рождается в вашей системе.** Реализация в 1С, закрытая сделка в CRM, отгрузка в ERP —
в этот момент система [создаёт заказ](/docs/merchant/order/create/) с типом плательщика `legal`,
составом и сроком оплаты в `expirationDate`.
2. **Счёт уходит покупателю.** По ссылке `paymentUrl`, письмом от Инвойсбокса или прямо в приложение
банка — [Запросом о платеже](/docs/scenarios/rtp/). Отправлять вложением из почты менеджера больше
не нужно.
3. **Покупатель платит удобным ему способом.** Классический перевод, ускоренная оплата в один шаг из
интернет-банка, подтверждение из гарантийного фонда за секунды —
[пять инструментов](/docs/merchant/payment-instruments/) отличаются только тем, как быстро приходит
подтверждение.
4. **Оплата возвращается в учётную систему.** Инвойсбокс присылает
[уведомление о смене статуса](/docs/merchant/notification/status/); ваш обработчик закрывает
задолженность по `merchantOrderId`. Ждать выписку и сверять платёжки по назначению платежа не нужно.
5. **Документы уходят сами.** Акт, счёт-фактура и УПД формируются по факту оплаты и отправляются
[через ЭДО](/docs/merchant/documentflow/), почтой или курьером.
6. **Деньги приходят на расчётный счёт** на следующий рабочий день после подтверждения оплаты —
[сроки](/docs/terms/).
## Реестр вместо таблицы
Состояние каждого счёта живёт в Инвойсбоксе, и его можно получить запросом — отдельный учёт вести
не нужно.
| Что нужно бухгалтерии | Как получить |
|---|---|
| Что оплачено за период | [заказы](/docs/merchant/order/get/) с фильтром `status=completed` и условием по дате |
| Что ждёт оплаты | `status=created` — счёт выставлен, срок ещё не прошёл |
| Что просрочено | `status=expired`: срок из `expirationDate` прошёл, по прежней ссылке не оплатить |
| Что отменено | `status=canceled` — счёт [снят](/docs/merchant/order/delete/) до оплаты |
Условия по датам, сортировки и постраничный вывод — в разделе [фильтров](/docs/api/filters/). Ночная
выборка неоплаченных счетов с истекающим сроком заменяет обзвон: система сама напоминает тем, у кого
срок на исходе.
Два правила, без которых сверка ломается:
- **Свой номер в каждом заказе.** `merchantOrderId` — номер счёта или договора из вашей системы. По нему
вы находите заказ и закрываете задолженность, не храня идентификаторы Инвойсбокса.
- **Идемпотентный обработчик.** Одно и то же уведомление может прийти дважды; повторная обработка не
должна закрывать задолженность второй раз — [как проверить обработчик](/docs/merchant/notification/status/).
## Счета, которые оплачивают мимо Инвойсбокса
У большинства продавцов часть покупателей платит напрямую на расчётный счёт: так сложилось, так
записано в договоре. Держать из-за них вторую систему учёта не обязательно.
Заказ можно создать [не процессинговым](/docs/merchant/order/non-processable-order/) — с флагом
`processable = false`. Денег по нему Инвойсбокс не проводит, но счёт живёт в общем реестре, а отметку об
оплате вы ставите сами [сменой статуса](/docs/merchant/order/order-status-update/), когда увидели
платёж в выписке. Реестр остаётся один, и «дебиторка» в отчёте совпадает с реальностью.
> [!NOTE]
> Смена статуса работает только для не процессинговых заказов. У обычных заказов состояние меняет сам
> Инвойсбокс по факту движения денег — вручную его переставить нельзя, и это защищает отчётность.
## Обратная сторона: оплата счетов из фонда
Если вы автоматизируете не выставление счетов, а их оплату — например, делаете корпоративный кабинет
или сервис снабжения, — работает [Инвойсбокс.Бизнес](/docs/business/). Покупатель держит гарантийный
фонд и в его пределах подтверждает оплату сразу, не дожидаясь банковского перевода; сверх фонда даётся
отсрочка.
Два метода закрывают этот процесс: [получение счёта](/docs/business/get/) — список счетов и их
состояние, и [подтверждение оплаты](/docs/business/confirm_payment/) — оплата счёта из фонда с вашим
`partnerOperationId`, чтобы повторный вызов не создал второй платёж.
## Что это даёт
- Задолженность закрывается в момент подтверждения оплаты, а не после сверки выписки.
- Счёт доходит до покупателя по каналу, которым он пользуется: банковское приложение, письмо, ссылка.
- Просроченные счёта видны запросом, а не по памяти менеджера.
- Закрывающие документы уходят без участия людей — [документооборот](/docs/merchant/documentflow/).
- Риск неплатежа и отсрочку можно передать платформе: деньги приходят в обычный срок —
[инструменты](/docs/merchant/payment-instruments/).
## Чем подключиться
| Путь | Когда подходит |
|---|---|
| [Модуль CRM](/docs/merchant/crm/) | счета выставляют менеджеры: amoCRM, retailCRM, SportCRM |
| [Модуль ERP или PMS](/docs/merchant/erp/) | счёт рождается в учётной системе: iiko, Bnovo |
| [API и PHP SDK](/docs/merchant/) | своя учётная система или доработанная 1С |
| [Готовый модуль CMS](/docs/merchant/cms/) | заказы приходят с сайта |
## Смежные кейсы
- [B2B продажи товаров](/docs/scenarios/retail/) — отгрузка партиями и возврат с корректировкой.
- [Подписки для юрлиц](/docs/scenarios/saas/) — счёт на каждый период и доначисления.
- [Запрос о платеже](/docs/scenarios/rtp/) — счёт в приложении банка покупателя.
Как это выглядит со стороны менеджера, показывает демо [Счёт юрлицу из CRM](/demo/crm/): счёт
выставляется настоящим вызовом на демо-контур, статус меняется, уведомление приходит.
---
---
# 🛒 Маркетплейс и сплит-корзина
# Маркетплейс и сплит-корзина: одна оплата, несколько продавцов
Площадка, которая продаёт чужой товар, живёт в противоречии. Покупателю нужен один счёт: он собрал
корзину из товаров трёх поставщиков и не хочет платить трижды. Продавцам нужно обратное — своя выручка
на свой расчётный счёт и свои закрывающие документы от своего юрлица. Если площадка собирает деньги на
себя, она становится посредником со всеми последствиями: налоги, документы, ответственность за товар,
который никогда не видела.
Инвойсбокс разделяет одно от другого: покупатель платит один раз, а платёж расходится по продавцам,
каждый из которых остаётся продавцом в документах.
## Как выглядит цикл
1. **Поставщики подключаются к площадке.** Площадка отправляет
[приглашение](/docs/partner/integration/invite/) по API — поставщик проходит регистрацию сам, а по
её завершении площадка получает [параметры доступа](/docs/partner/integration/activation/), чтобы
создавать заказы от его имени. Собирать документы поставщиков вручную не нужно.
2. **Корзина превращается в группу заказов.** Один вызов
[создания группы заказов](/docs/merchant/order/create-order-container/) — и внутри столько заказов,
сколько в корзине продавцов. У каждого свой `merchantId`, свой состав и свои ставки НДС; покупатель
видит один номер счёта, который вы передаёте в `merchantOrderIdVisible`.
3. **Покупатель платит один раз** — по счёту, из интернет-банка в один шаг или подтверждением из
гарантийного фонда, [чем инструменты отличаются](/docs/merchant/payment-instruments/).
4. **Каждый заказ живёт своей жизнью.** Уведомления о смене статуса приходят по каждому заказу
отдельно — площадка узнаёт, что оплачено, и запускает сборку и доставку.
5. **Отгрузка и документы — от каждого продавца.** Товар доезжает партиями, отгрузки оформляются
[по каждому заказу](/docs/merchant/order/shipment_create/), а закрывающие документы уходят
покупателю [через ЭДО](/docs/merchant/documentflow/) от лица продавца.
6. **Возврат затрагивает только своего продавца.** Не привезли шкаф — [возврат](/docs/merchant/refund/create/)
идёт по заказу мебельного поставщика, а техника и доставка остаются оплаченными.
## Кто продавец в документах
Ответ определяется схемой работы, и от неё зависит, какие документы формируются.
- **Продавец — поставщик.** Заказ создаётся от его имени, счёт и УПД выставляет он. Площадка получает
вознаграждение за посредничество — так работает
[партнёрская схема](/docs/partner/#вознаграждение-партнёра).
- **Продавец — Инвойсбокс по договору комиссии.** Товар остаётся собственностью поставщика, а продажу
оформляет комиссионер: последовательность документов при полной и частичной отгрузке разобрана в
[комиссионной схеме](/docs/merchant/schema/commission/).
Выбор фиксируется в договоре и настройках магазинов, а не в каждом запросе — тело
[создания заказа](/docs/merchant/order/create/) в обоих случаях одинаковое.
## Франшиза: выплата уходит той точке, которая исполнила заказ
У сетей и франшиз заказ часто приходит на общий сайт, а исполняет его конкретная точка со своим юрлицом.
Заранее это неизвестно: точка определяется по адресу доставки или по наличию товара.
Для такого случая есть [перенос заказа на другой магазин](/docs/merchant/order/merchant-move/):
получателя выплаты можно сменить и до оплаты, и после неё. Условие одно — исходный магазин должен быть
создан с типом, который допускает перенос; это настраивается при подключении.
> [!NOTE]
> Заказы по реквизитам продавца (ИНН и КПП вместо идентификатора магазина) —
> [отдельный режим](/docs/merchant/order/agent-create/) для банков и крупных платёжных агрегаторов.
> Его схема не входит в публикуемый набор, поэтому консоли «Выполнить» на странице нет: контракт
> сверяется с технической поддержкой.
## Витрина: продажа рядом с чужой покупкой
Кроме собственной корзины у площадки есть второй источник продаж — [Витрина Инвойсбокса](/docs/marketplace/).
Точка продаж публикует себя в каталоге, а её [мини-приложение](/docs/marketplace/mini-apps/)
показывается покупателю прямо на [платёжной странице](/docs/merchant/payment-page/), пока он оплачивает
основную покупку: трансфер к авиабилету, страховка к поездке, доставка к заказу.
Точку продаж создаёт и обновляет [API маркетплейса](/docs/marketplace/create/), а скидки и акции
оформляются [спецпредложениями](/docs/marketplace/special-offer/).
## Что это даёт
- Покупатель-организация получает один счёт вместо трёх и один комплект документов на каждую покупку.
- Площадка не становится держателем чужих денег: выручка идёт продавцу, площадке — вознаграждение.
- Подключение поставщиков идёт по API, без обмена сканами документов.
- Возвраты и отгрузки не путаются между продавцами: каждый заказ внутри группы независим.
## Чем подключиться
| Путь | Когда подходит |
|---|---|
| [Партнёрское API](/docs/partner/) | площадка подключает продавцов и создаёт заказы от их имени |
| [Группа заказов](/docs/merchant/order/create-order-container/) | в корзине бывает больше одного продавца |
| [API маркетплейса](/docs/marketplace/) | нужна витрина и продажа на платёжной странице |
| [Мини-приложения](/docs/marketplace/mini-apps/) | покупатель оформляет заказ внутри чужого потока оплаты |
## Смежные кейсы
- [B2B продажи товаров](/docs/scenarios/retail/) — отгрузка партиями и возврат с корректировкой.
- [B2B продажи услуг страхования пассажиров](/docs/scenarios/insurance/) — продажа рядом с основной
покупкой через мини-приложение.
- [Автоматизация дебиторки](/docs/scenarios/receivables/) — сверка оплат, когда счетов много.
---
---
# 🧩 Приём платежей без разработчика
# Приём платежей без разработчика: юристы, аудит, агентства, студии
В небольшой профессиональной практике счёт выставляет тот же человек, который оказывает услугу.
Разработчика нет, сайт собран на конструкторе, и любая интеграция звучит как проект на месяц. Поэтому
всё остаётся как есть: счёт в Word, реквизиты в подписи письма, звонок бухгалтеру клиента с вопросом,
дошли ли деньги, и акт, который печатают и подписывают вручную.
Ни один шаг здесь не требует программирования. Оплату от организаций можно принять кодом, который
копируется в страницу, или готовым модулем к вашей платформе — счёт, чек и закрывающие документы
формируются на стороне Инвойсбокса.
## Четыре пути без программирования
| Путь | Что делаете вы | Сколько занимает |
|---|---|---|
| [Счёт из личного кабинета](https://www.invoicebox.ru/ru/free-invoice) | заполняете счёт в кабинете и отправляете покупателю | пара кликов |
| [Платёжный виджет](/widgets/) | собираете кнопку в конструкторе и вставляете код на страницу | минуты |
| [Готовый модуль](/docs/merchant/cms/) | устанавливаете модуль для своей платформы и вводите данные магазина | часы |
| [ИИ-агент](/for-agents/) | даёте агенту в Cursor или Claude Code один промпт — код он пишет сам | часы |
Сайт нужен не всегда. Если счетов немного и каждый обсуждается с клиентом, начните с кабинета: там
счёт выставляется вручную, к нему можно добавить QR-код для оплаты через СБП и оформить отчётные
документы — [бесплатно, без интеграции и без сайта](https://www.invoicebox.ru/ru/free-invoice).
Виджет подходит, когда сумма известна заранее или её называет клиент: консультация по прайсу, оплата
этапа договора, абонентское обслуживание. Модуль — когда заказы уже рождаются на сайте.
## Счёт руками, когда сайт не нужен
Юрист выставляет пять счетов в месяц, аудитор — десять, и каждый обсуждается с клиентом лично. Ставить
для этого кнопку на сайт незачем: [сервис бесплатного выставления счёта](https://www.invoicebox.ru/ru/free-invoice) закрывает задачу из
кабинета.
- Счёт заполняется вручную и уходит покупателю; ему достаточно ссылки.
- К счёту добавляется QR-код — покупатель оплачивает через СБП из приложения своего банка.
- Отчётные документы оформляются там же, руками, когда они понадобятся.
- Регистрация и работа бесплатны — платить за приём оплаты от юрлиц заранее не нужно.
Когда счетов станет много, те же реквизиты работают в виджете и в API — переносить ничего не придётся.
## Как это работает у вас на странице
1. **Соберите кнопку.** В [конструкторе](/widgets/constructor/) выбираются состав заказа или свободная
сумма, дополнительные поля, тип плательщика и адрес страницы завершения. Понадобятся идентификатор
магазина и региональный код — [где их взять](/docs/merchant/integrationdata/); для пробы конструктор
подставит демо-магазин.
2. **Поставьте тип плательщика «организация».** Тогда клиент указывает ИНН, а Инвойсбокс формирует счёт
и закрывающие документы — [схема для юрлиц](/docs/merchant/schema/legal/). Для физлиц тот же виджет
выдаёт [чек по 54-ФЗ](/docs/merchant/fz54/).
3. **Вставьте код на страницу.** Примеры для обычного сайта, Тильды, WordPress и 1С-Битрикс — в
[инструкции по вставке](/widgets/embed/).
4. **Получите оплату и документы.** Клиент платит по счёту или картой, акт и счёт-фактура уходят его
бухгалтерии [через ЭДО](/docs/merchant/documentflow/), деньги приходят на расчётный счёт на
следующий рабочий день — [сроки](/docs/terms/).
## Что важно знать про виджет
Сумма и состав заказа приходят из браузера покупателя и не подписаны — в браузере их можно изменить до
отправки. Это осознанное упрощение ради быстрого старта, и оно накладывает одну обязанность: сверять
сумму оплаты с той, которую вы ожидали. Подробно — [Безопасность виджета](/widgets/security/).
Для практики, где счёт выставляется по договорённости, это почти не риск: оплату вы всё равно
сопоставляете с договором. Если же цену определяет только ваша система, надёжнее создавать заказы
[через API](/docs/merchant/order/create/) — этот шаг можно сделать позже, ничего не переделывая: виджет
и API работают с одним и тем же магазином.
## Когда клиент просит счёт «как обычно»
Корпоративная бухгалтерия часто хочет счёт на бумаге или в почте, а не ссылку на оплату. Здесь ничего
менять не нужно: счёт формируется на стороне Инвойсбокса и доходит до клиента письмом, а оплатить его
он может из своего банка. Тем, кто пользуется банковским приложением, счёт можно доставить прямо туда —
[Запросом о платеже](/docs/scenarios/rtp/).
## Что это даёт
- Оплата от организаций принимается без разработки и без изменения сайта.
- Счёт, акт и счёт-фактура формируются сами — печатать и подписывать вручную не нужно.
- Клиент платит привычным способом, а вы видите оплату, не звоня его бухгалтеру.
- Переход на API не требует переделки: тот же магазин, те же документы.
## Смежные кейсы
- [Подписки для юрлиц](/docs/scenarios/saas/) — если услуга продаётся периодами.
- [Автоматизация дебиторки](/docs/scenarios/receivables/) — когда счетов станет много.
- [B2B продажи 24/7](/docs/scenarios/b2b-sales/) — что даёт переход на API.
---
---
# 🎓 Корпоративное обучение и ДПО
# Корпоративное обучение и ДПО: оплата обучения сотрудников организацией
Учебный центр продаёт курс не тому, кто учится. Заявку оставляет специалист по обучению, платит
бухгалтерия, а на занятия приходят двенадцать человек, из которых двое в последний момент меняются, а
один вообще не выходит на связь. Всё это должно сойтись в счёте, в акте и в удостоверениях — и обычно
сходится вручную, письмами и правками в счёте, потому что «список поменялся».
Инвойсбокс закрывает денежную часть: счёт организации, оплата привычным ей способом, акт и
счёт-фактура после курса. Список слушателей живёт в составе заказа, и его можно менять, пока счёт не
оплачен.
## Как выглядит цикл
1. **Заявка превращается в счёт.** [Создание заказа](/docs/merchant/order/create/) с типом плательщика
`legal`: в составе корзины — позиции по программе и слушателям, в `merchantOrderId` — номер заявки
или договора, в `expirationDate` — срок оплаты, обычно до начала потока.
2. **Организация платит.** Переводом, в один шаг из интернет-банка, по
[Запросу о платеже](/docs/scenarios/rtp/) или подтверждением из гарантийного фонда — способ зависит
от [платёжного инструмента](/docs/merchant/payment-instruments/), запрос при этом один и тот же.
3. **Вы узнаёте об оплате сигналом,** а не из выписки:
[уведомление о смене статуса](/docs/merchant/notification/status/) приходит сразу после
подтверждения, и слушателей можно зачислять.
4. **Курс проходит, документы уходят.** Акт и счёт-фактура формируются по факту оказания услуги и
отправляются [через ЭДО](/docs/merchant/documentflow/) или на бумаге.
5. **Кто не учился — тому возврат.** Двое не приступили к обучению: сумма за них возвращается, а
корректировочный документ уходит вслед за возвратом —
[возврат с корректировкой](/docs/merchant/refund/correction/).
## Список слушателей — это состав заказа
Позиции корзины — не только «курс за 145 000 ₽». Слушатель, программа и период обучения, вписанные в
позиции, попадают в счёт и в акт, и бухгалтерия покупателя видит, за кого именно заплатила. Так снимается
вопрос, с которым клиент возвращается чаще прочих: «а кто у вас в этом счёте?».
Из этого следуют два правила работы со списком:
- **До оплаты состав правится в самом заказе.** [Изменение заказа](/docs/merchant/order/update/)
пересчитывает состав и сумму, ссылка на оплату остаётся прежней. Так оформляется замена слушателя,
добавление ещё двоих или переход на другую программу.
- **После оплаты состав не меняют — деньги двигают.** Кто-то не приступил к обучению: это
[возврат с корректировкой](/docs/merchant/refund/correction/), а не правка оплаченного счёта. Прежние
документы остаются в силе, а корректировка объясняет разницу.
Неоплаченный счёт по отменённой заявке [отменяется](/docs/merchant/order/delete/) — у клиента в списке
не останется висеть счёт, который никто не собирается платить.
## Обучение частных слушателей на том же контуре
Учебные центры почти всегда продают и организациям, и людям. Разница только в типе плательщика: для
физлица тот же заказ выдаёт [чек по 54-ФЗ](/docs/merchant/fz54/), для организации —
[счёт и закрывающие документы](/docs/merchant/schema/legal/). Второго подрядчика и второй личный
кабинет для этого не нужно.
Если курс продаётся периодами — доступ к платформе на год с оплатой по месяцам, — работает механика
подписки: [счёт на каждый период](/docs/scenarios/saas/) вместо привязки карты.
## Что это даёт
- Заявка становится счётом за один вызов, а зачисление привязано к подтверждению оплаты.
- Список слушателей виден в счёте и акте — меньше переписки с бухгалтерией клиента.
- Замены и отказы оформляются штатно: изменением заказа до оплаты и возвратом с корректировкой после.
- Акт и счёт-фактура за курс уходят по ЭДО без участия менеджера.
## Чем подключиться
| Путь | Когда подходит |
|---|---|
| [API и PHP SDK](/docs/merchant/) | заявки приходят в вашу систему обучения или CRM |
| [Модуль CRM](/docs/merchant/crm/) | заявками занимаются менеджеры: amoCRM, retailCRM |
| [Готовый модуль CMS](/docs/merchant/cms/) | курсы продаются с сайта |
| [Платёжный виджет](/widgets/) | нужно принять оплату за курс сегодня |
## Смежные кейсы
- [Подписки для юрлиц](/docs/scenarios/saas/) — доступ к платформе периодами.
- [Приём платежей без разработчика](/docs/scenarios/no-code/) — если своего разработчика нет.
- [Автоматизация дебиторки](/docs/scenarios/receivables/) — когда счетов становится много.
---
---
# 🎪 Событийная индустрия: конференции и выставки
# Конференции и выставки: участие компании одним счётом
Компания едет на выставку не за билетом. Ей нужен стенд, электричество и мебель на нём, шесть
делегатов, парковка и место в каталоге — и всё это заканчивается одним разговором с бухгалтерией:
«пришлите счёт». Организатор в ответ шлёт три счёта от трёх юрлиц, а через неделю четвёртый, потому
что участник добавил ещё одного делегата. Дальше начинается сверка, которая занимает больше времени,
чем продажа.
Инвойсбокс собирает участие в один платёж: покупатель платит один раз, документы приходят одним
комплектом, а изменения в составе делегатов проходят штатно — до оплаты правкой заказа, после —
возвратом с корректировкой.
## Один счёт вместо стопки
Если участие продаёт одно юрлицо, всё умещается в один
[заказ](/docs/merchant/order/create/): стенд, делегаты, доп-услуги — позиции корзины со своими
ставками НДС и единицами измерения. В `expirationDate` ставится срок оплаты — обычно за несколько дней
до мероприятия, чтобы место не висело за неплательщиком.
Когда услуги оказывают разные юрлица — площадка сдаёт метры, подрядчик строит стенд, кейтеринг кормит
гостей, — работает [группа заказов](/docs/merchant/order/create-order-container/): внутри столько
заказов, сколько продавцов, а покупатель платит одной суммой и видит один номер счёта. Выручка и
документы при этом расходятся по продавцам — подробно это разобрано в кейсе
[маркетплейса и сплит-корзины](/docs/scenarios/marketplace-split/).
## Состав участия меняется до последнего дня
Это отраслевая норма, а не исключение: за неделю до выставки меняются фамилии делегатов, добавляется
второй стол на стенде, отваливается один из приехавших. Правило то же, что и в обучении, и оно
определяется одним признаком — оплачен ли счёт.
- **До оплаты** — [изменение заказа](/docs/merchant/order/update/): состав и сумма пересчитываются,
ссылка на оплату остаётся прежней. Замена делегата, лишний квадратный метр, отказ от парковки.
- **После оплаты** — деньги, а не состав. Делегат не приехал: сумма за него возвращается, а
корректировочный документ уходит вслед за возвратом —
[возврат с корректировкой](/docs/merchant/refund/correction/).
Заявка отменилась до оплаты — счёт [отменяется](/docs/merchant/order/delete/), место освобождается под
следующего участника.
## Срок оплаты и место, которое нельзя держать вечно
У мероприятия есть дата, и это меняет отношение к неоплаченным счетам. Стенд, забронированный и не
оплаченный, — это не дебиторка, а потерянное место в зале. Поэтому:
- `expirationDate` ставится по вашему регламенту бронирования, а не «на всякий случай» на месяц;
- список неоплаченных счетов с истекающим сроком собирается [фильтрами](/docs/api/filters/) по
`status=created` и дате — [как это устроено](/docs/scenarios/receivables/);
- если участник платит по счёту и тянет с оплатой, счёт можно доставить прямо в его банковское
приложение — [Запросом о платеже](/docs/scenarios/rtp/).
Тем, кому нужно место здесь и сейчас — регистрация в день мероприятия, доплата за апгрейд на стойке, —
подойдёт [обещанный платёж](/docs/merchant/payment-instruments/): участник подтверждает картой за
минуту, а его организация оплачивает счёт в течение пяти суток.
## Что это даёт
- Участие продаётся одним счётом, даже если услуги оказывают несколько юрлиц.
- Изменения в составе делегатов не превращаются в переписку: до оплаты — правка заказа, после — возврат
с корректировкой.
- Закрывающие документы уходят [по ЭДО](/docs/merchant/documentflow/) одним комплектом после
мероприятия.
- Частные участники платят там же и получают [чек по 54-ФЗ](/docs/merchant/fz54/).
## Смежные кейсы
- [Корпоративное обучение и ДПО](/docs/scenarios/education/) — та же механика списка участников.
- [Маркетплейс и сплит-корзина](/docs/scenarios/marketplace-split/) — когда продавцов несколько.
- [Автоматизация дебиторки](/docs/scenarios/receivables/) — сверка оплат перед мероприятием.
---
---
# 🏷️ Маркированные товары (Честный знак)
# Маркированные товары: продажа организациям с передачей кодов
Продавец маркированного товара платит за интеграцию дважды. Первый раз — чтобы принять оплату от
организации и выдать закрывающие документы. Второй — чтобы сведения о маркировке дошли до покупателя
и до Честного знака в нужный момент и в нужном документе. Обычно это два разных подрядчика, два
договора и два места, где что-то может разъехаться: товар отгружен, а коды ушли не с тем УПД.
Инвойсбокс закрывает оба контура. Заказ несёт товарную группу в составе корзины, а сведения о
маркировке уходят покупателю и в систему маркировки вместе с документами по отгрузке.
## Как выглядит цикл
1. **Заказ с товарной группой.** При [создании заказа](/docs/merchant/order/create/) в позиции корзины
передаётся `categoryType: honestSign` и код группы в `category` — `shoes`, `milk`, `water`, `beer` и
так далее; [полный справочник групп](/docs/merchant/honest-sign/). Если у вас свой справочник
категорий, в `categoryType` идёт `merchantHonestSignMap`. Без этих полей заказ создастся, но
сведения о маркировке в чек не попадут.
2. **Оплата по счёту или с отсрочкой.** Покупатель-организация платит переводом, в один шаг из своего
банка или подтверждением из гарантийного фонда —
[чем инструменты отличаются](/docs/merchant/payment-instruments/).
3. **Отгрузка партиями.** Оптовый заказ редко уезжает целиком: каждая партия оформляется
[отгрузкой](/docs/merchant/order/shipment_create/), и сведения о маркировке относятся к тому, что
действительно отгружено, а не к заказу в целом.
4. **Документы через ЭДО.** УПД уходит покупателю [по электронному документообороту](/docs/merchant/documentflow/),
события обмена — [в перечне событий ЭДО](/docs/merchant/documentflow/edo_events/).
5. **Недовоз — возврат с корректировкой.** Привезли меньше, чем в счёте: разница возвращается
покупателю, а корректировочный документ уходит вслед за возвратом —
[возврат с корректировкой](/docs/merchant/refund/correction/).
## Почему маркировка привязана к отгрузке, а не к заказу
Заказ — это договорённость: столько-то пар обуви такой-то модели. Коды маркировки относятся к
конкретным экземплярам, а какие именно уедут покупателю, известно только в момент сборки партии.
Поэтому сведения о маркировке идут с отгрузкой: сколько отгрузили — столько и сведений.
Отсюда два следствия для интеграции:
- **Отгрузку нельзя откладывать «на потом».** Пока её нет, у покупателя нет и УПД, а значит, товар
формально не принят. Отгрузка вызывается по факту передачи товара —
[как её оформить](/docs/merchant/order/shipment_create/), как [поправить](/docs/merchant/order/shipment_update/)
и как [посмотреть](/docs/merchant/order/shipment_get/).
- **Если отгрузить нечего** — товара не оказалось на складе, покупатель отказался — об этом сообщают
[уведомлением о невозможности отгрузки](/docs/merchant/notification/shipping-unavailable/), и заказ
не остаётся оплаченным без движения.
## Что смотреть в справочниках
| Что нужно | Где взять |
|---|---|
| Код товарной группы для `category` | [Честный знак](/docs/merchant/honest-sign/) — 20 групп с описаниями |
| Ставка НДС для позиции | [Справочник ставок](/docs/dictionary/tag1199/) |
| Единица измерения количества | [Признак предмета расчёта](/docs/dictionary/tag1212/) и [ОКЕИ](/docs/dictionary/okei/) |
| Что уходит в чек физлицу | [Фискализация по 54-ФЗ](/docs/merchant/fz54/) |
## Что это даёт
- Один вендор закрывает и приём оплаты от организаций, и передачу сведений о маркировке.
- Коды привязаны к отгруженным партиям, поэтому документы совпадают с фактом.
- Недовоз и отказ оформляются штатно: возврат с корректировкой или уведомление о невозможности
отгрузки, а не ручная переписка с бухгалтерией покупателя.
- Физлицам по тому же заказу выдаётся чек с реквизитами маркировки.
## Смежные кейсы
- [B2B продажи товаров](/docs/scenarios/retail/) — отгрузка партиями и возвраты в оптовой торговле.
- [Маркетплейс и сплит-корзина](/docs/scenarios/marketplace-split/) — если товар продают несколько
поставщиков.
- [Автоматизация дебиторки](/docs/scenarios/receivables/) — сверка оплат по большому числу счетов.
---
---
# 🚛 Логистика и грузоперевозки
# Логистика и грузоперевозки: расчёт по факту, а не по заявке
В перевозке цена заявки редко совпадает с ценой рейса. Вес уточняется на погрузке, объём — при
загрузке в машину, к тарифу добавляются простой, доупаковка, второй адрес выгрузки. Предоплата по
заявке означает возврат почти в каждом втором рейсе; постоплата — работу в долг и разговоры с
бухгалтерией клиента о том, почему сумма в счёте не та, о которой договаривались.
Инвойсбокс закрывает разрыв между заявкой и фактом двумя механиками: сумму по заявке можно
зарезервировать и списать по факту, а можно выставить счёт организации и подтвердить возможность
перевозки до того, как деньги ушли.
## Резерв по заявке, списание по факту
[Холдирование](/docs/merchant/order/hold/) подходит, когда заявку оплачивают картой — личной,
корпоративной или картой водителя.
1. Заказ создаётся с подтипом `subtype: hold`; все позиции корзины идут с типом оплаты
`full_prepayment`.
2. После подтверждения оплаты сумма блокируется на карте до даты из `holdTill` в
[ответе на создание заказа](/docs/merchant/order/create/#orderresponse).
3. Груз доехал — [создаётся отгрузка](/docs/merchant/order/shipment_create/) по позициям заказа.
Отгрузок может быть несколько: сборный груз доезжает частями, и на каждую оформляются документы.
4. Когда все позиции отгружены, заблокированные деньги списываются. Если рейс вышел дешевле —
отгрузка с флагом `final: true` списывает только фактическое, а остаток разблокируется.
Так закрывается частый случай: заявка на 60 000 ₽, по факту 54 000 ₽ — клиент платит за то, что
действительно перевезли, и никто не оформляет возврат.
> [!NOTE]
> Резерв работает на карте. Если перевозку оплачивает организация по счёту, до оплаты состав и сумму
> правит [изменение заказа](/docs/merchant/order/update/), а после — недоплату закрывает отдельный
> счёт, переплату [возврат с корректировкой](/docs/merchant/refund/correction/).
## Подтверждение рейса до того, как деньги ушли
У экспедитора машина находится не всегда: заявка принята, оплата подтверждена, а свободного борта на
дату нет. Для этого случая есть [контроль отгрузки на платёжной странице](/docs/merchant/notification/shipping-unavailable/):
Инвойсбокс дожидается ответа вашей системы, пока покупатель ещё стоит на платёжной странице.
- Машина нашлась, рейс поставлен в план — вы отвечаете `success`, покупатель видит подтверждение
оплаты и едет дальше по своему сценарию.
- Борта нет — вы сообщаете об этом, и покупатель узнаёт о невозможности перевозки сразу, а не через
день от диспетчера.
Настройка включается на стороне вашей платёжной страницы — попросите её у
[поддержки](https://www.invoicebox.ru/ru/contacts) до запуска.
## Рейсы за месяц одним счётом
Постоянный клиент делает по десять отправлений в неделю, и десять счетов в неделю его бухгалтерии не
нужны. [Группа заказов](/docs/merchant/order/create-order-container/) собирает несколько заказов под
одну оплату: каждый рейс остаётся отдельным заказом со своими документами, а покупатель платит один
раз. Так же удобно, когда в перевозке участвуют несколько исполнителей: у каждого свой заказ и своя
выручка.
## Что это даёт
- Клиент платит за фактически выполненный рейс, а не за заявку — меньше возвратов и меньше споров.
- Невозможность перевозки видна покупателю сразу на платёжной странице, а не после списания денег.
- Документы за рейс уходят [через ЭДО](/docs/merchant/documentflow/) по каждой отгрузке.
- Деньги приходят на расчётный счёт на следующий рабочий день после подтверждения оплаты —
[сроки](/docs/terms/).
## Смежные кейсы
- [B2B продажи такси и трансфера](/docs/scenarios/taxi/) — та же механика резерва в пассажирских
перевозках.
- [B2B продажи товаров](/docs/scenarios/retail/) — отгрузка партиями и корректировки.
- [Маркированные товары](/docs/scenarios/marked-goods/) — если возите маркировку.
---
---
# ⚡ Запрос о платеже (RtP)
# Запрос о платеже (RtP)
**Запрос о платеже (RtP или Request to Pay)** — это [удобный сервис от НСПК](https://www.invoicebox.ru/ru/products/rtp)
по передаче электронных платёжных счетов, способный доставить информацию о необходимости оплаты
товаров, работ и услуг от поставщика до плательщика.
Счёт не нужно везти на бумаге, пересылать письмом или в мессенджере: он доставляется прямо в личный
кабинет плательщика, а оплатить его можно в банковском или финансовом приложении.
Счёт через сервис RtP может быть направлен как плательщиками - физическими лицами (B2C), так и
организациям (B2B). Оплата может быть совершена с использованием QR-кода СБП или
[СБП B2B](https://www.invoicebox.ru/ru/products/sbp-b2b), а также множество альтернативных способов
оплаты на [платёжной странице](/docs/merchant/payment-page/) Инвойсбокс.
### Основные преимущества Запроса о платеже:
- Поставщик может полностью автоматизировать формирование и доставку счетов своим клиентам.
- Плательщик может контролировать процесс оплаты счёта, выбирая, когда и каким образом произвести платёж.
- Используются современные технологии для защиты данных и предотвращения мошенничества.
- Счета, а также информация об их оплате могут быть отправлены и получены в реальном времени, что упрощает
взаимодействие между сторонами, а также позволяет сократить дебиторскую задолженность.
> ❗ Почти 40% участников опроса [РСПП](https://rspp.ru/) назвали неплатежи со стороны контрагентов главным
препятствием для бизнеса, потеснив на второе место проблему снижения спроса. По данным мониторинга за второй квартал
2026 года доля таких ответов выросла на 5,6 процентного пункта. Запрос о платеже с моментальным подтверждением оплаты
снимает эту проблему: поставщик видит оплату сразу.
### Как это работает?
Поставщик товаров или услуг отправляет счёт (запрос на оплату) плательщику через свою учётную систему,
личный кабинет Инвойсбокс, [CRM](/docs/merchant/crm), [CMS](/docs/merchant/cms), [ERP](/docs/merchant/erp)
или мобильное приложение.
Плательщик получает уведомление с подробной информацией о счёте, включая сумму, описание и сроки оплаты. Плательщик
может получать такие уведомления на электронную почту, в мессенджерах или иных сервисах. Плательщик может
выбрать один из нескольких вариантов: оплатить счёт немедленно, назначить дату платежа или отклонить запрос.
Платёж может быть осуществлён мгновенно с использованием удобного способа оплаты, например, банковского перевода или СБП.
См. также [использование API для выставления счёта](/docs/merchant/schema/rtp) через Запрос о платеже.
### Применение Запрос о платеже
Набор сценариев использования RtP обширен и не ограничен приведёнными примерами:
- B2B и B2C расчёты: Компании могут оптимизировать свои финансовые потоки, используя этот метод для выставления счетов и мгновенного получения информации об оплате.
- Коммунальные платежи: Поставщики услуг могут отправлять запросы на оплату, которые клиенты могут оплачивать удобным способом.
- Онлайн-покупки и подписки: Магазины могут использовать RtP для упрощения процесса оплаты заказов, а также для автоматизации подписок.
- Школы, учебные заведения и курсы: Учреждения могут использовать Запрос о платеже для упрощения процесса оплаты курсов, а также для автоматизации приёма оплаты.
### Как подключить: последовательность вызовов
1. [Создайте заказ](/docs/merchant/order/create/) с составом и суммой — как для обычной оплаты по счёту.
Идентификатор заказа в вашей системе передайте в `merchantOrderId`, а внутренние поля —
в [метаданные](/docs/merchant/order/metadata/): они вернутся в уведомлениях.
2. Отправьте плательщику ссылку или QR-код на оплату. Запрос уходит в приложение его банка —
отдельная платёжная страница не нужна.
3. Дождитесь [уведомления о смене статуса](/docs/merchant/notification/status/): по нему запускайте
отгрузку или оказание услуги. Опрашивать [состояние заказа](/docs/merchant/order/get/) вручную
не требуется — но метод пригодится для сверки.
4. Если платить передумали или счёт устарел, [отмените заказ](/docs/merchant/order/delete/) —
запрос у плательщика погаснет.
5. Возврат оформляется обычным [методом возврата](/docs/merchant/refund/create/).
### Что это даёт бизнесу
- Снижение административных затрат, связанных с обработкой, отслеживанием платежей и ведением документооборота.
- Снижение дебиторской задолженности.
- Сокращение времени обработки транзакций, быстрое получение оплаты покупателя.
- Запрос о платеже активно развивается в финансовой отрасли и поддерживается банками и финансовыми институтами России.
### Универсальный QR
Универсальный QR-код Национальной системы платёжных карт (НСПК) — единый инструмент
для приёма различных видов платежей. Он позволяет торговым точкам использовать один QR-код для обработки платежей
через Систему быстрых платежей (СБП), банковские pay-сервисы, сервисы рассрочки, а в перспективе — и с использованием
цифрового рубля.
Решения Инвойсбокс API позволяют интегрировать [сервис RtP](https://www.invoicebox.ru/ru/products/rtp) и Универсальный
QR (включая оплату с использованием [СБП B2B](https://www.invoicebox.ru/ru/products/sbp-b2b)) в достаточно короткие
сроки и сопроводить оплату счёта необходимым документооборотом.
> Если у вас возникли вопросы, пожалуйста, [обратитесь к специалистам](https://www.invoicebox.ru/ru/contacts)
> системы Инвойсбокс. Мы будем рады вам помочь!
---
# 💳 Холдирование средств
# Холдирование средств: платите за факт, а не за план
Холдирование — это резерв суммы на карте покупателя до того, как известна окончательная цена.
Деньги остаются у клиента, но потратить их он не может; продавец списывает ровно столько,
сколько стоил фактический заказ, а остаток возвращается автоматически.
Сценарий закрывает боль отраслей с плавающей суммой. Заказ подтверждён, а окончательная сумма
станет известна через час, день или после отгрузки.
> Не путайте с [подтверждением оплаты заказа](/docs/merchant/guarantee/) — там речь о другом
> механизме: покупатель подтверждает уже сформированный платёж кодом.
## Как это работает
1. **Резерв.** Магазин [создаёт заказ с холдированием](/docs/merchant/order/hold/) на максимально
возможную сумму — например, максимальный чек поездки или полную стоимость брони.
Клиент подтверждает резерв, деньги блокируются на его карте.
2. **Отгрузка.** По факту продавец [создаёт отгрузку](/docs/merchant/order/shipment_create/) с тем,
что действительно отгружено или оказано. Отгрузок может быть сколько угодно, на каждую
оформляется фискальный чек. Когда в отгрузках закрыты все позиции заказа, заблокированные
средства списываются.
3. **Частичное списание.** Если часть заказа не состоялась, отгрузка оформляется с флагом
`final` = `true`: заказ считается выполненным, а остаток резерва разблокируется — без
отдельного возврата. До какой даты держится резерв, видно в поле `holdTill`
[ответа на создание заказа](/docs/merchant/order/create/#orderresponse).
4. **Уведомление.** Вашу систему о каждом шаге извещает
[уведомление о смене статуса](/docs/merchant/notification/status/) — по нему запускается
отгрузка, оформление документов или закрытие смены.
Если заказ не состоялся, резерв снимается [отменой заказа](/docs/merchant/order/delete/):
деньги освобождаются на карте клиента, списания не происходит.
Как это выглядит в числах: резерв берётся с запасом, списывается факт, разница освобождается сама.
```mermaid
sequenceDiagram
participant K as Покупатель
participant M as Магазин
participant I as Инвойсбокс
M->>I: заказ с холдированием на 3 000 ₽
I-->>M: paymentUrl, holdTill — 5 суток
K->>I: подтверждение, 3 000 ₽ заблокированы на карте
M->>I: отгрузка по факту на 2 400 ₽, final = true
I-->>K: списано 2 400 ₽, 600 ₽ разблокированы
I->>M: уведомление о смене статуса
```
## Где это нужно
| Отрасль | Что резервируем | Что списываем |
|---|---|---|
| [Такси и трансфер](/docs/scenarios/taxi) | максимальную стоимость маршрута | фактическую поездку по счётчику |
| [Рестораны](/docs/scenarios/ras) | сумму заказа при подтверждении | фактически поданные блюда |
| [Гостиницы](/docs/scenarios/pms) | стоимость проживания | проживание плюс допуслуги при выезде |
| Прокат и аренда оборудования | залог и максимальный срок | фактическое время использования |
| Розница с частичной отгрузкой | полную корзину | каждую отгруженную партию |
| Предзаказы с плавающей ценой | верхнюю границу цены | цену на момент отгрузки |
## Что учесть до внедрения
- **Срок жизни резерва** ограничен правилами платёжной системы. Если заказ выполняется дольше,
резерв нужно обновлять — уточните допустимый срок у вашего менеджера.
- **Списать больше зарезервированного нельзя.** Резервируйте с запасом: увеличить сумму
постфактум не выйдет, придётся выставлять отдельный счёт.
- **Клиент видит блокировку** как уменьшение доступного остатка. В интерфейсе честно называйте
это резервом, а не оплатой, — иначе неизбежны обращения в поддержку.
> В случае, если у вас возникли вопросы, пожалуйста, [обратитесь к специалистам](https://www.invoicebox.ru/ru/contacts)
> системы Инвойсбокс. Мы ответим на любые ваши вопросы!
## Читайте также
- [Демо «Касса АЗС](/demo/fuel/)
---
# 📱 Оплата внутри приложения без платёжной страницы
# Оплата внутри приложения: подтверждение кодом вместо перехода на платёжную страницу
В мобильном приложении переход на внешнюю страницу оплаты стоит дорого. Открывается браузер, теряется
контекст экрана, покупатель возвращается не туда, откуда ушёл, — и часть заказов остаётся
неоплаченной просто потому, что дорога назад оказалась длиннее, чем сам заказ. Для повторяющихся
покупок — обед на офис, расходники, поездка — это особенно заметно: сам заказ занимает пятнадцать
секунд, а оплата уводит на минуту в чужой интерфейс.
Постоянный покупатель с гарантийным фондом может подтвердить оплату прямо в вашем приложении: код
приходит ему от Инвойсбокса, вводится на вашем экране, заказ становится оплаченным.
## Три вызова вместо перехода
1. **Заказ.** [Создание заказа](/docs/merchant/order/create/) с типом плательщика `legal` — как обычно.
2. **Проверка возможности оплаты.** [Метод проверки](/docs/merchant/guarantee/validate/) отвечает,
хватает ли средств фонда. Спрашивать стоит до того, как покажете покупателю кнопку: так он не
упрётся в отказ на последнем шаге.
3. **Код подтверждения.** [Запрос кода](/docs/merchant/guarantee/code/) — Инвойсбокс отправляет код
покупателю.
4. **Подтверждение оплаты.** Покупатель вводит код на вашем экране, вы передаёте его
[методом подтверждения](/docs/merchant/guarantee/pay/), и заказ переходит в оплаченный.
Полная последовательность с участниками — в [схеме взаимодействия](/docs/merchant/guarantee/schema/),
а весь набор методов — в разделе [Гарантийный фонд](/docs/merchant/guarantee/).
> [!IMPORTANT]
> Раз оплата подтверждается в вашем интерфейсе, защита от перебора кода — тоже ваша.
> В вашем сервисе должна стоять капча: Google reCAPTCHA, Yandex SmartCaptcha, Huawei Safety Detect
> или аналог. Об этом прямо сказано в [описании методов](/docs/merchant/guarantee/).
## Кому это доступно и что делать с остальными
Подтверждение кодом работает для покупателей, у которых есть договор и гарантийный фонд —
[что это за инструмент](/docs/merchant/payment-instruments/). Остальным нужен обычный путь, и приложение
не обязано ради этого выбрасывать человека в браузер:
- **Мини-приложение в потоке Инвойсбокса.** Метод
[onCheckout](/docs/marketplace/mini-apps/miniapp-sdk/#метод-oncheckout) открывает платёжную страницу
поверх мини-приложения, а после оплаты вызывается
[обработчик onPaymentResult](/docs/marketplace/mini-apps/miniapp-sdk/#обработчик-onpaymentresult) со
статусом — покупатель возвращается ровно туда, откуда ушёл.
- **Ссылка на оплату внутри приложения.** `paymentUrl` из ответа на создание заказа открывается во
встроенном браузере; на устройстве с приложением Инвойсбокса откроется оно.
- **Оплата физлицом.** Тот же заказ выдаёт [чек по 54-ФЗ](/docs/merchant/fz54/), последовательность —
в [схеме для физических лиц](/docs/merchant/schema/private/).
## Не путайте с холдированием
Здесь деньги списываются с фонда организации, и происходит это в момент подтверждения кода.
[Холдирование](/docs/scenarios/guarantee/) — другое: сумма блокируется на банковской карте и
списывается по факту отгрузки. Механизмы решают разные задачи и настраиваются по-разному.
## Что это даёт
- Покупатель не выходит из приложения: оплата занимает столько же экранов, сколько сам заказ.
- Отказ по нехватке средств виден до кнопки оплаты, а не после неё.
- Закрывающие документы формируются как при любой другой оплате —
[документооборот](/docs/merchant/documentflow/).
- Для покупателей без фонда сценарий не ломается: платёжная страница открывается поверх и возвращает
человека обратно.
## Смежные кейсы
- [Холдирование средств](/docs/scenarios/guarantee/) — резерв суммы на карте и списание по факту.
- [B2B продажи такси и трансфера](/docs/scenarios/taxi/) — оплата в приложении с расчётом по факту.
- [Системы автоматизации ресторанов](/docs/scenarios/ras/) — оплата по QR-коду со стола.
---