Libwebtopay Laravel Package

Product Decisions This Supports

• Build vs. buy for payments (regional): This is the vendor SDK for Paysera's Checkout API, so it directly collapses a "build" decision into "integrate and wrap." If Paysera is already the merchant/acquirer of record, this library is the cheapest path to collecting payments — no gateway abstraction to design from scratch.
• Payment method coverage as a conversion lever: The Checkout API aggregates many methods (bank links, cards, local methods). This supports roadmap decisions about which methods to surface at checkout, ordered by market, rather than building each bank integration individually — a months-long effort for a Baltics launch.
• Market/segment expansion gating: For a team evaluating entry into Lithuania/Baltics or a Paysera-heavy customer segment, this library is a cheap feasibility spike. A PM can timebox a two-day integration proof and use real conversion data before committing roadmap capacity to a region.
• Roadmap sequencing for checkout work: Because security parameter validation (signature/SS1/S2S checks on transferred and received data) is handled inside the library, "payment security hardening" can be deprioritized in the local backlog and redirected to the provider's scope — freeing engineering for checkout UX, retries, and reconciliation.
• Release-train planning for PHP modernization: Version lines matter for upgrade planning: ^1.6 (oldest supported), ^2.0 (new interface), ^3.0 (same interface, PHP 7.4 standards, strict_types, type hints). A PM can slot a "payments SDK upgrade" into a platform-maintenance sprint rather than treating it as a surprise.
• Buy-side vendor negotiation inputs: Knowing this is a single-vendor, low-adoption dependency (11 stars, no dependents) gives the PM leverage and clarity in commercial talks — support and roadmap requests go to Paysera, not a community, so SLA terms belong in the merchant contract.

When to Consider This Package

Adopt when:

• Paysera is your chosen/required payment provider (existing merchant account, settlement, or group relationship), and you need Checkout API access fast.
• Your target market is the Baltics/Lithuania, where Paysera's local method coverage is a genuine conversion advantage over card-only PSPs.
• Your stack is PHP 7.4+ (Laravel included) and your team can write a thin adapter — this is a plain PHP library, not a Laravel package: no service provider, no config publishing, no facade, no webhook scaffolding.
• You want the provider to own the cryptographic/security surface (request signing, response verification) rather than implementing it in-house.
• You can adopt via Composer on ^3.0 and avoid the all-in-one WebToPay.php drop-in, which fights Laravel's autoloading and PSR-4 conventions.

Look elsewhere (or plan to wrap heavily) when:

• Multi-PSP strategy is a near-term requirement. Locking a single provider's SDK into your domain layer is expensive to reverse; you want a provider-agnostic payment interface from day one with this as one adapter.
• Global or cards-first coverage is the goal — this SDK's value is concentrated in Paysera's regional method network.
• License compatibility is unresolved. LGPL-3.0 is copyleft; if you distribute a closed-source product or bundle binaries, get legal review before committing. Serving it server-side in a SaaS is typically fine, but confirm.
• You need official Laravel ergonomics — events, jobs, migrations, queue-backed webhook handling — since you'll build all of that. Budget 3–5 engineering days for the wrapper and test coverage, not zero.
• You depend on community velocity. 11 stars and zero dependents means no ecosystem answers: no blog posts, no Stack Overflow corpus, no third-party tutorials. Support is vendor-ticket-only.
• You need capabilities beyond basic checkout — subscriptions, marketplace/split payouts, multi-currency orchestration, or sophisticated dunning — verify these against Paysera docs before assuming this library covers them.
• Due diligence on quality is incomplete. The maturity signal is README + releases only; test coverage, CI status, and security disclosure policy are unverified. Run an engineering spike before it lands on the roadmap.

How to Pitch It (Stakeholders)

To executives: "This is the official Paysera SDK for taking online payments. It's a buy, not a build — it replaces what would otherwise be months of individual bank integrations with a single Composer dependency, and it puts payment security verification on the provider. For a Baltics launch it's the fastest credible route to revenue. Two caveats worth a decision from you: the license is LGPL-3.0, so legal needs a look if we ship closed-source binaries, and it's a single-vendor dependency with a small open-source footprint — so we should treat Paysera SLA terms as part of the commercial agreement, not the code as community-supported. Total incremental cost is small: roughly a week of engineering for a clean adapter and tests."

To engineering: "Plain PHP library, Composer-installable, target ^3.0 (PHP 7.4 baseline, strict_types, type hints) — same interface as 2.x, so no migration surprise. It is not a Laravel package: no service provider, config, facade, or webhook handling. Please do not require_once the all-in-one WebToPay.php; use the Composer autoload path and keep WebToPay::* calls confined to one adapter class behind our own PaymentGateway interface, so a second provider is additive rather than a refactor. The library validates security parameters on both outbound and inbound data — treat that as a boundary we own integration-testing for, not as a substitute for our own idempotency, logging, and reconciliation. Spike deliverables: sandbox end-to-end payment, callback verification test, failure/retry behavior, and a read of the source for test coverage and disclosure policy before we commit."