Weave Code
Weaver
Helps Laravel developers discover, compare, and choose open-source packages. See popularity, security, maintainers, and scores at a glance to make better decisions.
Feedback
Share your thoughts, report bugs, or suggest improvements.
Subject
Message
Payment Be2Bill Bundle

Payment Be2Bill Bundle Laravel Package

rezzza/payment-be2bill-bundle

A Symfony bundle for integrating the Be2bill payment gateway via Rezzza’s Payment Be2bill library. It provides configuration and service wiring to add Be2bill payments and transaction handling to PHP applications.

View on GitHub
Deep Wiki
Context7

Payment Bundle providing access to the Be2bill API

Frequently asked questions about Payment Be2Bill Bundle
Does rezzza/payment-be2bill-bundle work with Laravel?
No. It is a Symfony bundle built around a DI extension, a configuration tree and compiler passes, with no service provider, facade or publishable config, so Laravel package discovery registers nothing useful. The genuinely reusable code is the framework-agnostic Be2bill client and its parameter/response models underneath the bundle. Plan to wrap those in your own Laravel gateway service rather than loading the bundle.
Can I composer require rezzza/payment-be2bill-bundle in a Laravel 9, 10 or 11 app?
Mechanically it may resolve, but the 1.x line pinned PHP 5.6/7.0-7.1, Symfony 2.x/3.x and old PSR-7/Guzzle packages, which will not install alongside Laravel 10/11 (PHP 8.2+, Guzzle 7, Symfony 6/7). The 2.0.0 major bump is the conventional signal that those constraints were relaxed, but the release note does not state it, so read the tagged composer.json yourself. Even when it resolves, you are pulling in Symfony bundle machinery your Laravel app never uses. Requiring the underlying client directly is the cleaner path.
Which parts of the bundle can I actually reuse in a Laravel integration?
The reusable assets are the plain-Composer Be2bill client wrapper, the request-signing and payload construction code, the Be2bill parameter/response models, and the notification hash verification classes. All of that is framework-agnostic and binds cleanly to a Laravel service provider or a small gateway class. The Symfony layer itself - extension, config tree, compiler passes - has no Laravel equivalent and should be dropped. Because 2.0.0 may have changed signing or hashing, re-validate the wire format instead of porting 1.x assumptions.
How do I handle Be2bill server-to-server notifications in Laravel?
Reuse the notification verification logic to recompute and compare the provider hash against the raw request body, then return the acknowledgement Be2bill expects. In Laravel, expose it on a route outside CSRF protection (api middleware or a VerifyCsrfToken exception), read the raw input rather than the parsed request, and make the handler idempotent on transaction id. Since the 2.0.0 PR may have touched hashing or signing, test against real sandbox notifications rather than trusting a ported implementation.
Does this package support 3DS2 and SCA under PSD2?
The reviewed material does not confirm that the 2.0.0 client emits 3DS2/SCA parameters, and a version bump does nothing to answer that question. If it does not, European card payments will be declined or degrade into issuer friction regardless of code quality. Check the PR diff and client code for authentication fields and confirm requirements with Be2bill/Ingenico for your merchant country and card mix before committing to the package.
What changed in version 2.0.0 and is it a breaking change?
2.0.0 is a major bump published roughly seven years after the previous release and described only by a bare PR link, with no changelog or upgrade guide. A major version implies breaking changes, and in payment code the likely candidates are signature construction, parameter naming, endpoint paths, or the Guzzle/PSR-18 interface. Read the PR diff rather than inferring compatibility from the version number, because any of those changes silently invalidates a ported 1.x integration. Treat the lack of a documented delta as a risk in itself for payment-path code.
How do I configure sandbox versus production mode and test payments?
The bundle exposes credentials and a sandbox/production switch through Symfony configuration, which in Laravel you would replicate with config values and environment variables in your own gateway wrapper. For testing, point at Be2bill's sandbox endpoints with test merchant credentials and assert on the signed payload your code builds. Be aware that tests added in the modernization PR may only mock the HTTP layer, which proves nothing about provider conformance, so run at least one real sandbox flow per payment path, including the notification round trip.
Should I use the hosted payment page or the direct API, and what PCI scope results?
The bundle supports hosted pages, iframe and direct-API modes, and that choice drives your PCI scope. Hosted-page or iframe redirect keeps card data off your servers, which generally keeps you in SAQ-A or SAQ-A-EP. Direct API pulls card data into your environment and expands scope substantially. Your Laravel integration has to make that call explicitly, since the package supports both and does not decide it for you.
Is this bundle maintained enough to trust with production payments?
Adoption is effectively zero, there is no fork ecosystem and no production evidence beyond the original author, and one modernization PR does not constitute a maintenance cadence. A major release with no changelog, no CVE triage, no dependency currency policy and no disclosure process is a weak signal for code handling money. If you adopt it, fork it, pin the client version, and define your own patching SLA and owner. Treat it as a starting point rather than a dependency whose trust you can outsource.
Are there better alternatives for Be2bill payments in a Laravel application?
First check whether Be2bill/Ingenico (Dalenys) now ships an official SDK, and whether a maintained Omnipay driver covers Be2bill, since either would supersede this Symfony bundle for a Laravel codebase. If neither exists, wrapping the underlying Rezzza client in a thin Laravel gateway service is the lowest-risk route. Keep that abstraction provider-agnostic so swapping PSPs later is a config change, not a rewrite. Whichever option you pick, verify SCA support and notification verification before going live.
Weaver

How can I help you explore Laravel packages today?

Conversation history is not saved when not logged in.
Prompt
Add packages to context
No packages found.
uni-method/symfony-lib
tacticmedia/scim-server-bundle
neika-ai/symfony-bundle
mattleads/agent-publishing-bundle
glavweb/framework-bundle
glavweb/extra-bundle
glavweb/api-bundle
glavweb/admin-bundle
adachsoft/api-version-bundle
elsayed85/laravel-api-exceptions
ouhssini/laravel-demo-mode
daworks/ncloud-outbound-mailer-driver
gp247/cms
ignibyte/aic-gates
nexa-merchant/blog
novasa/laravel-language-center
opencage/geocode
adolfoholzer/parameters
livenetworks/ln-starter
shitoudev/permissionmanager