Laravel Myanmar Payments Laravel Package

Technical Evaluation

Architecture fit. laranex/laravel-myanmar-payments is a Laravel-native wrapper that puts Myanmar's domestic payment rails — KBZ Pay, Wave Money, CB Pay, and others — behind a single driver-based manager. The shape is conventional and appropriate: a service provider, a publishable config file, per-gateway drivers resolved through the container, and a fluent request object for initiation, refund, and status calls. For a Laravel monolith or modular monolith selling into Myanmar, this is the correct architectural slot — credentials live in config/ + .env, webhook handling is centralised rather than scattered across controllers, and gateway-specific signing logic is not reimplemented per feature. It is the wrong tool if you need multi-tenant credential routing (merchants with their own PSP accounts), non-Laravel services hitting the same rails, or gateways outside the supported set; in those cases you are writing an adapter anyway and the package becomes a partial convenience.

Integration feasibility. Mechanically low-effort: composer require, publish config, populate per-gateway credentials, register the callback routes, implement whatever callback/payment contracts the package exposes. The genuine effort is not wiring but hardening the money path around the abstraction — idempotency keying, signature verification at the edge, a persisted state machine (initiated → pending → paid → refunded → failed), and reconciliation against PSP settlement files. The single most important feasibility question is whether the package's webhook handler verifies each gateway's signature as a first-class behaviour, or merely parses the payload and hands it to you. If the latter, that hardening is entirely your scope and should be budgeted as such.

Technical risk. This is the dominant concern and it is not close.

• Pre-release churn. The current line is v4.0.0-alpha.17 — the seventeenth alpha of a major rewrite. Semver guarantees nothing pre-release, and seventeen alphas is a strong empirical signal of unstable class names, config keys, driver interfaces, and event names between iterations. Treat every bump as breaking until proven otherwise.
• Unreadable release notes. The alpha.17 notes are auto-generated and contain no categorised entries — only a compare link. There is no human-readable signal of what changed, whether anything broke, or whether a gateway API change was absorbed. For a payments dependency, that is a substantive risk finding, not a cosmetic one: upgrade triage requires diffing the commit range yourself, every time.
• Bus factor. Single-maintainer, 30 stars, issues-based support, no stated SLA or commercial backing. For a revenue-critical path this is a real concentration risk.
• External drift. Myanmar PSP APIs and onboarding policies change on the providers' schedule. An alpha-stage package may lag reality, and the empty release notes give you no way to tell whether it has.
• Alpha-vs-stable ambiguity. Unclear whether a stable v3 line exists and is still patched, and no published timeline to v4 stable.

Key questions to resolve before adoption.

1. Which gateways are genuinely implemented at alpha.17, and which are stubs or roadmap placeholders? (Verify by reading driver source, not the README.)
2. What is the tested Laravel/PHP support matrix, and is it enforced in CI?
3. Does the package verify webhook signatures per gateway, and does it expose idempotency or retry primitives, or leave both to the application?
4. Is there a tagged stable line still receiving fixes, and what is the maintainer's stated path and date to v4 stable?
5. What is the test coverage, and are there contract tests against gateway sandboxes?
6. Who maintains it — individual or company — and is there any commercial support or consultancy route?
7. Is the alpha.16 → alpha.17 diff substantive or housekeeping? (Read the compare link; the notes will not tell you.)

Integration Approach

Stack fit. Assumes a Laravel application on PHP 8.1+, Composer, and the standard HTTP client / queue / event stack. It is explicitly not framework-agnostic. Any part of the payments surface living outside Laravel — a settlement service, a storefront BFF, a mobile backend in another language — bypasses the package and needs a shared internal payments contract so the two paths cannot diverge on status semantics.

Migration path. Do not rip out a working gateway integration for an alpha. Introduce the package behind an internal PaymentGateway interface you own, with one adapter per PSP and Laranex as the engine inside each adapter. This buys three things: an escape hatch if an alpha bump breaks the public API, a single place to normalise the package's result objects into your own domain events and statuses, and the freedom to run one gateway on the package and another on a direct integration while you evaluate. Pin exactly — "laranex/laravel-myanmar-payments": "4.0.0-alpha.17" with minimum-stability: dev and prefer-stable: true. Never a floating ^4.0@alpha constraint on a payments dependency. Commit the lockfile.

Compatibility. Because alphas are unstable by construction, each bump is a potentially breaking upgrade: read the commit diff rather than the release notes, republish and diff the config file (silently renamed keys are the classic alpha-upgrade failure), and run the integration suite against gateway sandboxes before staging. Maintain a written record of which package internals you touch, so a diff review is scoped rather than open-ended.

Sequencing.

1. Spike (scratch branch): install, wire one gateway in sandbox, drive a full callback round-trip, note every place the package does not verify or persist what you need.
2. Build the seam: internal PaymentGateway interface, your own webhook endpoint with signature verification and idempotency enforced at the database, package used only for outbound initiation and payload normalisation.
3. Ship one gateway to production behind a feature flag, with a daily PSP-vs-ledger reconciliation report running from day one.
4. Add gateways incrementally, reusing the adapter pattern.
5. Collapse the adapter layer only if and when v4 reaches a tagged stable with readable release notes.

Budget roughly 2–3 days for the spike and 1–2 sprints for a hardened single-gateway production integration including reconciliation and ops runbooks.

Operational Impact

Maintenance. Expect recurring, unpredictable upgrade work for the duration of the alpha. Assume a small but non-zero tax per bump: diff review, sandbox regression, occasional fixes. Two mitigations: keep the adapter layer as the real product so the package is a swappable detail, and pre-agree a fork policy — if the maintainer goes quiet mid-alpha, you vendor a copy you control rather than block. Also budget for the maintenance nobody plans: gateway-side API and onboarding-policy changes the package may not track promptly. If you are not prepared to read and patch the source, you are not prepared to depend on it.

Support. Likely single-maintainer, GitHub-issues-based, no SLA, no escalation path. For a revenue-critical payment path that is a genuine gap rather than an inconvenience. Before this becomes load-bearing, name an internal owner who can read the package source and patch a fork, and confirm whether any commercial or consultancy arrangement exists. Record a documented "abandonment trigger" — e.g. no release or issue response for 90 days — that forces a fork-or-replace decision.

Scaling. The package is not the bottleneck; the PSP REST APIs and their per-gateway rate limits are. Scale by moving outbound initiation and webhook processing onto queues rather than executing inline in the checkout request, keeping webhook handlers fast and idempotent (unique constraint on gateway transaction ID + internal order ID), and retrying only on well-defined transient failures. Watch per-gateway concurrency ceilings and any synchronous package call sitting in the user-facing latency path. Signature verification and status writes should be the only work done synchronously in the webhook.

Failure modes to design for.

• Signature-verification bypass or misconfiguration (accepting unsigned webhooks) — highest severity; make it a hard failure with an alert, not a logged warning.
• Webhook replay / duplicate crediting — enforce idempotency at the database, not in application logic.
• Lost callbacks with no reconciliation — silent revenue loss; the daily PSP-vs-ledger reconciliation is mandatory, not a nice-to-have.
• PSP timeout on initiation leaving orphaned pending states — needs a sweeper with a pending-age alert.
• Alpha upgrade changing result-object shape, silently misrouting "paid" versus "pending" — the highest-probability upgrade hazard; cover with contract tests on the result normaliser.
• Config-cache staleness after credential rotation — bake config:cache into the rotation runbook.
• Maintainer abandonment mid-alpha — covered by the fork policy above.

Each of these needs a detection path — alerting on unmatched settlements, webhook 4xx rates, pending-age thresholds, signature-failure counts — not just a retry.

Ramp-up. A mid-level Laravel developer can get a sandbox transaction working in about a day from the package's examples. Reaching production grade — adapter layer, signature verification, idempotency, reconciliation, runbooks, settlement-mismatch alerting — is a 1–2 sprint effort for the first gateway. Each additional gateway then costs days rather than weeks once the pattern and the ops playbook exist.

Overall recommendation: architecturally well-shaped for the problem and cheap to trial, but adopt only behind an internal abstraction, pinned to an exact alpha, with sandbox regression tests and a reconciliation job in place before it touches real money — and treat the empty release notes as a standing obligation to review diffs manually rather than a one-off annoyance.