Every number about money traces to a row.
Payments are an append-only ledger, refunds are capped by the database, and a mismatch raises an alert instead of correcting itself.
The expensive bugs are quiet disagreements.
Two places that were meant to agree, and did not. A refund total that drifted. A cached figure nobody compared to its source. Nothing crashed, so nothing was noticed.
Nothing edits a row that already exists.
A correction adds a row rather than changing one. The history of an order's money stays complete, so reconciliation is a read rather than an investigation.
Ledger
PaymentTransaction
newestStored column
From events
Orders
Every order carries its payment, fulfilment and refund history on one record.
| # | Date | Status | Customer | Revenue |
|---|---|---|---|---|
| 1 | 12 Mar | Paid |  Maya Okonkwo | $182.40 |
| 2 | 12 Mar | Refunded |  Leo Martins | $96.00 |
| 3 | 11 Mar | Paid |  Priya Shah | $248.10 |
| 4 | 11 Mar | Disputed |  Dana Feld | $74.00 |
Four things the database will not allow.
Refunds past the order total. Money going negative. A ledger currency that does not match the order. A refund request reaching two terminal states.
Last quarter is the same number today.
Each order keeps its total converted to your base currency as it was on the day of purchase, so reporting does not move when exchange rates do.
Payments against refunds
8 monthsA mismatch raises an alert instead of being rounded away.
Cached figures are checked against the rows behind them. Nothing self-corrects quietly — if a projection disagrees with its source, somebody finds out.
Four steps, four records.
Litestore never sits between you and the money. There is no platform balance to withdraw from.
Money in
- 1Checkout quotes discounts, shipping and taxone server pass
- 2Stripe captures into your own accountPaymentTransaction
- 3Stock moves for every lineStockMovement
- 4The order and its receipt are writtenOrder · EmailLog
A stored total is a promise nobody kept.
Where a figure has to be cached for speed, it is compared against its source and any gap becomes a row you can act on.
Stored against derived
A total column has to be updated by a job. When that misses, the screen is wrong and nobody knows.
Returns, reviews and payouts compute status from their own events, so there is nothing to keep up to date.
What ships with it.
kinds of task the store spots for you
block types to build any page from
and the storefront reorders itself
tests keeping the money right
tables, all yours to query
database — nothing to sync
Across 151 files
Run in CI on every change
One Prisma schema
Money, stock and customers
The guarantees are written down in the repository, and the database is what enforces them.
Corrections are new rows
Payment rows are never edited, so an order keeps its full payment history.
Stored goes stale
Status is worked out from the events behind it, so nothing has to be kept up to date.
Reporting from your own tables
Revenue and conversion are computed from the rows that fulfilled the orders.
Reconcile from the rows themselves.
Payments settle into your own Stripe account and the ledger is yours to query.