Santechouse

A cashback ledger

The shop runs a cashback programme: customers earn on what they buy and spend it against later orders.

It’s built as a ledger. Every account carries a balance alongside its lifetime earned and redeemed totals, and every movement — earned, redeemed, adjusted — is an append-only entry referencing whatever caused it. The balance is a running total that can always be reconstructed from the entries beneath it, so any customer’s balance has a full history behind it.

Cashback is configured per product variant and per currency, so a supplier can set a different rate on a boiler than on a box of fittings, and set it independently in each currency the shop sells in.

Redemption is validated against both the account balance and the amount still owed on the order, and each write carries its inverse so a redemption applies as a single unit or not at all.

Earning is calculated on full item value: cashback spent on an order doesn’t reduce what that order earns. That keeps every total independent of the order redemptions happen in.

Multi-currency pricing

Prices are held in one base currency and derived for the others.

Each currency is configured independently and works one of two ways: rates pulled from an external source, or a rate pinned by hand when the shop wants a specific number held. A currency can be switched between the two at any point.

Applying rates recalculates prices across the catalogue in one pass. The workflow pauses at a confirmation step and waits for a shop manager to approve the run before anything is written, so repricing is something the shop triggers deliberately rather than something that happens on a schedule.

Invoices

Orders generate a PDF invoice on request.

Each invoice has its own sequential number, issued independently of the order number, and the generated PDF is stored against the order so asking for the same invoice twice doesn’t rebuild it. Company details — name, address, contact, logo, footer notes — live in a configuration record the shop edits in the admin, rather than being baked into the template.

The document is assembled from the order in full: line items with their brand, shipping and billing addresses with country codes resolved to real country names, shipping methods, subtotal, discounts and tax.

Phone and Telegram sign-in

Medusa authenticates on email and password. The customers here are plumbers and builders who identify by phone number.

So the backend has two custom auth providers. One is phone and password. The other is Telegram: sign-in verifies the token Telegram issues against their published signing keys, making the proof of identity cryptographic.

Both are implemented as providers inside the platform’s own auth abstraction, so sessions and customer records work exactly as the framework intends — only the proof of identity differs.