Smoney Bundle Laravel Package

Product Decisions This Supports

• Payment vendor integration scoping. The bundle is a thin Symfony client wrapper around the S-money payment API. It informs a build-vs-buy decision only if S-money is already (or is being evaluated as) the payment service provider for payouts, wallets, SEPA transfers, or marketplace disbursements.
• Not a Laravel decision. Despite being filed under a PHP/Laravel package search, this is a Symfony bundle: it ships a bundle class, DI extension, and service definitions rather than a Laravel service provider and facade. Any Laravel use is an adaptation project, not an install.
• Roadmap input for legacy Symfony estates. The realistic use case is a Symfony application already contracted with S-money that needs a faster path to first API call (wallet creation, beneficiary/KYC submission, payment initiation) than hand-rolling HTTP.
• Migration and deprecation planning. With 0 stars, 0 dependents, and a near-zero health score, the package itself is a signal to verify whether the S-money API and account model are still actively supported before writing any roadmap line that depends on it.
• Scope reduction for an internal integration spike. At best it is a reference implementation: request shapes, auth handling, and endpoint coverage can shortcut a 1–2 day discovery spike, even if the code is ultimately replaced.

When to Consider This Package

Consider it only when all of the following hold:

• The application is Symfony (or you accept porting bundle wiring into Laravel service-container bindings), and its Symfony/PHP versions are compatible with the bundle's constraints — verify composer.json before anything else.
• You have an active S-money merchant contract and confirmed API credentials, sandbox access, and current API documentation from the provider.
• The scope is narrow and time-boxed: a proof of concept or an internal admin tool, not a PCI-adjacent, customer-facing checkout path.
• You are prepared to fork and own the code. With no stars, no dependents, and no visible community, treat upstream as frozen: no security patches, no PHP version bumps, no bug triage.
• Legal/compliance has cleared the vendor: confirm S-money's current corporate status, data-processing terms, and whether card data ever touches your servers (it should not).

Look elsewhere when:

• You are Laravel-first. Write a small, testable API client (Guzzle/Http facade plus a SmoneyClient service and config file) instead of importing Symfony bundle plumbing. Expect roughly 3–5 engineer-days for a focused client covering only the endpoints you actually call.
• There is no signed S-money agreement. Do not let an unmaintained 0-star bundle be the reason a PSP gets shortlisted.
• You need a supported SDK, SLA, or vendor-side troubleshooting. Use the provider's official libraries or a well-maintained PSP SDK (Stripe, Adyen, Mollie, GoCardless) instead.
• The payment flow is revenue-critical. An unmaintained dependency in the money path is an availability and audit finding waiting to happen.
• You need tokenized cards, 3-D Secure, or webhook signature verification — confirm the bundle covers these at all before assuming it does.

How to Pitch It (Stakeholders)

To executives: This is a small, unmaintained open-source wrapper for a single French payment provider. It is not a platform decision and carries no license cost, but it also carries no support, no security updates, and effectively no user base. Recommendation: do not adopt it as a dependency. If S-money is already our processor, fund a short internal spike to evaluate the API directly; if it is not, this package should not influence PSP selection. The real decision on the table is which payment provider we standardize on, and that should be driven by commercial terms, coverage, and support — not by a 0-star bundle.

To engineering: It is a Symfony bundle, so Laravel teams get no service provider, no config publishing, and no facade — plan on a port. The code is useful as documentation of request/response shapes. Proposal: fork it into internal/smoney-client or, preferably, write a ~300-line client against the current API docs with contract tests and typed DTOs. Budget 3–5 days, plus a half-day to verify the provider's API is still live and versioned. Gate any merge behind static analysis, PHPUnit coverage of the payment and refund paths, and an explicit owner in CODEOWNERS so it does not silently rot.