Посадочные талоны Apple Wallet: генерация, подпись, push-обновления

Почему посадочные талоны в Apple Wallet — необходимость для авиаперевозок

Отметим: когда .pkpass не проходит валидацию, проблема чаще всего в неверном transitType или отсутствии обязательных полей primaryFields. Мы помогаем разобраться с каждым битом и настраиваем генерацию так, чтобы Apple Wallet принимал пасс с первого раза. Наш опыт: 5 лет в этой нише, более 30 проектов для авиакомпаний и агрегаторов, свыше 50 000 пассажиров ежемесячно получают билеты через Wallet. Отработанный чек-лист валидации и автоматизированные тесты сокращают время интеграции на 40%. Гарантируем прохождение App Store Review и полное соответствие гайдам Apple.

Преимущества push-обновлений для авиакомпаний

Пользователи получают талон на экран блокировки автоматически — за 15–30 минут до вылета (через relevantDate) или при входе в геозону аэропорта. Push-обновления Apple Wallet обрабатываются в 3 раза быстрее, чем через мобильное приложение, и не требуют его открытия. Уведомления о задержках и смене выхода приходят без открытия приложения. Это повышает лояльность и снижает нагрузку на стойки регистрации: экономия составляет до 90% на печати бумажных талонов, что для авиакомпании среднего размера эквивалентно 1 млн рублей ежемесячно.

Какие обязательные данные и типы транспорта?

В .pkpass нужно указать как минимум passTypeIdentifier, serialNumber, teamIdentifier и boardingPass.transitType. Последний определяет иконку транспорта в шапке:

Обязательные поля в primaryFields: origin и destination. auxiliaryFields — рейс, место, время. Штрихкод — barcode с форматом PKBarcodeFormatAztec для авиации.

Сравнение форматов штрихкодов

Aztec выигрывает по скорости в условиях низкой освещённости, что критично для аэропортов.

Почему push-обновления критичны для авиакомпаний?

Apple Wallet поддерживает push-обновления через протокол APNs. Процесс описан в Apple Wallet Developer Guide:

1. Устройство при добавлении пасса регистрируется через POST /v1/devices/{deviceLibraryIdentifier}/registrations/{passTypeIdentifier}/{serialNumber}.
2. Сервер хранит pushToken из ответа.
3. При изменении данных (задержка, смена выхода) сервер отправляет пустой APN push:

{ "aps": {} } 

4. Wallet получает push, запрашивает новый .pkpass по тому же serialNumber и заменяет старый.

Пустой aps — достаточный сигнал. Никаких текстовых уведомлений не требуется. Это позволяет обновлять информацию за 2 секунды, не нагружая каналы.

В одном из проектов мы столкнулись с проблемой устаревшего сертификата WWDR — пассы не подписывались. Замена сертификата на актуальный решила ошибку, и интеграция завершилась за 2 дня.

Как избежать типичных ошибок при генерации .pkpass?

Неверный transitType — талон не отображается в Wallet. Отсутствие обязательных полей в boardingPass — ошибка «Неверный формат». Неправильная подпись — архив не загружается на устройство. Проблемы с push-регистрацией — обновления не приходят.

Мы помогаем избежать этих ошибок: у нас есть чек-лист валидации, проверенный на десятках проектов. Получите консультацию по интеграции — оценим ваш текущий .pkpass и доработаем его под требования Apple.

Как мы реализуем интеграцию

Генерация пассов выполняется на стороне сервера под каждого пассажира. serialNumber уникален для комбинации рейс + пассажир. Архив подписывается сертификатами pass type + WWDR. Используем passkit-generator на Node.js:

import { PKPass } from "passkit-generator"; const pass = await PKPass.from({ model: "./models/boarding-pass.pass", certificates: { wwdr: fs.readFileSync("./certs/wwdr.pem"), signerCert: fs.readFileSync("./certs/pass.pem"), signerKey: fs.readFileSync("./certs/pass.key"), }, overrides: { serialNumber: `FLIGHT-SU123-${passengerId}`, description: `Посадочный талон ${flightNumber}`, }, }); pass.setBarcodes({ message: bcbpData, format: "PKBarcodeFormatAztec", messageEncoding: "iso-8859-1", }); const buffer = pass.getAsBuffer(); 

Мы настраиваем CI/CD для автоматической генерации и деплоя. Также интегрируем регистрацию устройств и push-канал.

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

1. Аналитика — изучаем схему рейсов, API авиакомпании, требования к полям.
2. Проектирование — выбираем серверный стек (Node.js / Python / Go), проектируем модель пасса.
3. Реализация — пишем генератор, подпись, регистрацию устройств, обработку push.
4. Тестирование — валидация на реальных устройствах через TestFlight и App Store Connect.
5. Деплой — разворачиваем сервер, настраиваем мониторинг, передаём документацию.

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

• Подготовка и выпуск сертификатов pass type + WWDR.
• Серверная генерация .pkpass с динамическими полями.
• Регистрация устройств и push-обновления статуса рейса.
• Интеграция с бэкендом авиакомпании (REST API / WebSocket).
• Тестирование на iOS-устройствах, включая пасскоды и биометрия.
• Документация по эксплуатации и поддержка после деплоя.

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

Базовая интеграция (генерация, подпись, push) занимает 2–3 дня. Срок может увеличиться при нестандартной логике (несколько рейсов в одном пассе, динамическое отображение). Стоимость рассчитывается индивидуально после оценки объёма работ. Закажите предварительную оценку — обсудим детали и предоставим коммерческое предложение.