- Is omnipay/bitpay compatible with Laravel 10 or 11?
- The package is very unlikely to be compatible with Laravel 10 or 11 out of the box. It was last released in 2016 and its Composer constraints target older PHP, Omnipay, Guzzle, and Symfony versions. Modern Laravel dependency graphs usually conflict with those constraints unless you fork or isolate the package.
- How do I install omnipay/bitpay in a Laravel application?
- You can try composer require omnipay/bitpay, but installation may fail on current Laravel due to old dependency constraints. For modern apps, use the official BitPay PHP SDK or hosted checkout behind an internal payment interface instead. If you must use it, fork and pin compatible dependencies in an isolated service.
- Does this package support the current BitPay API?
- No, it is unlikely to support the current BitPay API. The driver predates significant BitPay changes to endpoints, authentication, invoice lifecycle, and webhook formats. Validate any use case against BitPay sandbox before committing, because old endpoints may be deprecated or incompatible.
- What PHP and Omnipay versions does omnipay/bitpay require?
- The driver targets an Omnipay 2.x-era stack and older PHP versions, roughly PHP 5.x to 7.x. It is not designed for Omnipay 3.x, PHP 8.x, or modern Guzzle and Symfony components. Check the repository composer.json for exact constraints, but expect to patch or fork.
- Can I use omnipay/bitpay for Bitcoin payments in production?
- Not recommended as-is for production. It has been abandoned since 2016, has low adoption, and lacks recent security or compatibility testing. Payment code requires signature validation, secret handling, and reconciliation logic that you must review and likely rebuild. Prefer the official BitPay SDK or hosted checkout for new integrations.
- Does omnipay/bitpay handle BitPay webhooks and invoice status?
- The driver likely supports only older invoice flows and may not handle current BitPay webhooks or IPN formats correctly. Invoice status polling, expiry, confirmation states, refunds, and partial payments require custom application logic and explicit testing. Treat webhook signature validation and reconciliation as unverified until tested against BitPay sandbox.
- What are alternatives to omnipay/bitpay for Laravel?
- The preferred alternative is the official BitPay PHP SDK or BitPay Checkout, wrapped in your own payment service interface. You can also implement a custom Omnipay gateway backed by the official SDK if you must keep Omnipay. Avoid reviving the old driver for new production work.
- Is omnipay/bitpay still maintained?
- No, omnipay/bitpay appears abandoned; the last release was in 2016. The repository has low adoption and no evidence of maintained CI or security patching. You should assume you will own any fixes, upgrades, and incident response if you adopt it.
- How do I test omnipay/bitpay with BitPay sandbox?
- You would need BitPay sandbox credentials and a time-boxed spike covering invoice creation, redirect, webhook, status polling, expiry, and refund behavior. Do not assume card-payment equivalence for Bitcoin amounts, precision, or confirmation semantics. Because the driver is old, expect to patch endpoints or authentication before tests pass.
- Can I fork or patch omnipay/bitpay for modern Laravel?
- Forking is possible under the MIT license, but it is not a drop-in fix. You must update BitPay endpoints, authentication, webhook handling, and dependency constraints, then isolate the fork in a separate service or container. Prefer replacing the driver with an internal adapter using the official BitPay SDK, or a custom Omnipay gateway backed by that SDK.