Shipping and tax
Shipping options are deterministic simulations, never carrier quotes. Tax can be calculated through Stripe Tax sandbox when explicitly enabled; the browser never supplies the authoritative tax amount.
Back to Work
01 / Custom Ecommerce
Project Carry
Concept / Engineering Project
A custom ecommerce concept designed around product configuration, bundle relationships and reliable transaction authority—from catalogue and inventory through checkout and payment boundaries.
Current record state
Portfolio-ready engineering and storefront evidence, with final live provider-browser acceptance still deferred.Production-rendered storefront evidence and documented engineering checks support the implemented concept. Live provider-browser acceptance and commercial outcomes are not claimed.
01 / Commerce context
The hard part starts after the product grid.
Project Carry is an independent concept for premium work-and-travel accessories. It explores how a commerce system can make reliable promises without presenting synthetic inventory, sandbox providers or concept photography as a real retail operation.
A standard storefront model was not enough for the intended product system. Products have selectable variants, bundles depend on real component relationships, and the customer-facing total must stay aligned with inventory, shipping, tax and payment authority.
The business problem is therefore one of coordinated decisions: each promise needs a named source of truth, a safe transition and a recovery path when the browser or a provider disagrees.
The system is organised around six authority questions
- 01
Which price can the customer rely on now?
- 02
Is stock visible, available or already reserved?
- 03
Which product combinations are actually valid?
- 04
Is a shipping or tax value current, simulated or stale?
- 05
Which system is allowed to recognise payment?
- 06
Can a retry or second tab create a duplicate effect?
02 / Product system
Configuration and bundles shape discovery.
Catalogue records own known options and approved demo prices. Bundle offers reference physical components instead of inventing an independent stock item, so merchandising and later reservation logic describe the same product model.
The intended shopping journey
- 01
Catalogue
- 02
Product detail
- 03
Sign in when required
- 04
Add to Bag
- 05
Bag
- 06
Checkout
- 07
Address, shipping & tax
- 08
Payment boundary
The cart is authenticated: anonymous visits to /cartand anonymous Add-to-Bag actions redirect to Clerk sign-in. Guest cart remains deferred. The latest normal-local review did not close the full manual authenticated Add-to-Bag through Checkout journey, so this sequence is not presented as newly accepted end to end.
03 / Transaction authority
Checkout coordinates promises; it does not manufacture certainty.
A persistent, versioned snapshot separates accepted checkout state from mutable browser and address-book state. Shipping is simulated, tax can use an opt-in provider sandbox, and inventory reservation begins only at payment preparation.
Decisions and trade-offs
A cart is not a reservation
Customers can compose a private cart without creating a promise against synthetic inventory. Reservation starts only when checkout reaches payment preparation.
Trade-off: Availability must be checked again later, so a cart cannot guarantee that stock will remain available.
Checkout is a versioned snapshot
Accepted merchandise, address, shipping and tax are persisted together. A changed cart invalidates stale checkout authority.
Trade-off: Revalidation adds state and recovery work, but prevents a browser draft from becoming the commercial source of truth.
A redirect is not payment proof
The internal attempt advances only after a verified webhook or provider retrieval reconciles the matching provider state.
Trade-off: The customer may briefly see processing or recovery feedback instead of an instant success claim.
04 / Evidence and limits
The implementation is tested; the commercial boundary stays visible.
The supplied verification record supports implemented storefront, domain and browser behaviour. It does not support production readiness, live-provider acceptance, business performance or operational claims.
Code quality
Format, lint and strict TypeScript passed.
Unit tests
65 files and 487 tests passed.
MongoDB integration
23 files passed, 2 skipped; 153 tests passed, 2 skipped. The skips are declared opt-in provider fixtures.
Public browser
32 of 32 Playwright checks passed.
Accessibility
Automated axe checks found no serious or critical violations on Home, Catalogue or product detail.
Responsive containment
Passed at 320, 360, 390, 430, 768, 1024, 1280, 1440 and 1600 CSS pixels.
Commerce journeys
Pixel cart and checkout passed; owner 8 of 8, authenticated evidence capture 6 of 6, and bounded public 8 of 8 passed.
Production boundary
The concept build and browser-secret scan passed.
Clerk owns credential and session security; Project Carry owns customer status and internal staff authorisation. Browser roles cannot promote staff access. The implementation also documents exact origins, restrictive CORS, nonce-based CSP, rate limits, minimized projections and redacted evidence.
Final live provider-browser acceptance remains deferred. Current evidence also does not close the latest full manual authenticated shopping journey. Order creation, inventory consumption, fulfilment, returns and refunds remain later-phase work.
What this project demonstrates
Translating customer promises into catalogue authority, product configuration, bundle relationships, inventory protection, persistent checkout, provider boundaries, concurrency controls, reconciliation, failure recovery and honest interface feedback. The storefront is the visible expression of that operating model—not the whole project.
Related service
Have a related business problem?
This record is transparent about its current evidence. Your project can begin with the problem you are trying to solve.