Real Name Authentication Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy for identity verification. This package is an integration shim for real-name authentication (实名认证) — matching a legal name against an ID number, and potentially bank-card or phone-number "element" checks. It informs whether we build our own verification domain layer or buy a vendor SDK outright. At 0.0.1 it is a candidate adapter, not a compliance platform.
• Vendor-swap strategy. If the package abstracts multiple verification providers behind one interface, it supports a roadmap decision to keep provider selection a configuration concern rather than a code rewrite — valuable if we expect to renegotiate with, or fail over between, KYC vendors.
• Onboarding and compliance roadmap sequencing. Directly relevant to features gated on verified identity: marketplace seller onboarding, payout/withdrawal eligibility, age-gating, UGC or gaming registration in the China market, anti-fraud checks at signup.
• Where verification logic lives. A decision to delegate name/ID matching to a package versus owning the normalization, retry, and audit-trail logic in our own domain — the latter matters more for dispute handling and regulator requests than the API call itself.
• Not supported at this release: any decision about liveness detection, document capture UX, sanctions/PEP screening, or audit reporting. The 0.0.1 release notes contain no feature description, so scope must be confirmed by reading the source before it influences roadmap.

When to Consider This Package

Consider it when:

• You need Chinese-market real-name/ID verification and want a PHP-native abstraction instead of hand-rolling HTTP clients per provider.
• Your stack is Symfony, or you are willing to write a Laravel service provider and config bridge — the -bundle suffix and Tourze's publishing pattern indicate Symfony DI conventions, not a Laravel package with auto-discovery.
• You want a thin, replaceable seam in front of a vendor and can wrap it behind your own IdentityVerifier interface.
• You can run a timeboxed spike and pin the dependency exactly (0.0.1), accepting API churn.

Look elsewhere when:

• You need an audited vendor with an SLA, DPA, SOC 2/ISO evidence, and support escalation — this package is glue code; compliance accountability stays with the underlying provider.
• Your market is outside China. Stripe Identity, Persona, Onfido, or Jumio directly will be a shorter path.
• You expect a documented Laravel integration (published config, migrations, facades). None is evidenced at this release.
• You need liveness/biometric capture, document OCR, or a hosted verification UI — those are front-end and vendor-console concerns this package almost certainly does not cover.
• You cannot tolerate 0.0.x semver: no changelog, no tagged migration guide, and a maintainer org that publishes many small packages in bulk (low individual maintenance signal, unknown bus factor).

How to Pitch It (Stakeholders)

For executives: This is a small, low-cost integration component for verifying customer identity — the kind of check required before payouts, regulated content, or age-restricted signup. It is not a compliance vendor and carries no certification, SLA, or support contract. Recommendation: approve a 1–2 day technical spike only. Do not let it appear on a compliance roadmap until we have confirmed scope and chosen the underlying verification provider, who will carry the actual regulatory and data-protection obligations.

For engineering: Treat 0.0.1 as an unreviewed first tag — the release notes are an empty changelog link, so there is no documented API surface or feature list. Read the source before committing. It appears to follow Symfony bundle conventions, so plan on a Laravel service provider plus a config bridge, and pin the exact version. Wrap it behind an internal IdentityVerifier interface with contract tests so a provider or package swap is a one-file change. Confirm the license and check whether the repo is a read-only split from a monorepo before we depend on it.

Ask before adoption: scope confirmation from the README/source, license, and an explicit statement of which verification provider(s) it targets. Absent those, the decision is "spike, don't adopt."