Laravel Sumsub Sdk Laravel Package

Product Decisions This Supports

• Build vs. buy for KYC/AML plumbing. This package is the "don't build" option for the integration layer only — applicant creation, document upload, verification status retrieval, and webhook ingestion for Sumsub. The real buy decision (Sumsub as verification vendor) is separate and unaffected by this package's adoption.
• Onboarding feature scope. Supports identity verification (KYC) and business verification (KYB) flows: company info, beneficiaries, shareholders, and the SHAREHOLDER_REGISTRY document subtype added in v2.2.6. Useful when scoping whether a release includes sole-trader onboarding only or full corporate entity verification.
• Re-verification and remediation roadmap. Applicant reset (v0.0.18+) and top-level info updates (v0.0.17+) map directly to product features like "update your details," periodic re-verification, and rejected-applicant retry flows.
• Compliance-driven UX decisions. Reject-label support and webhook event types determine the rejection messaging we can surface to users and the state machine we can drive from Sumsub events. Webhook PayloadDigest signature checking is a security control we would otherwise have to build and audit.
• Multi-jurisdiction and multi-tenant architecture. Per-jurisdiction API keys (v2.0.2) and secret key support (v2.2.0) inform whether we can serve multiple regions or entities from one deployment.
• Release/upgrade planning. Laravel 13 support (v2.3.1) keeps this viable across framework upgrades; the version cadence is frequent and mostly additive, which lowers the cost of staying current.
• Use cases: fintech and payments onboarding, marketplace seller vetting, crypto/regulated-product sign-up, payout and withdrawal gating, age or ID verification.

When to Consider This Package

Consider it when:

• The stack is Laravel (the package now spans through Laravel 13) and the verification vendor is already, or is likely to be, Sumsub.
• You need KYC/KYB live in weeks, not quarters, and the verification integration is not a differentiator.
• You value typed response objects and webhook signature verification over a hand-rolled HTTP client.
• You are willing to vendor or fork the package and own it: publishable config plus interface-to-class bindings mean it can be swapped or replaced without rewriting call sites.
• You can pin a version and wrap the SDK behind an internal interface of your own.

Look elsewhere when:

• The app is not Laravel, or you need an SDK for another runtime.
• You require vendor support, an SLA, security attestations, or a documented deprecation policy. One maintainer, one star, and zero dependent packages mean no community battle-testing and a bus factor of one.
• You need guaranteed coverage of the full Sumsub API surface. Releases read as incremental endpoint and field additions; validate the specific routes you need before committing.
• Onboarding documentation matters. The README's Usage section is effectively empty, so the real learning cost is reading source.
• Your compliance posture requires audit logging, idempotency, retry/backoff, and rate-limit handling you own regardless — the package does not remove that work.
• The alternative is a thin Laravel HTTP client against Sumsub's REST API. Given the small footprint here, that option is genuinely competitive.

How to Pitch It (Stakeholders)

To executives: This is a shortcut, not a commitment. It gives us a ready-made Laravel integration to Sumsub so we can ship identity and business verification without spending engineering time on API plumbing, webhook signature checks, and response modeling. Sumsub remains the vendor decision; this package is replaceable glue under an MIT license, so there is no lock-in and no contractual exposure. The honest caveat is maturity: one maintainer, negligible external adoption. That is a code-level risk we contain by forking it into our codebase, not a reason to block a pilot. Recommendation: adopt with containment for an MVP, not as an org-wide standard until we have run it in production for a release cycle.

To engineering: Service provider registration, publishable config with interface-to-class bindings, typed DTOs via laravel-object-mapper, and webhook PayloadDigest verification. The surface is thin and the swap path is clean — bind it behind our own verification interface so the SDK is an implementation detail. Expect to own tests around the specific endpoints and events we use, plus retries, idempotency, and rate-limit handling. Plan to vendor the code and track upstream releases manually rather than depending on timely fixes.