I have an existing Laravel e-commerce site where shipping methods are already implemented. However, selecting a shipping method from the cart/checkout UI incorrectly applies shipping charges in some scenarios because the server-side validation for the shipping method's `minimum_order_amount` is either missing or inconsistent. I need an experienced Laravel developer to audit and fix the logic so shipping cost / free-shipping rules are validated and applied correctly in all flows (add-to-cart, update-quantity, cart page, buy-now, checkout shipping selection). What’s broken / expected behavior * Each `ShippingMethod` has a `minimum_order_amount` and a `cost`. * If the checked cart subtotal for a cart group meets or exceeds the `minimum_order_amount`, shipping for that cart group should be free (shipping cost = 0). * If subtotal < minimum, shipping cost should be the shipping method's `cost`. * Currently: * Selecting a shipping method on the cart page sometimes applies shipping charge immediately without checking minimum. * Increasing/decreasing quantity, direct buy-now, or switching to checkout may leave old shipping charges in place (not revalidated). * AJAX endpoint used by the frontend may be missing or not validating server-side (Postman showed 404 in debugging). * Client-side checks exist but server must be authoritative — server currently inconsistent. Tech stack * Laravel (PHP) — existing codebase (CartManager, CartShipping, Cart model, ShippingMethod model) * Blade templates + jQuery (frontend) * MySQL (or current DB) * You will modify existing backend controllers, route(s), CartManager utilities, and frontend JS/Blade partials as needed. Files / areas to inspect & change (expected) * `app/Utils/CartManager.php` — ensure `get_shipping_cost`, `updateOrderSummaryShippingCost`, `getShippingCostSavedForFreeDelivery`, and new helpers like `isFreeShippingEligible`/`getRemainingAmountForFreeShipping` are consistent and authoritative. * Blade cart page(s) (cart list / cart-details) — ensure shipping options have `data-minimum_order_amount` and JS does client-side validation only for UX, and triggers a secure server endpoint. * `routes/web.php` — POST route for `/customer/set-shipping-method` (or match your existing routing scheme). * Controller (create or update): e.g. `CustomerShippingController::setShippingMethod(Request $request)` — must validate shipping method ID, compute cart group subtotal server-side, enforce `minimum_order_amount`, update or create `CartShipping` records and return JSON. * `resources/js` or Blade inline JS: call AJAX to `/customer/set-shipping-method` and handle responses; do not trust client validation for final cost. * Clear route/cache where necessary (`php artisan route:clear`, `cache:clear`). * Add/update tests or manual testing steps (optional but preferred). Deliverables 1. Fixes applied to the repository (clear patch/PR or zipped patch) — all changed files listed in PR description. 2. New or updated controller method for setting shipping method securely. 3. Route added/verified for `/customer/set-shipping-method` (or match existing route name) with CSRF and session handling. 4. CartManager improvements (if needed) so `get_shipping_cost()` and `updateOrderSummaryShippingCost()` compute shipping correctly for: * add-to-cart (single product buy-now flow) * cart quantity update * selecting shipping method on cart page (per group or all groups) * checkout page selection 5. Frontend JS/Blade update to call the endpoint and display correct messages (e.g., when minimum not reached). 6. Short QA checklist and manual test instructions (what to click / expected results). 7. (Optional) Unit test(s) or integration test(s) for shipping cost calculation. 8. Brief notes describing the bug root cause and what you changed. Acceptance criteria * When a shipping method is selected, the server endpoint validates the selected shipping method against the server-calculated checked-subtotal for that cart group. If subtotal >= minimum -> shipping cost = 0. Else -> shipping cost = method.cost. * Changing cart quantities and toggling checkboxes re-triggers validation (either via AJAX recalculation or on next page load) and results are consistent. * All flows described above (add-to-cart → buy-now, cart update quantity, checkout shipping selection) show correct shipping or free shipping immediately after action, and persisted in DB (`cart_shippings` or equivalent). * No 404 from AJAX when selecting shipping method. The route and CSRF must work in browser. * No broken Blade syntax or JS console errors. * Provide short test steps that confirm the fix. Desired developer skills * Laravel 8/9/10 experience, strong knowledge of middleware, session and request lifecycle. * Comfortable reading and modifying helpers / utility classes. * Experience with payments/shipping logic and multi-seller cart grouping is a plus. * Familiar with Blade and jQuery AJAX. * Good communication and concise PR notes. Estimated effort * Small-medium bugfix: ~4–10 hours (developer’s estimate). Please propose your estimated hours and availability. What I will provide * Access to a staging/dev branch (GitHub) or code archive. * DB dump / credentials for staging (on request). * Reproduction steps where the bug occurs. How to apply * Share a brief plan (2–3 steps) you will follow to fix and validate the issue. * Share one or two past Laravel bugfix examples (links or short descriptions). * Estimated hours and hourly rate or fixed price. * Earliest start date. Screening questions (include in application) 1. Have you previously fixed shipping/free-shipping minimum logic in a Laravel ecommerce project? Briefly describe. 2. How will you ensure the server is authoritative for shipping validation (one-sentence answer)? 3. Can you commit changes and provide a PR with descriptive commit messages?