Paypal Pro Checkout Nvp Laravel Package

Product Decisions This Supports

• On-site card acceptance vs. hosted redirect. This package is the concrete implementation of a checkout UX decision: taking raw card fields on your own page via PayPal Payments Pro (NVP DoDirectPayment) instead of redirecting to PayPal. Choosing it commits you to a materially larger PCI scope (SAQ D-ish) than Smart Buttons / Express Checkout (SAQ A). That trade-off should be made deliberately, not as a side effect of picking a library.
• Payment gateway architecture: adapter vs. platform. This is a ~thin Payum gateway adapter, not a payments platform. It supports a "buy/borrow the glue, own the orchestration" decision if you are already standardized on Payum GatewayInterface, Capture/Authorize actions, and token-based flows.
• Legacy merchant-account retention. The only genuinely strong use case: you already hold a PayPal Payments Pro merchant account, you already run Payum, and you need card capture wired up with minimal work. It supports a "sweat the existing contract for one more cycle" decision.
• Roadmap input: NVP → REST migration. The package's existence and its freeze date (last release 2016-09-16) are a signal to schedule a payments modernization track — PayPal's strategic direction is REST APIs / Advanced Credit and Debit Card payments and Braintree, not NVP. Treat this as a bridge, and put the bridge's end date on the roadmap at the same time you adopt it.
• Feature scoping guardrail. Because it is a narrow adapter with 3 stars, 0 dependents, and no release in roughly a decade, it does not support decisions about 3DS/SCA, wallets (Apple Pay / Google Pay), vaulting beyond Payum's token model, partial captures, or multi-currency edge cases. Do not let it anchor those conversations.
• Build vs. buy, honestly scored. Opportunity score ~51 with a health signal of 0.135 and zero dependents means: cheap to integrate, expensive to depend on. It supports a "fork-and-pin" decision rather than an "add a dependency" decision.

When to Consider This Package

Consider it only when all of these are true:

• You are already running Payum in production and have an established action/token/GatewayFactory pattern you do not want to break.
• You hold a live PayPal Payments Pro (NVP) merchant account and are contractually or commercially committed to it for the near term.
• You need direct card capture in a small, bounded surface — a single checkout path, a limited set of currencies and countries where Pro is supported.
• You have accepted that you will vendor the code into your repo, pin the version, and own security patches, because upstream is dormant.
• You have verified version compatibility against your current Payum core — a 2016-era extension may not satisfy modern PHP/Payum constraints, and that alone can disqualify it.

Look elsewhere when any of these are true:

• New build. Start on PayPal's REST APIs (or Braintree) directly, or use a maintained Payum gateway if you must stay in the Payum ecosystem. Integrating a frozen NVP adapter into a greenfield product is a decision you will repay later.
• You need SCA/3DS, wallets, or modern fraud tooling. Not in scope here.
• You want a maintained dependency. 3 stars, 0 dependents, no release since 2016 is the definition of "no community safety net." No CVE response, no PHP version bumps, no PayPal API changes absorbed for you.
• You want to minimize PCI burden. Hosted fields / redirect flows are the cheaper compliance path; this package is the opposite.
• Your team has no Payum fluency. You would be paying the Payum learning curve and inheriting an unmaintained adapter — the worst of both.
• Payments are a core differentiator. For a revenue-critical path, pick a vendor with a support contract or a library with active maintenance and a real dependent graph.

How to Pitch It (Stakeholders)

One line: A small, MIT-licensed Payum adapter for PayPal Payments Pro that will get card payments working quickly if we are already on Payum and already have a Pro merchant account — and that we should treat as tactical, self-maintained glue rather than a strategic dependency.

For executives: The integration cost is low and the license is permissive, but the maintenance risk is high — the project has had no release since 2016, three stars, and zero downstream dependents, which means nobody else is stress-testing it and no one will patch it for us. Adopting it is a bet that our PayPal Pro relationship outlives our need for modern checkout features like 3-D Secure, wallets, and the REST API. My recommendation: fund it only as a short bridge with an explicit exit date tied to a NVP → REST migration, and budget a small amount of engineering time for fork ownership. If the question is "should this be our payments foundation," the answer is no.

For engineering: Narrow, readable surface — it wraps DoDirectPayment in Payum actions and is easy to audit in an afternoon. MIT means we can fork freely. Plan to vendor it, pin it, write contract tests around capture/authorize/refund, and confirm it resolves against our Payum and PHP versions before we commit. Assume zero upstream support; assign an owner and a review cadence. If the audit surfaces hard incompatibilities, that is our signal to go straight to REST and skip the bridge entirely.

Ask: A go/no-go on the bridge, a named owner for the fork, and a dated line item for the REST migration on the roadmap.