Product store
Staff sell goods (coffee, equipment) to anyone — member or walk-in — through a reusable payment link and QR code per product, or record a sale taken at the desk. Store money is ordinary ledger money: it is in every revenue total, and the revenue report can split it out.
What & why
A gym already sells plans through Taikan, but a coffee or a shaker is not a plan: there is no subscription, no member requirement, and no period. The store gives each product a public page behind a QR code. The buyer types a name and a phone, picks a quantity, and pays on the org’s Cardcom page. The webhook settles the sale, and the buyer gets a short receipt link by WhatsApp (if the org has it connected) or SMS (if the org turned SMS on).
| Persona | Capability |
|---|---|
| Owner / admin | Create, edit, archive products. Print the QR code. Record desk sales (cash, Bit, transfer). Link sales to members. Refund. Resend a receipt. Turn on SMS receipts (Settings → Payments). |
| Coach / member | No staff access (products permission: owner and admin only). |
| Buyer (anyone) | Scan the QR code, pay, receive the receipt link. A signed-in buyer is pre-filled and linked to their membership. |
Decisions
- Reusable link, one page per checkout. The link (
/p/<token>) never expires while the product is active. Each “Pay” mints a new Cardcom page and a new pending sale; Cardcom pages are single-use. - Cardcom only. Settlement keys on the page id (
LowProfileId) the webhook echoes back. Other providers returnunsupported_provider(STORE_PROVIDERS). - Price includes VAT. The price is sent as the unit cost on the Cardcom document. VAT-exempt orgs get the terminal’s default document type — VAT handling is deferred.
- One product per payment, with a quantity (1–20,
MAX_PRODUCT_SALE_QUANTITY). - Member link: a signed-in buyer’s membership wins; otherwise the phone must match exactly one active member; otherwise the sale stays unlinked. Staff can link or unlink later.
- Charge-only pages. Store pages use Cardcom
ChargeOnly: no card token is stored for a walk-in. - No stock, no fulfilment.
- Tier:
product_store, Pro and Elite. Roles: owner and admin. - No feature flag. A new surface with no prior usage, gated by tier and provider. Changes to shared code (webhook settlement, Cardcom adapter, transaction list) are additive.
Receipts
The buyer gets FRONTEND_URL/r/<receiptToken> — 12 characters, so a Hebrew SMS with the org name fits in one segment. The link redirects to the Cardcom document once Taikan has it; before that it says the receipt is on its way.
Channel order: WhatsApp (system template taikan_payment_receipt, member notification preferences apply) → SMS (platform Micropay account, the org’s approved sender name) → none (recorded as receipt_error). A receipt is sent at most once automatically; staff can resend.
Status
Built end to end: API, web (staff and public), WhatsApp template, SMS adapter, reports split, tests. Not built: Spotter/MCP tools for the store, minisite store section, stock.
See behavior, data model, code map, QA plan.