Stripe Bundle Laravel Package

Product Decisions This Supports

• Monetization & pricing experiments. v0.1.2 adds a free-trial length (in days) to createPaymentUrl, so trial duration becomes a per-request input rather than a hard-coded plan attribute. That turns "how long should the trial be?" into a cheap experiment: 7 vs. 14 vs. 30 days by cohort, acquisition channel, or plan tier, with no pricing-model rewrite.
• Feature decision: trial-gated plans now vs. later. The main blocker to shipping a "try before you buy" tier was payment orchestration. This release removes it; the remaining work is product policy (trial length, conversion messaging, what happens at expiry), not engineering plumbing.
• Build vs. buy. The payment URL construction, gateway handshake, and now trial configuration are commodity. Buy this; spend the engineering budget on trial lifecycle UX, entitlement checks, and dunning instead.
• Roadmap sequencing. Trial support is typically a prerequisite for self-serve signup, annual-prepay discounts, and expansion revenue. Treat this as unblocking the self-serve track rather than as a standalone line item.
• Use cases it fits: subscription or recurring checkout on a redirect-based gateway inside a Laravel app, regional bank-link payment flows, and MVP/early-revenue products where time-to-first-paid-customer dominates architecture purity.
• Decision it does not support well: any model needing server-side trial state (proration, mid-trial upgrades, trial-extension logic, churn-at-expiry reporting). Because trial length is passed at payment creation, the authoritative trial record lives at the gateway, not in your database.

When to Consider This Package

Consider it when:

• You are on a supported Laravel/PHP version and your target gateway is one this package already wraps — do not adopt it as a reason to change processors.
• You need trials live in days, not a quarter, and a per-request trialDays parameter is enough fidelity for your pricing model.
• Your team is small and would rather own the trial policy than the gateway protocol.
• You can tolerate a pre-1.0 dependency in a revenue path: pin the version, wrap it behind your own PaymentGateway interface, and keep a thin adapter so a swap is a one-file change.
• You will add your own observability — trial start/end events, conversion funnels — since the package will not provide them.

Look elsewhere when:

• You need a hardened, documented 1.0 surface: idempotency keys, refunds/partial refunds, webhook signature verification, retry and dunning behavior, multi-currency, SCA/3-D Secure edge cases. A v0.1.x release note that adds a single parameter is a fair signal that the surrounding lifecycle features are not yet first-class.
• Your trial logic must be server-authoritative (upgrades mid-trial, seat changes, grace periods, revenue recognition).
• Procurement or compliance review requires a stable API contract, a support SLA, or an audit trail — a solo/early-stage package will not clear that bar.
• You need vendor-backed SDKs and formal migration guides; the changelog here is one line, so upgrade risk is real.

How to Pitch It (Stakeholders)

For executives. The payment layer now supports free trials with a one-parameter change, which unblocks a try-before-buy offer without a rebuild. That matters commercially: trials are the cheapest lever we have on self-serve conversion, and we can now test trial length per cohort instead of arguing about it in planning. The dependency is small and pre-1.0, so the ask is modest engineering time plus a documented exit path — not a platform commitment.

For engineering. The change is additive: an optional trial-days value on createPaymentUrl. No schema change, no breaking API change, no migration. Two things to confirm before we build on it: (1) how trial expiry and first charge are signalled back to us — we need a reliable webhook or polling path to flip entitlements; (2) whether the underlying gateway call is idempotent, because a duplicate submission that starts two trials is a support and refund problem. Recommend pinning to 0.1.2, wrapping the client behind an internal interface, and emitting our own trial-started / trial-converted events so product analytics does not depend on gateway reporting.

For finance/support. Trial length becomes a configurable input rather than a contract term, so expect more variants in the wild; support needs a way to look up a customer's trial start and configured length, and finance needs clarity on whether an unconverted trial ever produces an invoice or a zero-value authorization. Get that answered before launch, not after the first billing disputes.