Как подключить приём оплаты через Т-Касса (Тинькофф) к интернет-магазину

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

Это пошаговая инструкция, как подключить приём оплаты через Т-Касса (ранее Тинькофф Касса) к интернет-магазину на 1С-Битрикс: от настройки платёжной системы и ключей до нотификаций, чеков по 54-ФЗ и тестирования. Разберём, что делают штатные средства, а где нужна доработка — которую мы закрываем услугой автоматизации на 1С.

Что такое Т-Касса и как она работает

Т-Касса — это интернет-эквайринг: сервис, который принимает оплату банковскими картами и другими способами на стороне защищённого платёжного шлюза банка. Магазин не хранит данные карт — покупатель вводит их на странице банка, что снимает с сайта большую часть требований по безопасности платёжных данных.

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

Что подготовить до подключения

Перед технической настройкой соберите исходные данные — это ускорит подключение и убережёт от ошибок.

• Договор эквайринга. Магазин зарегистрирован в банке, получен доступ в личный кабинет мерчанта.
• Учётные данные терминала. Идентификатор терминала и секретный пароль для боевого и тестового режимов.
• Система налогообложения. Согласованные с бухгалтерией ставки НДС и признаки для чеков.
• HTTPS на сайте. Приём оплаты и нотификации работают только по защищённому соединению.
• Доступ к настройкам магазина. Права администратора в 1С-Битрикс для настройки платёжной системы.

HTTPS здесь не опция, а обязательное условие — как и в целом для безопасности приёма данных, о чём мы писали в материале про REST, вебхуки и безопасность.

Как устроена оплата: поток данных

Чтобы настройка была осмысленной, важно видеть весь путь платежа.

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

Шаг 1: настройка платёжной системы

В 1С-Битрикс оплата настраивается через раздел платёжных систем в настройках интернет-магазина. Т-Касса подключается как отдельная платёжная система на базе готового обработчика — из поставки или официального модуля банка.

1. Добавьте платёжную систему. Создайте новую систему на основе обработчика Т-Касса.
2. Свяжите с типами плательщиков. Определите, кому она доступна — физлицам, конкретным группам, типам заказа.
3. Настройте отображение. Название, описание и логотип способа оплаты в оформлении заказа.
4. Проверьте валюту и суммы. Убедитесь, что валюта заказа и передаваемая сумма совпадают до копейки.

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

Шаг 2: терминал, ключи, секреты

После создания платёжной системы в её параметры вносят учётные данные, полученные от банка: идентификатор терминала и секретный пароль. Ими сайт подписывает запросы к шлюзу и проверяет подлинность уведомлений.

Здесь же настраивают разделение тестового и боевого режимов: пока идёт настройка, работают с тестовым терминалом, и только после полной проверки переключают на боевой. Правильное обращение с секретами и разделение окружений — часть общей культуры безопасности, о которой речь в статье про REST и безопасность в Битрикс, а безопасная выкатка настроек — в материале про CI/CD и деплой.

Шаг 3: нотификации о платеже

Нотификация — сердце надёжного приёма оплаты. Это серверное уведомление, которое шлюз отправляет на заданный URL магазина при смене статуса платежа. Обработчик обязан сделать несколько вещей:

1. Проверить подпись. Убедиться, что уведомление действительно от банка, а не подделка.
2. Сверить заказ и сумму. Найти заказ и проверить, что оплачена именно та сумма.
3. Сменить статус. Перевести заказ в «оплачен» и запустить дальнейшую обработку.
4. Ответить шлюзу. Вернуть подтверждение приёма, иначе шлюз будет повторять уведомление.
5. Обеспечить идемпотентность. Повторное уведомление по тому же платежу не должно оплачивать заказ дважды.

URL для нотификаций указывают в настройках терминала. Он должен быть доступен по HTTPS и стабильно отвечать. Обработку уведомлений строят по тем же принципам надёжности, что и любые входящие вебхуки — с проверкой подписи и защитой от повторов.

Шаг 4: кассовые чеки по 54-ФЗ

Приём онлайн-оплаты от физлиц по закону требует фискального чека. Чек формируют либо через подключённую онлайн-кассу, либо через фискализацию на стороне банковского сервиса, если он её предоставляет. В любом случае в чек нужно передать корректные данные заказа.

• Состав заказа. Каждая позиция с наименованием, количеством и ценой.
• Ставки НДС. Корректная ставка для каждой позиции по вашей системе налогообложения.
• Признак предмета расчёта. Товар, услуга и т.п. — по типу позиции.
• Признак способа расчёта. Полная оплата, предоплата, аванс — по сценарию продажи.
• Контакт покупателя. E-mail или телефон для отправки электронного чека.

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

Шаг 5: тестирование сценариев

Перед боевым запуском прогоняют полный набор сценариев на тестовом терминале и тестовых картах банка — без реальных списаний.

1. Успешная оплата. Заказ создаётся, платёж проходит, приходит нотификация, статус меняется, формируется чек.
2. Отказ в оплате. Заказ не помечается оплаченным, пользователь видит понятное сообщение.
3. Прерванная оплата. Клиент закрыл вкладку — заказ не «зависает» в неопределённом статусе.
4. Повторная оплата. Клиент оплачивает второй раз — нет двойного списания и двойной отметки.
5. Возврат. Полный и частичный возврат проходит, формируется чек возврата.

Только когда все сценарии, включая нотификации и чеки, отработали корректно, терминал переключают в боевой режим. Пропуск тестирования — прямой путь к потерянным платежам и недовольным клиентам в первый же день.

Возвраты и частичная оплата

Возврат — обязательная часть, а не «потом настроим». Его инициируют из административной части: обработчик отправляет в шлюз запрос на полный или частичный возврат по оплаченному заказу, а сайт формирует чек возврата по 54-ФЗ и меняет статус.

Ручные возвраты «мимо системы» — источник расхождений между сайтом, банком и бухгалтерией, которые потом мучительно сверяют. Поэтому процесс возврата настраивают заранее и проверяют на тесте. Частичная оплата и сложные сценарии (доплата, разбивка заказа) обычно требуют доработки обработчика — это зона кастомной разработки модуля.

Оплата по счёту для юрлиц

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

Оплата по счёту тесно связана с учётной системой: счёт выставляется и контролируется в 1С, а факт оплаты приходит на сайт обменом. Поэтому её настраивают вместе с интеграцией — про надёжный обмен данными полезен материал про работу с данными через D7 ORM, а стабильность обмена в целом — тема инфраструктуры BitrixVM. Комбинация «карта через Т-Касса + счёт для юрлиц» — типовой B2B-сценарий, который мы собираем в рамках автоматизации продаж и склада.

Частые ошибки подключения

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

Чек-лист запуска

1. Платёжная система настроена. Обработчик Т-Касса добавлен, привязан к плательщикам, валюта и суммы совпадают.
2. Секреты защищены. Терминал и пароль в защищённых настройках, тест и бой разделены.
3. Нотификации работают. Подпись проверяется, сумма сверяется, статус меняется, есть идемпотентность.
4. Чеки корректны. Состав, ставки НДС и признаки согласованы с бухгалтерией.
5. Возвраты настроены. Полный и частичный возврат с чеком возврата работают из админки.
6. Сценарии протестированы. Оплата, отказ, прерывание, повтор, возврат — на тестовом терминале.
7. Боевой режим включён. Переключение только после успешного прохождения всех тестов.

Вывод

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

Опирайтесь на нотификацию, а не на возврат пользователя; берегите секрет терминала; согласуйте реквизиты чеков с бухгалтерией; настройте возвраты заранее и обязательно прогоните все сценарии на тесте перед боевым запуском. Тогда приём оплаты станет тихой, надёжной частью магазина — а не источником ежедневных инцидентов на самом ценном шаге воронки.