Icreate Storefront

Icreate Storefront is a self-hosted local resale marketplace with offers, checkout and fulfillment, secured by password-free email, SMS and authenticator verification.

Comment

Inspiration

Icreate Storefront began as Icreate Gate, a password-free authentication project for small companies.

Passwords are reused, forgotten, stolen and expensive to support. I wanted to explore whether a small organization could operate its own understandable authentication system without storing user passwords or handing the entire identity process to a large identity platform.

Once Icreate Gate was working, a larger problem became clear: secure authentication is only useful when it protects something real.

I began building a storefront around the identity system. The idea developed into a local resale platform for one-of-a-kind and second-hand goods. A community store, market operator or local host could receive products from sellers, confirm that the products exist, list them online and coordinate pickup or delivery after a sale.

This model is especially relevant to community resale projects and independent second-hand markets in Vancouver. It connects a real local store or host with online inventory instead of creating another marketplace where products may be unavailable, falsely represented or sold somewhere else.

The result is Icreate Storefront: a self-hosted local commerce platform secured by Icreate Gate.

What it does

Icreate Storefront combines password-free identity, product listings, price negotiation, checkout and fulfillment in one system.

Password-free identity

Icreate Gate provides the security foundation.

First enrollment guides the user through three verification stages:

  1. A single-use code delivered by email
  2. A verification code delivered through Twilio Verify
  3. A code from a standard authenticator application

Gmail OAuth delivers branded verification emails without storing an email password. Twilio Verify handles telephone verification, and TOTP provides compatibility with standard authenticator applications.

After enrollment, the system stores encrypted user records, recognizes returning users and allows them to select two primary verification factors and one backup factor.

Temporary challenges expire automatically. Verification codes are single-use, Redis identifiers are keyed, authenticated sessions expire, and session tokens are stored as keyed digests rather than plaintext values.

The current build completes first enrollment and records the returning-user factor policy. Executing the complete saved two-factor login policy for returning users is identified honestly as the next implementation stage.

Local storefront

Visitors can browse and search one-of-a-kind products through a responsive public storefront.

Verified sellers and storefront operators can:

  • Create and manage product listings
  • Upload product images
  • Describe product condition
  • Set prices and inventory status
  • Choose local pickup, shipping or both
  • Record whether the seller or storefront physically controls the product
  • Review purchases, sales, inventory and private offers

The custody record is important. A host-operated second-hand store can receive a product before listing it, confirm possession and then control fulfillment after it sells. This makes the platform suitable for local consignment stores, community markets and independent resale hosts.

The same interface can also act as a lightweight browser-based sales counter. A market operator can display available inventory, help a customer select a product and direct the customer into the same checkout process.

It is not presented as a complete retail point-of-sale system because cash handling, receipt hardware, offline operation and advanced tax reporting would require additional work.

Offers and price negotiation

Sellers can allow private offers on individual products.

A buyer may submit a lower price, and the seller can:

  • Accept the offer
  • Reject it
  • Send a counteroffer

Offers remain private between the buyer and seller and can expire automatically. When an offer is accepted, the agreed price becomes part of the order process without changing the public listing price for everyone else.

Checkout and product reservations

The current demonstration uses Stripe-hosted Checkout in test mode.

Before creating a Checkout Session, the server reloads the product information rather than trusting a price supplied by the browser. One-of-a-kind products are temporarily reserved during checkout so that two buyers cannot complete the same purchase.

The product is marked sold only after the server receives and verifies the appropriate Stripe webhook. A browser redirect alone is not treated as proof of payment.

Each order records:

  • Customer total
  • Platform service fee
  • Seller amount
  • Shipping charge
  • Payment and fulfillment status

The initial business model uses no listing fee and a configurable platform commission when an item sells. The current default is 5% of the item price, excluding shipping.

This release records the commission in the server-side ledger, but it does not claim to automate third-party seller payouts. The current Stripe account receives the test payment.

A real multi-seller launch would require Stripe Connect onboarding, identity verification, payout reconciliation, refund handling and chargeback procedures.

Pickup, shipping and fulfillment

After payment, the order moves into a fulfillment workflow.

Depending on who controls the product, the responsible seller or storefront host can:

  • Prepare the product for local pickup
  • Arrange local delivery
  • Add shipment and tracking information
  • Update the fulfillment status
  • Record fulfillment deadlines

The buyer can then confirm that the product was received.

An administrative order queue gives the storefront operator a central view of paid orders, fulfillment responsibility and outstanding deadlines.

How we built it

The backend is written in Rust using Axum. Rust was selected for predictable behavior, strong type safety and explicit error handling.

Redis stores:

  • Temporary email and SMS challenges
  • Authenticator enrollment state
  • Encrypted persistent user records
  • Product and inventory state
  • Offers and counteroffers
  • Reservations
  • Authentication sessions
  • Order and fulfillment records

Temporary records use automatic expiration. Sensitive Redis values are encrypted and protected against tampering.

Session tokens are stored as keyed digests, and Redis identifiers are derived using keyed values rather than exposing raw personal identifiers directly in keys.

Gmail OAuth delivers email verification messages. Twilio Verify performs SMS delivery and code validation. Standard TOTP authenticator applications provide the third verification stage.

The storefront interface uses HTML, CSS and JavaScript. It is designed for desktop and mobile devices and presents one clear task at a time during authentication.

The commerce interface includes product browsing, seller inventory, offer management, purchases, sales, fulfillment controls and an administrative order queue.

Stripe-hosted Checkout is used so that raw card details are not collected by the application. Server-side price checks, temporary product reservations and signed webhook verification protect the order transition.

The project runs natively without requiring Docker. Setup documentation covers Linux, macOS and Windows, although Linux is the recommended server platform.

During development, OpenAI Codex powered by GPT-5.6 assisted with Rust integration, Redis state, provider debugging, security review, checkout logic, offer negotiation, fulfillment workflows, tests, documentation and interface refinement.

I directed the product, security requirements, business model and final engineering decisions.

Challenges we ran into

The first major challenge was making three independent verification systems feel like one understandable process.

Early versions exposed too many controls at once. The authentication interface was redesigned to present one clear stage at a time while still providing useful errors when Gmail, Twilio or authenticator enrollment failed.

Provider integration created additional challenges. Gmail OAuth required a secure authorization and token flow. Twilio errors required better diagnostics and consistent international telephone-number normalization.

Protecting Redis data also required more than simply hiding values. Temporary records needed expiration, verification codes needed single-use enforcement, persistent records required encryption, and session tokens needed to remain safe even if stored data was inspected.

The storefront introduced a different class of problems.

One-of-a-kind goods require inventory reservations because there may be only one physical product. The server also had to reload trusted product prices before checkout and wait for a verified Stripe webhook before marking an item sold.

Price negotiation required private offers, expiration, acceptance, rejection and counteroffers without exposing negotiations publicly or accidentally changing the listed price for every buyer.

Fulfillment was another major design challenge. A local resale marketplace must know who physically controls the item, who is responsible for pickup or shipping and when the buyer has actually received it.

The largest product decision was recognizing that trust could not be solved entirely through software. The strongest local model requires a participating storefront or host to possess and confirm the product before offering it for sale.

Preparing a safe public demonstration also required removing operational credentials while preserving usable configuration templates and setup instructions.

Accomplishments that we're proud of

Icreate Gate grew from separate authentication experiments into a working password-free identity foundation.

Email, SMS and authenticator enrollment now operate as one continuous flow. The system includes encrypted persistent records, returning-user recognition, keyed Redis identifiers, expiring sessions, single-use verification codes and stored primary and backup factor choices.

During the same project, that identity layer was extended into a functioning local storefront rather than ending at a simple authenticated success page.

The current demonstration includes:

  • Public product browsing and search
  • Seller product and inventory management
  • One-of-a-kind product reservations
  • Stripe-hosted test checkout
  • Signed webhook payment confirmation
  • Private offers and counteroffers
  • Seller or storefront custody tracking
  • Pickup and shipping workflows
  • Fulfillment deadlines
  • Buyer receipt confirmation
  • Purchases, sales, inventory and offer views
  • An administrative order queue
  • A configurable transaction commission ledger

I am also proud that the project distinguishes clearly between implemented behavior and planned production work. It does not claim that automatic seller payouts, complete account recovery or production security controls are finished when they are not.

What I learned

Authentication security and interface design cannot be separated. A technically secure system can still fail when users do not understand the next action.

I learned that provider integrations need strong diagnostics. Clear development errors made Gmail OAuth and Twilio problems much faster to identify without exposing private information to end users.

I also learned that secure checkout is not only a payment-page problem. The application must protect trusted pricing, inventory reservations, webhook processing, duplicate events and order-state transitions.

Building the offer system showed that commerce is a conversation as well as a transaction. Buyers and sellers need a controlled way to negotiate without exposing private discussions or creating inconsistent prices.

The fulfillment work revealed the importance of physical custody. In a second-hand marketplace, software cannot guarantee that an independently listed product exists or remains available. A local host or storefront that receives and controls the product can provide a stronger trust model.

Working with Codex powered by GPT-5.6 helped me move between product design, Rust implementation, security decisions, provider debugging, interface development and documentation without losing the direction of the project.

The project also taught me to separate a convincing demonstration from an unsafe production claim. Recording a seller amount in a ledger is not the same as operating a compliant payout system. A working test checkout is not the same as a production marketplace. Those distinctions matter.

What's next for Icreate Storefront

The immediate authentication work is to make returning login execute the saved two-factor policy and allow the selected backup factor to replace an unavailable primary factor.

Additional identity work includes:

  • Secure email replacement
  • Secure telephone replacement
  • Authenticator replacement
  • Logout and session revocation
  • Recovery codes
  • Administrator-assisted recovery
  • Account notifications
  • Account disable, export and deletion

The storefront requires further production work before handling real customer transactions:

  • Stripe Connect seller onboarding
  • Automated payout reconciliation
  • Refund and chargeback handling
  • Written seller and consignment agreements
  • Prohibited-goods and authenticity rules
  • Pickup, shipping, loss and damage policies
  • Returns and dispute procedures
  • Sales-tax and accounting review
  • Customer receipts
  • Audit logging
  • HTTPS and secure cookies
  • Per-IP and per-account rate limits
  • Monitoring and backups
  • Restore testing
  • Independent legal, accounting and security review

Future versions could allow local stores and community-market operators to deploy their own branded storefronts, manage consigned inventory and operate a connected online and in-person resale service.

The long-term goal is not merely another product-listing website. It is a safer connection between verified people, real local inventory and accountable fulfillment.

Built With

Share this project:

Updates