Универсальная электронная карта перестаёт быть концепцией из ФЗ-210. Регионы готовят первые партии, а федеральная уполномоченная организация выстраивает реестр и платёжное приложение. Карта несёт три функции сразу – идентификацию гражданина, доступ к государственным услугам и банковский инструмент на базе ПРО100. Для интеграторов это значит, что простого «считывателя» недостаточно: каждая точка приёма становится узлом, который обязан корректно говорить с несколькими ведомственными системами одновременно.

Что приходит на карту и кто это читает

УЭК – это контактно-бесконтактный чип с криптографией и электронной подписью. На нём лежат идентификационные данные, СНИЛС, полис ОМС и платёжное приложение. Чтение требует терминала с поддержкой ГОСТ-криптографии и сертифицированного СКЗИ, а не обычного PC/SC-ридера из коробки. Мы видим три класса точек приёма: банкоматы и POS для платёжной функции, инфоматы в МФЦ для госуслуг, и АРМ оператора в ведомстве для идентификации.

Каждый класс предъявляет свои требования к ПО. Платёжный сценарий замкнут на НСПК и банк-эквайер. Сценарий госуслуг идёт через региональный сегмент СМЭВ к ПФР, ФОМС и налоговой. Идентификационный сценарий проверяет подпись и сертификат против реестра уполномоченной организации. Связать эти три контура в одном рабочем месте – задача системной интеграции, а не установки драйвера.

Где ломается интеграция на практике

Первая проблема – разнородность сервисов. Региональные базы социальных льгот, ПФР и страховые компании отдают данные в несовместимых форматах, часть – синхронными SOAP-вызовами, часть – выгрузками по расписанию. Терминал не должен зависать, пока ведомство отвечает 40 секунд. Мы закладываем очереди и кэш на стороне регионального шлюза, чтобы оператор МФЦ получал отклик предсказуемо.

Второе – защита персональных данных. Точка приёма обрабатывает спецкатегории ПДн, и контур обязан соответствовать ужесточённым требованиям регулятора. Здесь напрямую работают недавние поправки к 152-ФЗ: аттестация по классам, журналирование доступа, разграничение ролей оператора. Соблазн «вынести часть данных в облако ради синхронизации между МФЦ» придётся притормозить – мы уже разбирали, почему облачная синхронизация по модели iCloud не подходит для контуров с гостайной и спецкатегориями ПДн без переаттестации трансграничной передачи.

Третье – клиентские устройства. Часть инфоматов и мобильных АРМ собирается на свежих Android-платформах; обновление до новых версий ОС меняет стек NFC и требований к подписи приложений, что мы отмечали в обзоре Android Ice Cream Sandwich. Парк устройств нужно фиксировать на сертифицированных сборках, иначе каждое OTA-обновление грозит обнулить аттестацию терминала.

Как мы строим узел приёма

Мы разделяем точку приёма на три слоя. Драйверный слой инкапсулирует работу с чипом и СКЗИ – единый API независимо от модели ридера. Слой бизнес-логики маршрутизирует запрос в нужный ведомственный сервис и держит состояние транзакции. Интеграционный слой – адаптеры к СМЭВ, эквайеру и реестру УЭК с ретраями и аудитом. Такое разделение позволяет менять одно ведомство, не переписывая терминал целиком.

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

Вывод

УЭК запускается не как карта, а как распределённая система с тремя контурами и жёсткими требованиями регулятора. Кто заранее строит точку приёма слоями и закладывает соответствие 152-ФЗ – пройдёт пилот без переделок. Кто относится к карте как к «ещё одному ридеру» – упрётся в аттестацию и несовместимость форматов уже на первой сотне карт.