Implementing Push Updates for Wallet Pass in Mobile Apps

In a mobile app for loyalty programs, a common situation arises: bonuses are credited, but the client sees the old balance until they manually open the card. Push updates for Wallet Pass solve this—data on the device updates in seconds without user involvement. We configured this mechanism for 5000+ pass cards, and the time from a server change to device update does not exceed 2 seconds. Implementing push updates reduces data update time on devices by 90%, increasing user loyalty. If you want to implement push updates, get a consultation.

How the Push Update Mechanism for Wallet Pass Works

Architecturally, the scheme looks like this: your server registers the device via the PassKit Web Service API, stores the pair deviceLibraryIdentifier + pushToken, and when data changes, sends a push via APNs to that token. iOS 'wakes up', makes a GET request to the server for the updated .pkpass file, and the card updates without user involvement.

Implementation is divided into two parts—server and client—with the client part being almost zero: PassKit handles the entire registration cycle if the server implements the protocol correctly.

Server-side PassKit Web Service Protocol

The server must implement four endpoints:

• POST /v1/devices/{deviceLibraryIdentifier}/registrations/{passTypeIdentifier}/{serialNumber} — device registration
• DELETE /v1/devices/{deviceLibraryIdentifier}/registrations/{passTypeIdentifier}/{serialNumber} — unregistration
• GET /v1/devices/{deviceLibraryIdentifier}/registrations/{passTypeIdentifier}?passesUpdatedSince={tag} — list of updated passes
• GET /v1/passes/{passTypeIdentifier}/{serialNumber} — download the latest .pkpass

The most common mistake is an incorrect HTTP status. Apple PassKit is extremely sensitive: 200 with an empty body on DELETE breaks unregistration. You need 204 No Content. On GET for the list of updates without changes, strictly 204, not 200.

// Example response structure for GET /registrations
{
  "serialNumbers": ["ABC123", "DEF456"],
  "lastUpdated": "1711234567"
}

The lastUpdated field is a UNIX timestamp as a string. iOS passes it back in passesUpdatedSince on the next request. If you return the timestamp in the wrong format, the device will constantly request all passes, ignoring incremental logic.

APNs Push for Updates

The push for Wallet is non-standard. The payload is minimal:

{
  "aps": {}
}

Exactly—empty aps. No alert, badge, sound. iOS, upon receiving such a push, silently goes to the server for updates. You need to send via APNs with apns-topic equal to the passTypeIdentifier of the app (format: pass.com.yourcompany.appname), not the bundleIdentifier.

The certificate for PassKit is separate—it's a Pass Type ID Certificate from the Apple Developer Portal, not a regular APNs certificate for the app. These are often confused, resulting in APNs accepting the request but the push not being delivered.

# Example sending via httpx (Python, APNs HTTP/2)
headers = {
    "apns-topic": "pass.com.example.loyalty",
    "apns-push-type": "background",
    "apns-priority": "5",
    "authorization": f"bearer {jwt_token}"
}
payload = json.dumps({"aps": {}})
response = await client.post(
    f"https://api.push.apple.com/3/device/{push_token}",
    content=payload,
    headers=headers
)

apns-priority: 5 is mandatory for background pushes. Priority 10 does not work as expected for Wallet.

curl -v --header "apns-topic: pass.com.example.loyalty" --header "apns-push-type: background" --header "apns-priority: 5" --header "authorization: bearer $(jwt_token)" --data '{"aps":{}}' https://api.push.apple.com/3/device/$(push_token)

Signing .pkpass

Each .pkpass is a ZIP archive with a manifest.json file (SHA-1 hashes of all files) and a signature (PKCS#7 detached signature). When updating a pass, you need to recalculate the manifest and recreate the signature. Using an old signature with new data causes iOS to silently ignore the file.

Generating the signature via openssl:

openssl smime -binary -sign \
  -certfile AppleWWDRCA.pem \
  -signer passcertificate.pem \
  -inkey passkey.pem \
  -in manifest.json \
  -out signature \
  -outform DER

Apple's signpass library is useful for testing, but in production it's better to implement signing natively on the server—without external binaries.

Typical Mistakes During Implementation

Based on our experience implementing push updates for Wallet Pass in projects of various scales, we highlight three most common problems:

Each of these mistakes leads to updates not being delivered, even though everything looks correct on the server. We have developed a checklist that allows diagnosing the problem in 30 minutes.

Our Work Process

1. Infrastructure analysis: check the current server, backend, and push token storage capabilities.
2. Design: define the architecture of the PassKit Web Service, choose the stack for pass file generation.
3. Certificate setup: create a Pass Type ID, generate a certificate in the Apple Developer Portal.
4. Endpoint implementation: set up the four endpoints according to the PassKit Web Service specification.
5. Pass generation and signing: implement automatic creation of .pkpass when data changes.
6. APNs integration: configure push sending with each change.
7. Testing: use Charles Proxy to intercept requests, check the full cycle.
8. Monitoring: set up logging and alerts for push sending failures.

What's Included in the Implementation

As a result, you get:

• Server-side: a fully working PassKit Web Service API with token storage and support for incremental updates.
• Client integration: minimal changes in the app (registration when adding a pass).
• Documentation: description of all endpoints, data formats, and update procedure.
• Test pass files: ready samples for debugging.
• Support during implementation: consultations on modifications on the client's side.

Why Trust Us

• 10+ years of experience in mobile development and server integration.
• 5000+ implemented Wallet Passes for various loyalty programs and ticketing systems.
• Compliance with all requirements of Apple PassKit Web Service Specification and App Store Review Guidelines.
• 99.9% uptime of our server solutions for clients.

Get a consultation on your project—we'll estimate timelines and costs.

Push Notifications in Mobile App: APNs, FCM, Segmentation, Rich Push

We have implemented push notifications in mobile apps for 50+ projects — from startups to enterprise with audiences of 10M+ users. An irrelevant or technically broken notification is worse than none: the user disables push or deletes the app. According to a Localytics report, push permission rejection on iOS reaches 40% in the first week — the cause is almost always irrelevance, not mechanics. Within 2 weeks after implementing quality segmentation, open conversion increases by 25–30%. Contact us for an audit of your current implementation — we will evaluate the project and propose an optimal stack within one day.

How the Infrastructure Works: APNs and FCM

APNs is the only delivery channel on iOS. Everything else (OneSignal, Braze, Airship) is a wrapper on top of it. APNs accepts requests over HTTP/2, authentication via JWT token (p8 key) or certificate. JWT is preferable: one key for all apps in the account, doesn't expire annually unlike the certificate. For more details, see the official documentation.

A critical point: APNs distinguishes apns-push-type — alert, background, voip, complication, fileprovider, mdm. An incorrect type on iOS 13+ causes background notifications not to wake the app. We've seen projects where content-available: 1 was sent without apns-push-type: background — the app didn't receive silent push on some devices, and the team spent a month looking for an 'app bug'.

FCM on Android works through Google Play Services. For devices without GMS (Huawei, part of the Chinese market), Huawei Push Kit or a direct WebSocket is needed — a separate task. FCM supports data messages (handled in onMessageReceived) and notification messages (the system displays automatically if the app is in the background). Mixing them requires caution: if the notification block has a click_action but the deep link is not registered in the app, tapping the notification simply opens the main screen without navigation.

Why Segmentation Is the Foundation of Effective Push Notifications?

Sending to everyone indiscriminately quickly exhausts user loyalty. Personalized messages are clicked 3 times more often than bulk ones, and proper segmentation reduces churn by 25% (on one project it brought significant additional revenue per quarter). The cost of setting up segmentation in OneSignal or a custom backend depends on the complexity of filters.

Proper segmentation is built on several levels.

Topics are for broad categories: 'new promotions', 'order status updates'. User subscribes via FirebaseMessaging.getInstance().subscribeToTopic("orders"). Simple, but no flexible filtering.

Attribute-based segments — via OneSignal, Braze, or custom backend. We store in the user profile: language, device type, last activity, LTV segment. Notification goes only to those with last_active < 7_days and plan = premium. OneSignal allows building such filters in the interface without code.

Personalized — by specific device_token. It's important to store tokens correctly: the token updates on app reinstall, restoration from backup on a new phone, or resetting settings. On iOS, use UNUserNotificationCenter + didRegisterForRemoteNotificationsWithDeviceToken, save to backend on every launch, not just the first. Otherwise, after 3 months 30% of tokens in the database are outdated.

What Is Rich Push and How Does It Boost Conversion?

A standard notification with title and text is clicked less often than a rich push with image and action buttons — by 3 times. But implementing rich push is a separate task on each platform.

On iOS, rich content requires UNNotificationServiceExtension (to modify payload) and UNNotificationContentExtension (custom UI). The extension runs in a separate process with limited time and memory. If the extension crashes or exceeds the timeout, the system shows the original payload without media. A typical mistake is trying to load an image over HTTP (not HTTPS): ATS blocks the request, the extension silently fails, and the user sees a notification without an image.

On Android with API 26+, notifications are tied to NotificationChannel. If the channel is created with IMPORTANCE_LOW, sound and vibration are unavailable. Different notification types (transactional, marketing) should be in different channels so the user can disable marketing without losing order notifications. BigPictureStyle, MessagingStyle, InboxStyle are templates for expanded notifications. MessagingStyle with Person and avatars is the best choice for chats.

How to Track Delivery and Conversion of Push Notifications?

Sending a notification is half the work. It's important to know: was it delivered, opened, and did it lead to a target action.

FCM returns a MessageId on send, but does not guarantee a delivery callback — by design. For open tracking, custom logic is needed: on notification tap in onMessageReceived or via getInitialNotification() / onNotificationOpenedApp (OneSignal SDK), send an event to analytics with notification_id.

OneSignal provides built-in delivery and CTR analytics. For more detailed analysis — integrate with Amplitude or Mixpanel via webhook on open events. The budget for such a dashboard varies depending on event volume.

How We Implement Push Notifications: Typical Process

1. Audit current implementation — check token storage, update handling, notification types.
2. Design architecture — choose transport (FCM + APNs), segmentation layer (OneSignal/Braze/custom), personalization method.
3. Implementation — write registration code, inbound handling, rich push, deep linking.
4. Testing — send test campaigns, verify delivery on different devices, simulators, regions.
5. Monitoring and analytics — set up dashboard, open and conversion events.
6. Documentation and training — hand over operational materials to the team.

Typical stack: FCM + APNs at transport level, OneSignal or Firebase Notifications Composer for segmentation, custom backend for personalized event-based notifications. For large apps with >1M users, OneSignal has pricing limits — then we use Braze or a custom implementation on AWS SNS.

Timelines depend on complexity: basic FCM+APNs integration with transactional notifications — 1–2 weeks. A full system with segmentation, rich push, analytics, and A/B testing — 4–8 weeks. Order an audit of your current push infrastructure or get a consultation on implementing push notifications in your mobile app — we will contact you within a day and provide an accurate estimate.