How to Sell Beats Online With a Cart That Works
For years, every beat on my store had one button: buy. It opened the licence selector, you picked one, and BeatStars took you to its checkout with that single beat loaded. It worked, and it was quietly losing sales. If a producer wanted two beats, he had to pay twice, because each button started a new purchase. Nobody does that. He buys one, says he will come back for the other, and does not come back.
So on 22 October I put a real cart on the site. Not a plugin: the store is a static site built with Astro, with no database and no admin panel of its own. It is the biggest change this store has had since I launched it, and this is how it works.
The problem with a buy button
A beat store is not a shop with a trolley. It is a catalogue where each item has six licence tiers, and the price changes with the tier, not with the quantity. That is why most producers never bothered with a cart: the platform gives you a link per beat and you send the buyer there.
The cost is invisible but real. Every extra checkout is another chance for the buyer to change his mind. He goes through a payment form twice, enters the same details twice, and gets two separate emails for two files. And if he wanted to compare a basic licence on one beat with a stems licence on another, the two purchases were completely independent.
What BeatStars gives you to work with
BeatStars does not publish a cart API, but the store front end uses one, and it is reachable. Three calls are enough:
- Create a cart with a new uuid. Each checkout gets a fresh one, so a buyer never inherits items from a previous visit.
- Add a line with the track id and the contract id of the licence chosen. The contract is what fixes the tier and the price, not the track alone.
- Ask for a share link. That URL, when the buyer opens it, copies the cart into his own browser and drops him on the BeatStars checkout with everything loaded.
The important part: payment and delivery stay on BeatStars. The site never touches a card, never stores a buyer, and never becomes a shop. It only builds the cart and hands it over, which is why the whole thing can live in a static page.
Keeping a static site static
The cart lives in the browser. It stores two things per line: which beat and which licence. Nothing else. Names, prices and contract ids are read from the site's own configuration every time the page loads, so a price change never leaves a stale number in a cart someone started last week.
The header counter, the add and remove buttons and the totals are plain JavaScript. There is no session, no login and no server of mine in the middle. The only moment the site talks to anybody is when the buyer presses checkout and the share link is built.
Two small details made a difference in testing. One licence per beat: the cart refuses to hold the same beat twice, because that is what the platform does and a buyer who tries it gets confused, not served. And when someone leaves for the checkout and comes back without paying, the cart is still there, restored from a copy saved just before leaving. That is the closest thing to an abandoned cart recovery you can build without an account system.
The discounts are the part nobody gets right
My licences carry the store's own offer: buy one basic and get two free, or three standard and get two free. BeatStars applies that once per cart, at checkout, on the cheapest lines. If the site shows a total of $65.90 and the checkout says $32.95, the buyer does not feel lucky, he feels tricked.
So the cart reproduces the rule and shows the same arithmetic before anyone leaves: what is free, what is still missing to unlock the next free line, and what the total will be. The ladder is visible while the cart is being filled instead of appearing as a surprise at the end. It also tells a buyer the truth, which is the only version of a discount that survives contact with a checkout page.
Why you probably won't build this yourself
This looks like a small feature and it is not. The site has no admin panel, no CMS and no plugins: every page is generated ahead of time and uploaded as plain HTML. A cart that only exists in the browser has to keep the total, the licence and the checkout in agreement without any server to arbitrate.
The store side is worse. BeatStars does not document a cart API, so the three calls behind it were found in its own front end and tested one by one. Each line needs the track id and the contract id of the licence, because the price lives in the contract, not in the beat. A licence that the store has disabled on one track makes the whole checkout fail, so the error has to come back with the name of the beat that broke it instead of a blank screen.
Then there is the part nobody sees: reproducing the discount ladder before the buyer leaves, so the total here and the total at checkout are the same number. BeatStars applies its free lines once per cart, on the cheapest ones. Get that wrong and the cart is not a feature, it is a complaint.
That is why most producers rent a platform instead of building one. And it is the reason this site runs on hosting that does not fall over: everything else is a static file, and the only moving part is the platform that takes the money.
The site underneath
None of this would survive a WordPress with fifteen plugins. The store is a static site: 430 pages built ahead of time, one stylesheet and a little JavaScript for the player and the cart. When a visitor lands, no database is asked for anything.
The audio follows the same idea: HE-AAC at 56 kbps instead of a 320 kbps MP3, with the index at the front of the file so playback can start before the beat is downloaded, and a cache header that keeps it on the visitor's machine for a year.
What a host has to do after that is small, but it has to do it well: serve files quickly, respect byte ranges and cache headers, include SSL and HTTP/2. This is the one this site runs on. If you want the same base under your store, that is the only piece you actually have to rent.
If you sell on another platform
This specific trick is BeatStars, because that is where my licences and my buyers are. The logic travels: any store that exposes a cart endpoint can be driven from a static site the same way. What does not travel is the shortcut. A cart is not a button that says add to cart; it is a price that matches, a licence that matches, and a checkout that opens with exactly what the buyer chose.
If you are still selling one beat per checkout, start with the catalogue and the licences, then build the cart. The full beat catalogue is here, and if you want to hear the kind of beat this store is built around, start with this boom bap instrumental.
Frequently asked questions
Do I need a developer to add a cart to my beat store?
For a static site, yes, some code. The calls are three mutations against the store's cart endpoint and the rest is browser state, but somebody has to write it and test every licence tier against the checkout total.
Does the cart work if the buyer changes his mind about the licence?
Yes. Each line carries its own licence, and it can be switched from the cart itself. The cart does not allow the same beat twice, so changing a licence replaces the line instead of adding a second one.
Where does the payment happen?
On BeatStars, always. The site only builds the cart and opens the checkout with it loaded. Cards, invoices, delivery and the licence PDF stay inside the platform.
Why not sell directly on the site?
Because then the site would need a payment processor, tax handling, invoices and a customer database. A static catalogue with a cart that hands off to the platform keeps the fast part fast and leaves the money part to the people who already do it legally.
