Smoney Bundle Laravel Package

Getting Started

Reality check first: this is a Symfony bundle, not a Laravel package, and it has zero stars, zero dependents, and an essentially dead ecosystem footprint. It wraps the legacy S-money (French wallet/payment provider) PHP client. Treat it as a reference implementation to copy, not a maintained dependency.

1. Install and inspect before wiring anything:

   composer require spyrit/smoney-bundle
   

   Then open vendor/spyrit/smoney-bundle/ and read, in this order:

   • DependencyInjection/Configuration.php — the actual config keys (client ID, secret, sandbox flag, endpoint URLs).
   • DependencyInjection/*Extension.php — how the services are constructed.
   • Resources/config/services.yml — the service IDs you'll need to mimic.
   • The underlying spyrit/smoney-api-client (or similarly named) package — this is where the real HTTP logic lives.

2. Do not attempt to register the bundle via Laravel's package discovery. Laravel has no bundle concept. You have two realistic options:

   • Port the client directly (recommended): instantiate the underlying S-money client in a Laravel service provider, bypassing the Symfony bundle entirely.
   • Boot the Symfony DI container manually inside a service provider (fragile, not worth it for a dead package).

3. First use case: initiating a payment. The typical flow is:

   • Configure credentials (client ID + secret + sandbox=true).
   • Create a "payment order" / "money transfer" object.
   • Redirect the user to the S-money hosted page (or receive a form token).
   • Handle the S-money callback (webhook) to confirm settlement.

Implementation Patterns

Service provider binding (the pragmatic path). Rather than pulling in the Symfony bundle, bind the raw client in a dedicated S-moneyServiceProvider:

// app/Providers/SmoneyServiceProvider.php
public function register(): void
{
    $this->app->singleton(SmoneyClient::class, function ($app) {
        return new SmoneyClient(
            clientId: config('services.smoney.client_id'),
            clientSecret: config('services.smoney.client_secret'),
            sandbox: app()->environment(['local', 'staging']),
        );
    });
}

Put the credentials in config/services.php under an smoney key and source them from .env — never hardcode. Follow the bundle's Configuration.php for the exact option names it expects; S-money used clientId/clientSecret/sandbox, but verify against the vendor source.

Payment initiation flow. Wrap the client behind an application-level service (e.g. App\Services\SmoneyGateway) that returns your own DTOs, not the vendor's objects. If S-money is ever replaced (Lydia, Mangopay, Stripe), only that adapter changes:

class SmoneyGateway
{
    public function startPayment(Order $order): PaymentRedirect
    {
        $response = $this->client->createPayment([
            'amount'      => $order->total_cents, // check units — likely cents
            'currency'    => 'EUR',
            'orderId'     => $order->reference,
            'returnUrl'   => route('smoney.return', $order),
            'callbackUrl' => route('smoney.callback'),
        ]);
        return new PaymentRedirect($response->redirectUrl, $response->token);
    }
}

Callback / webhook pattern. S-money callbacks are the authoritative source of payment state — do not trust the return URL redirect alone (a user can close the tab). Register a route, verify the payload, and update the order inside a transaction. Log the raw body before you parse it.

Facade for ergonomics (optional, if you're used to Laravel facades):

Smoney::startPayment($order);

backed by the singleton you registered above. Keep the facade thin — it's sugar over the gateway service.

Integration tip: if you're mixing Symfony components anyway, you're already using them — Laravel ships symfony/http-foundation and symfony/finder. But the bundle's own event dispatching (kernel.request, custom events) will not fire in Laravel. Any behavior relying on Symfony's event dispatcher must be reimplemented with Laravel events.

Gotchas and Tips

• It's a Symfony bundle for a Laravel app. There is no config/app.php providers array autoload, no ServiceProvider to rely on, no publishes() migrations. The bundle is effectively documentation for how to construct the client — plan on that.
• Package is abandoned (0 stars, 0 dependents, near-zero score). Assume no security patches, no PHP 8.3+ fixes. Pin exact versions in composer.json and audit the client source yourself before trusting it with money movement.
• Check whether S-money even exists anymore. S-money (Société Générale / Spyrit) has had a shrinking footprint. If the sandbox endpoints are dead, the whole exercise is academic — verify the API base URLs respond before building on them.
• Currency units. Payment APIs in this space almost universally take amounts in minor units (cents), not euros. Confirm in the client's Payment model. A silent ×100 error is catastrophic.
• Callback signature verification. The bundle may or may not implement HMAC/signature checks on callbacks. If it doesn't, implement your own verification against the shared secret — never process an unsigned callback.
• Idempotency. S-money uses an order/request ID to dedupe. Always send a stable ID derived from your own order (not uniqid()) so retries don't double-charge.
• Symfony DI config keys are not .env-aware. The bundle expects a config array; in Laravel you must translate your env() values into whatever argument names the client constructor takes. Read the constructor signature, not the YAML.
• Debugging: the bundle's logging is likely minimal. Wrap the HTTP client (Guzzle) with a Laravel middleware or a log tap that dumps request/response bodies to a dedicated log channel — but redact the client secret and any PAN-like data before logging.
• Extension points are Symfony-shaped. If the bundle registers event listeners or exposes @event_dispatcher, those hooks are inert in Laravel. Re-implement equivalent behavior with Event::dispatch() in your adapter.
• Test with a fake first. Because the vendor is untrustworthy, write a FakeSmoneyClient implementing the same interface and bind it in testing/local environments. You want to be able to run your checkout suite without hitting a possibly-dead sandbox.
• Consider replacing it. For a Laravel app doing real payments, a maintained gateway (Stripe, Mollie, Mangopay) with an actively maintained Laravel package is nearly always the better call than reviving a zero-star Symfony bundle. Use this package only if you're contractually locked into S-money.