Stripe Payment Jms Laravel Package

Getting Started

Start by accepting two realities before you install anything:

1. This is a Symfony bundle, not a Laravel package. The description is explicit — it rides on JMSPaymentCoreBundle and targets "the symfony framework." There is no service provider, no facade, no config/payment.php, no Blade/Cashier-style API. It will not composer require cleanly into a modern Laravel app without pulling in Symfony/JMS dependencies that fight Laravel's container.
2. JMSPaymentCoreBundle itself is effectively abandoned, and this package has 0 stars, 0 dependents, and a single 2023 tag. Treat it as unmaintained reference code, not a dependency you adopt.

Where to look first (if you genuinely must):

• Read the README for the required jms_payment_core config block and the service tag it uses to register the plugin.
• Open the plugin class (typically a StripePlugin implementing JMS\Payment\CoreBundle\Plugin\PluginInterface) — that class is the package. Everything else is wiring.
• Check the composer.json require block for symfony/* and jms/payment-core-bundle version constraints. If they cap below Symfony 4/5, you already know the answer.

The one realistic first use case is maintaining a legacy Symfony 2/3 application that already uses JMS Payment for order → payment instruction → transaction flows, and you want Stripe as one more gateway behind the existing PluginInterface. In that scenario the steps are: register the bundle, add Stripe API keys to jms_payment_core config, tag the Stripe plugin service as payment.plugin, then create a PaymentInstruction and run it through PaymentCoreBundle's payment service.

For a Laravel developer specifically: do not start here. Reach for laravel/cashier for subscriptions or stripe/stripe-php directly for one-off charges. If you only want the patterns from this package (how a JMS plugin maps Stripe calls to approve/deposit/reverseDeposit), read it as a case study, not a library.

Implementation Patterns

Assume you're in the legacy-Symfony corner where this can still run. The integration shapes you'll actually use:

• Plugin-as-gateway pattern. Register the Stripe plugin as a service with the payment.plugin tag; JMSPaymentCoreBundle then dispatches approve(), deposit(), reverseDeposit(), and credit() calls to it during a PaymentInstruction lifecycle. Keep all Stripe SDK usage behind that plugin boundary — mixing direct \Stripe\Charge::create() calls into controllers defeats the abstraction and makes the payment state machine inconsistent.
• Instruction → transaction → status flow. Model each order as a PaymentInstruction, let the core bundle create FinancialTransaction records, and read back authoritative state from those rows rather than from the Stripe response object. This is the same discipline Laravel devs use with Cashier's subscriptions/transactions tables — let the DB be the source of truth.
• Two-step authorization/capture. If the plugin exposes approve and deposit separately, use it for auth-then-capture flows (reserve on checkout, capture on ship). If it only supports single-shot charges, don't fake an auth/capture — pick a different integration.
• Config-driven credentials. API keys should come from jms_payment_core config fed by environment variables, never hardcoded. Mirror this in Laravel by keeping keys in config/services.php reading from env().
• Test-mode gating. Use Stripe test keys with test card numbers and drive a full instruction through approve → deposit before touching live keys. Because this package almost certainly has no test suite, your integration test is the proof.
• Idempotency. Wrap Stripe calls with an idempotency key derived from your local transaction ID, so retries after a network error don't double-charge. This is not something JMS will do for you.

If you're adapting the ideas into Laravel, the closest equivalent is: a PaymentGateway interface (approve/deposit/refund), a Stripe implementation, an Eloquent model for payment_instructions and transactions, and queued webhook handling — which is essentially what Cashier already is.

Gotchas and Tips

• Framework mismatch is the headline gotcha. Symfony DI tags, bundle registration, and JMS's container expectations don't translate to Laravel. Budget real work if you try to bridge them; expect to rip out the bundle wiring and keep only the plugin logic.
• Abandoned upstream. JMSPaymentCoreBundle hasn't been maintained for years, and Stripe's API surface has moved on considerably (PaymentIntents, SCA/3DS, Stripe\Charge deprecation). Any code written against old Stripe endpoints may fail or route through legacy compatibility modes.
• Composer conflicts. Old Symfony and PHP constraints will likely collide with Laravel 10/11's symfony/* requirements. If composer require fights you, that's the package telling you it doesn't belong in your project.
• No webhooks by default. Don't assume the plugin handles payment_intent.succeeded or charge.refunded. Acknowledge Stripe events out-of-band (a signed webhook endpoint that updates your transactions rows) and make handlers idempotent.
• State drift. If the Stripe call succeeds but the local transaction write fails, you have a charged customer and no record. Insert a pending transaction before the Stripe call, then reconcile via webhook or a scheduled sweep.
• Debugging. Log the Stripe request ID and your local instruction/transaction IDs together — Stripe support will ask for the former, your DB queries need the latter. Never log full card data or secret keys; strip Authorization and payload PII.
• Zero community, zero safety net. With 0 stars, 0 dependents, and no recent activity, there is no one to ask when something breaks and no security advisories to warn you. Pin the version explicitly and be prepared to fork.
• Extension points are thin. The only real seam is your PluginInterface implementation — override approve/deposit there rather than patching vendor code, so a future fork or abandonment is survivable.
• Migration tip. If you inherit an app using this, isolate Stripe calls behind your own adapter, then swap the implementation to stripe/stripe-php (or Cashier, if you move to Laravel). That way the JMS layer is disposable and the migration is a class swap, not a rewrite.