Возможно ли технически ограничить возврат средств строго на карту оплаты в 1С?

В практике автоматизации розничной торговли мы часто сталкиваемся с задачей возврата денежных средств покупателю. Стандартный сценарий кажется простым: покупатель оплатил картой, значит, и вернуть деньги мы должны на ту же карту. Это логично с точки зрения борьбы с незаконным обналичиванием (cashed-out) кредитных средств и соответствует требованиям многих банков.

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

Суть проблемы: ожидание и реальность

Рассмотрим ситуацию, описанную специалистами. В магазине совершена покупка, оплата прошла через банковский пин-пад. Спустя время клиент приходит делать возврат. Кассир запускает операцию возврата в 1С, терминал просит приложить карту. Если клиент прикладывает совершенно другую карту (например, дебетовую вместо кредитной, с которой была оплата), терминал успешно проводит операцию.

Это создает риски для бизнеса:

1. Нарушение договора эквайринга: Банки часто требуют в инструкциях возвращать средства на исходное средство платежа.
2. Схемы обналичивания (фрод): Покупатель оплачивает товар кредитной картой (получая бонусы или кэшбэк), а возврат оформляет на дебетовую карту, получая "живые" деньги без комиссии за снятие наличных.
3. Банковские комиссии: Возврат на чужую карту банк может расценить как новую операцию перевода, что повлечет дополнительные расходы.

Технические различия операций: Отмена и Возврат

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

1. Отмена операции (Reversal / Void)

Эта операция выполняется, как правило, до закрытия банковской смены (сверки итогов) на терминале. Технически деньги еще не ушли из банка-эквайера в банк-эмитента, они просто "захолдированы" (заблокированы) на счете клиента.

Для отмены физическое присутствие карты часто вовсе не требуется. Достаточно передать в терминал номер ссылки (RRN) или номер чека терминала. Операция просто аннулируется. В 1С это часто реализуется кнопкой "Аннулировать чек" при открытой смене.

2. Возврат (Refund)

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

Роль RRN и идентификаторов транзакции

Разберем, как оборудование понимает, к какой продаже относится возврат. Ключевым элементом здесь является RRN (Retrieval Reference Number) — уникальный ссылочный номер транзакции. Также могут использоваться AuthCode (код авторизации) или внутренний номер чека терминала.

При оплате через онлайн-магазины (интернет-эквайринг) возврат всегда идет на ту же карту, потому что API банка требует указать TransactionID исходной покупки, и банк сам знает, к какой карте привязан этот ID. Физически карту прикладывать не нужно.

В оффлайн-рознице (Retail) все сложнее. Стандартные драйверы оборудования 1С и прошивки пин-падов часто настроены на "упрощенный" режим. При команде "Вернуть 1000 рублей" терминал просто ждет карту, чтобы отправить деньги на её реквизиты. Он не сверяет их с историей, если мы его об этом не попросим.

Как реализовать проверку карты в 1С

Если перед нами стоит задача жестко запретить возврат на другую карту, необходимо выполнить комплексную доработку на двух сторонах: в учетной системе 1С и на стороне банка-эквайера.

Шаг 1. Сохранение данных при продаже

В момент пробития чека и успешной оплаты картой, драйвер оборудования возвращает в 1С структуру данных. Нам необходимо убедиться, что мы сохраняем следующие параметры в регистры сведений или реквизиты документа "Чек ККМ" (или "Эквайринговая операция"):

• RRN (Ссылочный номер);
• AuthCode (Код авторизации);
• Маскированный номер карты (обычно последние 4 цифры, PAN).

Рассмотрим пример того, как могут выглядеть данные, получаемые от драйвера:

// Пример получения данных от драйвера после успешной оплаты
ПараметрыОперации = Новый Структура;
ПараметрыОперации.Вставить("Amount", СуммаОплаты);
ПараметрыОперации.Вставить("RRN", ОтветТерминала.RRN); // Ссылочный номер
ПараметрыОперации.Вставить("AuthCode", ОтветТерминала.AuthCode);
ПараметрыОперации.Вставить("CardNumber", ОтветТерминала.CardNumber); // Обычно вида ************1234

Если ваша конфигурация типовая (например, 1С:Розница или 1С:УТ), эти данные, скорее всего, уже сохраняются в соответствующих регистрах сведений по эквайринговым операциям. Проверьте это.

Шаг 2. Передача параметров при возврате

При оформлении возврата мы должны найти исходную транзакцию и передать её идентификаторы в драйвер эквайрингового терминала. Многие современные драйверы (по стандарту 1С-Совместимо) имеют соответствующие входные параметры для метода ВернутьОплату.

Важный нюанс: даже если мы передадим RRN в терминал, это не гарантирует запрет на смену карты. Терминал может принять RRN для отчетности, но все равно позволить приложить другой пластик. Это зависит от настроек прошивки самого терминала ("конфигурации" на сленге банковских инженеров).

Шаг 3. Взаимодействие с банком (Критический этап)

Это самый важный шаг, без которого доработки в 1С могут быть бесполезны. Нам необходимо связаться с технической поддержкой банка-эквайера и поставить задачу следующим образом:

"Просим настроить на наших терминалах запрет возврата на карту, отличную от карты покупки. Мы готовы передавать RRN исходной транзакции из кассового ПО."

Возможные варианты ответа банка:

1. Включение сверки на терминале: Инженер банка обновляет конфигурацию пин-пада. Теперь, если 1С передает RRN, терминал при запросе карты сверяет предъявленный токен/PAN с тем, который хранится в его журнале (или запрашивает сверку у хоста банка). Если карты не совпадают — выдается ошибка.
2. Административный запрет: Банк может сообщить, что технически на данной модели оборудования это невозможно, но есть инструкции ЦБ и правила платежных систем.

Проблема токенизированных карт (Mir Pay, SberPay)

Давайте проанализируем современную проблему. Если покупатель платил телефоном (NFC), то терминал видит не реальный номер карты, а виртуальный токен. При возврате, если клиент снова прикладывает телефон, генерируется тот же токен (или связанный с ним), и проверка проходит.

Однако, если клиент платил телефоном, а возврат хочет сделать, приложив физическую карту (того же счета), номера (PAN) будут отличаться. Жесткая проверка "номер в номер" здесь может дать сбой и запретить легитимную операцию. Именно поэтому банки часто оставляют настройку "разрешить любую карту" включенной по умолчанию.

Особый случай: Система Быстрых Платежей (СБП)

Если вы используете оплату через QR-коды (СБП), ситуация упрощается. Архитектура СБП построена таким образом, что возврат технически возможен только на тот же счет, с которого пришли деньги. Здесь подмена невозможна на уровне банковского протокола. 1С отправляет команду "Вернуть по ID операции", и деньги уходят обратно отправителю без участия покупателя (ему не нужно ничего сканировать или прикладывать).

Юридический аспект: можно ли вернуть на другую карту или наличными?

Часто возникает вопрос: а законно ли вообще требовать ту же карту? Ведь старая карта могла быть утеряна, заблокирована или у неё истек срок действия.

Разберем актуальные требования (с учетом отмены старого указания ЦБ № 3073-У и ввода нового № 5348-У):

1. Основное правило: Возврат денег за товар, оплаченный безналичным путем, рекомендуется производить также безналичным путем. Это требование продиктовано правилами кассовой дисциплины и договорами эквайринга.
2. Если карта утеряна: Магазин не имеет права отказывать в возврате денег. Если возврат на исходную карту невозможен (технически не проходит), покупатель пишет заявление, в котором указывает реквизиты другого своего счета.
3. Возврат наличными: Прямого законодательного запрета вернуть наличные за безналичную покупку для физических лиц в Законе о защите прав потребителей нет (все виды расчетов равнозначны). Однако, Указание ЦБ РФ № 5348-У ограничивает использование наличной выручки из кассы. То есть, вернуть наличные можно, но эти деньги, скорее всего, придется сначала снять с расчетного счета или оформить как "возврат прихода" особым образом, чтобы не нарушить кассовую дисциплину (не тратить текущую выручку на возврат безнала).

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

Пример алгоритма действий для программиста 1С

Подведем итог в виде пошагового алгоритма реализации:

1. Проверьте, что в регистрах накопления или сведений вашей конфигурации сохраняется RRN (Reference Number) каждой оплаты картой.
2. Найдите участок кода, отвечающий за вызов драйвера при возврате (обычно это обработка ПодключаемоеОборудование или модули РМК).
3. Убедитесь, что метод драйвера (например, RefundTransaction) получает параметр RRN из найденной исходной операции.
Скопировать код

// Примерный псевдокод заполнения параметров для драйвера
ВходныеПараметры = Новый Массив;
ВходныеПараметры.Добавить(СуммаВозврата);
ВходныеПараметры.Добавить(ИсходныйRRN); // Важно передать это значение
ВходныеПараметры.Добавить(ИсходныйAuthCode);

// Вызов метода драйвера
Результат = ОбъектДрайвера.ВыполнитьКоманду("Refund", ВходныеПараметры, ...);

4. Свяжитесь с поставщиком терминалов (банком). Запросите инструкцию или настройку терминала для проверки соответствия карты по RRN.
5. Предусмотрите в интерфейсе РМК "аварийную кнопку" для возврата на другую карту (с повышением прав доступа), на случай, если исходная карта заблокирована.

Внедрение такого контроля позволит существенно снизить риски ошибок персонала и потенциального мошенничества с бонусными программами банков.