Document Signer Symfony Laravel Package

Product Decisions This Supports

• Build vs. buy for e-signature plumbing. This package is the "buy the plumbing" layer: provider abstraction, webhook routes, signature verification, and event translation. The decision it de-risks is "do we hand-roll DocuSign/ValidSign webhook handling?" — answer: no. That work is security-sensitive and commoditized; this is where we should spend license budget or integration time, not engineering weeks.
• Multi-provider e-signature strategy. The DocumentSignerManager driver pattern plus per-provider config means we can support more than one e-signature vendor behind one internal contract. That unlocks real product choices: ValidSign for EU/Netherlands compliance and eIDAS-style flows, DocuSign for global/enterprise customers, or per-customer vendor preference — without forking our codebase per vendor.
• Earlier shipping of signing features. RecipientRewriter / OverridingSignatureProvider lets QA, demos, and staging run real end-to-end signature flows while redirecting signers to internal addresses. That directly moves the date we can honestly say "signing works" in a non-production environment, which is usually the long pole in these projects.
• Roadmap coverage. Any feature needing a signature becomes cheaper to scope: customer onboarding/KYC packets, contract and SOW execution, HR offer letters, procurement and vendor agreements, consent forms. The marginal cost of the second such feature drops sharply once this is in place.
• Security and compliance sign-off. Per-provider webhook signature verification (ValidSignSignatureVerifier, DocuSignSignatureVerifier) plus a single DocumentSignerWebhookReceived event gives security reviewers a concrete, auditable boundary. That's a decision-enabler for regulated customers, not just an implementation detail.
• Document output quality as a product concern. The anchor_y_offset_pixels config (with documented positive/negative semantics, default 0) is a small but telling lever: field placement on anchor-based templates can be corrected per provider via config rather than code. It supports the decision to use anchor-based templates across varied document layouts rather than maintaining per-template coordinates.
• A platform-cost decision we must make explicitly. PHP 8.5+ is a hard floor. That is an infrastructure/roadmap commitment, not a footnote — it needs to be sequenced against our runtime upgrade and hosting support, and it will likely be the gating item in any adoption plan.

When to Consider This Package

Consider it when:

• We need e-signature in a PHP application and want verified webhooks and a single domain event rather than provider-specific glue in our controllers.
• We need, or plausibly will need, more than one e-signature provider — or want the option to switch without rewriting the integration.
• Our templates use anchor/field-based placement and we need a way to nudge field positions per provider without code changes.
• We need realistic non-production signing for QA and sales demos, with signers safely redirected.
• Our stack is Symfony, or we are willing to own a thin Laravel bridge (see caveat below).

Look elsewhere or defer when:

• Our application is Laravel and we expect a Laravel package. This release is a Symfony bundle. The Laravel story here is the underlying la-souris/document-signer-sdk plus provider packages — we would own the service provider, config publishing, and event/queue bridging ourselves. That is real, if modest, scope and should be priced into the estimate, not assumed away.
• We cannot move to PHP 8.5. Until the runtime upgrade lands, this is not adoptable regardless of merit.
• We have exactly one provider and a simple, synchronous flow. Direct SDK use is less machinery to maintain.
• We need vendor support, SLAs, or a long production track record. This is a v1.0.0 initial public release; the API surface is credible but unproven, and the package is a thin wrapper over an SDK that is itself at ^1.0. Early adopters should expect churn.
• We are unwilling to track multiple packages. Adoption means the bundle plus at least one provider package (la-souris/document-signer-validsign and/or la-souris/document-signer-docusign), with version alignment across all of them.

Recommended posture: low-risk pilot. Wire it into a single signing flow behind our own interface, keep vendor-specific types out of domain code, and revisit once the package has a few minor releases and the PHP 8.5 constraint is no longer novel.

How to Pitch It (Stakeholders)

For executives (one paragraph): E-signature is now a checkbox feature customers expect, and the expensive part is not the API call — it is securely confirming that a document was actually signed by the right person. This package supplies that verified path for two major vendors (ValidSign in the EU, DocuSign globally) behind one internal interface, so we can launch signing features sooner, support EU and US customers with the same codebase, and keep our vendor options open instead of locking in. It is open source and thin, so cost is mostly integration time, not license or platform spend. Three caveats to fund properly: it is a brand-new 1.0 release, it requires a PHP 8.5 runtime upgrade, and if our app is Laravel we will need to write and own a small adapter ourselves.

For engineering leads: A thin adapter over la-souris/document-signer-sdk ^1.0, not a framework of its own. You get a driver manager, per-provider config, verified webhook routes, a single DocumentSignerWebhookReceived event, human-readable event translation, and recipient overriding for non-production. The upside is that the security-critical verification logic is maintained upstream. The costs are an explicit PHP 8.5 floor, a multi-package dependency graph (bundle + SDK + one or both provider packages), and — on Laravel — the service provider, config, and event/queue glue we write and therefore own. Keep the SDK's types behind our own port so a 1.x breaking change is a one-file fix.

Ask: Approve a time-boxed pilot on one signing flow, contingent on the PHP 8.5 upgrade timeline, with a go/no-go review after two minor releases or one production flow, whichever comes first.