- Is wepay/php-sdk compatible with Laravel 10 or Laravel 11?
- No, not out of the box. The published package targets a 2017-era PHP toolchain and Composer constraints that conflict with Laravel 9+ and PHP 8.1+. You would need an internal compatibility fork that rewrites composer.json constraints and modernizes the transport before it can install alongside Laravel 10 or 11.
- Does wepay/php-sdk include a Laravel service provider or facade?
- No. It is framework-agnostic PHP with no Laravel service provider, facade, config publishing, or container bindings. You can wrap it in your own service provider and facade, but it will not behave like a first-class Laravel package without that extra work.
- How do I install wepay/php-sdk in a Laravel project?
- A direct Composer install is unlikely to succeed in a modern Laravel app because of old dependency constraints. The realistic path is to fork the SDK under an internal namespace, update its composer.json for current PHP and Guzzle versions, and then require that fork. After that you can add your own service provider, config file, and facade.
- What PHP versions does wepay/php-sdk support?
- The package targets a 2017-era PHP toolchain and has no PHP 8 support. Modernizing it requires adding PHP 8 return types and strict types, replacing deprecated Guzzle APIs, and auditing request signing and error handling. Treat PHP 8.1+ compatibility as fork work, not a supported feature.
- Is wepay/php-sdk still maintained?
- No. The last release was January 2017, it has roughly 56 stars, and there is no active maintainer. WePay was also acquired by JPMorgan Chase in 2017 and folded into Chase's payment rails, so upstream API v2 documentation and sandbox access may be inconsistent or gated. Adoption should be treated as a risk-acceptance decision.
- Can I use wepay/php-sdk with Guzzle 7 or Laravel's HTTP client?
- No. The SDK transport is tightly coupled to an older Guzzle major version and will not interoperate with Laravel's HTTP client without rewriting the request layer. Partial upgrades are not realistic, so either fully fork and modernize the SDK or re-implement the small API surface on Illuminate\Support\Facades\Http or Guzzle 7.
- Should I fork wepay/php-sdk or rewrite the WePay integration in Laravel?
- In many cases a rewrite is cheaper because the SDK surface is small: accounts, checkouts, credit cards, subscriptions, disputes, and refunds. A thin client on Laravel's HTTP client removes an unmaintained dependency and gives you clean retry, idempotency, and exception handling. Fork only if WePay is contractually mandated and your team can own maintenance with a clear SLA.
- How should I handle WePay configuration and secrets in Laravel?
- If you fork the SDK, bind it as a singleton in a WePayServiceProvider and publish a config/wepay.php file for client_id, client_secret, access_token, and environment. Route live merchant secrets through Laravel's encrypted config or an external secret manager rather than production .env files. Add exception translation, retry and backoff middleware, and idempotency keys on create operations.
- What are the security and PCI concerns with wepay/php-sdk?
- The package has an roughly eight-year security and dependency-patching gap, no PHP 8 support, and no PSR-18 or PSR-17 compliance. You must assess PCI DSS implications for how card data flows through the SDK, especially direct card capture versus tokenized credit_card_id usage. Keep raw card data out of your application where possible and audit the request-signing and error-handling paths before production use.
- What are the alternatives to wepay/php-sdk for Laravel?
- The most practical alternative is a thin Laravel HTTP client implementation that calls the WePay API v2 endpoints you actually use, such as checkout create, refund, account, and credit card operations. Because WePay v2 may be deprecated under Chase, also put a PSP abstraction layer in place so you can exit the legacy rail. A maintained internal fork is the fallback only when WePay is a mandated payment rail.