Sdk Laravel Package

Product Decisions This Supports

• Payment method coverage for the Mexican market. Openpay (a BBVA company) is a Mexican PSP whose differentiators are local rails: SPEI (bank transfer), OXXO/convenience-store cash payments, meses sin intereses (installment plans), and local card acquiring. If your roadmap includes Mexico or LATAM expansion, this package is the fastest way to answer "can we accept SPEI and OXXO without a six-week integration project?"
• Build vs. buy for the integration layer. The package is a thin REST wrapper, not a payment abstraction. The real decision is not "buy this SDK" but "do we wrap Openpay's API ourselves behind our own PaymentGateway interface, or spend a sprint on boilerplate?" This package lets you prototype the former cheaply while deferring the architectural commitment.
• Feature scoping for checkout. The SDK's surface (charges, customers, cards, subscriptions/plans, payouts, webhooks) maps almost directly to a backlog of payment features. Reading its resource classes is a cheap way to size "what does supporting subscriptions in Mexico actually entail?"
• Vendor strategy and redundancy. Evaluating Openpay against Stripe, Mercado Pago, Conekta, or Adyen for a Mexican launch is a roadmap-level decision. A low-cost, Apache-2.0 client makes a time-boxed spike against Openpay's sandbox inexpensive enough to run in parallel with a Mercado Pago spike.
• Use cases it fits well: internal back-office tooling (refunds, reconciliation exports), a first-pass checkout for a Mexican MVP, marketplace payouts, or a migration off a legacy gateway where speed matters more than elegance.
• What it should not decide for you: it should not be the reason you choose Openpay. The gateway decision should be driven by pricing, approval rates, settlement timing, and support SLAs — the SDK is a commodity input to that decision.

When to Consider This Package

Consider it when:

• Openpay is already the chosen provider (existing merchant account, negotiated rates, or a parent-company contract) and you need a PHP/Laravel client. At that point the question is only "this SDK or hand-rolled Guzzle calls?"
• You are running a time-boxed spike — one to two weeks to validate that SPEI/OXXO/installments work for your checkout before committing to an architecture. Wrap it behind your own interface from day one so it stays swappable.
• The scope is narrow and internal. Refund tooling, a reconciliation job, or an admin panel that lists transactions is a fine fit for a thin, unmaintained wrapper; you control both ends and can pin the version.
• You can accept the maintenance burden. Apache-2.0 permits forking and vendoring. If your team is comfortable reading ~a few thousand lines of resource classes and patching them, the license removes the legal blocker.
• Your PHP/Laravel baseline is compatible. Verify against your runtime (PHP 8.x, Laravel 9–11) before adopting — a 2020-vintage client predates PHP 8.1 deprecations and may pull in Guzzle constraints that conflict with your lockfile.

Look elsewhere when:

• You need current API coverage. A June 2020 last release is a strong signal that 3-D Secure 2 / SCA flows, newer subscription endpoints, payout APIs, or Openpay's post-2020 API revisions are absent or unverified. Confirm the specific endpoints you need exist and work against the sandbox — do not infer coverage from the README.
• PCI scope or compliance attestation matters. A zero-dependency-history wrapper with no security release cadence gives you no signal for vulnerability response. For card-not-present with stored credentials, prefer tokenization via hosted fields/iFrames and treat this as a server-side-only helper.
• You need an abstraction layer. If Mexico is one of several markets, or you expect to add a second PSP within 18 months, a gateway-agnostic layer (Laravel Cashier-style, Omnipay's openpay driver, or an in-house adapter) beats adopting a single-vendor SDK as a dependency.
• Adoption signals matter to your org. 68 stars and zero dependent packages means effectively no community validation: no Stack Overflow corpus, no third-party bug reports, no one else to absorb a breaking change. Budget for "we are the maintainers."
• You are on a modern Laravel stack and want first-class DX. No service provider, no facade, no config publishing, no typed DTOs. You will write that glue yourself — which is fine, but it should be in the estimate.
• The commercial relationship is not settled. Do not build on a provider you have not contractually committed to; the SDK's low cost makes it tempting to invert that order.

Adoption checklist (all must be green): sandbox credentials obtained → the 3–5 endpoints you need verified live → PHP/Laravel version compatibility confirmed in a branch → a one-file anti-corruption layer wrapping the SDK → a named owner and a documented vendor-and-patch procedure.

How to Pitch It (Stakeholders)

To executives: Openpay is a BBVA-backed Mexican payment provider with genuinely differentiated local coverage — SPEI transfers, OXXO cash payments, and installment plans are table stakes in Mexico and are not uniformly available from global processors. This package is a free, permissively licensed (Apache-2.0) PHP client that lets us test that coverage in days rather than the weeks a from-scratch integration would take. The commercial decision — whether Openpay wins on pricing, approval rates, and settlement terms — stays entirely open; this only makes the evaluation cheap. The honest caveat: the library has been untouched since mid-2020, has negligible community adoption, and carries no security-release cadence. We should treat it as a prototype accelerant, not a production dependency of record, and we should budget roughly one engineer-week to wrap, test, and own it before it touches real money.

To engineering: it is a thin REST wrapper with no Laravel integration — no service provider, facade, config, or typed responses. Plan to vendor or pin it, put it behind our own PaymentGateway contract, and treat the resource classes as documentation of Openpay's API shape rather than as a maintained dependency. Verify PHP 8.x and Guzzle constraint compatibility in a branch first; expect to patch. Server-side only — card data should go through hosted fields/tokenization so this never enters our PCI scope.

Recommendation: approve as a spike dependency, not a platform commitment. Thirty-day decision gate: if the endpoints we need work in sandbox and Openpay clears commercial diligence, we either fork-and-own the client or replace it with ~300 lines of our own Guzzle code. If either fails, we walk with almost nothing sunk.