Xendit Php Laravel Package

Product Decisions This Supports

• Build vs. buy on payments integration. This package makes "buy the glue" the default: adopting it converts an internal "integrate 8+ payment method APIs" epic into a thin wrapper task. It is the deciding artifact in the classic build the payment plumbing ourselves vs. adopt the vendor SDK trade-off — the SDK wins on time-to-market, the wrapper you build around it wins on portability.
• Market expansion sequencing. Xendit's coverage is Southeast Asia (Indonesia, Philippines, Thailand, Malaysia, Vietnam) with the local rails that actually convert there: virtual accounts (BCA, BNI, Mandiri, Permata, BRI), e-wallets (OVO, DANA, LinkAja, ShopeePay, GCash, GrabPay), retail outlets (Alfamart, Indomaret), QRIS, cards. If SEA is on the roadmap, this package changes the "which market can we launch in next quarter" answer from a multi-month build to a config-and-credentials exercise. If SEA is not on the roadmap, this package is answering a question you didn't ask.
• Payment method coverage as a conversion lever. Virtual accounts and e-wallets are not "nice to have" in Indonesia — they are frequently the difference between a completed checkout and an abandoned cart. Supporting this package is a checkout conversion decision, not just an engineering convenience decision.
• New product lines, not just checkout. Distinct API surfaces in this package map to distinct roadmap items: Disbursement/Payout → marketplace seller payouts, refunds, cash-out wallets, gig-worker payouts; Recurring Payments → subscription billing and installment plans; Invoice → hosted payment links for sales-led or B2B flows with no frontend work; Balance → treasury and reconciliation dashboards; xenPlatforms → a full marketplace/platform model with sub-accounts and split payments. Each is a "should we build this capability" decision this package makes materially cheaper.
• PCI scope and compliance posture. Choosing the hosted Invoice/checkout and tokenization paths over raw card API calls is a compliance-scope decision (SAQ reduction), and the SDK's card abstractions make that path the path of least resistance. Worth an explicit PM call, because it affects audit cost and launch timing.
• Vendor concentration and exit cost. Committing to this SDK is a soft bet on Xendit's pricing, uptime, and geographic coverage. The PM decision is whether to (a) call the SDK directly throughout the codebase or (b) define an internal PaymentGateway interface and let this package be one implementation. Recommendation: (b), always — the SDK is MIT-licensed and replaceable, but only if you never let it leak into domain code.
• Roadmap hygiene. Active releases (latest 2025-05-29) mean new payment methods and API versions arrive without a rebuild. Budget a recurring "bump the SDK, re-run the payment regression suite" line item rather than a one-off integration ticket.

When to Consider This Package

Adopt when most of these are true:

• Your stack is PHP/Laravel and you want Composer-native integration rather than hand-rolling cURL/Guzzle clients against the REST docs.
• You operate in or are entering Southeast Asia, and local payment method coverage is a stated growth objective rather than a checkbox.
• You need more than checkout — payouts, subscriptions, or marketplace/sub-merchant flows are on the 2–4 quarter horizon.
• You want the vendor-maintained path. Official SDK, MIT license, recent releases — this is the low-drama choice relative to unofficial community wrappers that rot silently.
• You can absorb a small wrapper layer. Expect to write a Laravel service provider, config, and an abstraction interface yourself; there is no first-party Laravel package with facades and published config here.

Look elsewhere or reconsider when:

• Your market is US/EU/LATAM. Stripe, Adyen, or Paddle (for SaaS tax handling) will serve you better; Xendit's value is concentrated in SEA.
• You want batteries-included Laravel billing. There is no Laravel Cashier driver for Xendit. If you need subscription lifecycle, proration, dunning, and invoice PDFs handled by framework tooling, you are signing up to build that on top of the Recurring Payments API.
• Your volume is low and your flows are simple. Xendit's hosted Invoice/payment links need no SDK at all. Don't take a dependency you don't need.
• You need a vendor-neutral payments abstraction as a hard requirement (multi-PSP routing, A/B testing processors). Then evaluate it purely as one adapter behind your own interface, and weigh the maintenance against a generic HTTP client.
• You require enterprise-grade SDK assurance — published test coverage, SLA-backed support terms, semver guarantees, a security disclosure policy. Stars (192) are a poor signal for payment SDKs since most users never star them, but the absence of a public repo in this record means you should vet the actual repository, changelog, and issue responsiveness directly before committing.

How to Pitch It (Stakeholders)

For executives: This is a free, MIT-licensed, vendor-maintained SDK that collapses our Southeast Asia payments integration from a multi-month engineering project into a few weeks of wrapper work. It unlocks the payment methods that actually drive conversion in that region — virtual accounts, e-wallets, retail outlets, QR — and, more importantly, it also covers payouts, recurring billing, and marketplace sub-accounts. That means the same dependency serves three roadmap items: expansion, subscription monetization, and platform/seller payouts. The strategic risk is vendor concentration on Xendit for SEA, which we mitigate by keeping the SDK behind an internal interface so we can add or swap providers without a rewrite. Cost exposure is Xendit's transaction fees, not the software.

For engineering: It's a Composer package, PSR-4 autoloaded, thin REST client over Xendit's API — cards, virtual accounts, invoices, disbursements, recurring, payouts, e-wallets, balance, retail outlets, and xenPlatforms. There is no first-party Laravel service provider, so plan for a small integration layer: config, a singleton binding, and — non-negotiable — an internal PaymentGateway interface so the SDK is confined to one namespace and never leaks into domain or controller code. Treat it as a replaceable adapter, pin versions, subscribe to releases (active as of May 2025), and put a payment regression suite around the wrapper so SDK bumps are boring. Flag the card path for a PCI-scope review before anyone calls it directly; prefer the hosted/tokenized flows unless there's a specific reason not to.