Weave Code
Weaver
Helps Laravel developers discover, compare, and choose open-source packages. See popularity, security, maintainers, and scores at a glance to make better decisions.
Feedback
Share your thoughts, report bugs, or suggest improvements.
Subject
Message

Filament Stripe Payment Link Laravel Package

andreia/filament-stripe-payment-link

A Filament plugin for Laravel that brings Stripe payment links into your admin panel, letting you create and manage payment links for products or invoices. Streamline payment collection and share Stripe links directly from Filament without custom Stripe workflows.

View on GitHub
Deep Wiki
Context7

Technical Evaluation

Architecture fit. andreia/filament-stripe-payment-link is a narrow Filament plugin that surfaces Stripe Payment Link creation/selection inside a Filament admin panel form. It is a thin integration layer — it does not replace Stripe's SDK, does not own checkout, and does not model payments in your domain. Architecturally that is a good fit for teams already running Filament who want operators to generate a payable URL without leaving the admin, but it is a presentation-layer convenience, not a payments subsystem. Do not let it become the system of record for pricing, entitlements, or reconciliation — those must stay in your own tables keyed by Stripe price/product IDs.

Integration feasibility. Low effort. Composer install, publish config, supply Stripe secret key via environment, drop the field into an existing Filament resource form. No queue workers, no webhooks, no migrations implied by the release notes. The realistic estimate is well under a day for a developer already fluent in Filament, plus review time.

Technical risk. Three items dominate:

  1. Stripe API version coupling. The headline change in v1.1.0 — "Update Stripe API to latest version" — is the only functional change. Stripe versions its API by dated snapshot; a library bump can silently change response shapes, expandable-field defaults, and error codes. This is the single highest-risk line in the changelog and it is described in six words with no migration notes.
  2. Bus factor. Two contributors in this release, one of whom is Dependabot, and both are "first contribution." A single-maintainer plugin in the payment path is a continuity risk.
  3. Governance signal. Of three merged PRs, two are Dependabot CI bumps. That tells you the maintainer keeps CI healthy but does not tell you anything about test coverage of the Stripe upgrade.

Key questions for the maintainer.

  • Which Stripe API version string does v1.1.0 pin, and is it configurable?
  • What is the supported Filament major-version matrix (v3 only, or v3 and v4)?
  • Is there a test suite exercising the Stripe call path, or is CI limited to Dependabot metadata?
  • What is the policy for following Stripe's deprecation calendar?
  • Does the plugin cache or persist generated links, and if so where?

Integration Approach

Stack fit. Requires Laravel with Filament installed and a Stripe account with Payment Links enabled. If your admin panel is Filament v3, this is a natural drop-in. If you are on a custom admin, Livewire-only, or Nova, the package offers nothing and you should call the Stripe SDK directly — the abstraction is too thin to be worth an adapter.

Migration path. Since there is no prior assessment, treat this as a greenfield evaluation rather than an upgrade. Pin to ^1.1.0 explicitly in composer.json; do not use a floating constraint. Publish the config file and keep the Stripe secret in your existing secrets manager, not in .env committed to the repo. If you are currently creating payment links manually in the Stripe dashboard, run the plugin in parallel for one billing cycle before retiring the manual process.

Compatibility. Two axes to verify before merging: Filament major version, and the Stripe PHP SDK constraint the package pulls in. The v1.1.0 API bump may force a transitive stripe/stripe-php version that conflicts with other Stripe-touching packages in your monorepo. Run composer why stripe/stripe-php across the dependency graph and resolve conflicts before the feature branch, not during.

Sequencing.

  1. Confirm Filament and Stripe SDK version compatibility in a throwaway branch.
  2. Deploy to staging against Stripe test mode keys; generate a link end-to-end and complete a test payment.
  3. Verify the generated link's price/amount against source-of-truth product data.
  4. Feature-flag the field to one internal admin user for a week.
  5. Roll out broadly; document the manual-dashboard fallback in the runbook.

Because v1.1.0 changes the Stripe API version, step 2 is non-negotiable — a green CI badge does not demonstrate that the new API snapshot behaves identically.

Operational Impact

Maintenance. Expect to track this package loosely rather than tightly. Releases appear low-cadence and mostly dependency-driven, so a quarterly review is proportionate. Budget a small recurring cost for Stripe API version drift: Stripe ships dated versions and deprecates old ones, and the plugin's upgrade is your trigger to re-test.

Support. No commercial support, no SLA, single primary maintainer. Internal ownership must be assigned to a named engineer on the platform team — "the Laravel team" is not an owner. Support burden is genuinely low because the blast radius is limited to an admin form field.

Scaling. Negligible runtime scaling concern: payment link creation is an operator-initiated action at human frequency, not a per-request hot path. The scaling question that matters is organizational — how many admin surfaces will embed this field, and whether each one independently calls Stripe. Centralize link creation behind one Filament action or service class so you are not scattering Stripe calls across resources.

Failure modes.

  • Stripe API drift — plugin sends a request shape the pinned/updated API rejects; operator sees an opaque error in the admin. Mitigate with a caught exception surfaced as a Filament notification plus a log entry.
  • Credential misconfiguration — test keys in production or vice versa, producing links that take real money or take none. Mitigate with an environment assertion at boot.
  • Silent price mismatch — the field allows selecting a Stripe price that no longer matches your catalog. Mitigate by validating selected price IDs against your own product table, not Stripe's list alone.
  • Abandonment — maintainer stops responding. Low severity given the thin surface; the exit path is to fork or replace with a direct SDK call in one Filament action.

Ramp-up. Hours, not days, for a developer who knows Filament. The conceptual load is Stripe's Payment Link model (price, quantity, after-completion redirect, expiry) rather than the package itself. Include in onboarding: which Stripe mode the environment uses, where the secret key lives, and who to call when a link misbehaves.

Weaver

How can I help you explore Laravel packages today?

Conversation history is not saved when not logged in.
Prompt
Add packages to context
No packages found.
3mdikram/worldmoneywords
snowsoft/config
itmosoft/laravel-subscriptions
larva/laravel-ai-qwen
diephp/sequences
users-au/socialite-provider
twidpay/twid-logger
mrnewport/laravel-plaid
mrnewport/laravel-repo
mrnewport/laravel-docsign
mrnewport/laravel-stow
mrnewport/laravel-flow
mrnewport/laravel-priceable
mrnewport/laravel-nestedterms
fredmeng/laravel-apidoc-generator
itstructure/laravel-multilingual-tools
pdustdar/elasticsearch
markupai/php-sdk
rlacerda83/lumem-microservice-shipment
uni-method/symfony-lib