Palermo.

The browser submits intent. It cannot decide final prices, stock availability, payment success or administrator authority. Shared contracts define the application’s API boundary, while domain modules own business rules.

Checkout revalidates the active cart, current variant prices, promotion, saved addresses, delivery method and available stock in one transaction. It creates the order, pending payment attempt and short inventory reservations together.

A customer-scoped idempotency key allows an identical checkout request to replay safely. Conditional inventory writes and unique movement references guard against repeat effects, while batch release is restricted to an authorised administrator.

The modular monolith keeps these transactional boundaries in one application. Provider-specific behaviour sits behind adapters, so isolated tests can exercise business rules without calling mutable hosted services.

Supabase Auth owns password handling and verification. Palermo owns application sessions and account eligibility. Session tokens are stored as hashes; browser cookies use HttpOnly and SameSite protections, with Secure host-scoped cookies in production.

Protected requests recheck account eligibility and credential version. Administrator operations resolve active roles and explicit permissions from the database; a browser role, email convention or provider metadata cannot grant authority.

Administrator passkeys use WebAuthn verification with expected challenge, origin and relying-party checks, requiring user verification. They add a credential path within the same server-owned permission model.

Input validation, customer-scoped reads, safe error contracts and server-only provider access reinforce these boundaries. The release security review records its scope and limitations; these controls are not presented as a security certification.

Palermo uses Stripe test-mode PaymentIntents and Stripe Elements. Card data remains within Stripe-controlled fields. Missing server payment configuration fails closed rather than silently switching to a simulated gateway.

The webhook verifies the raw body through Stripe’s signature verifier. A successful event finalises payment, confirms the order, claims active reservations, decrements inventory balances and appends movements within an authoritative database transaction.

Duplicate successful events are idempotent. If success arrives after stock reservations expire, the transaction returns a retryable conflict without changing commerce state. An explicit payment retry can reactivate released or expired reservations when stock remains available, allowing a repeated verified webhook to finish safely.

This separation matters: placing an order, reserving stock and receiving payment are distinct steps. A browser return from checkout is not evidence that the payment completed.

The final release freeze records a successful Vercel Production deployment, HTTP smoke checks and applied repository migrations. Application data and runtime roles are separated between Preview and Production, and migration authority stays outside the application runtime.

The deployed system remains a controlled demonstration: synthetic customers and orders, Stripe test mode and internally simulated delivery. Supabase Auth is shared at the project level, a documented limitation of this environment.

Release work included regression checks, catalogue and UI repairs, browser QA, a security review and a frozen application baseline. The handover records the operational boundaries and known limitations instead of treating a successful deployment as proof of commercial readiness.

Retries are part of the domain. Idempotency has to span the request, payment attempt and stock effects. Preventing a duplicate button click covers only one entry point.

Recovery must preserve the same invariants as success. A late webhook cannot confirm an order against stock it no longer owns. Restoring a reservation needs a fresh availability check.

Test evidence needs a boundary. Database fixtures, browser tests and deployment smoke checks prove different things. Naming the exclusions makes the evidence useful when planning the next release.