Laravel Mobile Pass Laravel Package

Product Decisions This Supports

• Build vs. buy for wallet passes: Apple PassKit signing (certificates, .pkpass bundling, web service registration) and Google Wallet's class/object API are each multi-week integration efforts with their own auth models. This package collapses both into one Laravel-native model (MobilePass) with unified addToWalletUrl(), expire(), and update-push behavior — turning a "maybe next quarter" integration into a scoped sprint.
• Feature bets that need a low-friction retention surface: Wallet passes live on the lock screen and surface via geofence/iBeacon relevance without an app install. This supports roadmap decisions around loyalty/store cards, coupon drops, membership cards, and event/boarding tickets where the goal is repeat engagement rather than a one-off email attachment.
• Extending the ticketing/fulfillment surface you already own: If you already issue PDFs or emailed QR codes, this is an incremental channel decision — same order/redemption data, new delivery format — rather than a new product line. Pass serials and MobilePass records give you an auditable link between a pass and a customer/order.
• Lifecycle messaging and live updates: PushPassUpdateJob (queue opt-in via MOBILE_PASS_QUEUE_CONNECTION), automatic Google object PATCHes on model update, and Apple webservice registration mean a gate change, price change, points balance, or coupon expiry can be reflected on the user's device. That supports decisions about real-time personalization, dynamic offers, and "always current" credentials instead of stale static artifacts.
• Attribution and channel instrumentation: Google save/remove callbacks fire GoogleMobilePassSaved / GoogleMobilePassRemoved events, plus isCurrentlySavedToGoogleWallet() and googleEvents. That gives you a measurable funnel (issued → added to wallet → updated → redeemed) to justify or kill the channel.
• Market and audience prioritization: First-class i18n support on both Apple and Google (1.7.x–1.8.x lineage) makes multi-locale rollout a configuration choice, not a fork. Useful when deciding whether to launch in one market first or design for international from day one.
• Platform parity decisions: The package deliberately unifies Apple and Google primitives rather than exposing two divergent SDKs, which makes "ship both platforms at once" the default cheap path and avoids a roadmap where Android silently lags.

When to Consider This Package

Adopt when most of these hold:

• You are on Laravel and want wallet passes as a first-class model, not a bolt-on HTTP client. The package's value is the Eloquent model, migrations, routes, queue jobs, and events — it fits existing conventions rather than asking you to restructure.
• You need both Apple and Google Wallet, or expect to within two quarters. Supporting one platform in-house is tractable; two is where the maintenance tax compounds.
• Your content is templated and dynamic — loyalty balances, event details, coupons with expiry, boarding info — and you expect to push updates after issuance.
• You can absorb platform prerequisites: Apple Developer Program membership, a Pass Type ID certificate, a Google Wallet issuer account and service account, and a publicly reachable HTTPS host for webServiceURL (the package now hard-fails on non-HTTPS config — a good thing, but a deployment constraint).
• You have engineering capacity for the non-code edges: certificate rotation, Apple/Google console configuration, and device-based QA (there is no meaningful simulator story for Wallet).
• You want a MIT-licensed, vendor-neutral starting point with real docs, a changelog, tagged releases, a live demo, and a test suite you can run — the repo's maturity signals (README, docs, changelog, releases, demo app) are strong for a 1.x package.

Look elsewhere or defer when:

• You need NFC/Smart Tap credentials now. Smart Tap NFC fields are explicitly deferred; Apple iBeacon relevance exists (1.5.0), but tap-to-validate isn't a solved path here.
• You need Samsung Wallet, Huawei Wallet, or other ecosystems. This is Apple + Google.
• You require a commercial SLA, indemnification, or a named support channel. MIT OSS from a respected vendor is not a contract; budget for internal ownership.
• Your stack isn't Laravel/PHP — the abstractions won't transfer.
• You only need a scannable code — a PDF or email QR is cheaper and has no certificate lifecycle.
• Your volume profile demands bespoke wallet infrastructure (deep white-labeling, custom object schemas at scale, strict data residency) — at that point you're likely building or buying an enterprise pass platform.
• You're risk-averse on adoption signals. Zero dependents on Packagist is a real caveat: this is early-adopter territory. Mitigate by scoping a thin spike, reading the demo source, and confirming the maintainer's release cadence (currently active, frequent patch/minor releases) before committing it to a revenue-critical path.

How to Pitch It (Stakeholders)

For executives — the one-liner: This is the buy-side answer to "should we put our tickets/coupons/loyalty cards in Apple and Google Wallet?" It replaces what is normally a multi-week, two-platform integration (cryptographic pass signing, certificate management, Google's class/object API, device registration and push updates) with a Laravel package we can adopt in days, under an MIT license, from a maintainer with a long track record in the PHP ecosystem.

Why it matters commercially: Wallet is a retention and conversion surface, not a cosmetic one. Passes sit on the lock screen, resurface by time and location, and update in place — so a coupon can expire, a gate can change, and a points balance can move without the customer opening anything. We also get a measurable funnel from the save/remove callbacks and update events, which means we can prove or kill the channel on data rather than opinion.

For engineering — the honest scope: The package handles pass generation, signing and bundling, unified add-to-wallet URLs, expiry, queued update pushes, and Apple/Google lifecycle events. What it does not remove: Apple Developer Program enrollment and Pass Type ID certificate handling, Google Wallet issuer/service-account configuration, a publicly reachable HTTPS host for Apple's web service, certificate rotation on a calendar, and real-device QA. Those are operational line items we should staff explicitly, not assume away.

Known constraints to state up front, not discover later: Smart Tap NFC is deferred; only Apple and Google wallets are covered; callback signature verification uses Google's ECv2 signing-only path rather than automatic JWKS fetching; and the package has essentially no downstream dependents yet, so we should treat 1.x as "active, well-documented, but early" and pin our version. A short spike — one pass type, end to end on both platforms — is the right first commitment before we put it behind a launch.