Laravel Paymaya Laravel Package

Product Decisions This Supports

• Payment acceptance in the Philippine market. The package wraps the PayMaya (Maya) payment SDK for Laravel, so it directly supports decisions about how we take cards, Maya wallet, and QR Ph payments without building gateway plumbing from scratch.
• Build vs. buy on payments. This is a "buy and wrap" option: Maya owns the protocol and PCI-adjacent surface, the package owns the Laravel ergonomics (config, service provider, facades, webhook handling). Relevant whenever someone proposes building a custom Maya integration.
• Roadmap sequencing for checkout and money movement. Useful for scoping checkout, refunds, and eventually recurring billing or payouts — the package's capabilities (and gaps) bound how fast those epics can move.
• Vendor concentration risk. Choosing this narrows the payment stack toward a single PSP. That is a product decision about redundancy and negotiation leverage, not just an engineering one.
• Release v1.1.2 specifically: the package now imports the PayMaya SDK base code as a Composer dependency rather than carrying it internally. This is a maintenance-model decision — upstream fixes and API version changes flow to us via composer update instead of package releases. It lowers the wrapper's long-term maintenance burden but couples our dependency tree to Maya's SDK release cadence and PHP version requirements.

When to Consider This Package

Consider it when:

• We are a Laravel/PHP shop with a Maya merchant account (or a concrete plan to open one), and the primary market is the Philippines.
• We want fast time-to-first-transaction — checkout and webhook handling without hand-rolling request signing, idempotency, and payload mapping.
• Our payment needs are conventional: one-time charges, redirects or hosted checkout, refunds, status webhooks.
• We are comfortable with a thin, single-maintainer-style wrapper and can absorb the risk ourselves via tests and monitoring.
• Post-v1.1.2, we can pin and audit the transitive PayMaya SDK in composer.lock and have a process for reviewing its upgrades.

Look elsewhere when:

• We need multi-PSP abstraction (Maya + Stripe + Adyen + local alternatives) behind one interface. A single-gateway wrapper becomes the wrong seam; use a payment orchestration layer or a clean internal port/adapter we own.
• We operate outside PH/Maya coverage, or need currencies and methods Maya does not cover.
• We require deep control over API versioning — the new Composer dependency means the SDK version is now constrained by both the wrapper's composer.json and our platform's PHP version. Conflicts here are a real operational cost.
• We need capabilities the wrapper does not expose (payouts, marketplace splits, tokenized recurring charges) — verify before committing; wrapping gaps ourselves negates the buy argument.
• The package is unmaintained or lagging the official SDK. With v1.1.2, the honest question becomes: why not depend on the official Maya SDK directly and keep our own thin Laravel service provider? That is a legitimate build-vs-buy checkpoint, not a dismissal.

How to Pitch It (Stakeholders)

For executives: This is a small open-source Laravel connector to Maya, one of the Philippines' main payment providers. Adopting it shortens the path to accepting local payments — likely weeks rather than months of integration work — and keeps our engineers focused on the checkout experience rather than payment plumbing. The trade-off is dependency on a single, thinly maintained third-party component and on Maya itself. Recommend a time-boxed pilot behind a feature flag with a fallback path, not a company-wide standard.

For engineering: v1.1.2 changes the dependency model — the Maya SDK base code is now pulled in via Composer instead of being vendored. That is the right direction (upstream security and API fixes arrive without waiting on the wrapper's author), but it introduces transitive-dependency risk: version constraints, PHP and extension requirements (ext-curl, ext-json, ext-openssl), and potential conflicts with existing packages. Before adoption, do three things: (1) pin the resolved SDK version in composer.lock and review its changelog; (2) regression-test the full payment lifecycle — authorize, capture, refund, webhook signature verification, idempotency on retries; (3) wrap the package behind our own interface so we can swap to the official SDK directly or add a second PSP without touching domain code. Assume no SLA and no vendor support: we own the failure modes.

Recommended next step: a one-sprint spike integrating this in a sandbox environment to validate the SDK version, webhook reliability, and error taxonomy, with a written go/no-go against the alternative of using the official Maya SDK directly.