BlinkReceipt: инструкция от гика, распознавание бумажных чеков в мобильных приложениях и через Scan API

↓Скачать Microblink BlinkReceipt

Microblink BlinkReceipt — не обычная программа, которую пользователь устанавливает на компьютер и запускает отдельным окном. Это технология распознавания розничных чеков, которая встраивается в мобильное приложение как SDK либо вызывается с сервера через Scan API. В сентябре 2026 года у продукта переходный статус: Microblink прямо сообщает, что BlinkReceipt теперь называется Actual, а действующая документация Actual продолжает использовать названия BlinkReceipt SDK, пакеты BlinkReceipt и домен Scan API. Поэтому под BlinkReceipt в этом обзоре понимается именно система захвата и структурирования бумажных чеков, ныне развиваемая в составе Actual Capture, а не отдельное приложение для личного учёта расходов.

Главная задача BlinkReceipt — превратить фотографию кассового чека в структурированные данные. Вместо сплошного OCR-текста интеграция получает сведения о продавце, дате и времени покупки, итоговой сумме, налогах, способе оплаты, а также позиции корзины с описанием, количеством, ценой, скидкой и единицей измерения. Для мобильных приложений базовое распознавание выполняется на устройстве; для веб-сервисов, серверных систем и пакетной обработки предусмотрен Scan API. Дополнительные механизмы оценивают качество изображения, отмечают дубликаты и отдельные признаки риска, а Product Intelligence может нормализовать товарные позиции до бренда, категории и UPC.

Важно не смешивать BlinkReceipt с соседними продуктами. Распознавание бумажного чека относится к Actual Capture и сохраняет техническое имя BlinkReceipt. Подключение электронных чеков и покупок из почты относится к отдельному направлению Actual Links и исторически использует BlinkEReceipt. Это разные интеграции, поэтому наличие e-mail-подключения в линейке Actual не означает, что базовый BlinkReceipt SDK сам читает почтовый ящик.

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

Параметр	Подтверждённое состояние
Тип продукта	SDK для iOS и Android плюс серверный Scan API для распознавания бумажных кассовых чеков
Текущий бренд	BlinkReceipt переименован в Actual; функция распознавания бумажных чеков входит в Actual Capture, при этом технические имена BlinkReceipt сохранены
Текущая организация	BlinkReceipt, LLC, работающая под брендом Actual; продукт исторически развивался в Microblink
Мобильные платформы	iOS и Android
Android	Для актуальной ветки 2.x минимум Android 7.0 / API 24; release notes версии 2.1.0 подняли порог с API 23 до 24. Текущая страница установки paper receipt всё ещё показывает API 23, поэтому для 2.x приоритетнее требования конкретного релиза. Compile SDK 36+ и Java 17+, ARM armeabi-v7a и arm64-v8a, камера от 720p
iOS	Актуальный пакет BlinkReceipt 1.75.0 требует iOS 15.0+; доступна интеграция через CocoaPods или Swift Package Manager, для камеры требуется системное разрешение
Серверный вариант	REST Scan API без собственной камеры и пользовательского интерфейса
Вход Scan API	PNG или JPEG, загрузка файла либо общедоступный URL изображения, до 10 МБ на изображение
Результат Scan API	Структурированный JSON с данными чека, позициями корзины, показателями качества и уверенности
Длинные чеки	Поддерживается многокадровое сканирование с совмещением частей чека
OCR-языки	Английский, испанский, французский, немецкий, польский, португальский и шведский; распознавание ориентировано на латинские символы
Подтверждённые рынки	США, Канада, Мексика, Бразилия, Великобритания, Германия, Испания, Польша, Швеция, Австралия, Франция и Бельгия
Обработка в мобильном SDK	Основное распознавание бумажного чека выполняется на устройстве; изображение чека для этого этапа не отправляется в облако
Обработка hosted Scan API	Серверная; инфраструктура Actual использует AWS, с размещением американских данных в Вирджинии и европейских в ЕС
Self-hosted Scan API	Docker-развёртывание внутри инфраструктуры заказчика, при котором изображения чеков и полный текст не должны покидать её; текущая self-hosted версия поддерживает только чеки США
Лицензирование	Для SDK и API нужен рабочий license key; предусмотрена 30-дневная пробная оценка BlinkReceipt
Открытая цена	Фиксированный публичный тариф для производственного Actual Capture в технической документации не приводится; коммерческий доступ оформляется через Actual
Последние подтверждённые релизы	iOS SDK 1.75.0 и Android SDK 2.4.0, оба опубликованы 1 сентября 2026 года

Из таблицы следует главный практический вывод: BlinkReceipt стоит оценивать как компонент собственной системы, а не как готовый сканер чеков для конечного пользователя. Компания получает библиотеку, API и готовые элементы камеры, а хранение, бизнес-логику, экран истории покупок, выгрузку в бухгалтерию или бонусную механику строит уже внутри своего приложения.

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

BlinkReceipt возник в продуктовой линейке Microblink как специализированное решение для распознавания чеков. К 2026 году коммерческий бренд изменился: Microblink перенаправляет аудиторию BlinkReceipt к Actual и формулирует переход однозначно — BlinkReceipt теперь Actual. При этом техническая преемственность заметна во всех рабочих артефактах: мобильные репозитории по-прежнему называются blinkreceipt-ios и blinkreceipt-android, классы и пространства имён содержат BlinkReceipt, а серверный путь Scan API продолжает использовать домен blinkreceipt.

Для разработчика это не прекращение поддержки, а миграция бренда поверх продолжающей жить технологии. 1 сентября 2026 года вышли iOS SDK 1.75.0 и Android SDK 2.4.0. В iOS исправлено состояние, при котором второй чек мог вернуть данные первого и получить ложный признак дубликата. В Android 2.4.0 устранён перенос текста предыдущего сканирования в следующий ScanResults. Чуть раньше, в Android 2.3.1, штатный Camera UI получил одноразовый полноэкранный экран с подсказкой и диалог How to scan a receipt. Такие релизы показывают, что кодовая база не заморожена.

В Android-документации переход между поколениями отражён неравномерно. Текущий Actual Capture Paper Receipts Guide направляет Gradle в репозиторий https://maven.microblink.com, показывает BOM 1.9.13 и минимальный API 23. В README тега Android 2.4.0 указан тот же Maven-репозиторий, но сохранился ещё более старый пример BOM 1.8.7; при этом раздел Android OS Support в самом теге уже требует minSdk 24, что соответствует release notes 2.1.0, где порог официально поднят с API 23 до 24. Эти публичные страницы нельзя механически смешивать: для ветки 2.x версию модулей и minSdk нужно сверять с release notes выбранного релиза, а не определять по устаревшему номеру BOM в общей инструкции.

Отдельно важно различать требования текущего пакета и устаревшие страницы. Для iOS исходники пакета 1.75.0 фиксируют платформу iOS 15, а changelog сообщает, что порог был поднят до iOS 15 ещё в ветке 1.65.0. Поэтому старые инструкции с iOS 11 относятся к прежним поколениям и не подходят для нового проекта на актуальной версии.

Юридически и продуктово нынешнее состояние лучше описывать так: BlinkReceipt, LLC работает как Actual, а Actual Capture наследует функцию бумажных чеков. Поэтому в новом проекте разумно ориентироваться на документацию Actual, сохраняя технические названия BlinkReceipt там, где их требует SDK или API. Старые маркетинговые страницы Microblink полезны для понимания происхождения продукта, но не должны определять текущую архитектуру интеграции.

Интерфейс и рабочие зоны

У BlinkReceipt нет единого «главного окна». Интерфейс зависит от способа интеграции. В мобильном приложении разработчик может использовать штатный Camera UI, дополнить его информационными элементами или построить собственный экран поверх recognizer-компонента. На сервере интерфейса вообще нет: Scan API принимает изображение и возвращает машинный результат.

Штатная камера

Для iOS предусмотрены Standard и Enhanced варианты Camera UX. Аналогичная идея используется на Android: готовый экран камеры ведёт пользователя при съёмке чека, оценивает кадр и помогает получить читаемое изображение. Такой интерфейс особенно полезен в программах лояльности, cashback-сервисах и исследованиях покупок, где от пользователя нужен один понятный сценарий — открыть сканер, расположить чек в кадре и дождаться подтверждения.

В актуальной Android-ветке Camera UI дополнен обучающим экраном перед первым запуском и справочной подсказкой о сканировании. Это не отдельное приложение Actual, а часть библиотеки, которую видит пользователь внутри приложения заказчика. Поэтому название, навигация, экран после распознавания и дальнейшая работа с покупкой зависят от конкретной интеграции.

Data Chips и обратная связь

Штатный мобильный интерфейс умеет показывать так называемые Data Chips — короткие подтверждения найденной даты, итоговой суммы и продавца. На iOS и Android эти элементы включаются отдельно. Их смысл не в украшении камеры, а в раннем контроле качества: пользователь получает визуальный сигнал, что из текущего кадра уже извлекаются ключевые поля, и может заметить явно неверный результат до ухода со сканера.

Длинный чек

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

Экран коррекции

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

На iOS для исторической коррекции есть параметр срока локального хранения данных чека. Значение по умолчанию равно нулю дней, то есть долговременное сохранение для последующей правки не включено автоматически. Если бизнес-процесс требует возвращаться к распознанным чекам, срок хранения задаётся осознанно с учётом политики персональных данных.

Пользовательский интерфейс камеры

Командам, которым нельзя использовать готовый дизайн, доступны низкоуровневые варианты. На Android это RecognizerView, на iOS — собственный контроллер на основе BRCameraViewController. В этом режиме BlinkReceipt остаётся движком распознавания, а рамка, кнопки, подсказки, состояние вспышки, реакции на готовность кадра и навигация проектируются приложением. Порог интеграции выше, зато визуальная часть не выбивается из фирменного интерфейса.

Что именно распознаёт BlinkReceipt

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

Продавец и транзакция

В США система сопоставляет торговую точку с базой, охватывающей более 250 тысяч локаций. Такое сопоставление помогает перейти от сырой строки в шапке чека к нормализованной торговой точке. Для приложений, которые строят отчёты по сетям или проверяют покупку у определённого продавца, это полезнее обычного OCR названия.

Позиции корзины

Извлечение line items — одна из центральных функций BlinkReceipt. Сервис старается отделить описание товара от цены, количества, скидки и единицы измерения. Именно этот слой позволяет подтвердить, что пользователь купил конкретный товар, а не просто потратил определённую сумму в магазине.

Проверка качества и достоверности

В результирующей структуре доступны признаки качества: распознан ли документ как чек, является ли изображение размытым, выглядит ли оно как снимок экрана, отмечено ли как подозрительное и является ли дубликатом. Дополнительно возвращается OCR confidence. Эти поля не следует трактовать как безусловный приговор о подлинности: они дают приложению основания для собственной бизнес-логики — принять чек автоматически, отправить на дополнительную проверку или попросить новый снимок.

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

Product Intelligence и обогащение

После OCR товарные строки могут быть сопоставлены с нормализованным каталогом. Для американских чеков обогащение включается в типичный поток Actual Capture и способно возвращать UPC, бренд, категорию, стандартизованное название и дополнительные атрибуты. При неоднозначности структура может содержать возможные варианты товара, а не один безусловно выбранный объект.

Этот слой важен для CPG-аналитики и промоакций: строка вроде сокращённого названия на чековой ленте не всегда совпадает с названием товара в каталоге. Product Intelligence связывает кассовое обозначение с более устойчивой продуктовой сущностью. Однако результат всё равно следует оценивать по уверенности и возможным кандидатам, особенно если магазин печатает собственные сокращения.

Что BlinkReceipt не делает сам

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

Отдельно стоит повторить границу с электронными покупками: доступ к электронным чекам из почты и торговых аккаунтов относится к Actual Links/BlinkEReceipt. Это соседняя технология и не должна фигурировать в требованиях к базовому paper-receipt SDK как встроенная «почтовая функция».

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

Задача	Инструмент BlinkReceipt	Результат	Что проверить
Снять бумажный чек внутри мобильного приложения	Штатный Camera UI iOS/Android	Структурированный объект чека и товарных строк	is_receipt, ocr_confidence, дата, итог и число товарных строк
Сканировать очень длинную кассовую ленту	Многокадровый режим с направляющей совмещения	Единый результат из нескольких кадров	Нет ли разрыва списка товаров и совпадает ли итог с напечатанным
Обработать снимки на сервере или из веб-сервиса	Scan API	JSON	Размер и формат входного файла, флаги качества, целостность line items
Не принимать повторно отправленный чек	Duplicate detection	Флаг is_duplicate	Контекст двухнедельного окна и собственные правила долгосрочной дедупликации
Отделить плохой кадр от нормального	Quality indicators	is_blurry, is_screen, is_receipt и confidence	Не строится ли автоматическое отклонение только на одном признаке
Привести товарную строку к каталожной сущности	Product Intelligence / Enrichment	UPC, бренд, категория, нормализованное имя и возможные кандидаты	Уверенность сопоставления и неоднозначные possible_products
Исправить неверную позицию вручную	Receipt Correction UI	Скорректированные товары и цены	Признаки userAdded и userModified
Встроить сканер в фирменный дизайн	RecognizerView на Android или BRCameraViewController на iOS	Собственный экран камеры с движком BlinkReceipt	Разрешения камеры, состояния готовности кадра, обработку отмены и завершения

Эта карта показывает границу ответственности. BlinkReceipt закрывает захват, распознавание, структурирование и часть контроля качества. Бизнес-решение — считать ли чек приемлемым, начислять ли вознаграждение и как долго хранить результат — остаётся у приложения заказчика.

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

Канал	Что поступает на вход	Что возвращается	Редактируемость и переносимость
iOS SDK	Кадры камеры и изображения из фототеки при включённой галерее	Объекты результатов BlinkReceipt	Приложение само решает, как сериализовать и хранить структуру; готовой кнопки экспорта в CSV или XLSX у SDK нет
Android SDK	Камера, изображения/Bitmap; отдельно документирован режим PDF recognition	Структурированный результат распознавания	Дальнейший экспорт реализуется приложением; исходная PDF-страница не превращается в редактируемый документ средствами BlinkReceipt
Hosted Scan API	PNG или JPEG до 10 МБ, файл либо публичный URL изображения	JSON	JSON удобно передавать в backend, базу данных или собственный экспорт; BlinkReceipt не формирует пользовательский отчёт автоматически
Self-hosted Scan API	Те же scan-запросы к развёрнутому у заказчика Docker-сервису; текущая версия ограничена чеками США	Структурированный результат Scan API	PII чека остаётся внутри инфраструктуры заказчика; развёртывание, временное хранилище для multi-frame и мониторинг становятся его ответственностью
Длинный чек через API	Последовательность PNG/JPEG-кадров с общим идентификатором и порядком frame_idx	Единая структура после последнего кадра	Переносимость зависит от того, как backend сохранит JSON и связь с исходными изображениями
Электронный чек из почты	Не относится к базовому paper-receipt BlinkReceipt	Используется отдельный Actual Links/BlinkEReceipt	Не следует проектировать эту функцию через Scan API бумажных чеков

Для пользователя, привыкшего к файловым конвертерам, здесь непривычна сама модель экспорта. BlinkReceipt не предлагает пункт «Сохранить как Excel». SDK отдаёт типизированные данные приложению, а API — JSON серверу. Если конечной системе нужен XLSX, CSV, PDF-отчёт или запись в CRM, преобразование выполняет код заказчика. Это отличается от обычных настольных OCR-программ, где файл экспорта является частью интерфейса.

Android-режим PDF полезен, когда чек уже оцифрован в документ, но BlinkReceipt остаётся распознавателем содержимого, а не PDF-редактором. Для дальнейшей правки документа пригодится отдельный инструмент; на GeekHow есть обзор бесплатных PDF-редакторов. Если задача состоит в преобразовании текста PDF в офисный документ, это уже другой сценарий, описанный в материале о конвертации PDF в Google Docs.

Приватность, безопасность и интернет-зависимость

Для мобильного paper-receipt SDK базовое распознавание выполняется на устройстве. Текущие руководства iOS и Android отдельно подчёркивают, что для этого этапа изображения чеков не отправляются в облако. Для приложений, которые работают с покупательской историей, это существенное архитектурное свойство: сырой снимок не обязан покидать телефон только ради OCR.

Но «on-device» не означает, что вся экосистема BlinkReceipt полностью автономна. Hosted Scan API и Product Intelligence требуют сетевого доступа к внешней инфраструктуре. Одновременно Actual документирует Self Hosted API: Docker-сервис разворачивается внутри инфраструктуры заказчика, а изображения чеков и полный текст не должны её покидать. У этого режима есть существенная граница — текущая self-hosted версия распознаёт только чеки США. Для гарантированно офлайн-мобильного сценария всё равно следует опираться на локальное распознавание SDK и отдельно проектировать сетевые функции.

Hosted-инфраструктура Actual работает на AWS. Для данных США указано размещение в Вирджинии, для европейских данных — в Европейском союзе. Сетевой транспорт защищается HTTPS/TLS; в документации также описаны certificate pinning и шифрование учётных данных. Self-hosted режим меняет границу ответственности: контейнер, хранилище промежуточных кадров, доступ к журналам и оркестрация находятся в инфраструктуре заказчика. Распознанный чек содержит сведения о покупках и может быть персональными данными в контексте конкретного приложения, поэтому локальное развёртывание не отменяет собственные правила доступа и хранения.

Практически важен принцип минимизации хранения. На iOS исторические данные для Receipt Correction не сохраняются автоматически на длительный срок: daysToStoreReceiptData по умолчанию равен 0. Если приложение увеличивает этот период, решение должно соответствовать собственной политике хранения, уведомлениям пользователя и требованиям региона.

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

Что перестанет работать первым

Без разрешения на камеру пропадает мобильный сценарий захвата. Сам движок может оставаться подключённым, но штатный экран не получит изображение с камеры. На iOS разрешение должно быть объявлено в конфигурации приложения, на Android — в manifest и runtime-проверке.

Без внешней сети hosted Scan API и сетевое обогащение недоступны. Основное OCR-распознавание в мобильном SDK остаётся локальным, а self-hosted Scan API способен работать внутри собственной серверной среды при правильно развёрнутой инфраструктуре; его текущая география ограничена США. Это разделение нужно учитывать до проектирования очередей и fallback-логики.

При неподдерживаемой Android-конфигурации проблема возникает ещё до рабочего сканирования. Для актуального release stream 2.x минимум поднят до API 24; compile SDK 36+ и Java 17+ указаны в текущем руководстве, а бинарные архитектуры ограничены ARM-вариантами armeabi-v7a и arm64-v8a. Страница установки, всё ещё показывающая API 23, относится к несинхронизированным переходным материалам, поэтому новый проект нужно сверять с release notes конкретной версии.

При неверной лицензии интеграция не готова к производственной работе. BlinkReceipt не распространяется как свободный конечный OCR без лицензирования: SDK и API рассчитаны на коммерческое встраивание, а пробный период предназначен для оценки.

При отключённом Product Intelligence базовое распознавание чека не превращается автоматически в полный каталог товаров. Останутся OCR-поля и line items, но нормализованные UPC, бренд, категория и другие обогащённые атрибуты зависят от соответствующей конфигурации и доступности сервиса.

При смешивании Android-инструкций разных веток чаще всего ломается сборка, а не само распознавание. В публичных материалах одновременно встречаются BOM 1.9.13 в руководстве Actual, BOM 1.8.7 в README тега 2.4.0 и требование minSdk 24 для ветки 2.x. Для одной сборки нужно выбрать один релиз SDK и использовать согласованные с ним версии Recognizer, Camera UI и остальных модулей, не позволяя старому BOM незаметно вернуть проект на 1.x.

Цена, лицензия и условия распространения

BlinkReceipt — B2B-компонент, а не магазинное приложение с ценником за пользователя. Для оценки доступен 30-дневный trial, а рабочий доступ к SDK и API связан с license key. Текущие материалы Actual направляют за производственными лицензиями через Developer Hub и команду Actual; фиксированный публичный прайс для Actual Capture в технической документации не опубликован.

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

Бесплатного производственного режима, эквивалентного обычному «free plan» пользовательского приложения, у BlinkReceipt нет. Trial нужен для прототипа и проверки качества на собственных чеках. Перед запуском в продакшен следует получить коммерческую лицензию и согласовать необходимые сервисы, включая Product Intelligence, если он входит в сценарий.

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

Поскольку BlinkReceipt является SDK/API, последовательность работы зависит от роли. Ниже описаны воспроизводимые операции для разработчика интеграции и для встроенного сканера. Названия классов и параметров соответствуют действующим руководствам Actual/BlinkReceipt; пользовательские кнопки приложения заказчика могут называться иначе.

Подключить BlinkReceipt на iOS и активировать лицензию

Цель. Добавить библиотеку в iOS-проект и подготовить штатный сканер чеков.

Подготовка. Для актуального BlinkReceipt 1.75.0 нужен проект с deployment target iOS 15.0+, Xcode, рабочий BlinkReceipt license key и описание доступа к камере в Info.plist.

1. Откройте настройки зависимостей проекта и выберите Swift Package Manager либо CocoaPods.
2. Для Swift Package Manager добавьте официальный пакет BlinkReceipt из репозитория blinkreceipt-ios. Для CocoaPods добавьте pod BlinkReceipt и установите зависимости.
3. Импортируйте BlinkReceipt в модуль, где будет запускаться камера.
4. До старта сканирования присвойте лицензии свойству BRScanManager.shared().licenseKey.
5. Убедитесь, что Info.plist содержит пользовательское объяснение разрешения камеры.

Проверка. Проект собирается без ошибки импорта BlinkReceipt, а при первом обращении к камере iOS показывает системный диалог разрешения.

Типичная ошибка. Библиотека подключена, но камера не открывается из-за отсутствующей записи о доступе к камере или отказа пользователя.

Безопасный откат. Удалите вызов сканера из пользовательского потока, сохранив остальную интеграцию, затем исправьте разрешения. Не меняйте сразу версию SDK и архитектуру проекта, если проблема воспроизводится только на этапе доступа к камере.

Подключить актуальную ветку BlinkReceipt на Android

Цель. Подключить Android SDK 2.x, не смешивая его с зависимостями и требованиями старой ветки 1.x.

Подготовка. Для актуальной ветки 2.x используйте minSdk 24+, compileSdk 36+ и Java 17+. Нужны ARM-устройства или эмуляторы с поддерживаемой архитектурой и рабочая лицензия.

1. В dependencyResolutionManagement или в репозиториях Gradle добавьте maven { url = uri(«https://maven.microblink.com») }. Этот адрес указан и в текущем руководстве Actual Capture, и в README тега Android 2.4.0.
2. В dependencies подключите модули com.microblink.blinkreceipt:blinkreceipt-recognizer и com.microblink.blinkreceipt:blinkreceipt-camera-ui версии выбранного релиза. Для актуального релиза это 2.4.0. Не используйте показанные в публичных README BOM 1.8.7 или 1.9.13 как способ зафиксировать ветку 2.4.0: эти номера относятся к более ранним наборам модулей.
3. Добавьте разрешение android.permission.CAMERA в AndroidManifest.xml и обработайте runtime-разрешение в приложении.
4. Инициализируйте BlinkReceipt SDK с выданной лицензией до открытия сканера.
5. Соберите приложение на arm64-v8a либо armeabi-v7a устройстве с Android 7.0 / API 24 или новее.

Проверка. Gradle разрешает выбранные 2.x-зависимости из репозитория Microblink, фактические версии Recognizer и Camera UI соответствуют 2.4.0, приложение запускается на API 24+ ARM-устройстве, камера получает изображение.

Типичная ошибка. Проект одновременно использует старый BOM/конфигурацию 1.x и явные версии модулей 2.x либо сохраняет minSdk 23, из-за чего сборка перестаёт соответствовать release stream.

Безопасный откат. Верните только набор зависимостей и minSdk к последней рабочей версии проекта, затем повторите обновление SDK отдельным изменением. Не меняйте одновременно Camera UI, Gradle toolchain и бизнес-логику.

Запустить штатную камеру и автозахват

Цель. Дать пользователю готовый экран съёмки, который направляет чек и автоматически принимает пригодный кадр.

Подготовка. SDK подключён, лицензия активна, разрешение камеры выдано. На iOS подготовьте BRScanOptions и выберите Standard либо Enhanced Camera UX.

1. На iOS создайте параметры BRScanOptions и включите enableAutoCapture, если кадр должен приниматься автоматически.
2. При необходимости включите enableTorch и enablePhotoGallery.
3. Выберите BRCameraUXStandard или BRCameraUXEnhanced и запустите штатную камеру через BRScanManager.
4. На Android откройте готовый Camera UI из пакета blinkreceipt-camera-ui и передайте активную конфигурацию recognizer.
5. Попросите пользователя расправить чек, держать его в границах кадра и избегать бликов. Для актуального Android UI подсказка How to scan a receipt доступна прямо из экрана камеры.

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

Проверка. После принятия кадра возвращается объект результатов, в котором is_receipt имеет ожидаемое значение, а дата, итог и продавец не пусты для хорошо читаемого чека.

Типичная ошибка. Чек снят под углом или на глянцевой поверхности; OCR confidence низкий, часть строк пропущена.

Безопасный откат. Не сохраняйте сомнительный результат как окончательный. Верните пользователя в камеру и замените только последний кадр.

Включить Data Chips для ранней проверки

Цель. Показывать на экране камеры уже найденные ключевые данные и снижать число чеков с явно неверным итогом.

Подготовка. Используется штатный Camera UI, который поддерживает Data Chips.

1. В конфигурации камеры включите enableDateChip, если нужна проверка даты.
2. Включите enableTotalChip для отображения итоговой суммы.
3. Включите enableMerchantChip для подтверждения продавца.
4. Откройте камеру и наведите её на чек так, чтобы шапка и итог были видимы.
5. Сравните появившиеся значения с печатным чеком до завершения сканирования.

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

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

Безопасный откат. Не завершайте длинный чек по одному найденному итогу; продолжите многокадровый режим и подтвердите результат после последнего фрагмента.

Сканировать длинный чек несколькими кадрами

Цель. Получить полный список товаров с кассовой ленты, которая не помещается в один кадр.

Подготовка. Используйте Camera UI с многокадровой съёмкой; разложите чек ровно и обеспечьте одинаковое освещение по всей длине.

1. Начните с верхней части чека и дождитесь принятия первого кадра.
2. Переместите камеру или чек вниз, сохранив участок предыдущего кадра в зоне перекрытия, которую показывает направляющая.
3. Повторяйте кадры, пока в поле зрения не окажется нижняя часть с итогом и служебными строками.
4. Завершите сканирование штатной командой Finish/Done, которую выводит интегрированный Camera UI.
5. Получите объединённый результат и сравните число товарных строк с физическим чеком.

Проверка. В результирующем объекте нет очевидного разрыва между товарами из соседних кадров, итоговая сумма совпадает с напечатанной.

Типичная ошибка. Между кадрами нет перекрытия или часть ленты пропущена, из-за чего отдельные позиции теряются.

Безопасный откат. Отмените текущую сессию и переснимите чек с большим перекрытием. Не пытайтесь вручную «достроить» десятки пропавших строк после неудачной съёмки.

Обработать готовое изображение через Scan API

Цель. Распознать чек на backend без мобильного SDK.

Подготовка. Нужны активная лицензия Scan API, изображение PNG или JPEG не более 10 МБ и сервер, способный выполнить multipart HTTP-вызов к endpoint api.blinkreceipt.com/v14.

1. Сформируйте multipart-вызов и передайте поле license_key.
2. Добавьте бинарное поле image либо используйте поддерживаемый вариант с публичным URL изображения.
3. Для одиночного кадра установите frame_idx в 1 и last_frame в true.
4. Отправьте данные на Scan API и дождитесь JSON-ответа.
5. Сохраните структурированные поля отдельно от исходного изображения в соответствии со своей политикой данных.

Проверка. Ответ содержит данные транзакции и basket items, а поля качества позволяют оценить пригодность кадра.

Типичная ошибка. На сервер передаётся PDF, TIFF или изображение больше 10 МБ, хотя данный путь Scan API документирован для PNG/JPEG.

Безопасный откат. Не изменяйте содержимое исходника без необходимости. Сделайте допустимую копию PNG/JPEG и повторите обработку, сохранив оригинал для аудита.

Отправить длинный чек в Scan API несколькими изображениями

Цель. Собрать единый серверный результат из нескольких кадров длинной кассовой ленты.

Подготовка. Подготовьте последовательные PNG/JPEG-кадры одной покупки и активную лицензию.

1. Первый кадр отправьте с frame_idx=1 и last_frame=false.
2. Сохраните полученный blink_receipt_id.
3. Во втором и следующих вызовах передавайте тот же blink_receipt_id и увеличивайте frame_idx по порядку.
4. Только для последнего кадра установите last_frame=true.
5. Используйте финальный JSON как результат всего чека.

Проверка. Все кадры относятся к одному blink_receipt_id, индексы идут без пропусков, финальный результат содержит данные со всей ленты.

Типичная ошибка. Backend создаёт новый идентификатор для каждого кадра или преждевременно ставит last_frame=true.

Безопасный откат. Отбросьте незавершённую серверную сессию и повторите серию кадров с одним идентификатором. Не склеивайте разрозненные JSON вручную как будто это один чек.

Включить проверку дубликатов и оценивать качество

Цель. Не принимать повторно отправленный чек и отсеивать явно плохие изображения до начисления награды.

Подготовка. На iOS включите detectDuplicates в BRScanOptions; для Scan API используется параметр detect_duplicates=true.

1. Активируйте duplicate detection в выбранном канале.
2. После распознавания прочитайте is_duplicate, is_receipt, is_blurry, is_screen и ocr_confidence.
3. Разделите техническое качество и бизнес-решение: низкая уверенность должна переводить чек в повторную съёмку или дополнительную проверку, а не автоматически доказывать мошенничество.
4. Для своей долгосрочной политики храните собственный идентификатор уже принятых покупок, потому что встроенная дедупликация работает в ограниченном окне.

Проверка. Повторная отправка того же чека в пределах поддерживаемого окна отмечается is_duplicate, а новый чек не получает этот флаг без основания.

Типичная ошибка. На старой iOS-версии второй чек получает данные первого и ложный duplicate. Этот дефект исправлен в iOS SDK 1.75.0.

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

Проверить и исправить распознанные позиции

Цель. Исправить неверно извлечённую цену или добавить пропущенный товар без повторного сканирования всего чека.

Подготовка. В проект подключён стандартный или собственный Receipt Correction UI; результат сканирования уже получен.

1. Откройте экран коррекции для текущего результата.
2. Сравните описания товаров и цены с бумажным чеком.
3. Измените ошибочную строку либо добавьте отсутствующую позицию.
4. Подтвердите изменения и получите обновлённый результат.
5. На backend отличайте автоматические поля от исправленных по признакам userAdded и userModified.

Проверка. Суммы и товары после коррекции соответствуют исходному чеку, а изменённые строки явно помечены.

Типичная ошибка. Приложение сохраняет ручную правку, но не сохраняет признак вмешательства, из-за чего последующая аналитика считает поле результатом OCR.

Безопасный откат. Храните исходный автоматический результат до подтверждения коррекции и позволяйте отменить последнюю правку в собственном UI.

Подключить Product Intelligence и проверить нормализацию товара

Цель. Превратить сокращённое описание из чека в более устойчивую товарную сущность с UPC, брендом и категорией.

Подготовка. Для проекта должен быть активирован соответствующий сервис Actual и выдана его конфигурация. Базовый OCR-чек должен распознаваться корректно до подключения обогащения.

1. Добавьте выданную Actual конфигурацию Product Intelligence в мобильный или серверный поток согласно своей лицензии.
2. Сканируйте чек обычным способом и дождитесь обогащённого результата.
3. Для каждой позиции сравните исходное описание с product_name, brand, category и upc, когда они присутствуют.
4. Если возвращаются possible_products, не подменяйте неоднозначность одним товаром без дополнительного правила.
5. Перед начислением товара-зависимой акции проверяйте уверенность сопоставления.

Проверка. Для поддерживаемых американских чеков подходящие строки получают нормализованные товарные атрибуты, а спорные варианты остаются видимыми как кандидаты.

Типичная ошибка. Команда ожидает UPC для любой строки, включая весовой товар или сокращение, которого нет в каталоге.

Безопасный откат. Сохраняйте исходный line item как первичный факт. При неуверенном enrichment используйте его без каталожной подстановки либо отправляйте на дополнительное сопоставление.

Сделать собственный экран камеры

Цель. Сохранить движок BlinkReceipt, но полностью контролировать фирменный интерфейс.

Подготовка. Штатный Camera UI уже интегрирован и распознавание подтверждено на тестовых чеках. Это важно: сначала отделите корректность OCR от дизайна камеры.

1. На Android используйте RecognizerView как основу custom UI; дождитесь состояния initialized перед запуском зависимых действий.
2. На iOS создайте контроллер на основе BRCameraViewController.
3. Свяжите собственные кнопки с событиями готовности кадра, ручного снимка, подтверждения, завершения и отмены.
4. Сохраните те же проверки разрешений и качества, которые использовались со штатной камерой.
5. Проверьте длинный чек, поворот устройства, уход приложения в фон и отказ в разрешении камеры.

Проверка. Пользователь может начать, завершить и отменить сканирование, а результат совпадает по структуре с результатом штатного UI на том же типе чека.

Типичная ошибка. Дизайн вызывает recognizer до завершения инициализации или не обрабатывает отмену, из-за чего экран зависает в промежуточном состоянии.

Безопасный откат. Оставьте штатный UI как временный fallback в тестовой сборке. Если custom-экран нестабилен, вернитесь к готовому Camera UI без изменения OCR-части.

Сквозной сценарий: от запуска сканера до сохранения результата

Цель. Проверить всю интеграцию на одном бумажном чеке без смешивания нескольких технологий.

1. Запустите тестовую сборку с действующей лицензией и откройте встроенный BlinkReceipt Camera UI.
2. Разрешите доступ к камере и расположите чек целиком в кадре; для длинной ленты продолжите многокадровую съёмку с перекрытием.
3. Дождитесь завершения распознавания и получите структуру trip-level и basket-level данных.
4. Проверьте is_receipt, is_blurry, is_screen, ocr_confidence и is_duplicate, если дедупликация включена.
5. Сравните продавца, дату, итог и несколько товарных строк с бумажным оригиналом.
6. При необходимости откройте Receipt Correction UI и исправьте одну заведомо неверную позицию, сохранив userModified.
7. Если подключён Product Intelligence, проверьте UPC/бренд/категорию только для тех строк, где обогащение вернуло уверенный результат.
8. Сериализуйте итоговую структуру в собственное хранилище приложения или передайте её backend. Не считайте локальный объект BlinkReceipt самостоятельным архивом.

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

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

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

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

Плюсы

• Мобильное OCR-распознавание бумажного чека выполняется на устройстве, поэтому для базового распознавания не требуется отправлять фото чека в облако.
• Система возвращает не только текст, но и структуру транзакции с merchant/date/total/tax/payment method и отдельными line items.
• Есть готовые Standard/Enhanced Camera UI, Data Chips, подсказки качества и многокадровый режим для длинной кассовой ленты.
• Один продукт закрывает нативный мобильный захват и серверную обработку через Scan API, что удобно для приложений с несколькими каналами ввода.
• Присутствуют признаки is_receipt, is_blurry, is_screen, is_duplicate, OCR confidence и отдельные механизмы проверки риска.
• Receipt Correction UI сохраняет различие между автоматическим результатом и строками, которые пользователь добавил или изменил вручную.
• Product Intelligence способен нормализовать американские товарные позиции до UPC, бренда и категории, что полезно для промоакций и аналитики корзины.
• Продукт активно обновляется: в августе–сентябре 2026 года опубликованы свежие Android и iOS релизы.

Минусы

• BlinkReceipt не является готовым приложением для личного архива чеков: без разработки SDK/API не даёт конечному пользователю самостоятельного продукта.
• Производственная стоимость не оформлена как простой публичный тариф, поэтому бюджет приходится уточнять у Actual.
• Подтверждённый набор OCR-языков ограничен семью языками на латинице, а перечень официально поддерживаемых рынков не является глобальным.
• Scan API принимает PNG/JPEG до 10 МБ и требует сети; собственную камеру или загрузчик для веб-приложения нужно создавать отдельно.
• Android-документация не полностью синхронизирована: руководство Actual показывает API 23 и BOM 1.9.13, README тега 2.4.0 содержит старый BOM 1.8.7, а release notes ветки 2.x и сам раздел Android OS Support требуют minSdk 24.
• Переход бренда Microblink → Actual и одновременное существование старых 1.x-примеров рядом с текущими 2.x-релизами усложняют сопровождение интеграции.
• Файлового экспорта в CSV/XLSX/PDF как готовой пользовательской функции нет: сериализацию и выгрузку результата реализует интегратор.

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

Приложениям лояльности и cashback. BlinkReceipt хорошо совпадает со сценарием, где пользователь подтверждает покупку бумажным чеком, а система должна увидеть конкретные товары, сумму, дату и продавца. Дедупликация, quality flags и Product Intelligence дают больше полезных сигналов, чем обычный OCR.

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

Финтех- и expense-продуктам с собственным интерфейсом. Команда может встроить камеру в мобильное приложение и получить структурированные данные без отправки фото на сервер для базового OCR. При этом BlinkReceipt не диктует модель хранения или отчётности.

Backend-системам с уже имеющимися изображениями чеков. Scan API снимает необходимость разворачивать мобильный SDK, если изображения уже поступают из другой системы. Веб-панель, чат-бот или партнёрский поток может отправлять PNG/JPEG на серверную обработку и получать JSON.

Командам, которым нужен собственный UX. Готовая камера ускоряет внедрение, а RecognizerView/BRCameraViewController позволяют заменить её собственным экраном после того, как распознавание уже стабильно работает.

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

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

Команде, которой нужен универсальный OCR всех деловых документов. BlinkReceipt специализирован на кассовых чеках. Счета, договоры, формы и многостраничные офисные документы лучше обрабатывать сервисом общего Document AI. Для массовой оцифровки бумажных документов может быть уместен и отдельный аппаратный сканер; варианты такого оборудования собраны в обзоре сканеров GeekHow.

Проекту с языками вне подтверждённого набора. Если кассовые ленты печатаются преимущественно нелатинским алфавитом или в неподдерживаемом регионе, BlinkReceipt нельзя выбирать только по общему обещанию OCR. Нужен отдельный пилот на реальных чеках и продукт с официальной поддержкой нужного языка.

Серверной системе вне США, которой запрещено отправлять чек во внешнее облако. Self-hosted Scan API снимает внешнюю передачу PII, но его текущая версия поддерживает только чеки США. Для других рынков при запрете внешней обработки придётся выбирать иной серверный OCR или менять архитектуру.

Команде без ресурса на интеграцию. Даже готовый Camera UI не решает хранение, авторизацию, очередь ошибок, пользовательскую историю и бизнес-правила. Если нужен результат «из коробки», SaaS с готовой панелью может оказаться дешевле по совокупной стоимости владения.

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

Ниже BlinkReceipt сравнивается с четырьмя актуальными облачными OCR-сервисами по одинаковым критериям. Это не рейтинг: каждый вариант рассчитан на свой уровень интеграции и тип документов.

Решение	Задача	Платформа	Порог освоения	Форматы	Автоматизация	Модель оплаты	Ограничения	Подходящий сценарий
BlinkReceipt / Actual Capture	Розничные бумажные чеки с item-level данными	iOS, Android, REST API	Средний/высокий: требуется интеграция SDK или backend	Мобильная камера/изображения; Scan API PNG/JPEG до 10 МБ; Android PDF recognition	Автозахват, multi-frame, quality flags, duplicates, enrichment	Trial и коммерческая лицензия без публичного фиксированного тарифа	Узкая специализация, ограниченный набор языков/рынков, нет готового пользовательского приложения	Лояльность, CPG, purchase validation, cashback
Veryfi Receipt OCR API	Чеки и финансовые документы с извлечением line items	Cloud API; отдельные SDK платформы Veryfi доступны для захвата документов	Средний	JPG/JPEG, PNG, PDF, HEIC/HEIF, WebP и другие поддерживаемые форматы	Structured JSON, line items, vendor/tax/currency и barcode extraction	Free до 100 документов в месяц; Starter от 500 долларов в месяц, для receipt extraction указано 0,08 доллара за чек после включённого объёма	Основной OCR-путь облачный; стоимость и хранение зависят от выбранного плана	Expense/receipt automation, когда нужен более широкий документный API
Mindee Receipt OCR API	Извлечение реквизитов чека и товарных строк	Cloud API	Средний	Сканированные изображения и PDF	Structured JSON, готовая receipt schema, REST API, backend SDK и no-code интеграции	14-дневный trial; далее тарифы Starter, Pro и Enterprise по объёму credits	Основной путь — облачный API, поэтому для мобильного on-device OCR это другая архитектура	Backend-проекты, которым важен универсальный API для чеков и документов
Google Cloud Document AI Expense Parser	Expense-документы и чеки в общей экосистеме Document AI	Google Cloud API	Средний/высокий: нужен GCP-проект и облачная инфраструктура	Документные файлы, поддерживаемые Document AI	Batch/cloud processing, структурированное извлечение	Оплата за обработанные документы/страницы по тарифу Google Cloud	Нет готовой мобильной камеры BlinkReceipt; данные проходят облачный сервис	Компании, уже использующие GCP и единый Document AI для нескольких классов документов
Doxis AI.dp, ранее Klippa	OCR чеков и других документов	API/SDK	Средний	JPG, PNG, PDF и другие поддерживаемые документные входы платформы	Structured JSON/CSV, OCR и document workflows	Коммерческое предложение	Более широкая документная платформа требует выбора нужного пайплайна	Организации, которым кроме чеков нужны другие типы документов и единый поставщик OCR

BlinkReceipt против Veryfi. BlinkReceipt сильнее привязан к мобильному захвату розничного чека и локальному OCR, тогда как Veryfi удобен как облачный финансовый API с прозрачнее выраженной моделью объёмной оплаты. Если критично не отправлять сырое фото чека для базового мобильного OCR, архитектура BlinkReceipt выглядит естественнее. Если основная задача — серверный expense pipeline для разных финансовых документов, Veryfi проще рассматривать как единый облачный слой.

BlinkReceipt против Mindee. Mindee удобен, когда нужен стандартный REST-интерфейс и receipt schema без глубокой нативной камеры. BlinkReceipt оправдан, когда качество захвата на смартфоне, длинные чеки, встроенные Data Chips и пользовательская коррекция являются частью продукта, а не внешними экранами.

BlinkReceipt против Google Document AI. Google Cloud логичен для компании, уже построившей обработку документов в GCP и желающей объединить чеки с другими типами документов. BlinkReceipt более специализирован: он ориентирован на розничную корзину и содержит мобильные UX-компоненты, которых у общего cloud parser нет.

BlinkReceipt против Doxis AI.dp. Doxis охватывает более широкую область document capture. BlinkReceipt уже по назначению, зато его модель merchant/basket, multi-frame кассовой ленты и Product Intelligence точнее соответствует purchase-data приложениям.

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

1. Камера не открывается в мобильном приложении

Симптом. Экран BlinkReceipt появляется без изображения либо закрывается сразу после запуска.

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

Диагностика. На iOS проверьте наличие camera usage description и состояние разрешения в системных настройках; на Android — CAMERA в manifest и runtime permission.

Исправление. Добавьте требуемое описание/permission и обработайте отказ пользователя с понятным переходом в настройки системы.

Проверка результата. После выдачи разрешения Camera UI показывает живое изображение и принимает кадр.

2. Android-зависимости BlinkReceipt больше не скачиваются

Симптом. Gradle сообщает, что не может найти BlinkReceipt artifact, хотя старый проект раньше собирался.

Возможная причина. Проект смешивает старую 1.x-конфигурацию BlinkReceipt с текущей 2.x-веткой либо не объявляет репозиторий https://maven.microblink.com, из которого официальные инструкции получают Android-артефакты.

Диагностика. Проверьте фактическую версию BlinkReceipt, секцию repositories и способ задания версий. Отдельно убедитесь, что BOM 1.8.7 или 1.9.13 не фиксирует старую ветку при попытке подключить модули 2.4.0.

Исправление. Приведите зависимости к одной ветке: добавьте репозиторий Microblink и согласованные версии Recognizer/Camera UI выбранного 2.x-релиза; изменения minSdk и Java выполняйте отдельно, чтобы причину сбоя можно было проверить по одному фактору.

Проверка результата. Gradle sync проходит, выбранные BlinkReceipt packages разрешаются, а собранное приложение использует одну согласованную версию SDK.

3. Проект Android не собирается после обновления toolchain

Симптом. Ошибка совместимости возникает ещё до запуска камеры.

Возможная причина. Проект на ветке 2.x имеет minSdk ниже 24, compileSdk ниже 36, Java ниже 17 либо использует неподдерживаемую архитектуру.

Диагностика. Сверьте Gradle-конфигурацию и ABI целевого устройства с минимальными требованиями BlinkReceipt.

Исправление. Поднимите параметры проекта до поддерживаемых значений и тестируйте на armeabi-v7a/arm64-v8a устройстве.

Проверка результата. Сборка создаёт APK/AAB, приложение стартует на поддерживаемой версии Android.

4. Чек распознаётся как размытый или даёт низкий OCR confidence

Симптом. Пропадают строки, итог или продавец распознаются неверно, is_blurry активен.

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

Диагностика. Сопоставьте is_blurry и OCR confidence с исходным изображением; увеличьте просмотр проблемной области и проверьте читаемость символов человеческим глазом.

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

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

5. Нижние позиции длинного чека отсутствуют

Симптом. В результате есть шапка и часть корзины, но товары из середины или низа пропущены.

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

Диагностика. Сравните физическое количество строк с результатом и найдите место разрыва между последовательными кадрами.

Исправление. Повторите multi-frame capture, сохраняя заметное перекрытие по направляющей и не перескакивая участки ленты.

Проверка результата. Список товаров идёт последовательно до итоговой части, сумма соответствует чеку.

6. Изображение помечено не как обычный бумажный чек

Симптом. is_receipt=false или is_screen=true, хотя пользователь ожидает принятия.

Возможная причина. Загружен снимок экрана, фотография дисплея, обрезанный фрагмент или документ, не похожий на поддерживаемый кассовый чек.

Диагностика. Посмотрите исходник и соответствующие quality indicators, не делая вывод только по одному полю.

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

Проверка результата. Новый кадр распознаётся как receipt, а структура содержит согласованные merchant/total/line items.

7. Второй чек ошибочно считается копией первого на iOS

Симптом. После последовательного сканирования второй документ получает данные первого или ложный is_duplicate.

Возможная причина. Используется iOS SDK до исправления, опубликованного в версии 1.75.0.

Диагностика. Проверьте фактическую версию BlinkReceipt iOS и воспроизводится ли дефект именно при втором сканировании одной сессии.

Исправление. Обновите SDK до 1.75.0 или более новой совместимой версии и повторите регрессионный тест двух разных чеков.

Проверка результата. Второй чек возвращает собственные поля, а duplicate определяется только для реального повтора.

8. Данные предыдущего чека попадают в следующий на Android

Симптом. После двух последовательных сканирований второй ScanResults содержит повторяющийся или объединённый текст первого документа.

Возможная причина. Используется Recognizer SDK до исправления, опубликованного в Android 2.4.0.

Диагностика. Проверьте фактическую версию recognizer и воспроизведите последовательное сканирование двух заведомо разных чеков в одной пользовательской сессии.

Исправление. Обновите Android BlinkReceipt до 2.4.0 или более новой совместимой версии, сохранив текущую бизнес-логику без параллельной замены Camera UI.

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

9. Product Intelligence не возвращает UPC или бренд

Симптом. Базовые товарные строки присутствуют, но enrichment-поля пусты или содержат несколько кандидатов.

Возможная причина. Сервис не активирован для лицензии, товар отсутствует в сопоставляемом каталоге либо строка чека неоднозначна.

Диагностика. Сначала подтвердите корректность исходного line item, затем проверьте конфигурацию Product Intelligence и possible_products.

Исправление. Исправьте конфигурацию сервиса либо оставьте исходный line item без принудительного UPC, если сопоставление неуверенное.

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

10. Scan API не принимает изображение

Симптом. Backend не получает распознанный JSON для отдельного файла.

Возможная причина. Неподдерживаемый формат, превышение 10 МБ, отсутствующая лицензия или неверные multipart-поля.

Диагностика. Проверьте, что файл PNG/JPEG, размер не превышает лимит, license_key передан, а для одиночного кадра frame_idx=1 и last_frame=true.

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

Проверка результата. API возвращает JSON со структурой чека и quality indicators.

11. Scan API недоступен, хотя мобильное распознавание работает

Симптом. Приложение на телефоне распознаёт чек, а серверный канал завершается сетевой ошибкой.

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

Диагностика. Проверьте DNS, TLS и доступность внешнего соединения с backend отдельно от мобильного SDK. Общие причины отсутствия сети на компьютере разобраны в материале GeekHow о том, почему нет подключения к интернету.

Исправление. Восстановите сетевой маршрут и повторите серверный вызов; локальное мобильное OCR не переустанавливайте, если оно работает.

Проверка результата. Scan API снова отвечает, а тот же PNG/JPEG обрабатывается без изменения мобильного проекта.

FAQ

BlinkReceipt всё ещё принадлежит Microblink?

Исторически BlinkReceipt был продуктом Microblink, но текущий бренд — Actual. Microblink сообщает о переименовании BlinkReceipt в Actual, а действующая политика Actual идентифицирует BlinkReceipt, LLC как организацию, работающую под брендом Actual. Технические названия BlinkReceipt при этом продолжают использоваться в SDK и API.

Можно ли скачать BlinkReceipt как обычное приложение для Windows?

Нет. Рассматриваемый продукт распространяется как SDK для iOS/Android и REST API. У него нет подтверждённой настольной Windows-программы для конечного пользователя, которая самостоятельно ведёт архив чеков.

Нужен ли интернет для сканирования?

Для базового распознавания бумажного чека мобильным SDK — нет: этот этап выполняется на устройстве. Scan API и облачное обогащение требуют соединения. Поэтому ответ зависит от выбранного канала, а не от слова BlinkReceipt в целом.

Отправляет ли мобильный SDK фотографию чека в облако?

Для основного paper-receipt OCR на iOS и Android текущие руководства описывают обработку на устройстве без отправки изображения чека в облако. Сетевые сервисы Actual являются отдельным слоем и должны учитываться отдельно в архитектуре приложения.

Какие языки распознавания подтверждены?

Английский, испанский, французский, немецкий, польский, португальский и шведский. Модели ориентированы на латинские символы. Локализация самого интерфейса камеры и язык OCR — разные параметры: iOS UI имеет более широкий список локализаций, но это не расширяет набор OCR-языков автоматически.

Может ли BlinkReceipt распознать PDF?

В актуальном Android-руководстве отдельно документирован PDF recognition. Серверный Scan API paper receipts в текущем руководстве принимает PNG и JPEG. Поэтому нельзя обобщать поддержку PDF на все каналы одной фразой: формат зависит от выбранного SDK/API.

Есть ли экспорт в Excel?

Готовой пользовательской функции экспорта XLSX у BlinkReceipt нет. Мобильный SDK возвращает объект данных, Scan API — JSON. Приложение заказчика может преобразовать эту структуру в Excel, CSV или базу данных, но это уже код интеграции.

Распознаёт ли BlinkReceipt штрихкоды?

Да. Актуальная линия BlinkReceipt продолжает извлекать штрихкоды в составе обработки чеков: iOS 1.71.0 и Android 2.1.1 содержат отдельные улучшения barcode extraction, а штатный Receipt Correction UI умеет использовать сканирование штрихкода для UPC-проверки. Это не превращает BlinkReceipt в универсальное самостоятельное приложение-сканер штрихкодов: функция встроена в receipt workflow.

Чем duplicate detection отличается от собственного антифрода?

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

Можно ли использовать BlinkReceipt для электронных чеков из e-mail?

Не через базовый paper-receipt SDK. Электронные чеки и подключение покупательских аккаунтов относятся к Actual Links/BlinkEReceipt. Это соседний продуктовый слой с другой интеграцией.

Есть ли русский интерфейс и русский OCR?

Русский язык не входит в подтверждённый набор OCR-языков BlinkReceipt. В перечне локализаций iOS Camera UI русский также не указан. Для чеков на кириллице нужен другой OCR либо отдельная проверенная конфигурация, официально поддерживающая русский.

Как оценить BlinkReceipt до покупки?

Для BlinkReceipt предусмотрена 30-дневная пробная оценка. За это время разумно прогнать реальные чеки целевых сетей, длинные ленты, плохое освещение, повторные отправки и выбранные языки, а затем обсуждать производственную лицензию с Actual.

Вывод

BlinkReceipt имеет смысл выбирать тогда, когда чек является источником структурированных purchase data, а не просто картинкой для архива. Для мобильной программы лояльности сильная сторона продукта — сочетание on-device OCR, готовой камеры, длинных чеков, line items, коррекции и сигналов качества. Такой стек закрывает сложную часть захвата, но оставляет компании контроль над хранением и бизнес-правилами.

Для backend-системы ключевой сценарий другой: Scan API превращает PNG/JPEG в JSON и подходит для уже существующего потока изображений. Здесь преимуществом становится единая модель данных с мобильным BlinkReceipt, а ограничением — облачная зависимость и необходимость самостоятельно строить загрузку, очередь, повторные попытки и экспорт.

Если нужен универсальный OCR счетов, договоров и других документов, специализированность BlinkReceipt превращается в ограничение: разумнее смотреть на Document AI общего назначения. Если нужен готовый личный архив чеков без разработки, BlinkReceipt также избыточен. Его целевая аудитория — продуктовые команды, которым распознавание чека является частью собственного приложения или сервиса.

В 2026 году отдельно нужно учитывать ребрендинг. Название Actual уже определяет коммерческий продукт, но техническая экосистема BlinkReceipt остаётся живой: свежие iOS и Android релизы, пакеты и Scan API продолжают работать под прежними именами. При новом внедрении ориентиром должна быть текущая документация Actual, а старые инструкции Microblink стоит использовать только после сверки с актуальной веткой SDK.