Omise Php Laravel Package

Technical Evaluation

Architecture fit — Despite being filed as a "Laravel/PHP package," this is a plain PHP SDK for the Omise (now Opn Payments) REST API. There is no ServiceProvider, no facade, no publishable config, no container bindings. Configuration is global static state (Omise::setApiKey(), OmiseApiResource::$apiVersion). The library exposes thin resource classes — Charge, Customer, Card, Token, Source, Refund, Dispute, Transfer, Recipient, Schedule, Link, Account, Balance — each a near-1:1 mapping to an HTTP endpoint. Integration therefore means writing your own Laravel adapter, not installing a package. That is 1–3 days of glue for a competent team, but you own it forever.

Integration feasibility — Straightforward. Guzzle-based JSON over HTTPS against a documented, versioned API. The resource model is well-trodden and readable. Omise/Opn is a legitimate regional PSP in Thailand, Japan, Singapore, Malaysia, and Indonesia with real card, PromptPay, Konbini, and instalment coverage. Feasibility is high conditional on Omise already being your contracted acquirer; as a speculative add it is a dead end.

Technical risk

• Global mutable static state — hostile to Octane/Swoole, queue workers, multi-tenant SaaS, and parallel test suites. Cross-tenant key bleed is a plausible, high-severity production failure.
• Provenance unverifiable — "Repository: unknown," 70 stars, no visible security-disclosure process, no observable governance. Supply-chain and abandonment risk are both unpriced.
• Metadata anomaly — the stated release date of 2026-04-22 is in the future. Treat the version signal as unverified until tags are reconciled against Packagist and the vendor's git history.
• Dependency coupling — Guzzle version pins can conflict with the Guzzle Laravel already locks; transitive churn is your problem, not upstream's.
• Missing primitives — no webhook signature helper, no idempotency abstraction, no retry policy, no typed error taxonomy. All of it is yours to build.
• Domain surface outside the library — 3DS/SCA, tokenization, PCI scope, settlement reconciliation, and dispute handling are entirely on you.

Key questions

• Is Omise/Opn the signed PSP for our target markets, or is this a hedge against Stripe/PayPal? If not signed, stop here.
• Which markets, currencies, and payment methods are in scope for v1?
• Do we require multi-tenant or multi-account key isolation? If yes, static state is disqualifying without a wrapper.
• Do we run Octane or long-lived workers today? This changes the risk from "annoying" to "blocking."
• Who owns the fork if upstream goes quiet, and what is our vendoring/pinning policy?
• Are idempotency keys generated client-side on every charge create, and are webhooks deduped by event ID?
• What is our API-version pinning strategy when Opn bumps the dated version string?

Integration Approach

Stack fit — PHP 8.x + Guzzle 7 fits a modern Laravel 10/11 application, but only behind an anti-corruption layer. Do not reference Omise* classes from controllers or jobs. Define a ChargeGateway / TokenGateway interface, ship one Omise implementation and one in-memory fake for tests. This also makes a future PSP swap a config change rather than a refactor.

Migration path — From Stripe/PayPal: dual-run. Put the new provider behind a per-market feature flag, shadow-create charges in sandbox to validate amount/currency semantics, then ramp by percentage of traffic. Greenfield: adopt directly, but wrap from commit one — retrofitting the seam later is expensive.

Compatibility — Pin an exact version, vendor the source into the repo or a private mirror, and record the commit SHA. MIT license is permissive and unproblematic. Confirm the Packagist entry under the omise vendor namespace actually resolves to the tag you intend to ship.

Sequencing

1. Provenance check — reconcile repo, tag, Packagist, and release notes. Do not accept the anomalous date at face value.
2. Adapter + config — config/services.php entry, env-backed keys, optional per-tenant key resolver, optional facade.
3. Tokenization flow — client-side omise.js token → server-side charge. Keeps PCI scope at SAQ A/A-EP rather than SAQ D. Non-negotiable.
4. Resilience layer — idempotency key on every create, bounded retry with jitter, explicit connect/read timeouts.
5. Webhook endpoint — verify, persist raw payload, dedupe on event ID, enqueue async processing, return 2xx fast.
6. Reconciliation — nightly job against settlement reports; alert on drift greater than tolerance.
7. Runbooks — refund, partial refund, dispute evidence, and stuck-charge resolution before go-live.

Operational Impact

Maintenance — Low upstream churn, high local ownership. You maintain the wrapper, the dependency pin, and the fork plan. Budget roughly 0.1–0.2 FTE steady-state for an integration of this shape, spiking during PSP API-version bumps or SCA mandate changes.

Support — Vendor support is regional and account-manager-mediated, governed by the commercial contract rather than the repo. The OSS project is a 70-star library with no SLA, thin issue traffic, and no observable security advisory channel. Escalation path is the PSP, not GitHub. Plan accordingly.

Scaling — The SDK is effectively stateless per call apart from static config, so throughput is bounded by PSP rate limits and your HTTP client settings, not by the library. Under Octane, static key state becomes a concurrency hazard: either reset it per request/tenant in middleware or bypass the static API entirely and construct your own client. The latter is cleaner and worth the extra day.

Failure modes

• Timeout on charge create → unknown charge state. Must poll by charge ID or idempotency key. Never blind-retry a create without a key; that is how customers get double-charged.
• Static key bleed in long-lived workers across tenants → charges against the wrong merchant account. Highest-severity risk in this integration.
• Unpinned Guzzle → silent breakage in CI when a transitive major bumps; catch it with a contract test hitting a recorded fixture.
• Webhook replay or duplicate delivery → double fulfillment absent event-ID dedupe.
• Upstream abandonment → no security patches. Mitigated only by vendoring and a named owner.
• Amount handling — smallest-unit integers and zero-decimal currencies (JPY, IDR) are a classic source of 100x errors; test explicitly.

Ramp-up — A mid-level Laravel developer reaches a working sandbox charge in 2–4 days. Production hardening — idempotency, webhooks, reconciliation, runbooks, observability — is 2–3 weeks of focused work. There are no Laravel-specific docs, so onboarding means reading the Omise REST reference and this source, not a package README.

Verdict — Acceptable as a tactical dependency if and only if Omise/Opn is already the contracted PSP in your markets, and only behind an owned adapter with a pinned, vendored version. A composite score of 13.7 with opportunity at 3.7 and an unverifiable repository is a clear signal against anything strategic: do not build a multi-market payments platform on this without a vendor commitment, a named maintainer, and a fork plan.