Passbook Bundle Laravel Package

Product Decisions This Supports

• Whether Apple Wallet is a feature worth building at all. The package exists to do one commercially boring, technically fiddly thing: assemble a .pkpass (pass.json + assets + manifest hashes + detached PKCS#7 signature) from a Pass Type ID .p12 and Apple's WWDR certificate. A PM can use it to run the cheapest possible experiment — do our users want a wallet-resident artifact (loyalty card, coupon, event/membership ticket) — and get evidence in days instead of speculating in a roadmap doc. The code is a means; the decision it informs is "is wallet presence on the roadmap or not."
• Build vs. buy vs. reference-implement. Signing and certificate plumbing are undifferentiated heavy lifting; every hour on ASN.1/PKCS#7 is an hour not spent on offer mechanics, redemption rules, or the customer-facing content. For a Laravel shop the honest framing is "buy" is not available here (see next section) — this package functions as a reference implementation and spec for the signing pipeline, and the actual decision is "adopt a maintained PHP pass library behind our own interface" vs. "vendor/port the ~few-hundred-line signing routine ourselves." Either way the bundle tells you the shape of the problem and the config surface you must own (pass type ID, team ID, org name, .p12 + password, WWDR cert, icon, output path).
• Feature scope: generation vs. lifecycle. The package covers generation and saving of .pkpass files. The product-defining question is updates: Apple Wallet passes go stale unless you operate a web-service endpoint Wallet polls and send APNs pushes on change. Use this package to scope the cheap half (generate a pass, prove demand), and treat the update service — device registration store, push sender, certificate rotation — as a separate, larger, platform commitment. Don't let "we can generate a pass" leak into the roadmap as "we have Wallet support."
• Use-case sequencing by operational cost. Low-cost, generation-only candidates to trial first: coupons, membership/loyalty cards, one-off event tickets. High-cost, lifecycle-heavy candidates to defer: boarding passes, time-sensitive transactional passes (balance changes, gate changes, tier upgrades) which imply SLAs, alerting on silent failures, and certificate-rotation discipline. One code path can serve all of them; the PM decision is which to fund first.
• One-off experiment vs. platform capability. If the roadmap also contemplates Google Wallet, the decision is whether wallet presence is an internal abstraction (WalletGateway) or a throwaway spike. This package's implicit answer is "one-off, Symfony-2-specific, unmaintained." Choosing it as-is sets how much you're willing to invest around it — and how painful the second wallet will be.
• Owning the certificate/secret lifecycle as an explicit product risk. The .p12 is a signing secret; Pass Type IDs expire and must be rotated (Apple has already rotated/expired older WWDR intermediates — G4 to 2030, earlier ones expired 2023). Adopting any of this forces a decision on secret storage, rotation ownership, and who gets paged when a renewal is missed — a customer-visible failure mode (passes silently stop updating) that belongs on the PM's risk register, not buried in a ticket.

When to Consider This Package

Consider it when:

• You treat it as a reference/spec, not a runtime dependency. For a Laravel (or modern Symfony 6/7, or any non-Symfony-2) codebase this is the only defensible use. Read the README and the sibling eymengunay/php-passbook library, lift the signing/bundling approach, and implement it behind your own WalletPassGenerator interface with a maintained library or ~a few hundred lines of your own code.
• You need a fast, low-stakes proof of concept — a single pass type, generation only, static or near-static content (coupon, membership card, one-time event ticket), no updates, no Wallet web service, no APNs.
• You're deliberately running a time-boxed spike with a kill criterion (e.g., "% of pilot users who add the pass" and "% redeemed within 30 days"), and you've accepted the abandonware risk in writing: last release January 2018, ~10 stars, zero dependents, single maintainer, dormant transitive dependency.
• You can isolate it behind a seam so replacing the engine later is a swap, not a rewrite — and you've budgeted that replacement from day one.

Look elsewhere (i.e., do not adopt this package as a dependency) when:

• You are on Laravel. This is not a Laravel package — it is a Symfony 2.1+ bundle (Eo\PassbookBundle\EoPassbookBundle) registered through AppKernel::registerBundles(), consuming Symfony's DI container and FrameworkBundle conventions. There is no service provider, no config publishing, no facade. The integration effort to bend it into Laravel exceeds wiring a maintained standalone pass library directly. It is commonly miscategorized as framework-agnostic PHP; it is not.
• You need PHP 7.4+/8.x or current dependency versions. The package predates all of it; expect composer resolution conflicts with modern symfony/* and --ignore-platform-reqs hacks rather than a clean install.
• You need the update half of Wallet — the web service, the device registration table, the APNs push sender, HTTP/2 (Apple retired the legacy binary provider protocol; a 2018 library may implement the dead one). You build this yourself regardless of what you choose here.
• You need Google Wallet parity, multi-wallet abstraction, or templated pass-design tooling.
• You need an SLA, vendor support, a documented upgrade path, or a security response process. Zero dependents and no releases in ~seven years means you are the maintainer; there is no one to escalate to.
• Signing secrets must live in a managed secrets system with audited access and rotation. A config-file-driven bundle is the wrong shape; wrap a maintained library in your own service instead.
• You need silent-failure observability out of the box. A bad or expired certificate doesn't shout at integration time — passes just stop updating on device. Plan explicit alerting on signing/rotation health.

How to Pitch It (Stakeholders)

To executives (one paragraph): Apple Wallet passes are a cheap, high-visibility retention surface — a loyalty card or ticket that lives on the customer's lock screen instead of buried in an app. The expensive part isn't the idea, it's the cryptographic signing and certificate plumbing, which is commodity work. This package is a free, pre-built adapter that proves the concept on a legacy Symfony 2 application in a sprint or two at effectively zero license cost and no vendor negotiation. Two caveats shape the recommendation. First, it is a Symfony bundle, not a Laravel package — on our stack it is a reference implementation and specification, not something we install and run. Second, it has been unmaintained since January 2018 with essentially no user base, so we treat it as a prototype accelerator, never a production foundation. Recommendation: fund a time-boxed spike with a defined kill criterion (e.g., "X% of pilot users add the pass, Y% redeem within 30 days"), build it behind an internal wallet interface so the engine can be swapped without touching product code, and do not commit to live pass updates, an SLA, or certificate-rotation operations until that signal exists. Roughly 60–70% of the spike effort is pass assets, Apple account setup, and certificate provisioning — not integration code — so size the estimate accordingly.

To engineering (one paragraph): Do not composer require this into a Laravel app. It is a Symfony 2.1+ bundle wrapping eymengunay/php-passbook; there is no service provider, config publishing, or facade, and its dependency constraints will collide with a modern PHP 8 / current-symfony/* stack. What it is good for is telling us the exact shape of the work: a .pkpass is pass.json + assets + manifest hashes + a detached PKCS#7 signature, signed with a Pass Type ID .p12 and Apple's WWDR cert, served as application/vnd.apple.pkpass. Take that spec, then either adopt a maintained standalone PHP pass library behind our own WalletPassGenerator interface, or port the signing/bundling routine (small, well-bounded surface) into a Laravel-native service with config published and secrets pulled from our secrets manager. Assume we own the certificate lifecycle: verify the WWDR chain against Apple's current intermediate (older generations expired in 2023), plan .p12 rotation and storage, and add alerting because a bad cert fails silently — passes just stop updating. Scope the spike to generation only: no Wallet web service, no device registration table, no APNs push, and confirm nothing in the underlying library relies on Apple's retired binary provider protocol before we estimate anything. Put it all behind the interface so the swap is trivial if the concept validates.