- What does the laravel-duitnow package actually do?
- It is a thin Laravel wrapper around a DuitNow acquirer or bank API, packaged as a service provider with a facade. It helps you initiate DuitNow payments and parse responses without hand-rolling the HTTP integration. It is not a full payment orchestration layer, so ledgering, reconciliation, and idempotency remain your responsibility.
- Which DuitNow products does this package support?
- DuitNow is PayNet's national real-time payments rail and covers Transfer, QR, Request, and Direct Debit. This wrapper targets one specific upstream acquirer contract, so the products available depend entirely on what your bank or acquirer exposes. Read the source and confirm with your acquirer before assuming QR or Direct Debit support.
- How do I install laravel-duitnow in a Laravel app?
- Install it with Composer using the package name zarulizham/laravel-duitnow, then publish any provided config if the service provider supports it. Because the last release was August 2024, pin the exact version rather than using a floating constraint. Consider vendoring or forking the package so upstream changes cannot break a revenue-critical path.
- Which Laravel and PHP versions are supported?
- Version constraints are declared in the package composer.json, so check them against your framework and PHP version before adopting. Also verify the Guzzle or HTTP-client version it pulls in, since Laravel's HTTP client wraps Guzzle and conflicts are common. Pin the exact release and add Dependabot or Renovate to track updates.
- Does it support idempotency keys and safe retries?
- Thin wrappers like this commonly omit idempotency keys, retry semantics, and replay protection, so do not assume they exist. Timeouts and ambiguous responses are the classic cause of duplicate payments on real-time rails. Build an idempotency layer and a payment state machine yourself, and treat the package as transport only.
- How are DuitNow webhooks or callbacks handled and verified?
- The package likely does not provide webhook signature verification or replay protection out of the box. You should implement your own callback endpoint, verify the signature against the acquirer's specification, and reject replayed or stale payloads. Persist raw payloads for audit and reconcile them against your ledger before fulfilling orders.
- Is there a sandbox or test mode I can use?
- Real feasibility is gated by onboarding: PayNet participation through a bank or acquirer, sandbox credentials, mTLS certificates, and certification. The package cannot shortcut any of that, and a test mode only helps if the sandbox contract matches production. Write contract tests against the sandbox and keep them running so API drift is caught early.
- How should I handle mTLS certificates and API credentials securely?
- DuitNow integrations typically require client certificates for mTLS plus API keys or secrets. Keep these in a vault or secrets manager rather than .env or committed config, and confirm how the package loads certificate paths before going live. Audit the credential handling in the source, since a thin wrapper often reads directly from config.
- Can I use this package in production given its low adoption?
- It has roughly 10 stars, a single maintainer, and no visible roadmap, which means little production evidence. Treat it as a fork candidate: read the source end to end, assign an internal owner, and keep a direct-API fallback. It should not be a single point of failure on a revenue-critical payment path.
- What are the alternatives if this wrapper is not maintained?
- You can fork and vendor the package, patch dependencies, and track bank or PayNet API changes internally. Alternatively, call your acquirer's DuitNow API directly behind your own PaymentGateway interface for full control. Either way, keep the abstraction so the transport can be swapped without touching domain code.