Weave Code
Laravel Myanmar Payments Laravel Package
laranex/laravel-myanmar-payments
Laravel Myanmar Payments helps you add Myanmar payment gateways and wallets to Laravel apps with a clean, configurable API for payment requests, callbacks, and transaction handling—reducing boilerplate so you can ship local checkout flows faster.
Laravel integration for Myanmar payment gateways: KBZ Pay, Wave Pay, Wave Pay Mini App, AYA Pay, Yoma MMQR and CyberSource. Built on PHP Myanmar Payments. Facade and config, verified callbacks and test fakes.
Frequently asked questions about Laravel Myanmar Payments
- How do I install laranex/laravel-myanmar-payments in a Laravel application?
- Install it with Composer (composer require laranex/laravel-myanmar-payments), then publish the package config file with vendor:publish and add your per-gateway credentials to .env. Because the current line is a pre-release (v4.0.0-alpha.17), you may need an explicit stability flag or pinned alpha constraint in your require line rather than a plain version constraint. After publishing, register the callback/webhook routes the package exposes and implement any payment or callback contracts it defines. Pin the exact alpha version you test against and treat every bump as potentially breaking until you have diffed it.
- Which Myanmar payment providers does this package support?
- The package is positioned as a single driver-based API for Myanmar gateways, with KBZPay, Wave Money, AYA Pay and UAB Pay named in the overview, and CB Pay also referenced in technical review notes. Because it is alpha software, confirm the real support set by reading the driver source in the installed package rather than the README, since some drivers may be stubs or roadmap placeholders. Gateways outside the supported set mean writing your own adapter.
- Which Laravel and PHP versions are supported?
- The integration assumes a Laravel application on PHP 8.1+ with Composer and Laravel's HTTP client, but the exact tested Laravel/PHP support matrix is not documented in the package description. Check the composer.json constraints and CI configuration in the repository before committing, and verify the matrix covers your installed Laravel version. For a payments dependency, run the package's own tests against your Laravel version rather than assuming compatibility.
- How do I configure KBZPay or Wave Money credentials?
- Credentials are config-driven: you publish the package config file, then populate each gateway's merchant ID, keys and secrets via environment variables so nothing sensitive lives in code. A sandbox setting lets you point drivers at provider test environments during development. Keep separate .env values per environment and never reuse production merchant credentials in staging. If you run several merchants, note that the config is a single credential set, not per-tenant routing.
- Does the package verify webhook and callback signatures for each gateway?
- The package provides centralised webhook/callback handling and verification, but the critical question before adoption is whether signature verification per gateway is a first-class behaviour or whether it only parses the payload and hands it to you. Read the callback handler source to confirm. If verification is left to the application, implement it at the edge, reject unsigned payloads, and key every callback by an idempotency value so replays cannot double-credit an order.
- Can I initiate payments, check transaction status and issue refunds through one API?
- Yes. The package exposes a fluent, driver-based interface for payment initiation, status checks and refunds, so the same call shape works across the supported Myanmar gateways once credentials are configured. Gateway-specific signing and request shaping are handled by each driver rather than in your controllers. You still own the persisted transaction state machine (initiated, pending, paid, refunded, failed) and reconciliation against provider settlement reports.
- Is there sandbox support for testing payments?
- Sandbox support is config-driven, letting you run drivers against gateway test environments before going live. Package-level test coverage and contract tests against real gateway sandboxes are not clearly documented, so budget time to write your own integration tests for each provider you enable. Fake the HTTP layer in unit tests and reserve sandbox runs for callback and refund flows.
- Is laravel-myanmar-payments stable enough for production use?
- Treat it cautiously: the current release is v4.0.0-alpha.17, the seventeenth alpha of a major rewrite, so semver guarantees do not apply and class names, config keys and driver interfaces can change between alphas. Release notes are auto-generated with only a compare link, so every upgrade requires diffing commits yourself. It is a single-maintainer, low-star package with no stated SLA or commercial backing, which is a real concentration risk on a revenue-critical path. It can be viable if you pin versions, harden the money path yourself, and accept upgrade triage work.
- Can I use it for multi-tenant merchants with their own payment provider accounts?
- No, not out of the box. The package is designed around one credential set per gateway in configuration, which suits a single-merchant Laravel application selling into Myanmar. Multi-tenant credential routing, where each merchant has its own KBZPay or Wave Money account, requires your own adapter layer or a custom driver manager on top of the package. Non-Laravel services hitting the same payment rails also fall outside its scope.
- How does this compare with using the KBZPay or Wave Money SDKs directly?
- Calling each provider's SDK or REST API directly gives you full control and no third-party maintenance risk, but you reimplement signature handling, callback routing and request shaping for every gateway, and those implementations drift as providers change. This package's value is a uniform driver API, centralised webhook handling and Laravel-native config, events and facade, which reduces boilerplate for local checkout flows. The trade-off is alpha-stage churn and single-maintainer risk, so weigh it against writing a thin in-house adapter if payment volume is core to your business.
Weaver
How can I help you explore Laravel packages today?