Главная Программы Софт для разработки Microblink BlinkCard: руководство от гика, распознавание платёжных карт, liveness и интеграция v3000

Microblink BlinkCard: руководство от гика, распознавание платёжных карт, liveness и интеграция v3000

Microblink BlinkCard — не обычное приложение, которое пользователь устанавливает ради самостоятельного сканирования карты, а коммерческий SDK для разработчиков мобильных и веб-приложений. Он встраивает в чужой продукт камеру, распознавание реквизитов платёжной карты, проверку качества кадра, liveness-проверки и выдачу структурированного результата. В 2026 году у BlinkCard произошёл крупный архитектурный переход: актуальная ветка v3000 отказалась от прежней схемы Recognizer в пользу сессий, а старая ветка v2 переведена в режим сопровождения без новых функций. Поэтому оценивать BlinkCard как «сканер карт для телефона» недостаточно: для выбора важны платформа, способ интеграции, лицензирование, работа с моделями, требования к камере, политика обработки PAN и CVV, а также то, нужен ли готовый интерфейс или собственный headless-процесс.

Что такое Microblink BlinkCard и чем он не является

BlinkCard разработан компанией Microblink как библиотека для распознавания кредитных, дебетовых и других платёжных карт внутри приложений. На стороне конечного пользователя продукт обычно выглядит как экран камеры, который открывается из банковского, финтех-, e-commerce- или другого приложения. Сам SDK остаётся частью программного кода этого приложения и возвращает разработчику результат сканирования.

Основная задача BlinkCard — заменить ручной ввод реквизитов распознаванием физической карты. Актуальная модель результата v3000 включает платёжную сеть, список обнаруженных карточных счетов, PAN, валидность номера, префикс номера, срок действия, CVV, имя держателя, IBAN и дополнительные данные BIN intelligence, когда они доступны: тип финансирования, категорию карты, название эмитента и страну эмитента. Отдельно возвращаются результаты liveness-проверок и изображения сторон карты, если их возврат разрешён настройками.

Это важно отличать от Microblink Platform. В Platform есть отдельная возможность Scan Payment Card, которая использует BlinkCard как внутренний движок в более широком оркестраторе идентификации и антифрода. У этой возможности своя политика результата: CVV там не возвращается и не хранится. В самостоятельном BlinkCard SDK v3000 поле CVV присутствует в структуре CardAccountResult. Смешивать эти две модели нельзя: у них различаются API, рабочий процесс и правила обработки данных.

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

Основные параметры BlinkCard

Параметр	Актуальное состояние
Разработчик	Microblink
Тип	SDK для распознавания и анализа платёжных карт
Текущая архитектура	v3000, session-based API; прежняя ветка v2 находится в maintenance mode
Основные платформы v3000	Android, iOS, Web; отдельный актуальный wrapper есть для React Native
Android	API 24+; ARMv7 и ARM64; готовый UX на Jetpack Compose или BlinkCardScanActivity
iOS	BlinkCard core для iOS 15+, BlinkCardUX для iOS 16+; Swift Package Manager и ручная интеграция
Web	Пакет @microblink/blinkcard с core, камерой и UX; WebAssembly-ресурсы размещаются на стороне приложения/CDN
Входные данные	Видеопоток камеры или отдельные изображения; в low-level API выбирается Video или Photo
Выход	Структурированный BlinkCardScanningResult и, при разрешении, изображения сторон карты
Распознаваемые поля	PAN, срок действия, имя держателя, CVV, IBAN, сеть; в v3000 — дополнительные BIN-данные при доступности
Антифрод	Проверка экрана, фотокопии, присутствия руки и агрегированный card liveness result
Анонимизация	Для номера карты, префикса, CVV, IBAN и имени держателя; отдельно для изображений и полей результата
Локализация UX	56 встроенных языков в v3000, включая русский; строки можно переопределять
Лицензия	Коммерческая; для запуска сканирования нужен валидный license key
Пробный режим	30-дневный trial через Microblink Developer Hub; требуется регистрация
Публичная цена	Фиксированный прайс для production не опубликован; коммерческий план подбирается через Microblink

Таблица показывает главное отличие BlinkCard от настольных OCR-программ: здесь нет понятия «открыть файл, отредактировать и сохранить проект». Разработчик создаёт сессию, подаёт кадры или изображения, получает структурированный объект и сам решает, как использовать результат в интерфейсе, API или платёжном процессе.

Актуальный статус, версии и платформы

В феврале 2026 года Microblink выпустила BlinkCard v3000.0.0. Это не обычное увеличение номера версии: компания перешла на epoch-versioning и одновременно заменила архитектуру. Вместо отдельных Recognizer-объектов теперь создаётся BlinkCardScanningSession, которая управляет анализом последовательности кадров и выдаёт итоговый BlinkCardScanningResult. Старые production license keys ветки v2 совместимы с v3000, но интеграционный код требует миграции.

На Android актуальная линия v3000 распространяется через Maven Central. В документации и репозитории Android фигурирует версия 3000.0.1; она исправляет завершение SDK и сессий, инициализацию и аналитику. Для готового интерфейса используется зависимость blinkcard-ux, для полностью собственного интерфейса достаточно blinkcard-core. Минимальная версия — Android 7.0, API 24. Нативные бинарники доступны для armeabi-v7a и arm64-v8a.

На iOS BlinkCard v3000 разделён на ядро и BlinkCardUX. Ядро можно разворачивать начиная с iOS 15, а готовый UX-компонент требует iOS 16. Основной путь установки — Swift Package Manager; ручное добавление XCFramework тоже поддерживается. Для проектов, где важна современная версия системы, полезно сверять требования SDK с фактической версией iPhone; на GeekHow есть отдельный материал о том, как устанавливается iOS 26.

Веб-ветка v3000 представлена пакетом @microblink/blinkcard. На дату подготовки обзора публичный npm-пакет достиг версии 3000.0.8. Внутри объединены scanning engine, camera manager, UX manager и необходимые ресурсы. Старый пакет @microblink/blinkcard-in-browser-sdk относится к ветке v2 и не должен использоваться как ориентир для новой интеграции.

React Native также имеет пакет семейства v3000. Он построен поверх нативных SDK, требует Android API 24+ и iOS 16+ и предоставляет готовый scan flow, а также обработку статических изображений. При этом официальная документация прямо советует выбирать нативные SDK, когда нужны максимальная производительность и полный набор возможностей. Capacitor и Cordova-пакеты в публичном npm остаются на старой ветке, поэтому их нельзя автоматически считать эквивалентом v3000.

Жизненный цикл продукта

BlinkCard прошёл несколько функционально разных этапов. Ветка v2 сформировала современную основу распознавания: двустороннее сканирование, вертикальные карты, Visa Quick Read, анонимизацию, улучшенную работу с нестандартными макетами и liveness-проверки. В v2.12 появились дополнительные проверки наклона и стабильности последовательных изображений.

Ветка v3000 стала архитектурной границей. Recognizer API объявлен устаревшим, а v2 переведена в maintenance mode: она продолжает получать исправления для критических проблем безопасности, но новые функции и улучшения качества направлены в v3000. Для проектов, которые только начинают интеграцию, ориентироваться на v2 нет смысла. Она остаётся актуальной только как промежуточный слой в уже выпущенных приложениях и старых cross-platform wrappers.

Новая ветка также изменила структуру результата. Карточные данные теперь группируются в массив cardAccounts, потому что одна физическая карта может представлять несколько платёжных счетов. Liveness возвращается по сторонам и агрегируется в overallCardLivenessResult. Из final result убраны некоторые служебные статусы, которые теперь приходят в BlinkCardProcessResult на уровне кадра.

Для миграции это означает, что обновление нельзя свести к смене номера зависимости. Нужно проверить импорты, модель результата, названия настроек, управление ресурсами, закрытие сессий и UI. В Android дополнительно меняются минимальный API, версия Kotlin/Gradle toolchain и подход к готовому интерфейсу: v3000 делает ставку на Jetpack Compose.

Как устроен интерфейс и рабочий процесс

У BlinkCard нет одного «главного окна». Интерфейс зависит от того, какой слой SDK выбрал разработчик. Самый высокий уровень — готовый BlinkCard UX: приложение показывает экран камеры с рамкой захвата, подсказками, onboarding-диалогом и help-кнопкой. Низкий уровень — BlinkCard Core: разработчик получает результаты анализа каждого кадра и рисует собственный интерфейс.

На Android готовый экран реализован как BlinkCardCameraScanningScreen для Compose или BlinkCardScanActivity для более простого подключения, в том числе к Java-коду. Параметры UiSettings управляют типографикой, схемой цветов, цветами рамки, строками, onboarding и кнопкой помощи. CameraSettings отвечает за фронтальную или заднюю камеру и желаемое разрешение.

Логически рабочий экран состоит из четырёх зон. Первая — camera preview, откуда идут кадры. Вторая — reticle/рамка, помогающая расположить карту. Третья — зона обратной связи: SDK сообщает, что карта слишком близко, слишком далеко, размыта, повернута или требуется вторая сторона. Четвёртая — управляющие элементы вроде закрытия, помощи и onboarding. В custom UX разработчик может заменить эти элементы полностью, но тогда обязан сам корректно реагировать на BlinkCardProcessResult.

Типичный пользовательский путь выглядит так: приложение открывает scan flow, SDK анализирует последовательность кадров, определяет сторону карты, извлекает данные, при необходимости просит перевернуть карту, выполняет liveness checks и завершает сессию. После этого приложение получает результат и либо показывает собственный экран подтверждения, либо сразу передаёт данные следующему модулю. В v3000 интерфейс и движок разъединены, поэтому тот же анализ можно запустить без камеры на заранее полученных изображениях.

Для качества исходного кадра важны обычные правила мобильной съёмки: отсутствие сильной тряски, достаточно света, отсутствие бликов и корректная дистанция. Эти общие принципы дополнительно разобраны в материале GeekHow о том, как лучше фотографировать на камеру iPhone. Сам BlinkCard добавляет к ним машинную проверку размытия, наклона и положения карты.

Основные функции BlinkCard

Распознавание реквизитов

Ядро SDK извлекает карточные данные из камеры или изображения. В v3000 общие поля находятся в BlinkCardScanningResult, а данные отдельных платёжных счетов — в cardAccounts. Это позволяет не сводить физическую карту к одному PAN: структура готова к случаям, когда на карте присутствуют разные account data.

Базовый набор включает PAN и признак его валидности, срок действия, CVV, имя держателя, IBAN и issuing network. Новая BIN intelligence добавляет funding type, card category, issuer name и issuer country, когда эти сведения возвращаются для конкретного номера. Такая информация полезна не для OCR как такового, а для дальнейшего риск-анализа и маршрутизации.

Двустороннее сканирование

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

Проверка качества изображения

В каждом ProcessResult v3000 присутствует inputImageAnalysisResult. Он сообщает статус обработки, текущую сторону, результат обнаружения карты, положение карты, наличие размытия и ориентацию. Благодаря этому интерфейс может дать конкретную подсказку вместо бессодержательного «не удалось распознать».

На Android для успешного live scan требуется camera preview не ниже 1080p. Это не означает, что видео должно записываться в 1080p: документация отдельно разделяет preview resolution и video recording resolution. При использовании фронтальной камеры следует учитывать отсутствие автофокуса на части устройств; для основной камеры такой риск ниже.

Liveness и защита от подмены

Liveness-подсистема проверяет три сигнала: показ карты на экране, использование фотокопии и присутствие руки. Итог доступен отдельно по сторонам и как общий overallCardLivenessResult. Для screen и photocopy checks задаётся уровень строгости, а hand check имеет собственные пороги размера и пересечения руки с картой.

Эти сигналы не превращают BlinkCard в самостоятельную систему авторизации платежа. Они дают приложению дополнительный антифрод-фактор, который можно объединять с собственными правилами, данными аккаунта и платёжной инфраструктурой. Для сервисов, где достаточно обычного автозаполнения реквизитов, liveness можно оценивать отдельно от качества OCR; для сценариев подтверждения физического владения он становится одной из центральных функций.

Анонимизация чувствительных данных

В v3000 AnonymizationSettings управляет маскированием номера карты, префикса, CVV, IBAN и имени держателя. Для номера отдельно задаётся число видимых цифр в начале и в конце. Режимы позволяют скрыть данные только на изображении, только в полях результата или в обоих местах.

Практический смысл этой настройки шире интерфейса. Возврат полного PAN или CVV увеличивает объём чувствительных данных, которые приложение должно защищать в памяти, логах, crash reports, аналитике и backend API. Поэтому конфигурацию анонимизации нужно проектировать до подключения SDK к production-потоку, а не после.

Готовый UX и кастомизация

Готовый UX закрывает управление камерой, рамку, подсказки и переход между сторонами. На Android доступны типографика, цветовая схема, пользовательские строки, onboarding, help button, edge-to-edge и haptic feedback. Более глубокая кастомизация выполняется через собственный Compose UI поверх CameraScreen и BlinkCardAnalyzer.

В v3000 добавлена поддержка screen readers и расширена локализация до 56 языков. Русский входит в готовый набор. Язык интерфейса может следовать настройкам ОС, а строки можно переопределять, если продукт использует собственную терминологию.

Статические изображения и headless-режим

Core API не привязан к камере. В Android BlinkCardScanningSession принимает InputImage, который можно создать из android.media.Image, CameraX ImageProxy или Bitmap. Для потока задаётся InputImageSource.Video, для отдельных картинок — InputImageSource.Photo. Это позволяет встроить движок в собственный camera pipeline или обрабатывать изображения из внутреннего хранилища приложения.

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

Задача → инструмент → результат → что проверить

Задача	Инструмент BlinkCard	Результат	Что проверить
Автозаполнить реквизиты	BlinkCardScanningSession + ExtractionSettings	cardAccounts, cardholderName, IBAN, issuingNetwork	Нужны ли все поля и проходит ли PAN проверку валидности
Сканировать картой через готовую камеру	BlinkCardCameraScanningScreen или BlinkCardScanActivity	Готовый UX и BlinkCardScanningResult	Разрешение камеры, разрешение пользователя, локализация
Использовать свой camera pipeline	blinkcard-core + BlinkCardScanningSession.process	ProcessResult по кадрам и final result	Закрытие ImageProxy, таймауты, обработка всех UX-состояний
Обработать готовую фотографию	InputImageSource.Photo	Результат без встроенного camera flow	Качество, ориентация и полнота сторон
Отсеять экран или копию	LivenessSettings	screen, photocopy, hand и overall liveness	Строгость и долю ложных отклонений на собственном наборе устройств
Снизить объём чувствительных данных	AnonymizationSettings	Маскированные поля и/или изображения	Что реально уходит в логи, аналитику и backend
Определить тип карты и эмитента	BIN intelligence v3000	fundingType, cardCategory, issuerName, issuerCountry	Наличие полей в конкретном результате и сетевую доступность lookup

Карта форматов и совместимости

Для BlinkCard слово «формат» относится не столько к расширениям файлов, сколько к типу входного изображения и структуре результата. SDK не создаёт проектный файл и не экспортирует PDF, CSV или XLSX сам по себе. Экспорт в такие форматы — ответственность приложения, которое получило BlinkCardScanningResult.

Направление	Поддерживаемый тип	Редактируемость	Потери и ограничения	Переносимость
Вход Android	CameraX ImageProxy, android.media.Image, Bitmap и видеопоток	Источник контролирует приложение	Плохой фокус, низкое preview resolution и размытие снижают шанс завершить сканирование	Нативные объекты Android
Вход iOS	Камера и кадры/изображения, передаваемые BlinkCard	Источник контролирует приложение	UX-компонент требует более новую версию iOS, чем core	Нативный Swift/iOS pipeline
Вход Web	Поток browser camera и изображения	Источник контролирует веб-приложение	Нужны WASM/model resources и корректная browser security configuration	JavaScript/TypeScript и браузер
Выход	BlinkCardScanningResult	Структурированные поля можно валидировать и переносить в собственные модели	Отдельные поля могут отсутствовать на карте или быть отключены настройками	Приложение сериализует результат в свой API-формат
Изображения карты	Обрезанные изображения сторон при включённом returnCardImage	Можно хранить, отображать или не возвращать	Хранение увеличивает требования к защите данных; анонимизация может изменить содержимое	Зависит от того, как приложение кодирует изображение

В v3000 encoded image больше не является отдельным полем результата, как в старом API. Это важная миграционная деталь: приложение не должно ожидать прежние encodedFirstSideFullDocumentImage или encodedImage. Если нужна сериализация изображения, её делает сам интегратор после получения нового типа cardImage.

Что перестанет работать первым при проблемах с зависимостями

Лицензия. Сканирование нельзя инициализировать без действующего license key. License key привязан к идентификатору приложения или домену, поэтому смена package/application ID либо production-домена без соответствующей лицензии ломает flow ещё до распознавания.

Ресурсы моделей. v3000 использует отдельные recognition resources. На Android и iOS их можно скачать при первом использовании или положить в пакет приложения. Если выбран downloadResources и сеть недоступна при первом запуске, движок не получит необходимые модели. Bundled resources снимают эту конкретную зависимость, но увеличивают размер поставки.

Камера. Без permission или без поддерживаемого video input готовый scan flow не начнёт захват. Для Android критичны API 24+, поддерживаемая ARM-архитектура и camera preview не ниже 1080p. Во вебе дополнительно действуют ограничения браузера; актуальный пакет не поддерживает camera-based scanning в Firefox для Android.

Совместимость toolchain. На Android v3000 требует современный Gradle/Compose-стек; на iOS BlinkCardUX требует iOS 16+. Если приложение должно поддерживать более старые устройства, разработчик либо остаётся на предыдущей ветке на время миграции, либо меняет минимальную версию приложения. Это не настраивается одной опцией SDK.

Сеть для лицензирования и enrichment. Базовое распознавание построено как локальная обработка на устройстве или в браузере, но license management выполняет периодические проверки, а BIN intelligence использует real-time BIN lookup. Для полностью изолированной среды это нужно учитывать отдельно от офлайн-доступности ML-моделей.

Если проблема касается именно подключения, а не BlinkCard, базовую диагностику сети можно сверить с материалом GeekHow о том, почему нет подключения к интернету на компьютере. Для браузерной интеграции это особенно полезно при загрузке WASM-ресурсов, CDN и проверке лицензии.

Производительность и требования к устройству

Microblink не публикует универсальный норматив «столько миллисекунд на карту» для всех устройств, поэтому сравнивать производительность лучше по архитектурным факторам. v3000 уменьшил вес Android SDK за счёт динамической загрузки моделей. В Android-документации рост размера приложения указан примерно как 3,04 МБ download / 3,84 МБ install для armeabi-v7a и 3,10 МБ / 4,29 МБ для arm64-v8a.

Распознавание выполняется нативным C++-ядром. На Android поддерживаются только ARMv7 и ARM64. Если другое нативное расширение в приложении упаковано для несовместимого ABI, загрузка может завершиться UnsatisfiedLinkError ещё до открытия камеры. Поэтому abiFilters должны соответствовать общему набору нативных библиотек.

Camera preview должен быть минимум 1080p. SDK позволяет выбирать разрешение через CameraSettings; в Android примере допустимый диапазон настроек идёт от 720p до 4320p, но это не отменяет требования к успешному сканированию. Более высокое разрешение не гарантирует лучший результат само по себе: важны фокус, стабильность и достаточная детализация символов.

При low-level интеграции производительность зависит и от того, как приложение кормит SDK кадрами. Каждый ImageProxy нужно закрывать после анализа, иначе pipeline CameraX начнёт накапливать ресурсы. После завершения сканирования необходимо закрыть BlinkCardScanningSession; закрытие SDK и очистку кэша следует выполнять вне UI thread, потому что эти операции блокирующие.

Безопасность, приватность и PCI DSS

Главное достоинство архитектуры BlinkCard для приватности — локальная обработка изображения. Мобильные SDK распознают карту на устройстве, а браузерная версия выполняет OCR в WebAssembly. Это позволяет не отправлять сырое изображение на удалённый OCR-сервис только ради извлечения текста. Однако локальный OCR не означает, что интеграция автоматически становится полностью офлайн или автоматически соответствует PCI DSS.

License management, загрузка моделей и BIN intelligence создают отдельные сетевые зависимости. Их нужно проектировать как самостоятельные каналы: доступность OCR и доступность лицензии — разные вещи. Для mobile можно заранее упаковать recognition resources, отключив их загрузку при запуске. Для Web ресурсы WASM и модели нужно корректно раздавать с инфраструктуры приложения или CDN.

Самая чувствительная настройка — возврат PAN и CVV. BlinkCard SDK умеет маскировать данные в полях результата и на изображениях. Если приложению достаточно последних четырёх цифр и сигнала liveness, нет технической причины сохранять полный номер только «на всякий случай». Чем меньше полных реквизитов выходит из scanning session, тем меньше мест приходится защищать.

Нельзя логировать полный PAN или CVV в debug/analytics. В troubleshooting Microblink просит включать verbose logging для диагностики поведения SDK, но это не делает допустимым собственное логирование карточных реквизитов. Перед отправкой журналов в поддержку разработчику нужно убедиться, что его код не добавляет чувствительные поля поверх системных логов SDK.

Если продукт уже использует Apple Pay, BlinkCard решает другую задачу: Apple Pay токенизирует оплату, а BlinkCard распознаёт физическую карту и при необходимости оценивает её присутствие. Сравнить пользовательскую сторону кошелька можно в отдельной инструкции GeekHow о том, как подключить и использовать Apple Pay.

Цена, лицензирование и пробный период

BlinkCard — коммерческий SDK. Для инициализации нужен license key, связанный с конкретным application ID, bundle identifier или доменом веб-приложения. Это не формальность: неверная привязка даёт лицензионную ошибку ещё до рабочего сканирования.

Для знакомства доступен 30-дневный trial через Microblink Developer Hub. Регистрация обязательна; для тестового периода банковская карта не требуется. Такой trial подходит для sample app, прототипа и проверки распознавания на собственном наборе устройств, но не заменяет production-лицензию.

Открытого фиксированного прайса BlinkCard на production у Microblink нет. Страница планов предлагает связаться с компанией и подобрать коммерческие условия под нагрузку и сценарий. Поэтому корректное бюджетирование строится через коммерческое предложение, а не через условную цену «за одну лицензию», которую нельзя подтвердить публично.

При расчёте владения нужно учитывать не только лицензию. В стоимость входят разработка интеграции, адаптация UX, тестирование на реальных устройствах, compliance-аудит, поддержка backend-обработки, мониторинг ошибок, обновления major/epoch-версий и потенциальная миграция старых wrappers. Для v3000 переход с v2 заметно дороже обычного patch-update из-за смены API.

Как пользоваться программой — советы гика

Практическая часть ниже описывает BlinkCard как SDK. Это не действия обычного владельца банковской карты, а воспроизводимые шаги разработчика, который добавляет сканирование в приложение. Для каждой операции указаны точные сущности v3000 и безопасный откат.

Получить trial-лицензию и привязать её к приложению

Цель. Подготовить license key, без которого BlinkCard не инициализируется. Подготовка. Нужен аккаунт Microblink Developer Hub и точный application ID, bundle identifier или домен тестового веб-приложения.

Создайте аккаунт Developer Hub и запустите 30-дневный trial для BlinkCard.
При создании лицензии укажите платформу и фактический идентификатор приложения; для Web укажите полный домен.
Сохраните выданный license key в защищённой конфигурации проекта, а не в публичном репозитории.
Для Android передайте его в BlinkCardSdkSettings через параметр licenseKey; для iOS используйте одноимённое поле настроек; для Web передайте licenseKey в createBlinkCard.

Важный параметр. Идентификатор должен совпадать с тем, под которым реально запускается сборка. Проверка. Инициализация должна завершиться без license error. Типичная ошибка. Debug-сборка использует другой application ID или веб-приложение открыто с другого домена. Безопасный откат. Не менять package ID production-приложения ради теста; выпустить корректный trial key под фактический идентификатор.

Подключить BlinkCard v3000 в Android-проект

Цель. Получить готовый scan flow на Android. Подготовка. Android 7.0/API 24+, Maven Central, поддерживаемый ARM ABI и современный Gradle/Compose-проект.

Убедитесь, что в repositories подключён mavenCentral().
В module build.gradle или build.gradle.kts добавьте зависимость com.microblink:blinkcard-ux:3000.0.1.
Инициализируйте SDK вызовом BlinkCardSdk.initializeSdk и передайте BlinkCardSdkSettings с licenseKey.
После успешной инициализации отобразите BlinkCardCameraScanningScreen и передайте sdkInstance.
Обработайте onScanningSuccess и onScanningCanceled; результат успешного потока имеет тип BlinkCardScanningResult.

Важные параметры. Для простого интерфейса достаточно стандартных BlinkCardUxSettings, UiSettings, CameraSettings и BlinkCardSessionSettings. Проверка. На физическом ARM-устройстве открывается камера и появляется scan overlay. Типичная ошибка. UnsatisfiedLinkError из-за несовместимого ABI. Безопасный откат. Удалить новую зависимость, вернуть исходные abiFilters и убедиться, что приложение снова запускается до повторной интеграции.

Подключить BlinkCard на iOS через Swift Package Manager

Цель. Добавить ядро и готовый UX в Swift-приложение. Подготовка. Для core нужен iOS 15+, для BlinkCardUX — iOS 16+; проект должен собираться поддерживаемым Xcode/Swift toolchain.

В Xcode откройте File > Add Package Dependencies….
Для BlinkCard core добавьте официальный Swift package BlinkCard; для готового UX подключите пакет BlinkCardUX из репозитория BlinkCard iOS.
Добавьте продукт BlinkCardUX в target, если нужен готовый интерфейс; он подтянет binary target BlinkCard.
Добавьте описание доступа к камере в Info.plist.
Создайте BlinkCardSdkSettings с licenseKey, инициализируйте SDK и запустите UX-компонент или собственную scanning session.

Важный параметр. Не устанавливайте deployment target ниже требований выбранного слоя. Проверка. Сборка проходит на реальном устройстве, а система показывает штатный диалог разрешения доступа к камере. Типичная ошибка. Проект поддерживает iOS 15, но подключён BlinkCardUX с минимумом iOS 16. Безопасный откат. Удалить UX package и оставить core для собственного интерфейса либо вернуть прежний SDK до пересмотра минимальной версии приложения.

Подключить веб-версию v3000

Цель. Запустить распознавание в браузере без старого in-browser package v2. Подготовка. Современный браузер, HTTPS, npm/yarn/pnpm и доменная лицензия.

Установите пакет @microblink/blinkcard.
Импортируйте createBlinkCard из @microblink/blinkcard.
Создайте экземпляр через createBlinkCard и передайте licenseKey.
Если ресурсы не входят в выбранную сборку, задайте resourcesLocation и разместите WASM/model files на своём сервере или CDN с корректными CORS и cross-origin headers.
Запустите camera flow из интерфейса приложения и обработайте финальный результат.

Важные параметры. Ресурсы лучше отдавать с предсказуемым кэшированием и того же origin, когда архитектура позволяет. Проверка. В Network нет 404/CORS для resources, а камера доступна через navigator.mediaDevices. Типичная ошибка. Используется старый @microblink/blinkcard-in-browser-sdk и Recognizer API. Безопасный откат. Вернуть lockfile и package.json к рабочей версии, а миграцию v3000 проводить отдельной веткой.

Запустить live-сканирование карты с готовым UX

Цель. Получить реквизиты с физической карты через камеру. Подготовка. Инициализированный SDK, camera permission и корректная лицензия.

Создайте BlinkCardSessionSettings с inputImageSource = Video.
Оставьте стандартный ScanningSettings на первом проходе, чтобы не смешивать ошибки интеграции и нестандартные пороги.
Откройте BlinkCardCameraScanningScreen, BlinkCardScanActivity или эквивалентный UX на iOS/Web.
Поместите сторону с номером карты в рамку; SDK самостоятельно анализирует кадры и фиксирует первую сторону.
Если данных недостаточно, следуйте событию второй стороны и переверните карту.
После onScanningSuccess получите BlinkCardScanningResult и закройте scan screen.

Важные параметры. На Android preview должен обеспечивать минимум 1080p, а задняя камера обычно предпочтительнее фронтальной. Проверка. resultCompleteness доходит до завершённого состояния, а в final result присутствует ожидаемый cardAccounts. Типичная ошибка. Пользователь держит карту слишком близко, далеко или под сильным углом. Безопасный откат. Отменить текущую сессию и запустить новую без изменения настроек распознавания.

Распознать статическое изображение без встроенной камеры

Цель. Использовать BlinkCard как headless OCR/analyzer. Подготовка. Подключён blinkcard-core и есть Bitmap/Image/ImageProxy либо эквивалентный объект изображения.

Инициализируйте BlinkCardSdk.
Создайте BlinkCardScanningSession с inputImageSource = Photo.
Преобразуйте исходную картинку в поддерживаемый InputImage.
Передайте изображение в BlinkCardScanningSession.process.
Проверьте BlinkCardProcessResult; если resultCompleteness сообщает завершение, вызовите getResult().
Закройте BlinkCardScanningSession после получения результата.

Важный параметр. Photo предназначен для отдельных изображений; Video — для непрерывной последовательности кадров. Проверка. Final result получен без запуска стандартного camera UI. Типичная ошибка. В Photo-session подаётся только одна сторона карты, хотя нужные поля находятся на другой. Безопасный откат. Не перезаписывать исходные изображения; создать новую session и подать обе стороны.

Ограничить извлекаемые поля

Цель. Не получать данные, которые продукт не использует. Подготовка. Список реально необходимых полей и схема дальнейшего backend-процесса.

Создайте ScanningSettings.
Вложите ExtractionSettings и включите только те поля, которые нужны сценарию.
Для имени держателя используйте extractCardholderName; для невалидных тестовых номеров предусмотрен extractInvalidCardNumber.
Оставьте отключёнными необязательные чувствительные поля, если они не участвуют в бизнес-логике.
Запустите тестовый scan и проверьте ResultCompleteness для каждого извлекаемого поля.

Важный параметр. «Не запрашивать» и «не найдено на карте» — разные статусы. Проверка. В final result отсутствуют ненужные данные, а обязательные поля получают expected extraction status. Типичная ошибка. Backend ожидает поле, отключённое в новой конфигурации. Безопасный откат. Вернуть предыдущий набор ExtractionSettings без изменения остальных liveness/anonymization параметров.

Настроить liveness без чрезмерных ложных отказов

Цель. Использовать screen, photocopy и hand checks как антифрод-сигнал. Подготовка. Набор реальных тестовых карт и устройств; одно значение строгости нельзя оценивать только на simulator/emulator.

Откройте LivenessSettings внутри ScanningSettings.
Оставьте enableCardHeldInHandCheck включённым, если сценарий требует подтверждать физическое владение картой.
Настройте screenCheckStrictnessLevel и photocopyCheckStrictnessLevel только после получения базовой статистики на стандартных значениях.
Для hand check при необходимости измените handToCardSizeRatio и handCardOverlapThreshold.
После сканирования анализируйте firstSideResult, secondSideResult и overallCardLivenessResult.

Важный параметр. Более строгий порог меняет баланс между отказами реальным пользователям и пропуском подделок. Проверка. Реальные карты стабильно проходят на целевых устройствах, а тестовые screen/photocopy сценарии дают ожидаемые сигналы. Типичная ошибка. Сразу выставить максимальную строгость и принять высокий отказ за ошибку OCR. Безопасный откат. Вернуть default StrictnessLevel и повторить выборку до изменения production-конфигурации.

Включить анонимизацию PAN, CVV и изображений

Цель. Снизить объём чувствительных данных вне scanning engine. Подготовка. Понимание того, какие реквизиты действительно нужны UI и backend.

Откройте AnonymizationSettings в ScanningSettings.
Для cardNumberAnonymizationSettings задайте режим и число prefixDigitsVisible/suffixDigitsVisible.
Отдельно задайте режимы для cardNumberPrefix, CVV, IBAN и cardholderName.
Выберите ImageOnly, ResultFieldsOnly или FullResult в зависимости от того, где должно применяться маскирование.
Запустите тестовый scan и проверьте одновременно поля результата и возвращаемые cardImage.

Важный параметр. Маскирование поля результата не гарантирует маскирование изображения, если выбран ResultFieldsOnly. Проверка. Ненужные цифры не видны ни в объекте, ни в изображении в соответствии с политикой продукта. Типичная ошибка. Защитить UI, но оставить полные изображения в кэше. Безопасный откат. Переключить режим на FullResult и удалить ранее сохранённые тестовые файлы из debug storage.

Настроить внешний вид, onboarding и русский язык

Цель. Встроить BlinkCard в дизайн приложения без разрушения scan flow. Подготовка. Готовая цветовая схема, типографика и тексты интерфейса.

В Android создайте UiSettings и задайте typography, colorScheme, uiColors и sdkStrings.
Используйте showOnboardingDialog для включения или отключения вводного окна и showHelpButton для кнопки помощи.
Для русского интерфейса оставьте системную локаль или переопределите нужные strings в ресурсах приложения.
Если стандартный экран недостаточен, переходите к собственному Composable поверх CameraScreen и BlinkCardAnalyzer вместо хаотичного изменения готового flow.
Проверьте светлую и тёмную тему, screen reader и крупный системный шрифт.

Важный параметр. В BlinkCardScanActivity ответственность за корректное соответствие цветов dark/light теме лежит на интеграторе. Проверка. Подсказки читаются, рамка видна на камере, кнопки доступны для screen reader. Типичная ошибка. Убрать почти все подсказки ради минималистичного дизайна и ухудшить понимание второй стороны. Безопасный откат. Вернуть Default UiSettings и менять по одному визуальному параметру за итерацию.

Обработать результат и корректно закрыть SDK

Цель. Завершить сквозной сценарий от сканирования до передачи результата и освобождения ресурсов. Подготовка. Определён DTO/backend contract и политика хранения карточных данных.

В onScanningSuccess получите BlinkCardScanningResult.
Проверьте issuingNetwork, cardholderName, IBAN и каждый элемент cardAccounts; отдельно обработайте cardNumberValid.
Проверьте overallCardLivenessResult и per-side checks, если они участвуют в принятии решения.
Скопируйте только разрешённые поля в собственную модель приложения; не сериализуйте весь объект «на будущее».
Передайте данные следующему модулю по защищённому внутреннему интерфейсу или API.
Закройте BlinkCardScanningSession. Если SDK больше не нужен, вызовите close; если нужно удалить и кэшированные assets — closeAndDeleteCachedAssets вне главного UI thread.

Важный параметр. cardAccounts — список, а не один объект. Проверка. UI закрыт, камера освобождена, новая scanning session открывается без конфликта, а backend получает только нужные поля. Типичная ошибка. Забыть закрыть session или ImageProxy и получить зависание следующего camera flow. Безопасный откат. Отменить незавершённую операцию, закрыть текущие session/SDK objects и повторно инициализировать чистый экземпляр.

Плюсы и минусы

Плюсы

актуальная v3000 имеет единый session-based API вместо связки recognizer-объектов;
есть нативные SDK Android и iOS, веб-пакет и актуальный React Native wrapper;
ядро отделено от готового UX, поэтому можно выбрать быстрый drop-in экран или полностью собственный интерфейс;
поддерживаются live camera и статические изображения;
результат включает не только OCR, но и liveness-сигналы;
анонимизация настраивается раздельно для полей и изображений;
56 встроенных языков, включая русский, и поддержка screen readers;
Android SDK сравнительно компактен по добавляемому размеру и может загружать модели динамически;
мобильная и браузерная обработка OCR выполняется локально, что уменьшает необходимость отправлять сырые изображения на сервер распознавания.

Минусы

production-цена не опубликована и требует коммерческого согласования;
для запуска нужен привязанный license key и периодическая лицензионная проверка;
v3000 — ломающая миграция для проектов на Recognizer API v2;
Android больше не поддерживает API ниже 24, а BlinkCardUX на iOS требует iOS 16+;
не все старые cross-platform wrappers перешли на v3000;
полный low-level UX требует самостоятельного camera management, таймаутов и обработки всех frame-level состояний;
возврат PAN/CVV и card images повышает требования к PCI DSS и внутренней защите данных;
веб-версия зависит от корректного размещения WASM/resources и ограничений конкретных браузеров.

Кому подойдёт

Финтеху и банкам, которым нужен ввод данных физической карты с дополнительным сигналом присутствия карты.
E-commerce и marketplaces, где ручной ввод PAN создаёт лишнее трение, а антифрод-процесс уже умеет принимать дополнительные liveness/BIN признаки.
Разработчикам приложений, которым нужен одинаковый движок на Android, iOS и Web с возможностью перейти от готового UI к headless API.
Командам с собственным camera pipeline, потому что core принимает отдельные изображения и не требует использовать фирменный экран.
Продуктам с жёсткой политикой минимизации данных, если команда готова правильно настроить ExtractionSettings и AnonymizationSettings до выхода в production.

Кому не подойдёт

Обычному пользователю, который ищет отдельное приложение для распознавания своей карты: BlinkCard предназначен для встраивания разработчиками.
Проекту без бюджета на коммерческую лицензию, если production должен оставаться полностью бесплатным и open source.
Приложению со старыми ОС, если нельзя поднять минимум до Android API 24 и iOS 15/16 в зависимости от слоя.
Команде без PCI/compliance процесса, если предполагается сохранять полный PAN, CVV или изображения карт без заранее определённой модели защиты.
Сценарию, где нужен только платёжный токен, а сами реквизиты приложению не нужны: в таком случае managed payment SDK может сократить площадь обработки чувствительных данных.

Сравнение с другими аналогами

Сравнивать BlinkCard корректно не с «приложениями-сканерами», а с библиотеками, которые разработчик встраивает в продукт. Ниже три решения с разной специализацией: универсальный credit-card scanner, большой document reader и платёжно-ориентированный CardScan.

Критерий	Microblink BlinkCard	Scanbot SDK Credit Card Scanner	Regula Document Reader SDK	StripeCardScan
Основная задача	Сканирование платёжных карт + liveness + BIN enrichment	Распознавание номера, срока и имени держателя	Большой document-reader с отдельным сценарием CreditCard	Сканирование платёжной карты и выдача результата в экосистеме Stripe CardScan
Платформы	Android, iOS, Web, React Native	Android, iOS, Web, Capacitor и другие SDK-платформы	Mobile, Web Service, Desktop и другие варианты	iOS 15+ для standalone StripeCardScan; card scanning также присутствует в Stripe mobile payment SDK
Порог освоения	Средний; простой готовый UX, высокий при headless	Средний; Ready-to-Use UI и Custom UI	Высокий из-за широкой платформы документов и сценариев	Низкий для iOS drop-in CardScanSheet
Вход	Камера и статические изображения	Live scanner и изображения	Камера/изображения в рамках document processing	Камера внутри CardScanSheet
Выход	Структурированные реквизиты, изображения, liveness, BIN data	Номер, срок, имя держателя	OCR-поля банковской карты в общей модели Document Reader	ScannedCard/CardScan result, ориентированный на payment card OCR
Антифрод	Screen, photocopy, hand presence и overall liveness	Основной акцент — OCR/credit card capture	Широкий набор document authenticity инструментов, но карта — один из сценариев	Есть отдельные возможности Card Image Verification; продукт теснее связан с Stripe-сервисами
Автоматизация	Session API, headless processing, per-frame feedback	API для live и image scanning	Много сценариев обработки документов и серверных вариантов	Drop-in sheet и completion result
Модель оплаты	Коммерческая, индивидуальное предложение; 30-дневный trial	Фиксированная годовая лицензия по коммерческому предложению; 7-дневный trial, без лицензии — до одной минуты на сессию	Mobile/Online/Software/Hardware licensing; trial на 30 дней и 2000 транзакций	Standalone SDK использует Stripe publishable key; отдельная публичная цена в API-документации CardScan не указана
Главное ограничение	Индивидуальное коммерческое предложение и миграция v2→v3000	Нет такой же акцентированной card-liveness модели, как у BlinkCard	Избыточен, если нужна только платёжная карта	Уже по назначению и сильнее привязан к Stripe-архитектуре
Когда выбирать	Нужен dedicated card SDK с liveness и гибким UX	Нужен прямой credit-card OCR в составе более широкого scanning SDK	В продукте уже обрабатываются паспорта, ID и банковские карты одним стеком	iOS-приложение уже использует Stripe или нужен максимально простой card-scan sheet

Scanbot ближе всего к BlinkCard по механике «камера → карточные поля», но BlinkCard сильнее выделяет liveness и BIN intelligence. Regula полезнее, если банковская карта — лишь один из многих типов документов. StripeCardScan рационален, когда задача находится рядом с Stripe payment stack и не требуется независимый multi-platform SDK со своей моделью liveness.

Типичные проблемы и диагностика

SDK не инициализируется из-за license error

Симптом: initializeSdk завершается ошибкой до открытия камеры. Причина: license key отсутствует, истёк или привязан к другому application ID/domain. Диагностика: сравнить фактический identifier сборки с данными лицензии и проверить статус trial/production key. Исправление: выпустить правильный license key для нужной платформы и идентификатора. Проверка: SDK создаёт экземпляр и scan flow открывается без лицензионного исключения.

Android-приложение падает с UnsatisfiedLinkError

Симптом: приложение завершается при загрузке BlinkCard. Причина: несовместимые ABI между BlinkCard и другой нативной библиотекой. Диагностика: проверить содержимое APK/AAB и abiFilters; BlinkCard v3000 поддерживает armeabi-v7a и arm64-v8a. Исправление: оставить общий поддерживаемый набор ABI для всех нативных зависимостей. Проверка: приложение запускается на физическом ARM-устройстве и создаёт BlinkCardSdk.

Камера открывается, но карта не захватывается

Симптом: preview работает, однако scanning session долго остаётся в progress. Причина: низкое preview resolution, плохой фокус, сильный наклон, размытие или неверная дистанция. Диагностика: посмотреть detectionStatus, blurDetectionStatus и cardRotation в ProcessResult; отдельно проверить фактическое camera preview resolution. Исправление: использовать заднюю камеру с autofocus, минимум 1080p preview и вернуть стандартные CameraSettings. Проверка: resultCompleteness последовательно переходит к sideScanned/cardScanned.

После поворота Android-устройства появляется чёрный preview

Симптом: камера на короткое время становится чёрной после rotation/configuration change. Причина: CameraX переинициализирует камеру при пересоздании Activity. Диагностика: сравнить поведение BlinkCardScanActivity и собственного Compose screen. Исправление: при необходимости добавить в manifest обработку screenSize, smallestScreenSize, orientation и screenLayout аналогично готовой activity. Проверка: rotation больше не вызывает пересоздание камеры в выбранной конфигурации.

Статическое изображение распознаётся хуже live camera

Симптом: Photo-session не выдаёт полный результат, хотя live scan работает. Причина: среди переданных изображений нет стороны с нужными полями, символы размыты или фото обрезано слишком близко к карте. Диагностика: проверить InputImageAnalysisResult и extraction status каждого поля. Исправление: подать качественные изображения тех сторон карты, где находятся требуемые данные, и не использовать случайный screenshot вместо исходного фото. Проверка: final result возвращается после обработки достаточного набора изображений.

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

Симптом: отсутствуют BlinkCardRecognizer, старые imports и привычные result fields. Причина: v3000 удаляет Recognizer architecture и перестраивает модели данных. Диагностика: найти все обращения к BlinkCardRecognizer, owner, issuer, encodedFullDocumentImage и старым liveness match levels. Исправление: перейти на BlinkCardSdk, BlinkCardScanningSession, cardholderName, issuingNetwork, cardAccounts и новые side result. Проверка: проект собирается без compatibility shims, а тестовые сценарии читают новый result object.

В Web не загружаются WASM или model resources

Симптом: createBlinkCard или начало scan flow завершается сетевой/CORS ошибкой. Причина: неверный resourcesLocation, 404, неподходящие CORS/Cross-Origin headers или смешанный HTTP/HTTPS. Диагностика: открыть DevTools Network и проверить каждый resource request. Исправление: разместить ресурсы по ожидаемому пути, включить корректные заголовки и использовать HTTPS. Проверка: все ресурсы получают 200, после чего SDK инициализируется.

В браузере нет доступной камеры

Симптом: SDK работает с изображениями, но camera scanning не стартует. Причина: браузер не дал permission, устройство не предоставляет video input или используется неподдерживаемая комбинация; для Firefox на Android camera-based scanning в актуальном web package не поддерживается. Диагностика: проверить navigator.mediaDevices, разрешение камеры и браузер. Исправление: переключиться на поддерживаемый браузер/устройство или предложить upload/static-image flow. Проверка: камера появляется в списке и preview запускается. Если камера в Windows не определяется на системном уровне, пригодится отдельная инструкция GeekHow по ошибке 0xA00F4244.

Liveness слишком часто отклоняет реальные карты

Симптом: OCR завершается, но overallCardLivenessResult часто получает Fail. Причина: чрезмерно строгие screen/photocopy thresholds, нестабильный свет или неподходящие hand settings. Диагностика: разделить screen, photocopy и hand results по сторонам и собрать статистику по устройствам. Исправление: вернуть default StrictnessLevel и менять только один параметр за итерацию. Проверка: доля отказов на реальных картах становится приемлемой без отключения нужного антифрод-сигнала.

После сканирования следующая сессия зависает

Симптом: первый scan проходит, второй не получает кадры или камера остаётся занята. Причина: предыдущий BlinkCardScanningSession, ImageProxy или SDK instance не был корректно закрыт. Диагностика: проверить lifecycle и наличие close() в success, cancel и error branches. Исправление: закрывать каждый ImageProxy, затем session; SDK закрывать или сохранять по осознанной lifecycle-модели. Проверка: несколько последовательных scan flows открываются без роста числа активных camera resources.

В результате неожиданно отсутствует поле

Симптом: cardholderName, IBAN, CVV или BIN field равен null/undefined. Причина: поле отсутствует на самой карте, отключено ExtractionSettings либо enrichment не вернул значение. Диагностика: проверить ResultCompleteness и настройки извлечения, а не считать null ошибкой сети по умолчанию. Исправление: сделать модель backend допускающей optional fields и требовать только действительно обязательные данные. Проверка: приложение корректно завершает scan flow как с полным, так и с частичным набором карточных данных.

FAQ

Можно ли скачать BlinkCard как обычное приложение?

Основной продукт BlinkCard — SDK. Microblink предоставляет демонстрационные приложения и web demo для оценки технологии, но production-сценарий строится через интеграцию SDK в собственное приложение.

Работает ли BlinkCard без интернета?

Само OCR-распознавание выполняется локально на устройстве или в браузере. Мобильные recognition resources можно заранее вложить в приложение. При этом BlinkCardSdk отвечает за актуальность license check, а BIN intelligence использует real-time lookup, поэтому «локальное OCR» и «полностью автономная работа всех настроенных функций» — не одно и то же.

Нужно ли хранить фотографию карты?

Нет. CroppedImageSettings позволяет управлять возвратом card image, а AnonymizationSettings — маскированием изображения. Если бизнес-процессу достаточно текстовых полей и liveness result, хранение картинки можно исключить.

Почему в Microblink Platform CVV не возвращается, а в BlinkCard SDK есть поле CVV?

Это разные продукты и API-контракты. Самостоятельный BlinkCard v3000 имеет cvv в CardAccountResult. Возможность Scan Payment Card внутри Microblink Platform применяет собственные правила и не возвращает/не хранит CVV. При проектировании нужно ориентироваться на документацию именно выбранного продукта.

Можно ли использовать BlinkCard только для номера карты?

Да. ExtractionSettings позволяет ограничить набор извлекаемых данных. Это предпочтительнее, чем получать все возможные реквизиты и затем удалять их в приложении.

Есть ли русский язык?

Да. Русский входит в 56 встроенных локализаций v3000. На Android SDK может автоматически подстраиваться под системный язык, а строки можно переопределить собственными ресурсами.

Поддерживает ли BlinkCard старые Android-устройства?

Ветка v3000 требует Android API 24 или новее. Старые версии v2 поддерживали более ранние Android, но они находятся в maintenance mode и не получают новые функции. Для нового проекта это аргумент в пользу повышения minSdk, а не старта на v2.

Можно ли использовать Java без Kotlin и Compose?

Да, но официальный путь ограничен BlinkCardScanActivity. Для полного low-level API и современного UX Microblink рекомендует Kotlin, потому что v3000 активно использует coroutines и Compose.

Подходит ли BlinkCard для desktop-приложения Windows?

Сам BlinkCard v3000 ориентирован на Android, iOS и Web. Для desktop-сценария рациональнее использовать web-оболочку в поддерживаемом браузере или выбрать другой SDK, который официально предоставляет desktop API, например Regula Document Reader. Старые упоминания других платформ не следует считать текущей v3000-поддержкой.

Заменяет ли BlinkCard Apple Pay, Google Pay или Stripe PaymentSheet?

Нет. BlinkCard извлекает и анализирует данные физической карты. Кошельки и payment sheets решают задачу принятия платежа и токенизации. В продукте эти механизмы могут сосуществовать: например, wallet остаётся основным способом оплаты, а BlinkCard используется для отдельного потока card provisioning или проверки физического владения.

Вывод

BlinkCard v3000 стоит рассматривать как специализированный компонент для приложений, которым нужен не просто OCR номера карты, а управляемый scan flow с двусторонним захватом, liveness, анонимизацией и структурированным результатом. Для нового Android/iOS/Web проекта его текущая session-based архитектура предпочтительнее ветки v2: она лучше разделяет движок и интерфейс, уменьшает зависимость от прежних recognizer-объектов и даёт нормальный headless-путь.

Для простого автозаполнения реквизитов сильная сторона BlinkCard — готовый UX и возможность извлекать только нужные поля. Для антифрода — screen/photocopy/hand checks и BIN intelligence. Для сложной собственной камеры — BlinkCard Core с ProcessResult по каждому кадру. Главный компромисс находится не в OCR, а в интеграции: коммерческая лицензия, требования новых ОС, сетевые проверки и ответственность разработчика за PCI DSS остаются обязательной частью проекта.

Если продукту нужен только небольшой drop-in scanner в Stripe-приложении, специализированный StripeCardScan может быть проще. Если одновременно распознаются десятки типов удостоверений личности и банковские карты, Regula даёт более широкий document stack. Если нужен самостоятельный card-focused SDK на мобильных платформах и в Web с акцентом на liveness и гибкость UX, BlinkCard остаётся наиболее предметным вариантом из этой группы.