A buy link is a URL, not a row

A merchant wants a link they can paste into a message, an invoice or a bio, that opens a checkout already filled in — the right product, the right option, the right quantity, a coupon applied, an affiliate credited. The obvious implementation is a row: mint it, store it, give it a short slug, count its clicks, let the merchant revoke it.

We already had a feature shaped exactly like that, for in-person selling. A counter code is a database row: minted, hashed at rest, expiring, revocable. It has to be, because it is a credential — it authorises a sale happening two feet away, and a credential you cannot revoke is a liability.

A buy link is the opposite kind of thing

It is a bookmark. A merchant pastes it into a newsletter that is delivered once and read for years, into a printed QR code, into a profile. Its whole value is that it keeps working.

A link backed by a row is a link that can be revoked from a screen the merchant has since forgotten — and one that dies silently in an email nobody can recall is worse than no link, because the merchant never learns it is dead.

So there is no table and no migration for the link itself. The link is its own record: everything it means is in the query string, resolved fresh on every click against the live product, the live coupon and the live affiliate. Nothing about it is stored, because there is nothing about it worth storing that is not already the product, the coupon or the affiliate.

The thing a row would buy — per-link click counts, a short slug, a dashboard — is a different feature with its own table. It is not built. When somebody wants it, it should be built as that, not smuggled in as “buy links, but persisted”.

The contested half: a bad parameter is ignored

The instinct is the opposite. Bad input should produce a clear error; that is close to a professional reflex. Here it must not.

A buy link exists to remove a step between a click and a sale. A link that can fail closed has negative value: the customer who followed it did nothing wrong, and landing them on a 400 because a coupon expired yesterday loses the sale the link was built to make. So every parameter is validated against what the product actually offers, and anything that no longer fits is dropped. An expired coupon arrives empty. A quantity past the field’s limit is clamped to it. A deleted variant is skipped and the rest of the link still works.

The load-bearing consequence, and the test that proves it: a link carrying a doomed coupon produces a checkout whose total is identical to no link at all. Not because a discount is quietly refused at the till — because the prefill runs the same coupon engine the checkout runs, so a code the link keeps is one the checkout would honour and a code it drops is one the checkout would have refused. The link suggests; the coupon engine still decides.