- Is netbull/mpay24-bundle a Laravel package or a Symfony bundle?
- It is a Symfony bundle, not a Laravel package. Its value is Symfony framework plumbing: a DI extension and configuration tree that bind merchant credentials to a configured mPAY24 client service for injection. There is no Laravel service provider, facade, or config publishing. On a Laravel stack it has no architecture fit, so treat the underlying mpay24/mpay24-php SDK as the real dependency.
- Can I use netbull/mpay24-bundle in a Laravel application?
- You technically could, but you should not. Bridging it would mean running a Symfony container inside Laravel for no gain, since the bundle only wires up a client you can instantiate yourself. Use the mpay24/mpay24-php SDK directly behind an internal PaymentGateway interface instead. Read the bundle source only as documentation of how mPAY24 expects its client to be configured.
- How do I install and configure netbull/mpay24-bundle?
- Install it with Composer and enable the bundle in your Symfony application's bundle registration, then supply your merchant credentials, endpoint, and sandbox or live environment settings through the bundle configuration. Because the package is a thin wrapper, most of the setup work is merchant-side rather than code: onboarding, KYC, sandbox credentials, and settlement configuration all happen with mPAY24 directly. Check the composer.json constraints before committing to a spike.
- Which Symfony and PHP versions does netbull/mpay24-bundle support?
- That is the critical unknown and must be verified in the package's composer.json before any evaluation. A bundle of this vintage plausibly pins Symfony 5 or earlier and PHP below 8.1, which would be dead on arrival for a current stack. Check the constraints alongside the last commit and release date. If the constraints are stale, the wrapper is not adoptable regardless of code quality.
- Does netbull/mpay24-bundle handle mPAY24 notifications and webhooks?
- The documented scope is configuration, service wiring, and authorization, capture, refund, and cancellation operations. Notification or webhook endpoint handling is not listed, so assume you must build the callback endpoint, idempotency, and reconciliation logic yourself. Confirm by reading the source before you plan around it. If the bundle adds nothing beyond service wiring and payment calls, its marginal value over the SDK is near zero.
- What payment operations does the bundle support?
- It exposes authorization, capture, refund, and cancellation, along with reusable payment and transaction objects and structured error handling for gateway responses. Those map to the typical authorize-then-capture lifecycle, with refunds and voids for post-sale adjustments. Anything beyond that, such as tokenization, 3DS flows, or retry logic, should be verified in the source rather than assumed. Even this payment surface sits in the transaction path, so bugs become reconciliation incidents.
- How do I switch between mPAY24 sandbox and live environments?
- The bundle advertises configurable credentials, endpoints, and sandbox versus live environments, so the switch is configuration-driven rather than code-driven. Keep separate credential sets per environment and never let live merchant data reach a sandbox-configured client. Validate the full authorize, capture, refund, and cancel cycle in sandbox against the current mPAY24 API version before go-live.
- Is netbull/mpay24-bundle actively maintained and safe for production?
- The adoption signals are weak: around 2 stars, 0 dependents, a composite score near 0.04, and no evidence of production use or a release cadence. That reads as a single-maintainer personal project with no community triage and no security response path. Because it sits in the payment-critical path, its maintenance status matters more than its code quality, and the thing you actually need patched is the mPAY24 SDK and gateway API, not the wrapper. The wrapper's maintenance status is worse than the dependency it wraps.
- How should I test an mPAY24 integration before going live?
- Test against mPAY24 sandbox credentials and exercise the full lifecycle your application will use: authorize, capture, refund, cancellation, and failure responses. Add explicit tests for request construction, idempotency keys, and status mapping, since those are the failure modes that turn into financial reconciliation incidents. Do not rely on the bundle for test coverage; it is a wrapper, and the behavior you must trust is the SDK and the gateway.
- What is the best alternative to netbull/mpay24-bundle?
- Use the mpay24/mpay24-php SDK directly behind your own PaymentGateway interface covering authorize, capture, refund, status, and notification handling. That removes the wrapper maintenance question entirely and keeps you tracking the only dependency that matters for security patches and API deprecations. On Symfony you may vendor or fork the bundle as a starting reference; on Laravel skip it. Separately, confirm mPAY24 is the right PSP commercially for DACH payment method coverage, fees, settlement currency, and SLA terms before writing code.