Ti Ext Payregister Laravel Package

Product Decisions This Supports

• Enhanced security for payment processing: The enforced Stripe webhook signing secret mitigates risks of webhook spoofing, replay attacks, or unauthorized event processing, aligning with compliance requirements (PCI DSS, GDPR) and reducing fraud exposure. Critical for high-value transactions, subscription services, or industries with strict security mandates (e.g., fintech, healthcare).
• Breadth of payment provider coverage (Stripe + Square): This release migrates the Square integration to the v47.0 SDK client API, replacing the legacy SquareClientBuilder and per-endpoint API class instantiation with the new SquareClient sub-client structure (payments, customers, cards, refunds). This means the package now serves as a multi-gateway payments layer—relevant for roadmap decisions around provider redundancy, geographic expansion, and merchant choice (Square is dominant in SMB/retail POS). Supports a "buy vs. build" decision where a single package handles both major gateways.
• Reduced operational overhead for payment infrastructure: By automatically rejecting unverified Stripe events and standardizing on the current Square SDK, the package eliminates manual validation logic and custom SDK-wrapping code, saving engineering time and reducing false positives in payment reconciliation across two providers. Supports roadmap goals for scalable, low-maintenance payment infrastructure.
• Future-proofing against provider API changes: The update reflects Stripe's shift toward stricter webhook security and\n Square's SDK evolution to the v47.0 sub-client model. Staying current keeps the package compatible with upcoming provider requirements and justifies a "buy vs. build" decision for teams prioritizing long-term maintainability over short-term customizations.
• Risk mitigation for async payment flows and amount handling: The Stripe webhook enforcement prevents malicious actors from triggering unintended actions (fake refunds, duplicate charges). Additionally, the release casts refund, order, and tip amounts to float before number_format, preventing deprecation warnings and type errors when Square returns string values—directly protecting financial accuracy and reconciliation integrity.
• Developer confidence in payment reliability: Explicit Stripe secret enforcement simplifies debugging by ensuring only legitimate events are processed, while the Square SDK migration and type-safety fix reduce runtime errors in production. Critical for teams relying on webhook-driven and SDK-driven workflows (inventory updates, subscription management, tipping/retail flows).

When to Consider This Package

Adopt if:

• You already use Stripe webhooks and need to enforce signing secrets to meet PCI DSS or internal security policies.
• You use Square (or plan to) and want a maintained wrapper aligned to the current v47.0 SDK, avoiding the legacy SquareClientBuilder deprecation path.
• Your payment flows depend on async processing (subscriptions, delayed refunds) and require tamper-proof event validation plus accurate amount formatting across providers.
• You're migrating to Stripe's latest API or Square's v47.0 SDK and want to avoid breaking changes related to webhook security or SDK structure.
• Your team lacks dedicated security expertise to manually validate Stripe webhooks or maintain Square SDK integrations, but still needs reliable event handling.
• You're using Laravel's queue system and want to prevent webhook failures or type errors from corrupting payment states (e.g., duplicate charges, misformatted refunds).
• Your compliance audits flag webhook security as a high-risk area, and you need a pre-configured solution.

Look elsewhere if:

• You don't use Stripe or Square webhooks/SDK (e.g., relying solely on server-side tokenization or real-time API calls to another provider).
• Your payment provider isn't supported (e.g., Mollie, PayPal, or Authorize.Net—these require alternative validation and are not covered by the new Square migration).
• You customize webhook or Square SDK logic extensively and need to bypass built-in validation or sub-client structure (e.g., for legacy integrations pinning pre-v47 SDKs).
• Your team can't configure webhook secrets in the Stripe dashboard or upgrade the Square SDK dependency (~47.0) due to access or platform constraints.
• You're in a highly regulated environment where manual review of all webhook events is mandatory (e.g., crypto, forex), and automatic rejection isn't acceptable.
• You prefer building custom validation or SDK wrapping (e.g., Laravel middleware) over leveraging the package's built-in security and provider abstractions.

How to Pitch It (Stakeholders)

For Executives: "This release hardens Stripe webhooks with signing secrets and modernizes our Square integration to the current v47.0 SDK. Together they eliminate the risk of fake payment events (fraud, double-charging, data corruption) and keep our Square flows—refunds, orders, tips—accurate and error-free by fixing amount formatting. This is a critical security and reliability upgrade—especially for subscription or high-value transactions—because it automatically rejects unauthorized events and removes runtime type errors. It aligns with PCI compliance and keeps us on both major gateways' current APIs, reducing exposure to webhook spoofing and SDK deprecation. For minimal engineering effort, we gain enterprise-grade security and provider flexibility—worth prioritizing in our next sprint."

For Engineering: *"This release makes two meaningful changes:

• Stripe webhook security: enforces signing secrets—a non-negotiable for PCI compliance. Events without a valid secret fail silently, preventing unintended actions and reducing false positives in payment logs and queue jobs.
• Square SDK migration to ~47.0: replaces the legacy SquareClientBuilder and per-endpoint API classes with the new SquareClient sub-client structure (payments, customers, cards, refunds), and casts refund/order/tip amounts to float before number_format to prevent deprecation warnings and type errors when Square returns strings.

Action Items:

1. Update Stripe settings: Copy the signing secret from the Stripe dashboard into Laravel's config (e.g., config/payments.php).
2. Bump the Square SDK dependency to ~47.0 and refactor any direct SquareClientBuilder/API-class calls to the new sub-client model.
3. Regression-test Square flows (refunds, orders, tips) with string-valued amounts to confirm formatting is correct.
4. Test webhook failures: Verify invalid Stripe events are rejected without crashing.
5. Monitor queue jobs to ensure no legitimate events are dropped due to misconfigured secrets or SDK changes.

Tradeoff: If you're using local testing tools (e.g., Stripe CLI) you'll need to mock the secret or use test mode; and if you pin the legacy Square SDK, plan the upgrade since the old builder is now unsupported by this package."*

For Security/Product: *"This change directly impacts our fraud prevention and payment accuracy:

• Stripe: only authenticated events trigger actions like refunds/chargebacks, subscription updates, and inventory deductions.
• Square: migration to the v47.0 sub-client SDK plus the amount-casting fix ensures refunds, orders, and tips are processed correctly—especially where Square returns numeric strings that previously triggered type errors.

Key Questions:

• Should we audit past webhook events for potential spoofing before enabling Stripe enforcement?
• How does rejecting Stripe webhooks affect our dispute resolution process?
• For Square, do we have test coverage on refund/tip amounts as strings, and are we ready for the v47.0 SDK dependency bump?
• Should we standardize validation across gateways, and is Square webhook signing on our roadmap?

UX Note: This is a backend-only change with no customer-facing impact, but it reduces risk for high-value transactions (enterprise plans, retail/tip flows) and is critical for trust."*