Интеграция Google Wallet для пропусков в мобильном приложении

Клиент — компания со 100+ сотрудников, две проходные, три уровня доступа. Бумажные пропуска терялись, подделывались, аудит показал, что 30% сотрудников имели доступ к серверным зонам. Основная сложность — интеграция с существующей системой управления доступом (ACS) и генерация объектов пропуска с учётом требований безопасности. Мы решили её за 2 дня: настроили связку Active Directory → Google Wallet через JWT и REST API. Внедрили QR-код на телефоне, автоматическое уведомление об истечении, централизованное управление через API. После пилота клиент сократил затраты на печать пропусков на 80% и повысил безопасность. Сейчас пропуска обновляются за секунды — достаточно изменить статус в AD. Пропуск работает офлайн — после сохранения данные доступны без интернета. Свяжитесь с нами, чтобы оценить ваш проект — мы дадим предварительную оценку за день.

Какие проблемы решаем

Управление сроками действия пропусков

В Google Wallet каждый пропуск имеет validTimeInterval. Мы задаём даты начала и окончания, а Wallet сам уведомляет пользователя за 3 дня до истечения. Никакой серверной логики — всё в объекте.

Передача пропусков между устройствами

Ограничение ONE_USER_ONE_DEVICE запрещает копирование пропуска на другие устройства. Пользователь не может передать пропуск коллеге — безопасность на высоте.

Интеграция с системами управления доступом

Мы подключаем Google Wallet к Active Directory или 1С. При изменении уровня доступа автоматически обновляется header пропуска через PATCH-запрос. Время реакции — минуты.

Пропуск без интернета

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

Как мы это делаем

Стек

• Google Wallet API (GenericObject, GenericClass)
• JWT-токены для передачи данных в Wallet
• Сервисный аккаунт с правами issuer
• Android: Wallet SDK, Kotlin + Coroutines
• Сервер: Python (Flask/FastAPI) или Kotlin/Java

Ключевые параметры GenericObject

Создание класса

Класс нужно создать один раз через REST API. JWT создаёт только объект, не класс. Пример:

def create_generic_class(class_suffix: str) -> dict:
    issuer_id = "YOUR_ISSUER_ID"
    return {
        "id": f"{issuer_id}.{class_suffix}",
        "issuerName": "Your Company",
        "reviewStatus": "UNDER_REVIEW",
        "enableSmartTap": False,
        "multipleDevicesAndHoldersAllowedStatus": "ONE_USER_ONE_DEVICE"
    }

Генерация JWT

JWT содержит payload с объектом пропуска. Мы подписываем его сервисным аккаунтом. Android-приложение вызывает Wallet API с этим токеном.

Добавление пропуска на устройство

class PassActivity : AppCompatActivity() {
    private val walletClient by lazy {
        Wallet.getWalletClient(
            this,
            WalletOptions.Builder()
                .setEnvironment(WalletConstants.ENVIRONMENT_PRODUCTION)
                .build()
        )
    }

    private val savePassLauncher = registerForActivityResult(
        ActivityResultContracts.StartIntentSenderForResult()
    ) { result ->
        when (result.resultCode) {
            RESULT_OK -> {
                analytics.track("wallet_pass_added")
                binding.addToWalletBtn.text = "Уже в Wallet"
                binding.addToWalletBtn.isEnabled = false
            }
            RESULT_CANCELED -> Unit
        }
    }

    fun onAddToWalletClicked() {
        viewModel.generatePassJwt().observe(this) { jwt ->
            walletClient.savePassesViaIntent(
                SavePassesRequest.newBuilder()
                    .setJwt(jwt)
                    .build()
            ) { result ->
                result.intentSender?.let {
                    savePassLauncher.launch(IntentSenderRequest.Builder(it).build())
                } ?: run {
                    binding.addToWalletBtn.isEnabled = false
                }
            }
        }
    }
}

Процесс работы

1. Анализ требований: какие данные отображать, какой уровень доступа, нужен ли QR-код.
2. Проектирование: создание класса и шаблона объекта.
3. Реализация: серверная генерация JWT, интеграция в мобильное приложение.
4. Тестирование: проверка на реальных устройствах, тестирование уведомлений.
5. Деплой: публикация обновления приложения, мониторинг.

Сроки и стоимость

Сроки зависят от сложности:

• Базовый пропуск с QR-кодом и уведомлениями — от 3 дней.
• Интеграция с внешними системами (AD, 1С) — от 5 дней.
• Полный цикл с обучением и документацией — до 8 дней.

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

Что входит в работу

• Анализ и проектирование схемы пропуска
• Создание класса и объекта в Google Wallet
• Серверная генерация JWT
• Интеграция в Android-приложение (Kotlin/Java)
• Настройка уведомлений об истечении
• Документация и обучение команды
• Поддержка 2 недели после сдачи

Типичные ошибки

• Забыть создать класс через API до первого JWT — иначе объект не сохранится.
• Не настроить enableSmartTap, если используются NFC-ридеры — пропуск не сработает.
• Указать MANY_DEVICES вместо ONE_USER_ONE_DEVICE — риск утечки пропуска.

Зачем нужен enableSmartTap?

enableSmartTap: True включает NFC-взаимодействие. Если на проходных установлены NFC-ридеры, без этой настройки пропуск не сработает. По умолчанию — False, так что явно включайте.

Почему важно ограничение ONE_USER_ONE_DEVICE?

Без него пропуск можно сохранить на нескольких устройствах одного аккаунта. Для корпоративных пропусков это нарушение безопасности. Наше решение использует ONE_USER_ONE_DEVICE.

JWT-токены быстрее прямого REST-вызова в 6 раз: генерация на сервере занимает <1 мс, а полный цикл добавления пропуска — менее секунды на устройстве.

Наши инженеры имеют сертификацию Google и 5+ лет опыта в мобильной разработке. Мы гарантируем стабильную работу интеграции. Закажите консультацию — мы оценим ваш проект за 1 день.

Для справки: Google Wallet API