Pakasir Sdk Laravel Package

Technical Evaluation

Architecture fit

• Pakasir is an Indonesian aggregator (QRIS, multi-bank VA, PayPal). This package is a thin HTTP client with a service provider, facade, and PakasirInterface container binding — dependency-inversion friendly, which is the main thing we care about.
• It ships no migrations, no route registration, and no persistence. That is the right call (no schema coupling), but it means order state, idempotency, and reconciliation are entirely ours to build. Treat the SDK as a transport adapter, not a payments subsystem.
• Events (TransactionCreated, PaymentCompleted, WebhookReceived) and PaymentLinkNotification are convenience features. Dispatching them synchronously inside a webhook handler couples our callback latency to our own listener code — we should queue listeners and not rely on the default behavior.
• Recommended pattern: define our own PaymentGateway port and a PakasirAdapter that delegates to the SDK. Domain code must never import Fadhila36\Pakasir\*. Cost ~1 engineering day; buys provider-swap and version-pinning isolation.

Integration feasibility

• Install is trivial (composer require, publish config, two env vars). Time to first sandbox transaction is hours via simulationPayment().
• Hard floor: PHP 8.3+ and Laravel 11+. Anything on PHP 8.1/8.2 or Laravel 10 is blocked outright — confirm runtime parity across web, queue, and scheduler before committing.
• v2.0.0 is a breaking rewrite (readonly DTOs, dropped PHP 8.1/8.2, dropped Laravel 10). With 4 stars and 0 dependents there is no deprecation runway and no downstream ecosystem absorbing the churn. Assume further breaking majors.
• Money handling is a concern: signatures accept int|float, and fee estimates (QRIS 0.7–1%, VA Rp2,000–3,500, PayPal 1% min 3k) are hardcoded in the PaymentMethod enum. Float money plus a static vendor-side fee table is a correctness risk for displayed totals and margin math. Pass integers only, and own the fee/limit table in our own config or DB against the signed rate card.
• verifyWebhook() is a compensating control, not authentication. Pakasir does not sign webhooks, so the SDK makes a back-channel detailPayment call and compares the amount we supply. That is better than naive trust, but it turns an unauthenticated inbound endpoint into an outbound-call amplifier (cost, rate-limit, DoS surface) and makes callback correctness depend on provider API availability.
• API surface is five methods. No refunds, payouts, subscriptions, or settlement/reconciliation endpoints.

Technical risk (ranked)

1. Supply-chain / bus factor. Single maintainer, 4 stars, 0 dependents, README assets pointing at a zeative org while the composer namespace is Fadhila36 (rebrand churn), and the v1.0.1 release notes compare v2.0.0...v1.0.1 — a release-tooling anomaly that undermines confidence in the published changelog. Individually survivable; collectively a "do not take an unabstracted hard dependency" signal.
2. Availability coupling at webhook time. If Pakasir's API is slow or down when the webhook lands, verification throws. We must park the order as unverified, never as failed, and reconcile by polling.
3. Undocumented idempotency. createPayment retries (default 3, exponential delay) on what appears to be a non-idempotent POST. Duplicate or orphaned transactions are plausible under provider degradation.
4. Fee/minimum drift. Hardcoded tables go stale silently, producing wrong customer-facing totals.
5. Logging exposure. PAKASIR_LOGGING_ENABLED writes request/response payloads to Laravel logs; needs redaction, channel isolation, and retention limits.
6. Version claims to verify. "Laravel 13+ ready" with a CI matrix claim; validate independently against our pinned versions. Quality signals are otherwise good (PHPStan level 8, strict_types, Pest 4 / PHPUnit 12).

Key questions

• Does Pakasir now support signed webhooks, IP allowlists, or stable egress IPs? If yes, verification becomes a nice-to-have rather than the control.
• Does createPayment dedupe on orderId? What is returned on duplicate — the same transaction or an error? What is the ID reuse TTL?
• Is the fee table sourced from the API response or hardcoded constants? How are Pakasir rate changes communicated, and with what notice?
• Refunds and partial refunds: API, dashboard-only, or unsupported? What is the settlement/reconciliation data source and format?
• Provider rate limits, uptime SLA, sandbox parity, and named support escalation.
• Package governance: security disclosure policy, issue response time, committed support window for v2.x, authoritative changelog location.

Integration Approach

Stack fit

• Laravel-only by design (pulls illuminate components). Fits an existing Laravel 11/12 monolith or modular monolith; not portable to non-Laravel PHP services without a raw-HTTP fallback.
• Use the container binding (PakasirInterface) rather than the facade inside our adapter, so tests can bind a fake cleanly.
• Keep IDR amounts as integers at the boundary; do not let floats reach the SDK signatures.

Migration path

• Greenfield checkout in an IDR market: fastest credible path to QRIS + VA. Adopt behind the adapter from commit one.
• Existing gateway: run Pakasir in parallel behind a per-method config flag (e.g., QRIS via Pakasir, cards via incumbent). Do not migrate the order state machine — map Pakasir statuses into existing statuses.
• If the app is on Laravel 10 / PHP 8.1–8.2: this package cannot be adopted without a framework upgrade. Scope that as its own project, or implement raw HTTP for the interim and revisit later.

Compatibility

• Pin "fadhila36/pakasir-sdk": "2.0.*" with a committed composer.lock; treat minors as potentially breaking.
• Verify PHP 8.3 in build images, queue workers, and schedulers — mismatch fails at container build, not at test time.
• Indonesian-language README is appropriate for the target market; note it as onboarding friction for a non-Indonesian-speaking team.

Sequencing

1. Sandbox spike: createPayment for QRIS plus one VA, simulationPayment, and verifyWebhook against happy path, replayed payload, tampered amount, and wrong project slug. Exit criteria must include duplicate-orderId behavior and forced-timeout behavior.
2. Build the port + adapter + our own webhook controller (rate-limited, queued, idempotent on orderId + terminal-state guard).
3. Ship the reconciliation sweep (scheduled detailPayment over non-terminal orders) in the same release. This is day-one scope, not a follow-up.
4. Replace the enum fee constants with our own table sourced from the contract; alert on total mismatch versus provider response.
5. Staging with real rails in small amounts; validate webhook retry/duplicate-delivery semantics end to end.
6. Production canary: one payment method, one segment, low value cap. Watch success rate, verification-failure rate, and reconciliation catch-up volume.

Operational Impact

Maintenance

• Two ongoing surfaces: the vendor package (low bus factor, breaking majors, no downstream signal) and our adapter/reconciliation code (ours permanently). Budget ~0.1 FTE steady state for a single-method integration; more per additional method.
• Quarterly release review; any bump is a staging exercise, not a patch-and-ship.
• Pricing and method tables change inside the vendor package first — track Pakasir's rate card independently so a stale enum never drives a customer-facing total.

Support

• Upstream support is effectively one maintainer's GitHub issues with no community gravity. Plan for us to debug the HTTP layer ourselves: retain redacted request/response dumps for every call.
• Pakasir's commercial support (settlements, disputes, refunds) is a vendor-relationship question, not a package question — secure a named escalation path before launch.

Scaling

• Stateless client; per-transaction cost is one outbound call at charge time plus one at webhook verification. Throughput is bounded by Pakasir's limits and our worker pool, not by the SDK.
• Webhook verification doubles outbound volume and adds p95 latency to callback handling. Queue it so Pakasir's webhook timeout isn't consumed by our back-channel call, and so provider-side retries don't compound.
• Retries multiply volume during provider degradation: add a circuit breaker with jitter so a Pakasir outage doesn't become a queue stampede.
• The 30s default timeout is too long for an in-checkout request. Set ~5–10s and surface a pending state with async resolution.

Failure modes and required mitigations

• Provider API down at charge time → order exists, no payment record. Mark pending, retry async, expire on TTL; never drop silently.
• Webhook arrives but verification call fails → do not mark paid or failed; park as unverified, retry with backoff, reconcile by polling.
• Webhook lost entirely → the reconciliation sweep is the only backstop; without it, paid orders sit pending indefinitely.
• Duplicate webhook delivery or duplicate charge from a retried POST → idempotency key on our side plus an audit log of every status transition.
• Spoofed webhook flood → cheap pre-validation (project slug, order existence, amount) before any outbound call; per-IP and per-order rate limits; alert on verification-failure rate spikes.
• Log leakage → redact credentials and payload PII; disable PAKASIR_LOGGING_ENABLED in production by default or route to a restricted channel with short retention.
• Enum/fee drift → assert totals against the provider response and alert on mismatch.

Ramp-up

• Engineer: five methods with typed DTOs; ~half a day to a working sandbox checkout, 2–3 days to production-grade with adapter, hardened webhook, and reconciliation.
• Team: documentation is thin beyond docs/INTEGRATION.md; the verification model (why the double-check exists, what to do when it fails) needs an internal ADR — that is the piece most likely to be implemented wrong.
• Ops/Finance: needs a runbook for pending-payment reconciliation and settlement-to-order matching. The SDK provides none of this and it is not optional for a payment rail.

Recommendation Viable as a secondary IDR rail — QRIS and VA — behind a thin internal adapter, with reconciliation and webhook hardening in the first release and a documented fallback provider. Not viable as a sole, unabstracted dependency: single maintainer, zero dependents, unsigned webhooks, hardcoded fee tables, and a breaking-major cadence. Reassess toward primary-rail status only after we have a quarter of production data and confirmation on idempotency, refunds, and provider SLA.