- How do I install srmklive/paypal in a Laravel app?
- Run composer require srmklive/paypal, then publish the configuration with php artisan vendor:publish --provider="Srmklive\PayPal\Providers\PayPalServiceProvider". Add your PayPal client ID, secret, and mode to config/paypal.php or your .env file. The package ships a service provider and a PayPal facade, so you can resolve the client from the container and start calling the REST API right away. As of 3.2.0 the ext-bcmath extension is no longer required, so most existing PHP images work without changes.
- Can I use srmklive/paypal without Laravel?
- Yes. The client used inside Laravel, Srmklive\PayPal\Services\PayPalClient, can be instantiated directly in plain PHP with no framework bootstrapping. You set the API credentials and call getAccessToken() yourself, then use the same order, subscription, invoice, payout, and dispute methods. That makes it usable in Symfony apps, CLI scripts, queue workers, or legacy codebases that do not run Laravel.
- Which PHP and Laravel versions does srmklive/paypal support?
- The 3.x line supports PHP 8.2 through 8.5 and Laravel 12 and 13. Older Laravel or PHP versions require pinning an earlier major release. It is an MIT-licensed community package maintained by blendbyte and is not affiliated with or endorsed by PayPal, so pin a version and read the release notes before upgrading.
- How do I configure PayPal API credentials for sandbox and live mode?
- Provide client_id, client_secret, and app_id under the sandbox or live key in config/paypal.php, and set mode to sandbox or live. A minimal config only needs credentials, since currency defaults to USD, locale to en_US, and validate_ssl to true. Keep secrets in your .env file rather than committing them, and make sure the selected mode matches the credentials you loaded so you never send live traffic to sandbox endpoints or the reverse.
- How do I create and capture a PayPal order with this package?
- Call createOrder() with an intent of CAPTURE or AUTHORIZE and a purchase_units array, then send the buyer to the approval link returned in the response. After approval, call captureOrder() with the order ID to take the payment. Always check the returned status and error payload instead of assuming success, and opt in with an idempotency key if your code may retry the capture.
- Does srmklive/paypal support subscriptions, billing plans, and catalog products?
- Yes. The Subscriptions service and BillingPlanBuilder cover creating catalog products, billing plans, and subscription lifecycle actions such as capture, suspend, cancel, and activate. These helpers cut down the raw payload building you would otherwise do by hand. Be aware that in 3.2.0 addTaxes() payloads are genuinely applied by PayPal, so avoid double-taxing buyers if your application already calculates tax itself.
- What PayPal APIs does srmklive/paypal cover?
- It covers Orders v2, Payments, Subscriptions, Billing Plans, Catalog Products, Invoicing, Payouts and Referenced Payouts, Reference Transactions, Disputes, and shipment tracking. Version 3.2.0 audited every request against PayPal's official OpenAPI specs, so payloads are far less likely to be rejected or silently ignored. Because the v1 Payments API sunsets in January 2027, new integrations should be built on Orders v2.
- Is upgrading to srmklive/paypal 3.2.0 a breaking change?
- No methods were removed and no required signatures changed, but the release is not drop-in because of its behaviour changes. Responses are now decoded arrays instead of JSON strings, errors on raw-body methods are decoded, Accept-Language is sent, taxes are actually applied, currency minor-unit handling is corrected, and send_recipient = false is respected. Audit any code that json_decode'd responses or worked around the old behaviour, and treat the tax and email changes as the highest-risk items before upgrading production integrations.
- Does srmklive/paypal support idempotency keys and safe retries?
- Yes. POST and PATCH requests are retried only on 5xx, 429, or timeout responses when a PayPal-Request-Id header is present, and you opt in through withIdempotencyKey(). That turns retry logic from a double-charge hazard into a supported feature. Use a stable, unique key per logical operation so a retried request is mapped back to the original instead of creating a second charge.
- How do I verify PayPal webhooks with srmklive/paypal?
- The package includes a Webhooks service for managing webhook endpoints and verifying notification signatures alongside the rest of the REST API surface. Verify every notification server-side and deduplicate on the event ID before fulfilling an order or activating a subscription. Treat webhook payloads as the trigger rather than the source of truth, and fetch the current resource through the API when you need authoritative state.