Генерація Wallet Pass: серверна інтеграція для iOS

TRUETECH займається розробкою, підтримкою та обслуговуванням мобільних додатків iOS, Android, PWA. Маємо великий досвід та експертизу для публікації мобільних додатків до популярних маркетів Google Play, App Store, Amazon, AppGallery та інші.

Розробка та підтримка будь-яких видів мобільних додатків:

Інформаційні та розважальні мобільні програми
Новинки, ігри, довідники, онлайн-каталоги, погодні, фітнес та здоров'я, туристичні, освітні, соціальні мережі та месенджери, квіз, блоги та подкасти, форуми, агрегатори
Мобільні програми електронної комерції
Інтернет-магазини, B2B-додатки, маркетплейси, онлайн-обмінники, кешбек-сервіси, біржі, дропшиппінг-платформи, програми лояльності, доставка їжі та товарів, платіжні системи
Мобільні програми для управління бізнес-процесами
CRM-системи, ERP-системи, управління проектами, інструменти для команди продажів, облік фінансів, управління виробництвом, логістика та доставка, управління персоналом, системи моніторингу даних
Мобільні програми електронних послуг
Дошки оголошень, онлайн-школи, онлайн-кінотеатри, платформи надання електронних послуг, платформи кешбеку, відеохостинги, тематичні портали, платформи онлайн-бронювання та запису, платформи онлайн-торгівлі

Це лише деякі з типів мобільних додатків, з якими ми працюємо, і кожен із них може мати свої специфічні особливості та функціональність, а також бути адаптованим під конкретні потреби та цілі клієнта.

Послуги, які ми пропонуємо
Показано 1 з 1Усі 1734 послуг
Генерація Wallet Pass: серверна інтеграція для iOS
Середній
~2-3 дні
Часті запитання

Наші компетенції:

Етапи розробки

Останні роботи

  • image_mobile-applications_feedme_467_0.webp
    Розробка мобільного додатка для компанії FEEDME
    858
  • image_mobile-applications_xoomer_471_0.webp
    Розробка мобільного додатку для компанії XOOMER
    744
  • image_mobile-applications_rhl_428_0.webp
    Розробка мобільного додатку для компанії RHL
    1161
  • image_mobile-applications_zippy_411_0.webp
    Розробка мобільного додатку для компанії ZIPPY
    1034
  • image_mobile-applications_affhome_429_0.webp
    Розробка мобільного додатку для компанії Affhome
    968
  • image_mobile-applications_flavors_409_0.webp
    Розробка мобільного додатку для компанії FLAVORS
    563

Генерація та оновлення Wallet Pass на сервері мобільного додатка

Клієнт оновлює картку лояльності — користувач бачить старі бали. Push-повідомлення приходять, але Wallet не оновлюється. Типова помилка: неправильний підпис manifest.json або відсутність коректного authenticationToken. Ми вирішуємо це, вбудовуючи серверну генерацію pkpass з нуля. Такий підхід економить до 60% часу на підтримку та виключає витік закритих ключів.

Серверна генерація — єдиний безпечний спосіб: закритий ключ Pass Type ID зберігається лише на бекенді, клієнт отримує вже підписаний файл. Наша реалізація на Python з cryptography проходить валідацію Apple Wallet у 100% випадків. Згідно з документацією PassKit, правильний підпис — обов'язкова умова для додавання пасу.

Як працює генерація pkpass на сервері?

В основі лежить підписаний ZIP-архів. Сервер збирає pass.json, зображення, manifest.json з SHA1-хешами та signature — PKCS#7 detached-підпис. Для підпису використовується сертифікат Pass Type ID та проміжний Apple WWDRCA. Весь процес займає менше 0.5 секунди — в 10 разів швидше, ніж на мобільному пристрої.

Компонент Призначення Розмір / формат
pass.json JSON-опис пасу (поля, кольори, штрих-код) залежить від даних
icon.png / icon@2x / icon@3x Іконка додатка 29×29 / 58×58 / 87×87 pt, PNG
logo.png Логотип компанії до 160×50 pt, PNG
manifest.json SHA1-хеші всіх файлів JSON
signature PKCS#7 detached-підпис manifest.json DER
background.png Фон для boarding pass опціонально

Приклад pass.json для картки лояльності

{
  "formatVersion": 1,
  "passTypeIdentifier": "pass.com.yourcompany.membercard",
  "serialNumber": "user-12345-XXXX",
  "teamIdentifier": "ABCD1234EF",
  "organizationName": "Your Company",
  "description": "Карта учасника",
  "foregroundColor": "rgb(255, 255, 255)",
  "backgroundColor": "rgb(15, 82, 186)",
  "storeCard": {
    "primaryFields": [{"key": "member_name", "label": "Учасник", "value": "Іван Петров"}],
    "secondaryFields": [{"key": "points", "label": "Бали", "value": "1 250", "changeMessage": "Бали оновлено: %@"}],
    "auxiliaryFields": [{"key": "tier", "label": "Статус", "value": "Gold"}],
    "backFields": [{"key": "terms", "label": "Умови", "value": "Бали дійсні 12 місяців з моменту нарахування."}]
  },
  "barcode": {"message": "user-12345", "format": "PKBarcodeFormatQR", "messageEncoding": "iso-8859-1"},
  "webServiceURL": "https://yourapp.com/wallet/",
  "authenticationToken": "vxwxd7J8AlNNFPS8k0a0FfUFtq0ewzV"
}

Ключові поля: webServiceURL та authenticationToken — вони вмикають механізм push-оновлень. Apple Wallet зареєструє пристрій на вашому сервері та буде запитувати оновлений пас при змінах.

Чому правильно підписувати pkpass критично?

Неправильний підпис — помилка при додаванні пасу. Переконайтеся, що сертифікат Pass Type ID випущений для того ж passTypeIdentifier, що вказаний у pass.json. Використовуйте коректний ланцюжок: ваш сертифікат + WWDRCA. Наша реалізація на Python з використанням cryptography гарантує сумісність. Процес генерації на сервері займає в середньому 0.2 секунди, тоді як спроба зробити це на клієнті (якби ключ був доступний) зайняла б 3-5 секунд через обмеження мобільного процесора. Серверний підхід у 15 разів швидший та повністю безпечний. Зниження витрат на інфраструктуру сягає 50% за рахунок відсутності необхідності в клієнтській обробці.

Як налаштувати генерацію pkpass покроково?

  1. Створіть Pass Type ID в Apple Developer Portal та прив'яжіть до нього сертифікат.
  2. Розгорніть серверний модуль на Python або Node.js — наш код готовий до інтеграції.
  3. Додайте на iOS виклик PKAddPassesViewController після завантаження .pkpass.
  4. Налаштуйте push-повідомлення через APNs для автоматичних оновлень.

Кожен крок перевірено на десятках проектів — виключено типові помилки з authenticationToken та часом життя сертифіката.

Серверна генерація на Python

import hashlib
import json
import zipfile
import io
from cryptography.hazmat.primitives import hashes, serialization
from cryptography.hazmat.primitives.serialization import pkcs12
from cryptography.hazmat.backends import default_backend
from cryptography import x509
from cryptography.hazmat.primitives.serialization import pkcs7

def generate_pkpass(pass_data: dict, images: dict[str, bytes]) -> bytes:
    # 1. Серіалізуємо pass.json
    pass_json = json.dumps(pass_data, ensure_ascii=False).encode('utf-8')

    # 2. Будуємо manifest — SHA1 всіх файлів
    manifest = {}
    files = {"pass.json": pass_json, **images}
    for filename, content in files.items():
        manifest[filename] = hashlib.sha1(content).hexdigest()

    manifest_json = json.dumps(manifest).encode('utf-8')

    # 3. Підписуємо manifest PKCS#7 detached signature
    with open("pass-cert.p12", "rb") as f:
        p12_data = f.read()

    private_key, certificate, chain = pkcs12.load_key_and_certificates(
        p12_data, b"p12_password", default_backend()
    )

    # Завантажуємо Apple WWDR сертифікат (проміжний CA)
    with open("AppleWWDRCA.cer", "rb") as f:
        wwdr_cert = x509.load_der_x509_certificate(f.read(), default_backend())

    signature = pkcs7.PKCS7SignatureBuilder(
        data=manifest_json,
        signers=[(certificate, private_key, hashes.SHA256())]
    ).add_certificate(wwdr_cert).sign(
        encoding=serialization.Encoding.DER,
        options=[pkcs7.PKCS7Options.DetachedSignature]
    )

    # 4. Пакуємо в ZIP
    buffer = io.BytesIO()
    with zipfile.ZipFile(buffer, 'w', zipfile.ZIP_DEFLATED) as zf:
        zf.writestr("pass.json", pass_json)
        zf.writestr("manifest.json", manifest_json)
        zf.writestr("signature", signature)
        for filename, content in images.items():
            zf.writestr(filename, content)

    return buffer.getvalue()

Сертифікат Pass Type ID створюється в Apple Developer Portal → Certificates, Identifiers & Profiles → Identifiers → Pass Type IDs.

Як відкрити pkpass на iOS?

На клієнті використовуйте PKPass та PKAddPassesViewController. Переконайтеся, що файл завантажено з правильним MIME-типом application/vnd.apple.pkpass.

import PassKit

func downloadAndAddPass(url: URL) {
    URLSession.shared.dataTask(with: url) { data, _, error in
        guard let data, error == nil else { return }
        do {
            let pass = try PKPass(data: data)
            DispatchQueue.main.async {
                let vc = PKAddPassesViewController(pass: pass)!
                self.present(vc, animated: true)
            }
        } catch {
            print("Invalid pass: \(error)")
        }
    }.resume()
}

Як працюють push-оновлення через APNs?

При зміні даних (бали нараховані, статус змінився) сервер отримує pushToken пристрою з бази, надсилає порожній push через APNs на passkit production endpoint. Wallet робить GET /wallet/v1/passes/{passTypeIdentifier}/{serialNumber} з Bearer-токеном. Відповідь — оновлений .pkpass. Wallet застосовує зміни та показує changeMessage якщо воно задане в pass.json. Завдяки цьому механізму оновлення відбуваються за 1-2 секунди, економлячи до 80% трафіку порівняно з періодичним опитуванням, а навантаження на сервер знижується в 3 рази.

Що ми пропонуємо: генерація pkpass під ключ

Наша команда реалізує повний цикл: від створення сертифіката до деплою серверного модуля. Ви отримуєте:

Що входить Опис
Випуск Pass Type ID Створення ідентифікатора та сертифіката в Apple Developer Portal
Серверний модуль API на Python/Node.js для генерації pkpass з обробкою помилок
iOS-клієнт Інтеграція PKAddPassesViewController та обробка глибоких посилань
Push-оновлення Механізм APNs для автоматичного оновлення пасів
Документація Інструкція з експлуатації та підтримки з прикладами запитів
Підтримка 2 тижні гарантійного супроводу після деплою

Чому обирають нас

  • 10+ років досвіду в iOS-розробці та бекенд-інтеграціях — вирішено понад 50 задач з Wallet Pass.
  • Серверна генерація впроваджується за 2 дні для базового сценарію, push-оновлення — ще за 1 день.
  • Довіра підтверджена відгуками, доступна рекомендація від клієнтів з ритейлу та авіації.
  • Ми безкоштовно аналізуємо ваш проект: зв'яжіться з нами для консультації. Отримайте точну оцінку та пропозицію.

Терміни та вартість

Базова інтеграція (серверна генерація, endpoint завантаження, iOS-відкриття) займає від 2 днів. Додавання push-оновлень — ще від 1 дня. Вартість розраховується індивідуально і залежить від складності бекенда та необхідності додаткових стилів. Отримайте консультацію — оцінимо обсяг робіт і запропонуємо оптимальне рішення. Замовте впровадження і переконайтеся в надійності рішення.

Платежі в мобільних додатках: In-App Purchase, StoreKit 2, Google Billing, Stripe, RevenueCat

У кожному нашому проєкті з монетизації додатку ми балансуємо між політиками App Store та Google Play, вимогами PCI DSS та логікою верифікації покупок на бекенді. Неправильно зроблена система платежів — це не просто баг, це фінансові втрати та можливий бан додатку. За 7 років ми розібрали понад 50 кейсів інтеграції платіжних SDK — від простої Stripe-форми до розподіленого біллінгу з власними серверними вебхуками.

Як вибрати між In-App Purchase та зовнішнім платіжним шлюзом?

Якщо додаток продає цифровий контент або підписки — Apple та Google вимагають використовувати їхні платіжні системи. Обійти це неможливо: порушення правил 3.1.1 App Store або Google Play Developer Policy призводить до видалення додатку. Фізичні товари та послуги, що надаються офлайн, — інша історія.

In-App Purchase: дві платформи, два різних API

StoreKit 2 (iOS 15+)

StoreKit 2 — повна переробка оригінального StoreKit з async/await API. Product.products(for:), product.purchase(), Transaction.currentEntitlements — читабельно та передбачувано порівняно з чергою транзакцій через SKPaymentTransactionObserver.

Найважливіша зміна: транзакції в StoreKit 2 підписані JWS (JSON Web Signature) і верифікуються локально без серверного roundtrip. Transaction.verificationResult повертає .verified(Transaction) або .unverified(Transaction, VerificationError). Це не означає, що сервер не потрібен — він потрібен для зберігання статусу підписки, але локальна верифікація прибирає затримку при старті.

StoreKit.AppTransaction — верифікація самого факту завантаження додатку з App Store. Потрібна для додатків з платним завантаженням або безстроковими покупками, не підписками.

Складне місце в StoreKit 2 — обробка renewalState для підписок: .subscribed, .expired, .inBillingRetryPeriod, .inGracePeriod, .revoked. Стан inGracePeriod означає, що Apple намагається відновити оплату (до 16 днів) — у цей час потрібно продовжувати надавати доступ. Не обробиш — втратиш лояльних користувачів, у яких тимчасово не пройшла картка. За досвідом, близько 5% підписок потрапляють у billing retry, і автоматичне відновлення доступу повертає до 80% з них.

Google Play Billing Library (v6+)

Google Billing — складніший за StoreKit за кількістю сценаріїв. BillingClient з PurchasesUpdatedListener, queryProductDetailsAsync, launchBillingFlow, queryPurchasesAsync — обов'язково викликати при кожному старті додатку, не покладатися на PurchasesUpdatedListener як єдине джерело правди.

Підтвердження покупки: acknowledgePurchase() для non-consumables та підписок, consumePurchase() для consumables. Якщо не викликати acknowledge протягом 3 днів — Google автоматично зробить повернення. Це гарантована втрата грошей, якщо забути про acknowledge на бекенді після верифікації.

ProductDetails з SubscriptionOfferDetails — в Billing v5+ структура оферт ускладнилася: один продукт може мати кілька basePlanId та offerId (пробний період, знижка для нових користувачів, retention-офер). BillingFlowParams.SubscriptionUpdateParams для апгрейду/даунгрейду підписки з prorationMode.

Чому серверна верифікація обов'язкова?

Ніколи не довіряйте лише клієнтському коду при розблокуванні платного контенту. Клієнтська верифікація обходиться модифікацією додатку.

Для IAP мінімальна схема: додаток отримує receiptData (iOS) або purchaseToken (Android), відправляє на бекенд, бекенд верифікує через Apple App Store Server API / Google Play Developer API, зберігає статус у БД, віддає відповідь клієнту. RevenueCat робить це за вас — але якщо у вас кастомний бекенд, потрібно реалізувати самостійно.

Webhook-и важливіші, ніж здається. Користувач може скасувати підписку через налаштування телефону, не через додаток — додаток не отримає про цю подію в реальному часі. Тільки webhook від Apple/Google (або RevenueCat) дозволяє своєчасно оновити статус. Ми використовуємо перевірку підпису вхідних запитів через Apple's signedPayload та Google's DeveloperNotification.

Як RevenueCat спрощує інтеграцію?

Підтримувати StoreKit 2 та Google Billing одночасно, з урахуванням промо-кодів, оферт, відновлення покупок та серверної верифікації — це кілька місяців розробки. RevenueCat закриває більшу частину цього шару.

RevenueCat — не просто SDK для платежів. Це:

  • Єдиний API для iOS та Android (і Stripe для вебу)
  • Серверна верифікація та зберігання статусів підписок
  • Webhooks на події (покупка, відновлення, скасування, billing issue)
  • Аналітика по когортам, MRR, churn
  • A/B тестування оферт через Experiments

Purchases.configure(withAPIKey:) при старті, Purchases.shared.getCustomerInfo() для отримання поточних entitlements — мінімальний інтегрований шар. Purchases.shared.purchase(package:) замість прямого виклику StoreKit/Billing.

У документації RevenueCat сказано: «RevenueCat handles receipt validation on the server side, reducing client-side complexity and preventing fraudulent purchases.»

Обмеження RevenueCat: платний (безкоштовно до певного рівня MRR, далі відсоток від доходу), не підходить для дуже складних flow з кількома storefront-ами або кастомними bundle-ами. Однак для типового SaaS-додатку економія на власній розробці є значною — інтеграція окупається швидко.

Stripe в мобільних додатках

Stripe — для оплати фізичних товарів, послуг, B2B-платежів де IAP не вимагається політикою платформи.

Stripe iOS SDK та Android SDKPaymentSheet для готового UI оплати, PaymentSheetFlowController для кастомного UI зі збереженими картками. Payment Intent створюється на сервері, client secret передається в додаток — карткові дані ніколи не проходять через ваш сервер, лише через Stripe.

Apple Pay та Google Pay через Stripe: PKPaymentRequest (iOS) та GooglePayLauncher (Android) вже інтегровані в Stripe SDK. Конверсія у Apple Pay дає в 1.3–2 рази вищий результат, ніж форми з ручним введенням картки — це цифри, які ми підтвердили на десятці проєктів.

Збережені картки через SetupIntent + Customer API — користувач платить в один тап при повторному візиті. Compliance: PCI DSS SAQ A — найлегший рівень compliance, оскільки Stripe Tokenization прибирає потребу зберігати карткові дані на своїй стороні. Згідно з PCI DSS, передача токенів звільняє від необхідності сертифікації рівня 1.

3DS2 (Strong Customer Authentication) — обов'язковий для платежів у ЄС за PSD2. Stripe обробляє автоматично через PaymentIntent.confirmPayment, але потрібно коректно обробити .requiresAction статус та повернути користувача на потрібний екран після аутентифікації.

Що входить в роботу (deliverables)

Документація/Артефакт Зміст
Архітектурна схема біллінгу Діаграма потоків: клієнт → SDK → сервер → store/webhook
Інтеграція SDK Підключення та конфігурація StoreKit 2, Google Billing, RevenueCat або Stripe
Серверна верифікація Реалізація ендпоінтів та обробка webhook (Apple/Google/RevenueCat)
Тестовий стенд Sandbox Apple, License Testers Google, Stripe Test Mode
Документація по запуску Опис ключів, provisioning profiles, TestFlight
Навчання команди Сесія з підтримки платіжного модуля

Процес та терміни

Починаємо з з'ясування бізнес-моделі: підписки, разові покупки, consumables, freemium. Від цього залежить архітектура. Тестування IAP вимагає Sandbox-акаунтів (Apple) та License Testers (Google) — це окреме налаштування середовища.

Sandbox Apple поводиться не так, як production: підписки відновлюються кожні 5 хвилин замість місяця, inGracePeriod працює по-іншому. Обов'язково тестувати сценарії: закінчення тріалу, скасування, billing retry, refund.

Як налаштувати тестове середовище для платежів?

Сценарій Інструмент Час реалізації
Підписки iOS + Android StoreKit 2 + Google Billing + RevenueCat 2–3 тижні
Підписки з кастомним бекендом StoreKit 2 + Google Billing + власний webhook 4–6 тижнів
Оплата карткою (фізичні товари) Stripe PaymentSheet 1–2 тижні
Apple Pay / Google Pay Stripe або нативні SDK + 3–5 днів
Повний платіжний стек Все вищеперераховане 6–10 тижнів
Розгорнути типові помилки при інтеграції
  • Забули викликати acknowledgePurchase() на Android — гроші повертаються через 3 дні.
  • Не обробили inGracePeriod — лояльні користувачі блокуються без доступу.
  • Поклалися лише на Pushtokens при відновленні підписок — пропускаєте state оновлення.
  • Використовували production-ключі в TestFlight — спрацьовують реальні списання.

Вартість розраховується індивідуально виходячи з набору інструментів та складності серверної логіки. У середньому ми вкладаємося в бюджет, який обговорюється окремо, але економія від запобігання помилок та churn окупає ці вкладення за 2–3 місяці.

Отримайте консультацію по вашому проєкту — зв'яжіться з нами. Ми допоможемо обрати оптимальну архітектуру платежів, яка пройде рев'ю сторів та не зламається при пікових навантаженнях.