Laravel Duitnow Laravel Package

Product Decisions This Supports

• Market expansion into Malaysia. DuitNow is the national rail (QR, proxy transfers, request-to-pay, online banking), so this maps directly to a "can we launch MY checkout?" decision. Evaluate whether adding DuitNow QR/Transfer moves conversion and unlocks a segment we currently lose at payment selection.
• Payment method roadmap prioritisation. Use it to scope the cost and time of shipping a DuitNow option — the wrapper collapses "integrate a national payment scheme" into something closer to "wire up a driver, config, and webhook handler," which changes the sequencing conversation from a quarter to a sprint.
• Build vs. buy vs. PSP. Three real options: (1) this package against a direct merchant/acquirer API, (2) a commercial aggregator (Stripe/Billplz/iPay88/SenangPay-class), (3) in-house direct integration. This package is the cheap probe that lets you price option (1) before committing to option (2)'s take rate. At low volume, aggregator fees are usually cheaper than engineering time; at scale, direct wins — this package is the tool that moves the crossover point.
• Use-case fit. Best suited to checkout payments, invoice/collection flows (DuitNow Request is effectively request-to-pay), and QR-at-counter scenarios. Weaker fit if the requirement is multi-currency, cross-border SEA, or marketplace split payouts — those need orchestration more than a scheme wrapper.
• Reconciliation and ops design. Any DuitNow decision is really a decision about webhook handling, idempotency, refunds, and settlement reporting. Adopting the package forces us to make those calls explicitly rather than discovering them in production.

When to Consider This Package

Consider it when:

• Malaysia is a committed target market and DuitNow is a named requirement, not a nice-to-have.
• The stack is already Laravel/PHP and the team is comfortable owning a small vendor dependency.
• We already hold (or are actively acquiring) a merchant relationship with the specific acquirer whose API this wraps — confirm this first; a DuitNow wrapper is only useful if its underlying provider is the one we can actually onboard with. This is the gating question, not the star count.
• We need direct integration to reduce per-transaction cost, or we need control the aggregator won't give us (custom flow, specific QR presentation, own settlement data).
• We're willing to fork and vendor it. MIT license makes that legally clean; the maintenance profile makes it prudent.

Look elsewhere when:

• We need SLAs, 24/7 support, uptime commitments, or a vendor to escalate to. Ten stars and a single 2024 release is a community-signal problem, not a quality verdict — but it does mean no one is on the hook but us.
• We need multi-provider failover, multi-country coverage, tokenised cards alongside DuitNow, or a hosted checkout/dispute console. That's aggregator territory.
• Security and compliance review capacity is thin. Payment credential handling, signature verification, and idempotency are our problem regardless of who wrote the wrapper.
• The transaction volume is low and the aggregator's take rate is cheaper than the engineering + on-call cost of owning this.
• The underlying provider's API has moved since the last release (Aug 2024) — verify current API compatibility before scoping, not after.

How to Pitch It (Stakeholders)

To executives: This is a small, MIT-licensed Laravel component that lets us add DuitNow — Malaysia's national QR and instant-payment rail — without building the protocol plumbing ourselves. The strategic value is optionality: it lets us price a direct DuitNow integration against an aggregator's fees with a one-to-two-week technical spike instead of a six-week build. The risk is maintenance, not licensing: ten stars and a single maintainer means if we ship this, we own it. Recommendation is a bounded spike plus a security and provider-compatibility review, with a go/no-go gate before it touches production. Worst case we spend a sprint and get a firm cost number for the roadmap.

To engineering: Treat it as a starting point, not a dependency. Fork it, review how it handles signatures, key storage, webhook verification, retries, and idempotency, and confirm which acquirer's API it targets and whether that API has changed since August 2024. Pin it, vendor it, and put reconciliation and refund paths on our side. If the review finds the wrapper is thin enough that we'd rewrite most of it, that's a finding worth shipping back to the roadmap — it tells us direct integration is genuinely cheap.