Laravel Purchases Laravel Package

Product Decisions This Supports

• Mobile monetization launch/expansion: Server-side validation of Apple App Store and Google Play in-app purchases so premium features, subscriptions, and paid unlocks are granted from verified purchases rather than trusting the client.
• Entitlement model design: Decide how premium access is represented, synchronized across iOS/Android, restored after reinstall, and revoked on refunds or failed renewals. As of 1.20.0, the package exposes immutable subscription and renewal dates, which gives us a trustworthy server-side basis for "access valid until" logic and renewal-window UI instead of deriving dates from client payloads.
• Build vs. adopt vs. buy: Compare adopting this MIT Laravel package against building direct Apple/Google integrations or buying a managed in-app purchase/subscription platform.
• Roadmap sequencing: Use it for an MVP that validates receipts and gates features; the new immutable date fields make a first-pass renewal/expiry model feasible without custom parsing, while store notifications, refund/grace-period logic, analytics, and experimentation remain later phases.
• Operational and support decisions: Define flows for failed validation, sandbox vs. production testing, purchase restoration, refunds, fraud signals, and customer-support tooling. Immutable renewal dates also help support agents answer "when does this expire?" consistently across platforms.
• Risk ownership: Treat the package as a focused component, not a complete billing system. Decide who owns the surrounding entitlement service, monitoring, and fallback plan.

When to Consider This Package

Consider it when:

• Your backend is Laravel/PHP and your mobile apps sell digital goods or subscriptions through Apple/Google.
• You need server-side receipt validation quickly for an MVP, internal product, or small team.
• You need a reliable, non-mutable view of subscription start/renewal dates to drive entitlement expiry and renewal messaging (available from 1.20.0).
• You can own the surrounding entitlement logic, audit logging, retries, secrets management, and support flows.
• You want an MIT-licensed, Laravel-native starting point instead of writing store-specific validation code from scratch.
• Your near-term needs are simple validation and feature gating rather than full subscription revenue operations.

Look elsewhere or plan to supplement when:

• You are not on Laravel/PHP.
• You need a full subscription management platform: paywalls, experimentation, revenue analytics, customer dashboards, lifecycle automation, or managed support.
• You need web payments, Stripe-style billing, or stores beyond Apple/Google.
• You require enterprise SLAs, guaranteed maintenance, or deep compliance support.
• You need event-driven lifecycle handling (renewal, cancellation, billing retry, grace period) — date exposure in 1.20.0 helps with expiry math but does not replace Apple/Google server notifications, so confirm notification coverage and plan to build or buy that layer.
• The package does not cover the store APIs or notification flows you depend on—confirm Apple/Google API coverage, subscription lifecycle support, and sandbox behavior.
• The low public dependent count and single-maintainer/OSS risk are unacceptable without a fork, pinning strategy, or fallback plan.

How to Pitch It (Stakeholders)

Executive summary: This package is a Laravel-native receipt validator that helps us launch mobile monetization faster and at lower cost. It verifies Apple/Google purchases server-side, reducing reliance on client claims and basic fraud risk, and the 1.20.0 release adds immutable subscription and renewal dates so we can calculate access expiry from verified data. It is a component—not a complete billing or subscription platform—so we should wrap it in entitlement logic and plan for renewals, refunds, and support. Recommendation: run a time-boxed spike, adopt for MVP if it covers our target stores, and revisit a managed platform if subscription complexity becomes core.

Engineering summary: Use it as an adapter for Apple/Google receipt validation to avoid custom store-specific code. The 1.20.0 addition of immutable subscription/renewal date properties is backwards-compatible and useful for expiry logic, but it is a data exposure improvement, not a lifecycle engine. We still own the entitlement service, idempotency, audit trail, secret management, retry behavior, sandbox/production configuration, and monitoring. Pin versions, review maintenance/security posture, and document a fallback path.

Product summary: It enables faster testing of premium features, subscriptions, and paid unlocks in a Laravel-backed app, and now surfaces fixed subscription and renewal dates we can show in account screens and use for expiry reminders. It also forces useful clarity on entitlement rules and restore-purchase behavior, but product must still plan for renewal, refund, grace-period, and customer-support workflows rather than assuming the package handles them.