Подключение АТОЛ Онлайн строим отдельно от банковской оплаты. Платёжный сервис подтверждает движение оплаты в своём контуре, а кассовая интеграция передаёт согласованную операцию и получает её результат. До разработки определяем участников, состав данных и применимый сценарий вместе с ответственным специалистом заказчика.
Граница платёжного и кассового контура
Описываем, откуда приходит подтверждённое событие, какая система формирует данные и где хранится результат. Интернет-магазин, CRM и 1С не должны независимо отправлять одну операцию без общего правила. Выбираем единственного ответственного отправителя для согласованного события.
Проверяем, нет ли уже действующего подключения у платёжного провайдера или CMS. Если оно покрывает задачу и правильно передаёт данные, дополнительная параллельная интеграция может создать дубли. Проект начинается с обследования существующей цепочки.
Доступы и параметры сервиса
Проверяем регистрацию и готовность сервисного контура, учётные данные, доступный интерфейс и настройки организации. Административные и договорные действия заказчик выполняет по установленным правилам сервиса. Техническая команда не объявляет их автоматически завершёнными после получения API-ключа.
Разделяем тестовую и рабочую конфигурацию, адреса, идентификаторы и секреты. Служебные сведения храним на сервере в предназначенном месте. Публичный браузерный код не должен получать полномочия отправителя кассовых операций.
Состав операции и данные заказа
Согласуем номенклатуру позиций, количества, суммы, скидки, способы расчёта и другие необходимые реквизиты. Налоговые и кассовые параметры подтверждает профильный специалист заказчика на основе применимых требований. Мы реализуем согласованную схему, а не придумываем методологию по названию товара.
Проверяем округление и соответствие итогов: сумма позиций должна согласовываться с передаваемым расчётом. Для частичной оплаты, возврата и иных требуемых ситуаций составляем отдельные контрольные примеры. Не предполагаем, что один успешный сценарий полной покупки покрывает все варианты бизнеса.
Отправка и получение результата
Сохраняем связь внешней операции с заказом и идентификатором запроса. Различаем принятие запроса сервисом, обработку и итоговый результат. Пользовательский интерфейс и внутренний учёт должны отражать нужное состояние, а не произвольный успех после HTTP-ответа.
При задержке ответа проверяем доступный способ получения результата. Потеря соединения после отправки не означает, что операция не выполнена. Прежде чем повторить её, используем предусмотренные идентификаторы и согласованный порядок проверки.
Ошибки, возвраты и сверка
Классифицируем ошибки данных, доступа и временной недоступности. Исправляемые данные направляем ответственному, временные ошибки — в контролируемый повтор. Бесконечно повторять один запрос с неверными реквизитами нельзя считать сопровождением.
Для согласованных возвратов проверяем связь с исходной операцией и фактический результат обработки. Сверка выявляет оплаченные заказы без нужного результата и операции с неоднозначным статусом. Правила корректирующих действий утверждаются отдельно; технический журнал не заменяет профессиональную оценку ситуации.
Приёмка подключения
Проходим выбранные успешные сценарии, повторное событие, тайм-аут, неверные данные и получение результата после восстановления связи. Проверяем, что один платёжный вебхук не вызывает повторную самостоятельную операцию из нескольких систем.
По итогам подключения АТОЛ Онлайн передаём схему, соответствие данных, правила диагностики и список проверенных ситуаций. Применимость требований и полноту кассового учёта согласуют ответственные специалисты. Установка модуля сама по себе не подтверждает готовность всей цепочки.
Вопросы по услуге
Если эквайринг работает, кассовый контур уже подключён?
Не обязательно. Проверяем договорённости и фактический путь события от оплаты до кассового результата. У некоторых решений есть готовое подключение, но его состав и данные нужно подтвердить. Успешная банковская операция не является единственным доказательством.
Нужно ли писать интеграцию, если есть модуль CMS?
Сначала проверяем готовый модуль, его версию и покрытие ваших операций. Индивидуальная разработка нужна при неподдерживаемом сценарии или особой архитектуре. Дублировать действующую отправку из другой системы нельзя без общего правила.
Кто определяет реквизиты и параметры расчёта?
Ответственный профильный специалист заказчика согласует методологию и применимые требования. Команда интеграции реализует передачу и проверяет контрольные примеры. Техническое подключение не заменяет правовое или бухгалтерское заключение.
Что делать при потере ответа после отправки?
Сначала проверить результат операции по предусмотренным идентификаторам и интерфейсу. Слепая отправка как новой операции может привести к дублю. Этот сценарий обязательно включаем в испытания.
Какие ситуации проверяются до запуска?
Согласованные виды покупки и возврата, повтор события, ошибка данных, недоступность и получение итогового результата. Перечень зависит от бизнеса. Проверка одной тестовой операции не подтверждает все частичные и исключительные расчёты.