Voucher Laravel Package

Product Decisions This Supports

• Voucher validation feature scope: The package provides a structured validation engine for time-bound and location-bound voucher rules, alongside identity checks (signature, selfie, OTP, face match). PMs can use it to define redemption constraints without building custom validation logic.
• Build vs. buy: Adopt the package for standard voucher validation contracts instead of maintaining bespoke DTOs and validation flows. The 0.10.3 naming standardization signals a maturing contract system and reduces long-term maintenance cost.
• Roadmap alignment: The release aligns validation DTO names with the established *InstructionData convention. PMs should schedule an internal migration to the canonical names and track the deprecated shims (TimeValidationData, LocationValidationData) for eventual removal.
• Integration stability: Backward-compatible shims mean existing partner or internal integrations continue to work. This supports rollout decisions that avoid forced client-side changes in the current cycle.
• Developer experience and API consistency: Consistent naming improves readability of voucher contracts and lowers onboarding friction for engineering teams. This is a low-risk release that supports incremental platform hardening.

When to Consider This Package

Consider adoption when:

• You are building a Laravel/PHP application that needs reusable voucher validation rules (time windows, location constraints, signature/selfie/OTP/face-match checks).
• You want a standardized DTO contract system rather than ad hoc validation arrays or custom classes.
• You value backward compatibility during upgrades and can tolerate a pre-1.0 package that is still standardizing its public API.
• You plan to integrate multiple validation types and want a consistent naming convention across them.

Look elsewhere when:

• You are not on Laravel/PHP or need a framework-agnostic validation engine.
• Your validation requirements are highly bespoke and unlikely to map to the package’s instruction types.
• You cannot accept any deprecation cycle, even non-breaking shims, or require a stable 1.0+ API contract before adoption.
• You need vendor-supported SLAs or long-term enterprise support; assess the package’s maintenance cadence and community before committing.

How to Pitch It (Stakeholders)

To executives: This package gives us a reusable validation layer for voucher redemption and identity checks. The latest release is a naming cleanup with no breaking changes, meaning low migration risk. It reduces custom development effort and supports faster rollout of fraud-prevention and redemption controls. The deprecated shims give us time to migrate without disrupting existing integrations.

To engineering: Version 0.10.3 standardizes validation DTO names to the *InstructionData convention (TimeValidationInstructionData, LocationValidationInstructionData) and keeps the old classes as deprecated shims. No code changes are required today. Plan a cleanup ticket to migrate internal references to the canonical names and remove deprecated usage before the next major version. The release improves API consistency across all validation types and demonstrates active maintenance of the validation engine.

To product and partners: Existing integrations remain functional. We can adopt the new canonical names incrementally, with no customer-facing impact. This is a good moment to document the preferred DTO names in internal integration guides and set a deprecation review date.