Weave Code
Weaver
Helps Laravel developers discover, compare, and choose open-source packages. See popularity, security, maintainers, and scores at a glance to make better decisions.
Feedback
Share your thoughts, report bugs, or suggest improvements.
Subject
Message

Php Sdk Laravel Package

wepay/php-sdk

View on GitHub
Deep Wiki
Context7

WePay APIv2 SDK for PHP

Frequently asked questions about Php Sdk
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.
Weaver

How can I help you explore Laravel packages today?

Conversation history is not saved when not logged in.
Prompt
Add packages to context
No packages found.
users-au/socialite-provider
twidpay/twid-logger
mrnewport/laravel-plaid
mrnewport/laravel-repo
mrnewport/laravel-docsign
mrnewport/laravel-stow
mrnewport/laravel-flow
mrnewport/laravel-priceable
mrnewport/laravel-nestedterms
fredmeng/laravel-apidoc-generator
itstructure/laravel-multilingual-tools
pdustdar/elasticsearch
markupai/php-sdk
rlacerda83/lumem-microservice-shipment
uni-method/symfony-lib
tacticmedia/scim-server-bundle
neika-ai/symfony-bundle
mattleads/agent-publishing-bundle
glavweb/framework-bundle
glavweb/extra-bundle