Payment Stripe Bundle Laravel Package

Getting Started

This is a Symfony2 bundle, not a Laravel package. If you're in a Laravel codebase, the practical first step is to not install it and instead read it as a reference implementation for wiring JMSPaymentCoreBundle to Stripe. For a Laravel app, use stripe/stripe-php directly or Laravel Cashier; for a legacy Symfony2 app, proceed below.

Minimal setup for the intended environment:

composer require ruudk/payment-stripe-bundle

Enable the bundle in app/AppKernel.php alongside its required dependency:

$bundles = [
    new JMS\Payment\CoreBundle\JMSPaymentCoreBundle(),
    new Ruudk\Payment\StripeBundle\RuudkPaymentStripeBundle(),
];

Configure the API credentials. The exact key names should be verified against DependencyInjection/Configuration.php, but expect something close to:

# app/config/config.yml
ruudk_payment_stripe:
    api_key: "%stripe.secret_key%"
    publishable_key: "%stripe.publishable_key%"

Where to look first, in order:

1. Resources/config/services.yml — the gateway service ID and its dependencies.
2. DependencyInjection/Configuration.php — the real config schema.
3. The gateway class (likely Gateway.php or similar) — this is where the Stripe API call is made.
4. JMSPaymentCoreBundle docs/source — because this bundle is mostly an adapter; the payment instruction/payment state machine lives in JMS.

First real use case: create a PaymentInstruction via JMS, obtain the Stripe gateway from the container, and charge a Stripe token created client-side with Stripe.js v2:

$instruction = new PaymentInstruction(
    $amount,
    'EUR',
    'stripe'
);

$em->persist($instruction);
$em->flush();

$gateway = $container->get('ruudk_payment_stripe.gateway'); // verify service ID
$gateway->approveAndDeposit($instruction, $tokenFromStripeJs);

If you are on Laravel and only need Stripe, stop here: the day-to-day leverage of this repository is almost entirely as a historical reference.

Implementation Patterns

Service-container wiring. The bundle is designed around Symfony DI. Inject the gateway service into your controller/service rather than constructing Stripe clients yourself:

class CheckoutController extends Controller
{
    public function chargeAction(Request $request)
    {
        $gateway = $this->get('ruudk_payment_stripe.gateway');
        // ...
    }
}

JMS payment state machine. The intended workflow is JMSPaymentCoreBundle's, not Stripe's:

1. Create and persist a PaymentInstruction with amount, currency, and the stripe payment system name.
2. Client-side Stripe.js tokenizes the card and posts the token to your controller.
3. Call the gateway to approve/deposit, which performs the Stripe charge.
4. Persist the resulting Payment / CreditCard metadata via JMS.
5. Redirect to a success/failure route based on the gateway result.

Do not try to bypass JMS and call the gateway directly with a raw amount; the bundle expects the instruction/payment context to be populated.

Client-side token flow. This bundle predates PaymentIntents and SCA. The pattern it supports is the old “token then charge” flow:

<form action="{{ path('checkout_charge') }}" method="post" id="payment-form">
    <input type="text" data-stripe="number">
    <input type="text" data-stripe="exp-month">
    <input type="text" data-stripe="exp-year">
    <input type="text" data-stripe="cvc">
    <button type="submit">Pay</button>
</form>

<script src="https://js.stripe.com/v2/"></script>
<script>
Stripe.setPublishableKey('{{ stripe_publishable_key }}');
// submit handler -> Stripe.card.createToken(form, callback)
// inject returned token into a hidden input before POSTing
</script>

Testing pattern. Point the bundle at Stripe test keys and use the standard test card numbers. Because the gateway is a container service, you can replace it in the test container with a stub implementing the same interface, avoiding network calls in functional tests.

Integration tips.

• Keep the Stripe secret key out of config.yml; use Symfony parameters/environment-specific config.
• Put the charge call inside a transaction boundary that records your own order state first, then confirm payment; never rely solely on the Stripe response to mark an order paid.
• If you need custom behavior, decorate or override the gateway service rather than editing the bundle. The gateway class is the intended extension point.
• For webhooks, write your own controller; this bundle does not provide a complete webhook ingestion pipeline.

If you are porting to Laravel. Use the bundle as a map: the gateway class shows which Stripe SDK calls were used, and the JMS integration shows which fields were persisted. Reimplement that mapping against stripe/stripe-php PaymentIntents, and use Laravel's HTTP/queue infrastructure for webhooks. Do not attempt to run this Symfony2 bundle inside Laravel.

Gotchas and Tips

• Archived since 2016. There will be no fixes for modern Stripe API changes, PHP 8 compatibility, or security issues. Treat it as legacy-only.
• Symfony2 is end-of-life. This bundle assumes Symfony2 service definitions, AppKernel, and old container semantics. It will not drop into a Symfony 5/6/7 application without a rewrite.
• Old Stripe API model. The bundle predates PaymentIntents, Sources, and SCA/3DS. It cannot correctly handle European card payments requiring strong customer authentication. Do not use it for new commerce flows.
• Old Stripe PHP SDK. Expect pre-namespace classes such as Stripe_Charge rather than \Stripe\Charge. Modern stripe/stripe-php releases are namespaced and will conflict; check composer.json constraints before installing anything else Stripe-related.
• No webhook signature verification. Stripe's Stripe-Signature verification and idempotency keys are not part of this bundle's design. Any webhook endpoint you build around it must add those yourself.
• Config key names drift. The README may be stale. Always confirm the config root and keys in DependencyInjection/Configuration.php; a wrong key silently leaves the gateway unconfigured until the first charge fails.
• JMSPaymentCoreBundle is also legacy. Debugging often means tracing through JMS's payment instruction state transitions, not Stripe. If a charge fails, first verify the PaymentInstruction is in the expected state and the payment system name matches stripe.
• Error handling is thin. Stripe exceptions from the old SDK may surface as generic gateway exceptions. Log the raw Stripe error code/message at the gateway boundary so you can distinguish card declines from configuration failures.
• Debugging tip. Enable Stripe test mode and log the outgoing charge parameters (amount, currency, token, description) without logging the secret key. Most failures are currency/amount-format issues or reused tokens.
• Extension points. Override the gateway service ID in your app config, or decorate it, to add logging, retries, or custom metadata. Avoid forking the bundle unless you plan to maintain it.
• Migration advice. If this bundle is in production, isolate Stripe calls behind your own interface now. That makes the eventual move to PaymentIntents and a maintained SDK a service swap rather than a rewrite of the checkout flow.