- How do I install vrajroham/laravel-bitpay in a Laravel application?
- Install it with Composer using composer require vrajroham/laravel-bitpay, which pulls in the official bitpay/sdk as a transitive dependency. After installing, publish the package config file with the vendor:publish command so config/bitpay.php exists in your app. Then populate the BITPAY_* environment values and inject or alias the client where you need it. Because v6.0.0 is a semver-major release, verify the resolved PHP and Laravel constraints before installing on an existing project.
- Which PHP and Laravel versions does this package support?
- The package targets conventional Laravel applications on PHP 8.x and wraps the BitPay PHP SDK. The supplied release notes for v6.0.0 do not state the exact minimum PHP floor or Laravel major support, so check the composer.json constraints for the version you install. If you are upgrading from v5.3.0, run composer why-not vrajroham/laravel-bitpay 6.0.0 in a scratch branch to surface platform conflicts cheaply.
- How do I configure my BitPay credentials with laravel-bitpay?
- Configuration is handled through the publishable config/bitpay.php file plus BITPAY_* environment variables, keeping secrets out of source control. After publishing, diff the new config against any existing file so you can reconcile renamed or removed keys. Set the appropriate token and environment values for test versus production, and never commit live credentials. If you upgraded from v5.3.0, re-publish the config rather than assuming the old keys still apply.
- How do I create a BitPay invoice and get a payment URL in Laravel?
- Use the package's Laravel-idiomatic wrappers, typically accessed through the facade or an injected client, to create an invoice with the amount, currency, and order reference. The response from BitPay includes the hosted checkout URL you redirect the customer to. You can then retrieve the invoice later by ID to check its status. Keeping invoice creation inside a single injectable service keeps the payment boundary contained in your codebase.
- Does this package handle BitPay webhooks and signature verification?
- The wrapper covers webhook handling alongside invoice creation, invoice retrieval, refunds, and ledger and currency lookups. Whether signature verification is implemented, and whether its behavior changed in v6.0.0, is not documented in the supplied release notes. Inspect the webhook-related classes in the v5.3.0...v6.0.0 diff before relying on them. Always verify the IPN signature against the raw request body and treat unverified callbacks as untrusted.
- Is laravel-bitpay a full multi-gateway payment abstraction?
- No. It is a thin integration layer over the official bitpay/sdk and exposes a service provider, facade, config file, and wrapper methods rather than a driver interface or gateway contract. Adopting it couples your application code directly to BitPay and to this package's facade surface. That is a good fit for a monolith that only needs hosted crypto checkout, but multi-gateway architectures should define an internal payment port and put this package behind an adapter.
- What breaking changes are in v6.0.0 compared to v5.3.0?
- The supplied release notes contain no changelog beyond a link to PR #46 and the compare range, so the breaking surface is unverified. Plausible candidates for a major bump include a raised PHP floor, a bumped bitpay/sdk major, Laravel 10 or 11-only support, renamed config keys, changed facade aliases, and altered exception or webhook-signature behavior. Diff v5.3.0...v6.0.0 with priority on composer.json, the service provider, the config file, and any webhook or exception classes. Until that diff says otherwise, treat v6.0.0 as breaking.
- Can I handle refunds and currency or ledger lookups with this package?
- Yes, the wrapper exposes BitPay client operations for refunds plus ledger and currency lookups in addition to invoice creation and retrieval. These defer to the vendor SDK rather than bespoke HTTP calls against BitPay's REST API. Refunds still require the correct BitPay token and permissions on your account. Test the full lifecycle, including error paths, against a BitPay test token before going live.
- How should I test a BitPay integration in Laravel without touching production?
- Point the package at a BitPay test token and exercise the complete lifecycle: invoice create, invoice fetch, webhook receipt and verification, refund, and error paths. There is no evidence in the package notes of a CI matrix or integration tests against a BitPay sandbox, so do not assume the package's own test coverage protects you. Mock the client in unit tests and reserve sandbox calls for a small integration suite. Never run these flows against live credentials in CI.
- Is vrajroham/laravel-bitpay actively maintained and safe for production?
- It is a single-maintainer, low-cadence project, so bus factor and time-to-patch for upstream BitPay API or SDK changes are real considerations. BitPay has repeatedly revised its token model and API surface, and a wrapper pinned to a specific SDK generation can lag that churn. Pin production to a known-good version, record the resolved bitpay/sdk version as a baseline, and confirm the maintainer's support policy for prior majors. Also note that crypto settlement carries AML, KYC, and tax obligations that the package does not address; those remain your application's responsibility.