Интеграция 1С с платёжными сервисами: как настроить автосверку оплат

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

Зачем вообще связывать 1С с платёжными сервисами?

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

Чем это отличается от обмена 1С с банк-клиентом?

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

Какие данные передаются между 1С и платёжным сервисом?

Обычно обмен строится на нескольких типах данных:

• статус платежа — оплачен, отклонён, возвращён, в обработке;
• сумма транзакции и размер комиссии агрегатора;
• идентификатор заказа, к которому привязана оплата;
• данные о частичных возвратах и отменах;
• информация о способе оплаты — карта, СБП, электронный кошелёк.

На основе этих данных 1С может автоматически менять статус заказа с «ожидает оплаты» на «оплачен», формировать документ поступления денег и учитывать комиссию как отдельный расход.

Какими способами настраивают интеграцию?

Есть три основных подхода. Первый — готовые модули и обработки для конкретных платёжных сервисов, которые устанавливаются в 1С и настраиваются через интерфейс без программирования. Второй — обмен через API, когда 1С и платёжный сервис обмениваются данными напрямую по протоколу, который поддерживает агрегатор; этот вариант гибче, но требует настройки со стороны программиста. Третий — через промежуточный сервис-посредник, который сам забирает данные у платёжной системы и передаёт их в 1С в удобном формате; это удобно, если нужно связать сразу несколько источников оплат — сайт, маркетплейсы, мобильное приложение.

Как проходит настройка пошагово?

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

Какие ошибки чаще всего встречаются при настройке?

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

Как понять, что интеграция настроена правильно?

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

Кстати, откуда вообще взялось слово «эквайринг»?

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

Как с этой задачей помогает «Клауд АйСи»?

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