Laravel Myanmar Payments Laravel Package

Product Decisions This Supports

• Market-entry sequencing for Myanmar. This package is the cheapest credible way to answer "can we sell here?" without staffing a PSP-integration project. A one-gateway sandbox spike against KBZ Pay or Wave Money is a ~2–3 day question, which makes "launch Myanmar" a roadmap item you can size rather than a research spike with an open-ended budget.
• Build vs. buy on provider boilerplate. The package covers the commodity layer — driver selection, request signing, callback parsing, credential config, result objects, exceptions/events. That is work you would otherwise re-write per gateway and re-maintain when endpoints drift. The decision it doesn't make for you is the defensible layer: idempotency, ledger reconciliation, refund state machine, ops runbooks. Those stay in-house regardless, which is itself a useful framing for stakeholders: buy the plumbing, build the money path.
• Multi-gateway breadth as a product option, not a commitment. Because gateways are drivers behind one manager, supporting "KBZ Pay now, Wave Money next quarter, CB Pay when we have enterprise demand" becomes config plus a per-driver hardening task, not a second integration project. That directly enables decisions like offering wallet-specific checkout options or regional payment preferences without re-litigating architecture.
• Localized checkout as a positioning lever. Myanmar buyers concentrate heavily on wallet rails rather than cards. Being able to say "we accept KBZ Pay and Wave Money" is a conversion and trust feature in-market, not just an engineering detail — it belongs in pricing/GTM conversations, not only the backlog.
• Trial/pilot scoping. The adoption pattern here (one gateway behind a feature flag, manual reconciliation report, then expand) is a natural pilot shape: a limited-market or invite-only launch that generates real transaction data before you commit to a full build-out.
• Reverse decision — deliberate deferral. If the assessment surfaces that the package is alpha with no readable release notes and no commercial support, the product decision can legitimately be "not this quarter," with a documented trigger to revisit (v4 stable tagged, or a second maintainer/company backing appears). Having a named trigger prevents the item from resurfacing every planning cycle.

When to Consider This Package

Consider it when:

• You are on a Laravel application (9/10/11-class) with PHP 8.1+ and standard HTTP/queue/event infrastructure, and the Myanmar payment surface lives inside that app.
• You need more than one local gateway, or expect to. A single, never-changing gateway is thin justification for a third-party dependency; the payoff here is breadth behind one API.
• Your gateway set overlaps the supported providers (KBZ Pay, Wave Money, CB Pay and peers). Anything outside that set means writing an adapter anyway — at which point you should ask whether you're adopting a package or a pattern.
• You can absorb alpha risk: an internal owner who can read the source and patch a fork, sandbox access for regression tests, and a team willing to treat every version bump as potentially breaking.
• You intend to put your own abstraction in front of it. This package is a good engine inside an adapter, not a good public interface for the rest of your domain.
• You need a fast, defensible feasibility answer for a market-entry or partnership conversation, and a 2–3 day spike is cheaper than a design doc debate.

Look elsewhere when:

• You need multi-tenant credential routing (one install, many merchants), a non-Laravel service in the payment path (Go settlement, Node storefront), or gateways outside the supported set. Expect to write your own adapter regardless.
• You need vendor SLAs, commercial support, or a security-response commitment. This looks like a single-maintainer, GitHub-issues project; a revenue-critical payment path with no support contract is an organizational risk you must consciously accept.
• Your risk posture forbids pre-release dependencies on money-handling systems, or you cannot commit to pinning an exact alpha, committing the lockfile, and manually diffing commits because the release notes are auto-generated and carry no changelog signal.
• You need the package to own idempotency, retries, reconciliation, or a refund state machine. It doesn't — and if your team reads "handles callbacks" as "handles settlement," you will ship a silent-revenue-loss bug.
• You're evaluating against a stable v3 line and cannot confirm whether v3 still receives fixes and what the maintainer's timeline to v4 stable is. No answer to that question is itself a reason to pause.

How to Pitch It (Stakeholders)

To executives — the one-paragraph version: We can enter the Myanmar market without building four payment integrations. An open-source package gives us a single Laravel-native API across the dominant local wallets (KBZ Pay, Wave Money, CB Pay) — signing, callbacks, credentials, refunds, status checks — so the team's effort goes into the parts that actually protect revenue (verification, idempotency, reconciliation) rather than provider boilerplate. The caveat is maturity: it's a pre-release alpha from a small maintainer with no support contract. So the recommendation is proceed, but deliberately — one gateway, sandbox-first, behind a feature flag, pinned to an exact version, with our own abstraction layer so we can swap the engine or fork it. Budget roughly 2–3 days to prove feasibility and 1–2 sprints to a hardened single-gateway production launch. Each additional wallet after that is days, not weeks.

To engineering — the framing they need: Adopt it as a swappable detail inside our own PaymentGateway interface, never as a public dependency of domain code. One adapter per PSP, package as the engine. Pin 4.0.0-alpha.17 exactly, no floating alpha ranges, commit the lockfile, and treat every bump as breaking — the auto-generated release notes give us nothing, so we diff commits and re-run sandbox regressions. We own the money path: webhook signature verification on our own endpoint, a unique constraint on gateway transaction ID + our order ID, queued outbound initiation, and a daily PSP-vs-ledger reconciliation job. Flag the failure modes explicitly — unsigned-webhook acceptance, replayed callbacks double-crediting, orphaned pending states from PSP timeouts, config-cache staleness after credential rotation, and silent misrouting of "paid" vs "pending" if a result object changes shape.

To sales and partnerships: We'll be able to say we accept the wallets buyers here actually use, and to add another wallet as a configuration change once the pattern is proven. Don't promise a gateway list or dates until each one has cleared sandbox and a production pilot — and note the honest constraint: the underlying project has no commercial support and is pre-1.0 in its next major version, so we're depending on our own team's ability to maintain it if the maintainer goes quiet.

The ask: approval for a scoped spike (one gateway, sandbox, ~3 days) plus a named internal owner for the payment path. The spike result — pass or fail — is a cheap, concrete input to the Myanmar roadmap decision either way, and the fail case still leaves us with a documented gateway evaluation we can reuse.