- How do I install imdhemy/laravel-purchases in a Laravel application?
- Install it with Composer using composer require imdhemy/laravel-purchases. Laravel's package auto-discovery registers the service provider, and you publish the configuration file and migrations with the vendor:publish command. Then add your Apple, Google, and Huawei credentials to the published config or environment variables. No new runtime or datastore is required because the package is a library, not a service.
- Which PHP and Laravel versions does laravel-purchases support?
- The package targets a modern baseline of PHP 8.x and Laravel 10 or newer. You should confirm the exact constraints in the composer.json of the release you install, since platform API updates can shift the minimum versions. Running an older Laravel or PHP version is likely to require a pinned older release.
- Does it support Apple StoreKit 2, the App Store Server API, and modern Google Play Billing?
- The package wraps Apple App Store and Google Play receipt validation behind contracts such as Receipt, Purchase, Subscription, and Transaction. Apple is retiring the legacy verifyReceipt endpoint in favor of the App Store Server API, and Google Play Billing has moved through several major versions, so you must verify which billing generations the specific release supports. Check the release notes and source for StoreKit 2 and Play Billing v6 or v7 coverage before committing.
- How do I receive App Store Server Notifications V2 and Google Real-time Developer Notifications?
- The package can expose optional webhook routes for Apple App Store Server Notifications V2 and Google Real-time Developer Notifications. You still need a public HTTPS endpoint, secure secret storage, and for Google a GCP Pub/Sub topic with a push subscription. Apple delivers notifications out of order and can duplicate or replay them, so your handler must be idempotent.
- Is webhook signature verification handled securely by the package?
- The package provides the webhook routes, but signature verification is security-critical and should get an explicit security review rather than a routine code review. Apple uses JWS signatures and Google Pub/Sub push uses OIDC authentication, both of which are easy to get subtly wrong. Confirm who owns replay protection and authentication in your integration: the package or your application.
- Can I use the package's Purchase and Subscription tables as my system of record?
- It is technically possible, but the package's shipped models couple your domain to a third-party schema. For a server-authoritative entitlement model, keep your own entitlement or account service as the system of record and treat the package tables as validation and event data. This limits the blast radius if the package's schema or interfaces change.
- Does the package handle grace periods, billing retry, account hold, refunds, and revocations?
- Subscription lifecycle handling is a core part of the package, but notification semantics are under-specified in most integrations. Apple and Google produce real states such as grace period, billing retry, account hold, pause, upgrade or downgrade proration, refunds, revocations, offer codes, and family sharing. You must verify the package's normalized state against your actual product catalog and be prepared to build the missing layer yourself.
- Can I configure multiple apps or tenants with different bundle IDs and package names?
- The package uses a configuration-driven, singleton-style credential model, which fits a single app with one Apple bundle ID and one Google package name. If you need multi-tenant app credentials, you will likely need to adapt the configuration and service bindings. Plan that adaptation before you build the entitlement model around the package.
- How do I test in-app purchase validation without relying on Apple or Google sandbox flows?
- Sandbox, TestFlight, and license-tester flows are slow and manual, so automated coverage of failure paths requires deliberate test doubles. Mock the package's Receipt, Purchase, Subscription, and Transaction contracts or fake the store responses at the boundary. Test signature verification failures, duplicate notifications, refunds, and out-of-order events explicitly rather than only happy-path receipt validation.
- Is imdhemy/laravel-purchases production-ready given it is a single-maintainer project?
- It is MIT licensed, actively released as of late 2025, and has a clean Laravel integration, but it has a bus factor of one and zero dependent packages. That means no downstream library has stress-tested its interfaces and there is little ecosystem pressure to preserve backward compatibility. If you adopt it, pin the version, keep an internal fork option, and have a fallback plan if the maintainer stops shipping.