- How do I install lloricode/laravel-paymaya-sdk in a Laravel app?
- Install it with composer require lloricode/laravel-paymaya-sdk. The package follows Laravel conventions: its service provider is registered through auto-discovery, and it ships a publishable config file at config/paymaya.php. Publish the config with vendor:publish, then set your PayMaya credentials, preferably through environment variables rather than committing secrets.
- Which Laravel and PHP versions does this PayMaya SDK support?
- The package overview does not publish a Laravel or PHP support matrix, so check the composer.json version constraints before committing. A mismatch between your runtime and the package constraints turns a simple install into a fork or backport. Confirm that your Laravel and PHP versions fall inside the declared requirements as part of your evaluation.
- How do I configure PayMaya API credentials in Laravel?
- After publishing config/paymaya.php, place your PayMaya sandbox or production keys in your .env file and reference them from the config. The facade resolves the PayMaya client through Laravel's container, so configuration is centralized and the client is mockable in tests. Keep credentials out of version control and use separate sandbox and production values per environment.
- Does this package verify PayMaya webhook signatures?
- The overview describes a thin wrapper around PayMaya's REST surface, including webhook and invoice endpoints depending on API version, but it does not state that signature or authenticity verification is implemented. Assume you own webhook ingestion, signature checks, idempotency on retries, and reconciliation in your application. Treat the SDK as covering the happy-path API calls only.
- Can I use this SDK for PayMaya checkout and payment links?
- Yes, the package is described as making it easier to integrate PayMaya checkout, payment links, and related payment APIs into Laravel. It wraps PayMaya's own PHP SDK rather than reimplementing the HTTP layer, so the available operations track what that SDK exposes. Verify the specific endpoints you need, such as refunds or invoices, against your target API version before relying on them.
- Is lloricode/laravel-paymaya-sdk production ready?
- Treat it as unvalidated: it has zero stars and zero dependents, a single maintainer, and no evidence of a security review, which matters for payment code handling API keys and webhook secrets. Pin an exact version in composer.json, commit composer.lock, and wrap the SDK behind an internal interface so you can fork or replace it. Confirm the license and release cadence before adoption.
- How can I test PayMaya payments in Laravel without hitting production?
- Use PayMaya sandbox credentials for a proof of concept, and resolve the facade through Laravel's container so you can mock the client in unit tests. Because the package does not add an idempotency or retry layer beyond Guzzle defaults, write your own contract tests around checkout initiation and webhook handling against the sandbox. A realistic spike of a few days is enough to validate the checkout and webhook round trip.
- What PayMaya or Maya API version does this SDK target?
- The overview does not state which PayMaya or Maya API version the package targets. PayMaya has rebranded to Maya and iterated on its API surface, so there is a real chance the SDK lags current production documentation. Confirm this against the live docs before adoption, because a superseded API version means maintaining a fork from day one.
- What are the alternatives to this Laravel PayMaya SDK?
- You can call PayMaya's REST API directly through Guzzle, use PayMaya's official PHP SDK without the Laravel wrapper, or look for a more actively maintained community package. Because this package is a thin adapter with no gateway-agnostic interface, defining your own PaymentGateway contract and treating the SDK as one adapter lets you swap implementations later. That seam costs roughly a day upfront and protects your order and ledger code.
- Should I use this package in a multi-gateway Laravel application?
- It is a poor fit for multi-gateway routing because it is a thin, opinionated adapter with no gateway-agnostic interface or shared domain abstractions. It suits a Laravel monolith that targets the Philippine market with PayMaya or Maya as its primary or sole payment service provider. For multiple gateways or regions, put an internal abstraction in front of it or choose a different integration approach.