Architecture fit. OmniPay is a framework-agnostic PHP payment abstraction: a gateway class, a request/response pair per operation, and a common HTTP transport (Guzzle). It is a library, not a Laravel package — there is no service provider, no publishable config, no facade, no queue/event integration. That is workable in Laravel, but the TPM should plan for a thin first-party adapter (a PagSeguroGateway service bound in a service provider, config in config/services.php or a dedicated file) rather than assuming this drops in. It fits best where the application already treats payments behind an interface or already uses OmniPay; it is a poorer fit for a team expecting a Cashier-style, Laravel-native experience.
Integration feasibility. Mechanically straightforward: composer require abdala/omnipay-pagseguro, register the gateway with league/omnipay's GatewayFactory or OmniPay::create(), supply PagSeguro credentials (account email + API token; sandbox vs. production endpoints), call purchase()/authorize()/capture() or redirect to hosted checkout, and handle PagSeguro's notification callback (notificationCode → transaction lookup). The real integration cost is not composer — it is the surrounding Laravel work: credential/config management per environment, a webhook controller with idempotency, status mapping to an internal enum, and reconciliation. Feasible in a 1–2 sprint spike.
Technical risk. Material, and consistent with a 0.485 score. Last release March 2020, ~25 stars, and the repository is not resolvable — the source cannot be audited, there is no issue tracker, CI, security policy, or visible maintainer activity. Specific risks: unverified PHP 8.1–8.3 / Laravel 10–11 compatibility; OmniPay 3.x version-constraint drift; PagSeguro's migration to PagBank APIs and the eventual deprecation of legacy endpoints; and almost certainly no support for Pix, installments nuances, or newer 3DS flows (Pix launched in late 2020, after this release). MIT licensing is the one unambiguous positive — fork-and-patch is legally clean. Amount formatting (decimal BRL strings, not cents) and Brazil-specific fields (CPF/CNPJ, shipping) are common sources of defects.
Key questions.
acceptNotification() correctly, including signature/authenticity validation?Fit. Introduce the package behind an internal PaymentGateway interface and keep OmniPay classes out of domain code. Concretely: a service provider binding a configured gateway instance, a PagSeguroService translating domain commands into OmniPay requests, response mappers converting OmniPay responses and PagSeguro status codes into internal enums, and a webhook controller that resolves notificationCode to a transaction and dispatches a queued job. This makes the package a swappable implementation detail — the single most important architectural decision given the maintenance risk.
Migration path. Do not replace an existing provider in one step. Stand the gateway up in sandbox behind a feature flag, run it in shadow/dual-run mode against real order flows without charging, then pilot with a low-value cohort. If the team is currently on PagSeguro's official SDK, wrap this package in the same interface so the SDK remains a fallback. If there is no current provider, ship hosted checkout first (lower PCI scope, less surface area) before considering transparent checkout.
Compatibility. Pin exact versions in composer.json and verify the matrix explicitly: PHP 8.1/8.2/8.3 × Laravel 10/11, plus league/omnipay v3 and omnipay/common constraints. Expect to fork under a vcs repository and patch for PHP 8 deprecations — budget for it rather than discover it in production. Add a contract test suite against PagSeguro sandbox so a fork stays honest.
Sequencing.
Maintenance. Assume ownership. This is effectively a vendored dependency: pin it, fork it, add it to dependency-update automation, and run static analysis/security scanning against the fork. Schedule an annual (or per-Laravel-major) compatibility review, and track PagBank API deprecation notices as a standing risk item. Treat any upstream release as a review event, not an auto-merge.
Support. There is no vendor. Support is: community GitHub (unverifiable), PagSeguro/PagBank merchant support for API and account issues, and internal on-call for everything in between. Write a runbook covering credential rotation, sandbox/production config drift, and "payment stuck pending" triage before go-live.
Scaling. OmniPay itself is stateless per request and scales horizontally with the app; there is no shared state or connection pool to worry about. The real constraints are PagSeguro API rate limits, upstream latency/timeouts, and webhook delivery reliability. Process notifications asynchronously on a queue with idempotency keys, and run a scheduled reconciliation job that polls pending transactions — never rely on notifications alone.
Failure modes. Duplicate or out-of-order notifications; silently missed notifications (requires reconciliation); upstream timeouts leaving ambiguous order state; credential expiry or rotation; amount/currency formatting defects; unmapped PagSeguro status codes; breaking changes in the legacy API; PHP/Laravel upgrades breaking the unmaintained package; and the product-level risk that Pix and modern installment flows are simply absent. Each needs an explicit detection and mitigation path.
Ramp-up. Low-to-moderate engineering ramp (roughly 2–5 dev-days to become productive with OmniPay's request/response model and PagSeguro's credential and notification flow), but a real domain ramp: Brazilian payment conventions (CPF/CNPJ, parcelamento, boleto, Pix), sandbox quirks, and PCI scope decisions. Budget for a payments-literate owner, not just a Laravel developer — that person is also the one who should own the keep/fork/migrate decision gate.
How can I help you explore Laravel packages today?