Is paypal/merchant-sdk-php a Laravel package?

No. It is a plain Composer library for PayPal's classic Merchant APIs and ships no service provider, facade, config file, or publishable assets. In Laravel you must write a thin adapter, such as a container binding that constructs the SDK service with credentials from config/services.php and a wrapper class your controllers depend on.

Does paypal/merchant-sdk-php work with PHP 8 and modern Laravel?

Not reliably. The last release was October 2017 and the repository is archived, so its older Guzzle and XML dependencies routinely conflict with PHP 8.x and current Laravel stacks. Realistically you will need to pin an old PHP runtime, fork and patch the SDK, or isolate it behind a separate service.

How do I install paypal/merchant-sdk-php in a Laravel application?

Install it with Composer, then create a small service provider that binds the PayPal service class into the container using credentials from config/services.php and environment variables. Do not reference SDK classes directly in controllers or domain models. Keep the SDK as an infrastructure detail behind your own gateway interface.

Which PayPal APIs does paypal/merchant-sdk-php support?

It provides generated service classes and typed request/response objects for the classic Merchant APIs, including Express Checkout, Payments Pro Direct Payment, Recurring Payments, and Adaptive Payments. These are legacy NVP and SOAP endpoints rather than PayPal's newer REST APIs. New integrations should use PayPal's REST or Checkout SDKs instead.

Is paypal/merchant-sdk-php still maintained?

No. The repository is archived, the last release was in October 2017, and there are no security patches, bug fixes, or compatibility updates. Any vulnerability in its HTTP transport or XML parsing becomes your responsibility to remediate by forking the code. Plan an exit strategy before adopting it.

Should I use paypal/merchant-sdk-php for a new PayPal integration?

No. PayPal recommends its REST and Checkout SDKs for new work, and classic APIs like Express Checkout and Payments Pro are no longer the preferred path. Adaptive Payments is already sunset. Start new integrations on paypal/checkout-sdk-php or the REST Orders and Subscriptions APIs.

How do I configure sandbox versus live credentials with paypal/merchant-sdk-php?

Credentials and endpoint selection are handled directly by the SDK service constructors, so you must build environment switching yourself. Read values from config/services.php and environment variables, then pass the correct sandbox or live endpoint when binding the service. Laravel config caching works fine as long as secrets are sourced from env at deploy time.

What are the alternatives to paypal/merchant-sdk-php?

For new development, use paypal/checkout-sdk-php or PayPal's REST APIs directly; Express Checkout maps to Orders v2, Payments Pro to Card Fields or Advanced Credit and Debit Card, and Recurring to the Subscriptions API. Omnipay PayPal drivers are another option for a framework-agnostic gateway abstraction. All are actively maintained and better suited to modern Laravel applications.

What PCI compliance risks come with Payments Pro via this SDK?

Payments Pro means card data transits your server environment, putting you in SAQ D scope unless you use hosted or tokenized flows. The SDK only serializes requests and does not reduce PCI scope for you. Confirm who owns card-data handling before shipping and prefer PayPal-hosted fields where possible.

How do I test paypal/merchant-sdk-php integrations in Laravel?

Automated coverage is hard because classic API sandbox behavior diverges from production and from REST sandbox tooling. Define a PaymentGateway interface, mock that in unit tests, and reserve a small set of contract tests for the sandbox. Keep SDK types out of your domain code so tests do not depend on the archived package.

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.

Merchant Sdk Php Laravel Package

paypal/merchant-sdk-php

PayPal's classic Merchant SDK for PHP lets you integrate Express Checkout, Payments Pro, Adaptive Payments, and related APIs using generated service classes. Best suited to legacy integrations, as PayPal now recommends the newer REST SDKs.

Deep Wiki

Context7

Deprecated in favor of:

Frequently asked questions about Merchant Sdk Php

Is paypal/merchant-sdk-php a Laravel package?: No. It is a plain Composer library for PayPal's classic Merchant APIs and ships no service provider, facade, config file, or publishable assets. In Laravel you must write a thin adapter, such as a container binding that constructs the SDK service with credentials from config/services.php and a wrapper class your controllers depend on.
Does paypal/merchant-sdk-php work with PHP 8 and modern Laravel?: Not reliably. The last release was October 2017 and the repository is archived, so its older Guzzle and XML dependencies routinely conflict with PHP 8.x and current Laravel stacks. Realistically you will need to pin an old PHP runtime, fork and patch the SDK, or isolate it behind a separate service.
How do I install paypal/merchant-sdk-php in a Laravel application?: Install it with Composer, then create a small service provider that binds the PayPal service class into the container using credentials from config/services.php and environment variables. Do not reference SDK classes directly in controllers or domain models. Keep the SDK as an infrastructure detail behind your own gateway interface.
Which PayPal APIs does paypal/merchant-sdk-php support?: It provides generated service classes and typed request/response objects for the classic Merchant APIs, including Express Checkout, Payments Pro Direct Payment, Recurring Payments, and Adaptive Payments. These are legacy NVP and SOAP endpoints rather than PayPal's newer REST APIs. New integrations should use PayPal's REST or Checkout SDKs instead.
Is paypal/merchant-sdk-php still maintained?: No. The repository is archived, the last release was in October 2017, and there are no security patches, bug fixes, or compatibility updates. Any vulnerability in its HTTP transport or XML parsing becomes your responsibility to remediate by forking the code. Plan an exit strategy before adopting it.
Should I use paypal/merchant-sdk-php for a new PayPal integration?: No. PayPal recommends its REST and Checkout SDKs for new work, and classic APIs like Express Checkout and Payments Pro are no longer the preferred path. Adaptive Payments is already sunset. Start new integrations on paypal/checkout-sdk-php or the REST Orders and Subscriptions APIs.
How do I configure sandbox versus live credentials with paypal/merchant-sdk-php?: Credentials and endpoint selection are handled directly by the SDK service constructors, so you must build environment switching yourself. Read values from config/services.php and environment variables, then pass the correct sandbox or live endpoint when binding the service. Laravel config caching works fine as long as secrets are sourced from env at deploy time.
What are the alternatives to paypal/merchant-sdk-php?: For new development, use paypal/checkout-sdk-php or PayPal's REST APIs directly; Express Checkout maps to Orders v2, Payments Pro to Card Fields or Advanced Credit and Debit Card, and Recurring to the Subscriptions API. Omnipay PayPal drivers are another option for a framework-agnostic gateway abstraction. All are actively maintained and better suited to modern Laravel applications.
What PCI compliance risks come with Payments Pro via this SDK?: Payments Pro means card data transits your server environment, putting you in SAQ D scope unless you use hosted or tokenized flows. The SDK only serializes requests and does not reduce PCI scope for you. Confirm who owns card-data handling before shipping and prefer PayPal-hosted fields where possible.
How do I test paypal/merchant-sdk-php integrations in Laravel?: Automated coverage is hard because classic API sandbox behavior diverges from production and from REST sandbox tooling. Define a PaymentGateway interface, mock that in unit tests, and reserve a small set of contract tests for the sandbox. Keep SDK types out of your domain code so tests do not depend on the archived package.

Popularity trends

Recorded values over time (once-a-day snapshots). Oct 8, 2026 – Nov 6, 2026

GitHub · stars

GitHub · forks

GitHub · watchers

Packagist · monthly downloads

Stars

232

Forks

200

Score

3.6

Score breakdown

Sum of components, capped 0–100. Halved if archived.

Stars

input: 232

+1.2
Forks

input: 200

+6.0
Open issues + PRs

input: 1

+0.1
Releases

input: 0

+0.0
Recency

input: 3314

+0.0
Issue opportunity

input: 1

+0.0
Laravel News mentions

input: 0

+0.0
Dependents

input: 0

+0.0

Archived: total halved

Total 3.6

License

NOASSERTION

Last release

Oct 10, 2017

Watchers

Open issues

Weaver

How can I help you explore Laravel packages today?

Conversation history is not saved when not logged in.

Add packages to context

No packages found.

robertmarney/lara-hierarchial-collections

simonschaufi/rule-doc-generator

emissaoja/emissaoja

blackbricksoftware/gravityforms-civicrm-form-processor

al-rahabi/fancy-crud

jinas/dhivatar-component

mltstephane/laravel-quality

bernskiold/laravel-talentlms

bernskioldmedia/laravel-form-architect

youbar/easy-crud

c-point-labs/laravel-hostyourai

dbravoan/dbcms-admin-theme-dbcms

dbravoan/dbcms-theme-db-cyber

dbravoan/dbcms-blocks-basic

dbravoan/dbcms-module-content-audit

dbravoan/dbcms-module-ai-assistant

paygate-to/paygate-php

padosoft/askmydocs-connector-base

defstudio/supercharged-carbon

bernskioldmedia/laravel-matomo