Pakasir Sdk Laravel Package

Product Decisions This Supports

• Build vs. buy for payment acceptance. If Pakasir is already (or is being considered as) your Indonesian payment provider, this package collapses a chunk of integration work — QRIS, nine Virtual Account rails, and PayPal behind one facade — into a single composer require. The decision it unblocks is which gateway to sign with, not whether to write your own HTTP client: the SDK is a thin, well-shaped wrapper, so the switching cost is mostly the commercial Pakasir contract, not code.
• Checkout scope for an MVP or v1. createPayment() returning a paymentUrl, paymentNumber (QRIS string or VA number), and totalPayment (amount + fee) covers the minimum viable checkout: generate a charge, redirect, show the code. That is enough to ship a paid pilot without a payments squad.
• Roadmap sequencing of payment methods. PaymentMethod is a backed enum with per-method fee rules (QRIS ~0.7–1%, VA flat Rp2,000–3,500, PayPal 1% min Rp3,000) and minimum-amount validation baked in. A PM can price and sequence rail rollout — launch QRIS-only in week one, add VA for B2B invoicing later — without re-planning engineering work, because enabling a rail is a config/UI change rather than a new integration.
• Fee and margin modelling. Fee logic being encoded in the SDK (rather than in a spreadsheet someone forgets to update) means your "who absorbs the fee" product decision — pass-through vs. absorbed — is expressed once and stays consistent across channels and surfaces.
• Fraud and reconciliation posture. verifyWebhook() validates schema, project slug, and expected amount, then makes a back-channel call to Pakasir to confirm the payment state. That is effectively a product decision to treat webhooks as untrusted hints rather than as source-of-truth events — a meaningful stance to be able to state explicitly to risk and finance. It also means your reconciliation flow needs a deliberate retry/fallback path for the case where Pakasir is unreachable at webhook time.
• Order lifecycle and downstream automation. Native TransactionCreated, PaymentCompleted, TransactionCanceled, and WebhookReceived events let fulfilment, provisioning, receipts, and analytics subscribe without bespoke glue. This is the difference between "we accept payments" and "payment triggers the product," and it directly affects how fast you can ship post-purchase flows (e.g. instant license issuance, WhatsApp/email receipts via the bundled PaymentLinkNotification).
• Operational ownership and support SLAs. Configurable timeout, retry attempts, retry delay, and logging map to a support-policy decision: how long a customer waits before we tell them "payment is pending," and what we can show an agent when they file a ticket. detailPayment() plus simulationPayment() (sandbox) also means QA and support can reproduce payment states without a live charge — a real reduction in release friction.
• Idempotency and duplicate-charge design. The API is keyed on a merchant-supplied orderId with an amount. That makes your order-ID scheme a payments-critical decision (retries, double-submits, cart re-entry), and the SDK's surface forces that conversation early — which is where most payment incidents originate.
• Market expansion gate. Because Pakasir is Indonesia-centric (QRIS, ATM Bersama, BNI/BRI/CIMB/Permata VAs), this package is a market-entry enabler for an Indonesian launch and a non-starter for a LatAm/EU-first roadmap. That is a strategic fit question, not a technical one.

When to Consider This Package

Adopt when all of the following hold:

• Indonesia is a primary market, and QRIS plus local bank VAs are the expected payment experience for your users.
• You are on Laravel 11–13 and PHP 8.3+, or can get there. This is a hard floor — v2.0.0 dropped PHP 8.1/8.2 and Laravel 10 entirely, so a legacy monolith on Laravel 10 cannot use it without a framework upgrade.
• Your payment volume and surface area are modest — a single product, one checkout, one currency. Below roughly the point where you'd want a dedicated payments service, a small SDK is the correct amount of machinery.
• You accept a low-adoption dependency. Four GitHub stars and zero dependents is the headline risk. The mitigation is that this package wraps a remote API you already depend on contractually — if the SDK is abandoned, you rewrite an HTTP client against Pakasir's documented endpoints, not your whole payments stack. That is a bounded, days-not-months exit, and it's the main reason this is defensible at all.
• MIT licensing matters to you. Permissive, forkable, no procurement escalation. If you need to patch a bug or vendor a fork, you can, today, without legal review.
• You want the Pakasir integration to be one person-week, not one person-quarter, and you're comfortable owning the operational layer (queues, idempotency keys, reconciliation jobs, dunning) yourself — the SDK does not provide those.

Look elsewhere when:

• You need a vendor with a support contract and an SLA. This is a single-maintainer community package with no commercial backing. Nobody is on call. If a payment flow breaks at 2am on a Saturday, your team fixes it, and you should say that out loud before committing.
• Compliance is in scope. No PCI scoping documentation, no SOC 2, no security review artefacts. If you're handling card data directly or answering to a regulated auditor, this is a conversation starter, not a solution. (Pakasir's hosted-page/QRIS model keeps you out of card-data scope, which helps — but confirm that with your compliance owner rather than assuming.)
• You need regional breadth. Stripe, Adyen, Xendit, Midtrans, or DOKU if you're multi-country, need card acquiring, subscriptions, or marketplace/split payouts. Pakasir's rail list is domestic and the SDK exposes no subscription, refund, or split-payment primitives — cancelPayment() on a pending bill is the extent of the reversal story.
• You require cryptographic webhook signatures. Pakasir webhooks have no signature scheme; this SDK compensates with a back-channel verification call. That is a reasonable control, but it is a workaround, and it makes every webhook a two-hop synchronous dependency. If your architecture demands signed, offline-verifiable events, pick a gateway that provides them.
• Your dependency policy blocks unproven packages. Zero dependents, low star count, and release-metadata inconsistencies (v1.0.1's changelog points at a v2.0.0...v1.0.1 comparison, and the recorded last-release date is ahead of today) are exactly the signals a strict supply-chain review flags. Some orgs will reject on that alone, and they're not wrong.
• You're building payments as a core competency — multi-PSP routing, cascading retries across acquirers, custom risk scoring. A single-gateway SDK is the wrong abstraction level; you want the raw API and your own orchestration layer.

How to Pitch It (Stakeholders)

For executives — one paragraph. We need to take payments in Indonesia, where QRIS and bank virtual accounts are table stakes. The fadhila36/pakasir-sdk is a free (MIT), type-safe Laravel wrapper around the Pakasir gateway that gives us QRIS, nine VA rails, and PayPal behind roughly a dozen lines of code, with automatic fee calculation, retry/timeout handling, and framework-native events and notifications. It is a fast, low-commitment path to a working checkout — we can demo a paid transaction in days, not a quarter. The trade-off is honest and bounded: it is a small, single-maintainer open-source project with essentially no adoption, and we would be early adopters. We mitigate that two ways — the code is permissively licensed and small enough that we can fork and maintain it ourselves if it goes stale, and more importantly the real dependency is our commercial relationship with Pakasir, not this wrapper. If the package dies, we lose the convenience layer, not the integration.

For engineering — the technical case. PHP 8.3+, Laravel 11–13, declare(strict_types=1), readonly DTOs on every response, a container-bound PakasirInterface for testability, PHPStan Level 8 green, Pest/PHPUnit CI across PHP 8.3–8.4 and Laravel 11–13. Response mapping is typed (TransactionCreateResponse, TransactionDetailResponse, WebhookPayload) so no array-key archaeology in controllers. Webhooks are handled properly: verifyWebhook() validates payload shape, project slug, and expected amount against our own database value, then re-queries Pakasir to confirm the state — this closes the spoofing hole that unsigned webhooks would otherwise leave open, and it's the single strongest argument for using this over hand-rolling. Timeout/retry/logging are config-driven rather than scattered through our code. Caveats to own explicitly: no refund primitive beyond cancelling a pending bill; no idempotency key beyond our orderId, so our order-number generation becomes a payments-critical invariant; verifyWebhook() adds a synchronous outbound call we must make resilient (queue it, alert on it); and we should pin the version and vendor or mirror the source given the low upstream activity.

The ask. Timebox a one-sprint spike: integrate in a sandbox project, model fees end-to-end, run the webhook path including the failure mode where Pakasir is unreachable, and confirm the PHP 8.3 / Laravel 11+ prerequisite against our actual stack. Decide on spike results — with a documented fallback to a direct HTTP client if the spike surfaces maintainer or API gaps. Do not adopt for a revenue-critical launch without a named internal owner for the dependency.