Кошелёк ЮMoney — это персональный счёт физлица или самозанятого, а не мерчант-аккаунт: принимать деньги на него в 1С-Битрикс проще всего через форму приёма платежей (quickpay) и HTTP-уведомления с проверкой секретного слова. Разберём, чем кошелёк отличается от ЮKassa, как собрать форму, поймать уведомление об оплате и не забыть про ограничения кошелька и 54-ФЗ.
Кошелёк ЮMoney и ЮKassa: в чём разница
В экосистеме ЮMoney легко перепутать два разных продукта. ЮKassa — это платёжный сервис для бизнеса: под него нужен договор от ИП или юрлица, в кабинете выдаются shopId и секретный ключ, доступен полноценный API, возвраты и фискализация. Кошелёк ЮMoney — это личный счёт человека (номер начинается на 4100), и приём платежей на него устроен принципиально проще: через готовую форму перевода и уведомления.
- Кошелёк подойдёт, если вы физлицо или самозанятый, обороты небольшие, а сложный API и автоматические возвраты не нужны;
- ЮKassa нужна, если у вас ИП/ООО, важны чеки по 54-ФЗ «из коробки», СБП, рассрочка и статусы платежей по API.
Подготовка кошелька и его статус
Перед интеграцией разберитесь со статусом кошелька. У ЮMoney есть уровни идентификации — анонимный, именной и идентифицированный, — и от них зависят лимиты на входящие переводы и остаток на счёте. Для приёма оплаты от покупателей анонимного кошелька почти всегда недостаточно: упрётесь в ограничения по сумме операций и балансу.
Что нужно подготовить:
- Номер кошелька — 16 цифр вида
4100XXXXXXXXXXX, это реквизит получателя в форме; - Повышенный статус (именной или идентифицированный) — чтобы поднять лимиты;
- Доступ в раздел настроек уведомлений ЮMoney, где задаётся URL уведомлений и секретное слово для проверки подписи.
Форма для приёма платежей (quickpay)
Основной инструмент приёма на кошелёк — форма quickpay. Это HTML-форма, которая отправляет покупателя на страницу оплаты ЮMoney с уже подставленными реквизитами получателя и суммой. Ключевые поля формы:
| Поле | Назначение |
|---|---|
receiver | Номер вашего кошелька (4100…) |
quickpay-form | Тип формы, для магазина — shop |
sum | Сумма к оплате |
label | Метка платежа — сюда пишется номер заказа |
paymentType | Способ: PC — из кошелька ЮMoney, AC — банковской картой |
successURL | Адрес возврата после оплаты |
Самое важное поле для магазина — label. Именно по нему вы свяжете входящий платёж с конкретным заказом Битрикс, когда придёт уведомление. Передавайте туда идентификатор заказа (например, его ID или номер), а не произвольный текст.
Как оформить это в 1С-Битрикс
Платёжная система настраивается в разделе Магазин → Настройки → Платёжные системы. Обратите внимание: штатный обработчик ЮMoney в модуле sale ориентирован на ЮKassa (бизнес-протокол с shopId), а не на приём переводов на кошелёк. Поэтому под кошелёк используют один из двух путей:
- Обработчик «Свой вариант оплаты» с шаблоном формы. Создаёте платёжную систему, а в её шаблоне выводите форму quickpay, подставляя
receiver,sumиз заказа иlabelс номером заказа; - Собственный (пользовательский) обработчик в
/bitrix/php_interface/include/sale_payment/или в каталоге обработчиковpaysystem— если нужна аккуратная логика формирования формы и приёма уведомлений.
В настройках платёжной системы значения удобно привязать к данным заказа: сумму — «Из заказа», номер заказа в label — из свойства заказа, номер кошелька — фиксированным «Значением». Тип плательщика обычно ограничивают «Физическим лицом».
shopId и секретного ключа означает, что это обработчик ЮKassa. Для кошелька этих реквизитов нет — там оперируют номером кошелька и секретным словом уведомлений.HTTP-уведомления и секретное слово
Как и в любой redirect-схеме, факт оплаты нельзя определять по возврату покупателя — вкладку могли закрыть. Достоверный источник — HTTP-уведомление, которое ЮMoney отправляет POST-запросом на указанный вами URL после зачисления перевода.
В настройках уведомлений ЮMoney задаётся:
- URL для уведомлений — публичный адрес вашего скрипта-приёмника на сайте;
- Секретное слово (
notification_secret) — строка, участвующая в расчёте подписи.
В теле уведомления приходят поля notification_type, operation_id, amount, currency, datetime, sender, codepro, label и контрольный sha1_hash. Приёмник обязан пересчитать SHA-1 от склейки значимых полей и секретного слова и сверить с присланным sha1_hash. Только при совпадении подписи, верной сумме и известном label заказ помечается оплаченным.
54-ФЗ, чеки и ограничения
Ключевое отличие кошелька от ЮKassa — фискализация не выполняется автоматически. Форма quickpay просто зачисляет перевод, но чек по 54-ФЗ она не пробьёт. Если вы обязаны выдавать чеки покупателям-физлицам, кассу придётся подключать отдельно и связывать с моментом оплаты вручную или через сторонний сервис.
Что ещё стоит учитывать:
- Лимиты кошелька — потолок на входящие суммы и на остаток счёта зависит от статуса идентификации;
- Комиссия — при оплате картой (
AC) и выводе средств удерживается процент; закладывайте его в экономику; - Возвраты — автоматического возврата, как в ЮKassa API, здесь нет; возврат делается вручную из кабинета;
- Ассортимент способов оплаты — кошелёк даёт карту и баланс ЮMoney, но не полный набор методов бизнес-кассы.
Проверка и типичные ошибки
Перед запуском прогоните полный сценарий на небольшой сумме, чтобы проверить не только редирект, но и приём уведомления.
- Оформите заказ и перейдите к оплате — убедитесь, что форма открывает страницу ЮMoney с верной суммой и получателем;
- Проведите оплату и вернитесь на
successURL; - Проверьте, что пришло HTTP-уведомление, подпись
sha1_hashсошлась, а заказ поlabelавтоматически стал «Оплачен»; - Просмотрите журнал в
Магазин → Настройки → Журнали историю операций в кабинете ЮMoney.
Чаще всего ломается именно приём уведомления:
- Не сходится подпись — неверное секретное слово или порядок полей при расчёте SHA-1;
- Заказ не находится — в
labelушёл не тот идентификатор; - Уведомление не приходит — URL недоступен снаружи или отвечает ошибкой.
Итог
Приём на кошелёк ЮMoney в 1С-Битрикс держится на трёх вещах: кошелёк с повышенным статусом и его номером 4100…, форма quickpay с меткой label для связи с заказом и HTTP-уведомления с проверкой sha1_hash по секретному слову. Помните про отсутствие автоматической фискализации и лимиты кошелька — это решение для лёгких сценариев, а не для полноценного товарного магазина.
Если нужен приём оплаты, которому можно доверять, — с корректной проверкой подписей, автосменой статусов и переходом на ЮKassa по мере роста, — мы поможем настроить платёжные системы под ваш магазин на Битрикс, собрать пользовательский обработчик и взять проект на сопровождение.
Частые вопросы
Чем кошелёк ЮMoney отличается от ЮKassa?
Кошелёк — это личный счёт физлица или самозанятого с приёмом через форму и уведомления, без API и автоматических чеков. ЮKassa — сервис для ИП и юрлиц с shopId, секретным ключом, фискализацией и возвратами по API.
Есть ли в 1С-Битрикс штатный обработчик именно для кошелька?
Штатный обработчик ЮMoney в модуле sale ориентирован на ЮKassa (бизнес-протокол). Приём на кошелёк обычно оформляют через обработчик «свой вариант оплаты» с формой quickpay или пользовательский обработчик.
Как связать входящий платёж с заказом магазина?
Через поле label в форме quickpay: туда передаётся идентификатор заказа. Это же значение приходит в HTTP-уведомлении, и по нему обработчик находит нужный заказ и меняет его статус.
Зачем нужно секретное слово?
Секретное слово (notification_secret) участвует в расчёте контрольной подписи sha1_hash уведомления. Приёмник пересчитывает подпись и сверяет её, чтобы убедиться, что уведомление действительно от ЮMoney, а не подделано.
Пробивается ли чек по 54-ФЗ при оплате на кошелёк?
Нет, автоматически чек не формируется. Если вы обязаны выдавать чеки, кассу нужно подключать отдельно и связывать её с моментом оплаты. Автоматическая фискализация есть у ЮKassa, а не у кошелька.
Почему заказ не переходит в статус «Оплачен» после перевода?
Обычно причина в приёме уведомления: не сходится подпись из-за неверного секретного слова, в label ушёл не тот идентификатор, либо URL уведомлений недоступен снаружи. Проверьте эти три пункта и журнал магазина.
Какой статус кошелька нужен для приёма оплаты?
Анонимного кошелька обычно недостаточно из-за лимитов на суммы и остаток. Нужен именной или идентифицированный статус, иначе часть операций будет упираться в ограничения.
Можно ли делать автоматические возвраты через кошелёк?
Автоматического возврата, как в API ЮKassa, у кошелька нет. Возврат оформляется вручную из кабинета ЮMoney, а в Битрикс отражается изменением статуса заказа.
Поможем с настройкой и поддержкой 1С-Битрикс: Управление сайтом
Поможем с настройкой, доработкой и поддержкой 1С-Битрикс: Управление сайтом.