- Does michael/laravelpagseguro work with Laravel 9, 10, or 11?
- No. The package's composer.json pins era-appropriate constraints around PHP 7.x, Illuminate 5.x, and Guzzle 6, so Laravel 9, 10, and 11 will fail dependency resolution. You would need to fork the package, relax or upgrade those constraints, and test against your target Laravel and PHP versions. For a greenfield Laravel 9+/PHP 8.2 app, use PagBank's current SDK or a maintained gateway abstraction instead.
- How do I install and configure michael/laravelpagseguro in a Laravel app?
- Install it with Composer and register the package's service provider and facade if your Laravel version does not auto-discover them. Then publish or edit the package config and set your PagSeguro seller email plus the sandbox or production token, along with any app ID/key the package expects. You also need a public HTTPS endpoint registered as the notification URL so PagSeguro can send postbacks. Because it is a thin wrapper, checkout and transaction calls will mirror PagSeguro's session, transaction, and notification APIs.
- Is michael/laravelpagseguro still maintained and safe for production?
- Treat it as unmaintained: the last release was 2018-01-16, there is no PHP 8 support, and no security-patch cadence. Any vulnerability in its transitive dependencies, such as Guzzle or Illuminate, becomes your responsibility to remediate. If you must use it, fork or vendor it, pin it by commit hash, wrap it behind your own adapter, and set an explicit sunset date. Do not assume Packagist availability or upstream fixes.
- How do I handle PagSeguro payment notifications or webhooks with this package?
- The package wraps PagSeguro's notification API, but you should not rely on it as your reconciliation layer. Expose a public HTTPS endpoint, validate the notification code against PagSeguro before trusting it, and persist raw payloads in your own payment_events table with a uniqueness constraint to block replays. Respond quickly with a 2xx and do the heavy reconciliation asynchronously by querying the transaction status. The package's postback handling likely lacks duplicate protection, so idempotency is yours to add.
- Does the package support PIX, boleto, and credit card payments?
- It is a thin wrapper over PagSeguro's legacy REST/XML gateway APIs, so coverage is limited to the methods the package actually wraps. Boleto and credit card were core PagSeguro flows, but PIX support is not guaranteed in a 2018-era wrapper, so verify the source before committing. If a required method is missing, you will end up making raw HTTP calls to PagSeguro anyway. Confirm PIX, boleto, and card parity against your merchant account before adoption.
- Can I use this package for transparent checkout, and what PCI scope does that imply?
- Yes, transparent checkout is possible only if the wrapped API and your integration collect card data, which pulls cardholder data into your PCI scope and lands you in SAQ-D-adjacent territory. Redirect checkout keeps card entry on PagSeguro's hosted page and keeps you in SAQ-A. Decide redirect versus transparent before writing code, because it changes your compliance obligations, not just your UX. For most legacy Laravel 5.x estates, redirect is the lower-risk path.
- What credentials and sandbox setup do I need to test a PagSeguro integration?
- You need PagSeguro/PagBank seller credentials: the account email, a sandbox and production token, and the app ID/key if your flow requires it. Create a sandbox seller account, register a public HTTPS notification URL, and point the package config at the sandbox environment first. A proof of concept in the PagSeguro sandbox is achievable in days, not weeks, because the package's surface area is small. Do not start with production credentials.
- Is PagSeguro being retired in favor of PagBank, and should I still adopt this package?
- PagSeguro's legacy checkout and API surface has been superseded by PagBank, so confirm the exact deactivation timeline and endpoint status with the vendor before any commitment. That confirmation is a decision gate, not a footnote. For a greenfield build, do not adopt this package: use PagBank's current SDK/API directly or a maintained multi-gateway abstraction. For a legacy Laravel 5.4-5.8/PHP 7.1-7.4 estate with an existing PagSeguro relationship, it is viable only as a wrapped, pinned, short-horizon bridge with a sunset date.
- How do I prevent duplicate charges and safely retry failed payments with this package?
- The package has no idempotency keys on charge creation and only generic exception handling, so duplicate-charge protection is your job. Assign a unique order reference per charge attempt, enforce it with a database unique constraint or lock, and persist the gateway transaction ID before retrying. Make your webhook handler idempotent by storing notification codes and event IDs, and reconcile uncertain outcomes by querying the transaction rather than blindly re-charging. Wrap the facade in your own PaymentGateway adapter so retry and refund logic lives in one place.
- What are the best alternatives to michael/laravelpagseguro for Laravel?
- For new Laravel versions, use PagBank's current SDK/API directly, or a maintained multi-gateway abstraction with a PaymentGateway interface for authorize, capture, refund, handleWebhook, and reconcile. If you are stuck on a legacy Laravel 5.x app with an existing PagSeguro merchant account, fork or vendor this package behind your own adapter and keep raw request/response payloads in your own payments tables. Avoid direct facade calls outside the adapter so you can swap providers. Also check Packagist and GitHub for maintained community packages, but verify their PagSeguro/PagBank endpoint support before adopting.