- How do I install socialiteproviders/paypal in a Laravel app?
- Install it with Composer by requiring socialiteproviders/paypal, which pulls in the socialiteproviders/manager package it depends on. Then register the PayPalProvider and the PayPalExtendSocialite event listener in your application. There are no migrations, routes, or published assets, so installation is just the dependency plus the two registrations. After that you call Socialite::driver('paypal') from your login controller.
- How do I configure the PayPal client ID and secret for Laravel Socialite?
- Add a paypal entry to config/services.php containing client_id, client_secret, and redirect, populated from matching .env values. Those credentials come from a REST app you create in the PayPal developer dashboard. The redirect URI in your config must exactly match one of the return URLs allowlisted on that PayPal app, or the handshake will fail. Sandbox and live environments use separate credentials, so configure both sets explicitly.
- Which Laravel and Socialite versions does socialiteproviders/paypal support?
- The package targets PHP 8.1 or newer alongside laravel/socialite ^5.x and socialiteproviders/manager ^4.x, which covers Laravel 9 through Laravel 11. Because it is a thin adapter over Socialite's AbstractProvider, it is additive and does not alter your existing auth stack. Check the 4.3.0 diff before pinning if you have tight constraints on Socialite or the manager package, since the empty changelog makes the release contents unverified.
- Where do I register the PayPal provider and SocialiteWasCalled listener?
- On Laravel 10 and earlier, add the provider and the PayPalExtendSocialite listener to the providers array in config/app.php. On Laravel 11 and later, register the provider in bootstrap/providers.php and wire the SocialiteWasCalled event listener in a service provider. The listener is what tells Socialite's manager to hand back a PayPal driver when you call Socialite::driver('paypal'). Missing either piece results in a driver-not-supported exception at runtime.
- Why is the PayPal user's email null after login?
- PayPal only returns an email address when you request the relevant scopes and the end user's account has a confirmed email. Without those scopes, the user detail response contains little more than an identifier. Downstream code that assumes email is always present will create null-keyed users or duplicate accounts, so treat the email field as nullable. Always fall back to the provider user ID for identity matching.
- Is "Log in with PayPal" the same as my PayPal Checkout app?
- No. Log in with PayPal is a distinct product from PayPal Checkout and is not enabled by default, so a working payments integration does not imply a working login integration. You must create a REST app in the PayPal developer dashboard and confirm that the login product is enabled for it. You should also verify PayPal's current roadmap for the product in your operating regions before making it an authentication dependency.
- Can I use socialiteproviders/paypal to accept PayPal payments?
- No, this package is strictly an OAuth 2.0 identity adapter that lets users sign in or link accounts through PayPal. It exposes authorization, token, and user-detail endpoints only, with no order, capture, or webhook handling. If payments are your only requirement, use a PayPal SDK or an Omnipay-style gateway instead. Adding this package for checkout functionality is the wrong tool.
- How do I link a PayPal account to an existing user without creating duplicates?
- Store the PayPal subject identifier alongside the local user rather than relying on email alone, since PayPal email may be absent or may match an existing local account. A dedicated social_accounts table with provider and provider_user_id columns scales better than adding oauth columns to the users table. Decide explicitly whether a matching verified email auto-links an account or requires the user to confirm while signed in. Auto-linking on an unverified claim is an account takeover risk.
- How do I test PayPal login in Laravel without calling the real PayPal API?
- Mock the Socialite driver in your feature tests, for example by faking the Socialite facade or swapping in a stub AbstractUser, so no HTTP request reaches PayPal. Assert the callback path handles both a populated email and a null email to cover the scope behaviour described above. The package itself ships minimal test coverage, so your own tests are the real safety net. Keep one manual sandbox smoke test, remembering that sandbox consent screens do not perfectly predict live behaviour.
- Is socialiteproviders/paypal actively maintained and safe for production?
- It is community-maintained as part of the SocialiteProviders split-package family, with a single-maintainer bus factor and no commercial support path. The 4.3.0 release ships an empty changelog with only a compare link and no major version bump, which suggests no intended breaking change but is not verification. Pin a specific version, diff 4.2.0 against 4.3.0 before upgrading, and review PayPal's own product status separately. The code risk is low; the vendor lifecycle risk around Log in with PayPal is the item to watch.