Weave Code
Laravel Omnipay Laravel Package
ignited/laravel-omnipay
Laravel integration for the Omnipay payment library, giving you a clean, unified API to accept payments through PayPal, Stripe, Authorize.Net and dozens of other gateways. Configure drivers in Laravel, then purchase, authorize, capture, refund, and handle callbacks from one consistent interface.
Ignited Laravel Omnipay integrates the Omnipay payment processing library into Laravel, giving you a clean, consistent API for working with multiple payment gateways. It provides a service provider, facade, and publishable configuration, making it easy to configure gateways and handle payments within Laravel applications.
- Unified purchase, authorize, capture, and refund workflows
- Supports many Omnipay gateways, including PayPal, Stripe, and Authorize.Net
- Laravel-friendly configuration and facade access
- Publishable config for managing gateway credentials
- Simplifies multi-gateway payment integration
Frequently asked questions about Laravel Omnipay
- How do I install ignited/laravel-omnipay in a Laravel application?
- Install it with Composer, publish the package config to config/omnipay.php, and add your gateway credentials there. The service provider is auto-discovered on modern Laravel and binds each configured Omnipay gateway into the container, so you resolve it through the Omnipay facade and call standard Omnipay methods such as purchase() and refund(). Most developers reach a working sandbox transaction in under a day; the real friction is Composer constraint resolution, not the code.
- Which Laravel, PHP, and Omnipay versions does this package support?
- Treat the support matrix as something to verify rather than assume: read the composer.json constraints and check whether CI actually tests those combinations. The package is a thin adapter, so its real API surface is the Omnipay major version it pins, and Omnipay v2 and v3 differ materially in how gateways are constructed and called. Your Laravel version, PHP version, and Omnipay major all have to line up before you bet a payment flow on it.
- Can I use multiple payment gateways, like Stripe and PayPal, in one Laravel app?
- Yes, multi-gateway support behind one interface is exactly the use case this package targets: you declare several gateways in config/omnipay.php and resolve the one you need from the container at runtime. The risk is not the wrapper but dependency resolution, because two gateway packages can pin conflicting Omnipay or Guzzle versions. Confirm that the specific gateway drivers you need resolve together against a single Omnipay major before committing to the design.
- What is the difference between laravel-omnipay and Laravel Cashier?
- Cashier owns subscription billing on a specific provider, including proration, dunning, invoices, and a hosted billing portal. laravel-omnipay is a configuration and dependency-injection wrapper around Omnipay that gives you one consistent API across many payment service providers. Choose this package when gateway portability is the actual requirement, and choose Cashier when recurring billing logic is.
- Does laravel-omnipay handle subscriptions, proration, and dunning?
- No. The package only wires Omnipay gateways into Laravel's container and facade, so subscription lifecycles, proration, retries, dunning emails, and invoice generation are all yours to build or to delegate to a provider that offers them. If recurring revenue is the core of your product, this is the wrong layer to solve it at and Cashier or the PSP's own billing product is a better fit.
- Does laravel-omnipay cover SCA, 3DS2 challenges, and webhook verification?
- No. Strong Customer Authentication challenge flows, idempotency keys, webhook and notification signature verification, replay handling, partial refunds, tokenization, minor-unit currency handling, and reconciliation are not provided by the wrapper. Those are the areas where payment incidents actually originate, so plan for them explicitly. On the browser side you will still need hosted fields or the provider's JavaScript SDK to keep a PCI SAQ-A posture.
- How does laravel-omnipay behave with php artisan config:cache and credential rotation?
- Gateway definitions live in config/omnipay.php, so config:cache works as it does for any Laravel config file, but cached config is frozen until you re-cache it. That means rotating PSP credentials may require a redeploy or an explicit config:cache run unless you resolve secrets at runtime. Test both paths in staging before relying on them in production.
- Is ignited/laravel-omnipay safe and actively maintained enough for production?
- Be cautious. The signals are mixed: a healthy star count against zero Packagist dependents suggests popularity is unverified, and it is a single-maintainer wrapper over a fast-moving framework with an MIT license and no visible security disclosure policy. Pin your versions, confirm issue-response history, and build one reference implementation before putting a revenue path behind it. Note also that it is replaceable with roughly thirty lines of your own service-provider binding if it ever stalls.
- Can I use laravel-omnipay with Lumen?
- Yes, the package describes itself as Omnipay for Laravel and Lumen and is designed to work in both. In Lumen there is no package auto-discovery, so you register the service provider manually and enable facades if you want the Omnipay facade. Configuration loading and the config/omnipay.php layout also need to be set up the Lumen way.
- How should I test payments without hitting a real gateway?
- Test at the Omnipay layer, since the wrapper adds no test helpers of its own: use each gateway's test mode or Omnipay's mock gateway to simulate purchases, refunds, and failures in your suite. Keep sandbox credentials in your test environment and assert on the Omnipay response objects rather than on facade internals. Also add integration tests for idempotency and webhook replay handling, because those are not supplied by the package.
Weaver
How can I help you explore Laravel packages today?