- Is paypal/sdk-core-php a Laravel package?
- No. It is a low-level, framework-agnostic PHP library with no service provider, facade, config publishing, or container binding. It assumes a bootstrap or autoloader model and global-style configuration rather than Laravel's config repository and DI container. Using it in Laravel requires a bespoke adapter layer.
- How do I install paypal/sdk-core-php with Composer?
- You can install it with composer require paypal/sdk-core-php. However, its conventions predate PSR-4 and Composer-native autoloading and assume older PHP runtimes. Check for autoloader conflicts with Laravel's Composer setup and for Guzzle version collisions in the host application.
- Does paypal/sdk-core-php support Laravel 10 or Laravel 11?
- There is no official Laravel integration or tested support for modern Laravel versions. The package's conventions predate current Laravel architecture, so you would own the adapter, exception mapping, HTTP client wiring, and configuration surface. Do not assume it runs cleanly in Laravel 10 or 11 without sandbox verification.
- Is paypal/sdk-core-php still maintained?
- The available signals suggest it is effectively abandoned: zero stars, zero dependents, and a score of 0, with no upstream activity expected. PayPal has been actively sunsetting the classic APIs this library historically supported in favor of REST v2. Treat every bug, security advisory, and API change as your own patch.
- Does paypal/sdk-core-php work on PHP 8.1?
- Compatibility is uncertain because the library assumes older PHP runtimes. Risks include dynamic properties and removed syntax that can break under PHP 8.x. Verify behavior in PayPal's sandbox before committing, and expect to pin versions or carry local patches.
- What is paypal/sdk-core-php actually used for?
- It is the shared transport, credential, and configuration core that historically backed PayPal's classic merchant SDKs such as Express Checkout/NVP, Payflow, and Adaptive Payments. It is infrastructure rather than a complete modern payments client. For REST v2 Orders and Payments, use a maintained REST client instead.
- What should Laravel developers use instead of paypal/sdk-core-php?
- Prefer paypal/paypal-server-sdk, which is OpenAPI-generated and actively maintained, or call PayPal REST v2 directly through Laravel's Http client. Community wrappers such as srmklive/laravel-paypal exist, but evaluate their maintenance cadence before adopting. Keep a domain-level PaymentGateway contract so the transport can be swapped.
- How do I safely integrate paypal/sdk-core-php into an existing Laravel app?
- Adopt it only to sustain an existing classic-API integration, never as a direct call-site dependency. Introduce a domain interface such as a PaymentGateway contract with a single adapter implementation that isolates the SDK. That lets you replace the transport with REST v2 later without touching business logic.
- What is the migration path from paypal/sdk-core-php to REST v2?
- Inventory current PayPal usage, credentials, and endpoint coverage first. Freeze new feature work on the legacy path and add no new call sites. Introduce the gateway abstraction, build sandbox parity tests for the flows you depend on, migrate endpoint by endpoint behind the same interface, then decommission the legacy adapter and credentials.
- What production concerns come with paypal/sdk-core-php?
- There is no vendor support, documentation is stale or unavailable, and troubleshooting depends on community knowledge and archived references. The library lacks modern retry, idempotency-key, and connection-reuse primitives, so you must build those around it. Budget recurring engineering time for patching and expect higher mean time to resolution during incidents.