Laravel Midtrans Laravel Package

Technical Evaluation

Architecture fit. The package is a thin Laravel service-provider wrapper around Midtrans' official PHP SDK (midtrans/midtrans-php), exposing a config file, a facade, and convenience bindings for the Snap and Core API surfaces. This is a low-coupling shape: it does not touch Eloquent models, queue workers, or framework internals, so it is easy to remove or replace if needed. For an existing Laravel app already targeting the Indonesian market, it slots into the standard "external payment provider" seam without reshaping code — a net positive for architectural risk.

Integration feasibility. Integration requires a Midtrans merchant account, a server key and client key for sandbox and production, and a public webhook endpoint for HTTP notifications (Midtrans' async payment-confirmation callback). The wrapper's value is limited to DI registration and config wiring; the substantive logic (Snap token creation, transaction status checks, signature verification) still originates from the upstream PHP SDK. Feasibility is high as a spike, but the value of the wrapper itself is small — most of the "does it work" question is really "does the upstream SDK and Midtrans account work."

Technical risk. The dominant risk is lifecycle, not design. Last release is 2023-02-15, which predates Laravel 11 and Laravel 12; the package effectively targets Laravel 8/9/10 and PHP 8.0/8.1 conventions. Compatibility with modern Laravel is unknown without inspecting composer.json constraints. With 12 stars, the bus factor is effectively one, CI status and test coverage are not visible externally, and the opportunity score of 0.38 reflects a narrow, tactical utility rather than strategic leverage. Security posture also depends on whether the wrapper correctly surfaces Midtrans' notification signature verification; if it does not, teams must implement verification themselves (which they should regardless).

Key questions.

• What are the exact composer.json constraints for php, laravel/framework, and midtrans/midtrans-php? Does it install on Laravel 10/11/12 today?
• Which Midtrans surfaces are wrapped: Snap only, or also Core API (VT-Direct, bank transfer, e-wallet), and Iris/disbursement?
• Does it expose notification signature verification, or does it leave that to the consumer?
• Is there test coverage, CI, and static analysis, or is it a one-shot release?
• Is the upstream midtrans/midtrans-php pinned to a supported version, and does it handle Midtrans' current Snap JS/API versions?
• What is the maintainer's responsiveness record on issues and PRs?

Integration Approach

Stack fit. Best fit is a Laravel 9/10 / PHP 8.1 monolith or modular monolith serving Indonesian customers, where the team wants a fast, low-ceremony wiring of Midtrans. It is a poor fit for multi-tenant SaaS requiring provider abstraction across multiple gateways (Stripe + Midtrans + Xendit), because the facade is Midtrans-specific and offers no gateway-agnostic interface.

Migration path. Because the package is thin, the pragmatic path is to evaluate it, then treat it as a convenience layer only and put an internal PaymentGateway interface in front of it. That interface owns the contract (create charge, verify webhook, refund, query status). If the package goes stale, the implementation swaps to the raw midtrans/midtrans-php SDK or a fork of this package, and no domain code changes. Forking is cheap given the small surface: MIT license, low LOC, single maintainer — a fork can be vendored into the app or published to a private registry without licensing friction.

Compatibility. Before any commitment, run composer why-not and a scratch install against the target Laravel and PHP versions. Verify PHP extension assumptions (curl, openssl, json), confirm midtrans/midtrans-php resolves to a current minor, and confirm the config keys align with the merchant's Midtrans dashboard (server key, client key, isProduction, isSanitized, is3ds). Any mismatch on these is a fork-level fix, not a blocker.

Sequencing.

1. Spike (1–2 days): install in a scratch Laravel app on the target version, exercise Snap token creation against Midtrans sandbox, confirm webhook receipt and signature verification.
2. Interface first: define the internal PaymentGateway contract before writing any adapter code, so the package is never referenced outside one adapter class.
3. Sandbox build: implement the adapter against the package; add the Midtrans notification endpoint behind your own controller with signature verification and idempotency keys.
4. Reconciliation: wire order-status transitions to Midtrans transaction_status values (capture, settlement, pending, deny, expire, cancel, refund) and add a nightly reconciliation job against Midtrans' transaction status API.
5. Production cutover: gate behind a feature flag, start with a single payment method, expand after stability proves out.
6. Contingency: keep the fork/raw-SDK swap as a documented two-day task, so the stale-maintainer risk is bounded.

Operational Impact

Maintenance. Expect to own the package. A 2023 release means no routine bumps for Laravel major versions, no security patches for upstream advisories, and no fixes for Midtrans API changes. Budget a recurring review (monthly or per-Laravel-major) and plan to fork if support is needed. The MIT license makes this legally clean; the operational cost is engineering time, not licensing.

Support. Support is community/GitHub-issues only, with a 12-star project — realistically, self-support. That is acceptable if the team treats it as an internal dependency with a fork path, not as a vendor with an SLA. This is the right call for a tactical payment wiring; it is the wrong call if the payment flow is business-critical and no in-house Laravel engineer is available.

Scaling. The wrapper does not affect throughput. Midtrans handles the transaction volume; the Laravel side scales with the app's existing horizontal scaling story. Watch three things at scale: (a) synchronous Midtrans API calls inside request handlers — move to queued jobs to avoid latency coupling; (b) webhook endpoint rate and idempotency — deduplicate on Midtrans order_id + transaction_id; (c) Snap token lifetime and retry behavior under load. None of these are the package's fault; all of them are the integrator's responsibility.

Failure modes.

• Package staleness: blocks a Laravel upgrade; mitigated by the interface + fork path.
• Webhook spoofing: if signature verification is not enforced, fraudulent settle notifications can mark orders paid. This is the highest-severity risk and must be handled in application code regardless of what the package ships.
• Idempotency gaps: duplicate notifications can double-credit or double-fulfill; require idempotency keys and an immutable transaction log.
• Status desync: missed webhooks leave orders pending; mitigate with a scheduled reconciliation poll against Midtrans' status API.
• Credential leakage: server key in .env only, never in client bundles, rotate on exposure.
• Midtrans-side incidents: Midtrans is a GoTo company with materially better uptime posture than this package ever will have; the risk surface is the integration, not the gateway.

Ramp-up. Low. A Laravel developer familiar with service providers and facades can be productive in half a day; the domain learning curve (Snap vs. Core API, notification statuses, 3DS, IDR-only currency, convenience-store payment expiry semantics) dwarfs the package learning curve. Onboarding material should be internal documentation, not the package README — the README is a thin starter guide and does not cover the operational concerns above.