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.
Example curl for sending push
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:
| Mistake | Cause | Fix |
|---|---|---|
| Wrong HTTP status | Using 200 instead of 204 on DELETE | Return 204 No Content |
| Incorrect lastUpdated | Returning a non-string or non-UNIX timestamp | Pass timestamp as string, e.g., "1711234567" |
| Wrong apns-topic | Using bundleIdentifier of the app | Use passTypeIdentifier like pass.com.company.app |
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
- Infrastructure analysis: check the current server, backend, and push token storage capabilities.
- Design: define the architecture of the PassKit Web Service, choose the stack for pass file generation.
- Certificate setup: create a Pass Type ID, generate a certificate in the Apple Developer Portal.
- Endpoint implementation: set up the four endpoints according to the PassKit Web Service specification.
- Pass generation and signing: implement automatic creation of .pkpass when data changes.
- APNs integration: configure push sending with each change.
- Testing: use Charles Proxy to intercept requests, check the full cycle.
- 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.
| Component | Duration | Result |
|---|---|---|
| Basic integration (server exists) | 3–5 days | Push updates work on a test pass |
| Full implementation from scratch | 1–2 weeks | Production .pkpass, automatic generation and signing |
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.