Products and prices
2 min readLast updated 16 September 2026 Read as plain text
Define what you sell once, attach as many prices to it as you need, and stop typing amounts into every payment you create.
Most businesses start by typing an amount into every payment they create. It works until the price changes, and then nobody can tell which customers are on the old one, because the old one exists only as a number typed into a hundred separate payments.
A catalogue fixes that by separating two things that are usually confused: what you sell, and what it costs.
The product is the thing. The price is a number attached to it
A gym membership is one product. Monthly at 50,000 and yearly at 500,000 are two prices on it. A course is one product; the early-bird price and the standard price are two prices on it.
Because the prices hang off one product, a customer can move between them without leaving the product, and your reporting still says how many people bought the course rather than how many bought each of four unrelated things.
Why this matters when the price changes
- Add a new price rather than editing the old one. Existing customers keep what they agreed to.
- The old price stays on the record, so a payment from March still explains itself in June.
- Nobody has to remember which amount was current when.
Checking out straight from a price
Once a price exists, a payment is created from it rather than from an amount you pass in. Your code stops carrying prices, which means your code stops being the thing that has to be changed when a price does.
Prices can also carry a stable alias, so your own systems can refer to "standard-monthly" rather than to an identifier that means nothing to a human.
One more use
Several prices can be sold together as a cart, and a set of prices can be published as an embeddable pricing table on your own site. Both of those come free once the catalogue exists, and neither is possible while your prices live as numbers typed into payments.